Seven steps. One prompt in, a living unit out.
Everything below is shipping today inside the DoctrineStrike editor. Follow the arrows.
One style governs the entire game
A single GraphicsStyleConfig defines the look of everything. Choose a Style ID — here “lowpoly2” (Synty POLYGON) — and every generation inherits a universal suffix plus per-role rules (building, vehicle, aircraft, infantry…). Authors only describe the subject; the engine assembles the rest.
- →Current Style ID — switch the whole game’s art direction in one field.
- →Universal suffix — appended to every prompt, so nothing drifts off-model.
- →Per-role prefixes — buildings, vehicles & co. each get framing + art rules.
Change the AI engine in one dropdown
Four pipeline stages — Text→Image, Image→Image, Image→Mesh, Text→Mesh — each point to an active backend asset. Today: GPT-Image-2 for images, Tripo for meshes. Replacing any stage with Magnific is a single selection. No code. No rebuild.
- →Active Text→Image — currently GPT-Image-2.
- →Active Image→Mesh — currently Tripo 3.1.
- →Each slot is a free choice — the perfect socket for Magnific.
Every backend is just a Unity asset
Each ComfyUI workflow lives as a ScriptableObject under Workflows/Generated — Gemini, Hunyuan, Meshy, GPT-Image, Tripo (3.0 / 3.1 / p1). The same config you’d wire in a ComfyUI graph, exposed in the editor. Adding a backend = dropping in one file. A Magnific workflow joins the shelf the same way.
- →Text-to-image, image-edit and image-to-mesh engines, side by side.
- →Open standard — new providers slot in without touching the game.
ComfyUI’s knobs, surfaced as clean fields
Whatever you would configure in a node graph is a tidy Unity field: resolution, negative prompt, model, quality, style, background. For fast iteration we run GPT-Image at low quality — ~1–4 credits, seconds per image — more than enough to lock a composition before any final pass.
- →1024 × 1024, model gpt-image-2, background auto.
- →Quality: low — cheap, instant iteration; quality is dialed up only for finals.
The same control for 3D generation
Mesh backends expose their own knobs — target polycount, texture resolution, PBR, model version, geometry/texture quality. Tripo here at 60k / 1024, PBR on. Swap to any other mesh engine without disturbing the rest of the pipeline.
- →Generate PBR + texture — production-ready materials, not grey blobs.
- →Per-backend logic already handles each engine’s quirks downstream.
Describe the subject. Press a button. Get a prefab.
Every art asset is a VisualData object: a clean subject prompt, a role preset (building / aircraft / vehicle / infantry → sets resolution & polycount), and three buttons — Regen Image, Regen Mesh from sprite, or both.
Behind them: generate sprite → white-mask → mesh via ComfyUI → GLB→FBX with PBR (per-backend logic) → prefab, auto-scaled to its class and auto-wired with the gameplay scripts it needs. Infantry even auto-rig in Blender, tuned per mesh backend.
Static art becomes a living, combat-wired unit
The Multipart Builder takes one unit and its sprite and splits it into working parts. A tank → body, tracks, turret (auto-aiming). An Apache → body, rotor (spinning), gun (tracking), missiles (firing). Templates per class — fully editable: add or remove parts, retune polycount, regenerate or edit any piece.
- →Image-to-image splits the master sprite into a clean part sheet.
- →Auto-aim, spin and fire scripts wired automatically per part.
- →The output isn’t a model — it’s a playable unit.