No Editor, By Design: The Art Pipeline of Agentic Game Development

Every time we show people our game project — a Rust + Bevy engine layer, Lua for gameplay, an AI agent doing the development, and Floniks generating the art — the first question is almost always the same one:

"Interesting. But… where's the editor?"

Honestly, we wavered on this too. For the last twenty years, "game engine" has meant a particular picture: scene tree on the left, viewport in the middle, inspector on the right, asset browser at the bottom. Unity looks like that. Godot looks like that. Unreal and Cocos look like that. Without that picture, do you even get to call yourself an engine?

It took actually shipping eight mini-games with an agent — with AI-generated sprites, backdrops, and UI art flowing in from Floniks over MCP — before the answer became obvious to us: for the way we build games, an editor would not be missing infrastructure. It would be a liability. "No editor" isn't our debt; it's our foundation.

This post is a reflection on why — and, more importantly, an inventory of what we equip art and visuals with instead. Every claim below is backed by a real file in the open-source repository, not a roadmap slide.

What an editor actually is

Strip away the nostalgia and a game editor is an I/O adapter: it connects human hands — mouse, drag, sliders — to scene data.

It optimizes for human input bandwidth. People can't picture position: (312.5, -87.0) in their heads, so they need to drag a thing and look at it. People can't memorize four thousand APIs, so they need an inspector that lays every property out in panels. People can't match colors by feel, so they need a picker. Every widget in an editor is a concession to human senses and muscles. For fifty years those concessions were exactly right — because the operator was always a person.

But the costs have been on the ledger all along; we just stopped seeing them:

1. Scene files are written for machines, not people. Binary or semi-readable .unity / .prefab / .tscn files produce unreadable diffs, merges that run on prayer, and code review that amounts to "open the editor and look."
2. Viewports lie. Editor lighting, import settings, and scaling never quite match the shipped build. "It looked fine in my editor" is an industry-wide punchline.
3. Consistency depends on discipline, not construction. The style guide lives in a wiki; three artists produce three different outline weights. An editor can constrain coordinates. It cannot constrain taste.

When the operator changes from a person to an agent, the ledger flips. An agent has no eyes or hands to accommodate — its native I/O is text. Giving an agent a GUI is like giving a fish a bicycle, and the three hidden costs above land precisely on an agent workflow's weakest points.

So our choice was simple: don't build an interface the agent can't use. Replace each of the editor's duties with an agent-native form.

What we equip art and visuals with instead

An editor has five core duties: define the style, manage assets, place content, tune parameters, and preview results. Here is what replaced each one.

1. Defining style: an executable style bible

In a traditional pipeline the art director's style guide is a PDF; two weeks later someone paraphrases it in an outsourcing email and the palette starts to drift. We wrote our style bible as code (tools/style_bible.py). Its header states the philosophy:

"A style bible's only job is to make every future asset look like it came from the same hand. The failure mode is drift… Encoding the locked tokens as data + a tiny assembler kills drift by construction — the shared DNA is literally the same string every time, and only the per-asset subject slot changes."

Palette, outline rules, camera angle, composition — all locked constants. Each asset fills in exactly one slot: its subject ("a cute shiny red apple with a small glossy green leaf"). Want to re-theme the whole game? Flip one palette switch and regenerate everything. Style consistency stops being artist discipline and becomes a program guarantee — something no editor can offer, because editors constrain coordinates, not aesthetics.

2. Managing assets: a declarative manifest

Art has source code here. One line in tools/floniks_manifest.json is the entire truth about one asset:

{"name": "gem", "w": 16, "h": 16, "bg": "alpha",
 "subject": "a cute glowing teal diamond gem, faceted, glossy"}

Name, exact pixel size, background-keying mode (transparent cutout / solid-blue keying / black-preserving glow / full-frame), subject description. An asset is not "the output of some generation run" — it is "a result that can be replayed from the manifest at any time." Lost a file? Re-run. Want the whole set at 2x resolution? Change w/h and re-run. This is Infrastructure-as-Code for game art.

3. Producing assets: the Floniks pipeline

The manifest's executor is an automated pipeline riding on Floniks, called over MCP:

style bible assembles the prompt → Floniks text-to-image
  → download → key out the backdrop (calibrated tolerance per mode)
  → resize to exact target pixels → drop into assets/textures/
  → emit an 8x nearest-neighbour preview for human spot-checks

Sequence frames go through a sheet slicer: generate a sprite sheet, cut it into walk_0.png … walk_7.png, and a ten-line Lua frame timer becomes the animation system. The pipeline's hard-won lessons live in code comments — which backdrop each model actually respects, which parameter shape each API wants — so the scars became part of the pipeline instead of part of someone's memory.

Beneath it all sits a safety net: pure-stdlib procedural generators produce a full set of placeholder assets with zero dependencies. The game is runnable at every moment. AI art is an upgrade, never a dependency.

4. Placing content and tuning parameters: contracts plus hot reload

The scene tree and the inspector are replaced by two things:

• Contracts. One page (ART_REQUESTS.md) declares that any asset dropped in with the same filename and pixel size goes live with zero code changes. Another page (PACK_SPEC.md) defines a complete game pack: a factory function, a self-registration table, the list of available textures, and the requirement to expose a DEBUG table so headless tests can drive the game. The menu builds itself from the registration table. Nothing, anywhere, requires clicking in a GUI.
• Hot reload. All placement and tuning is just numbers in Lua source — and Lua, textures, even the WGSL shader load through the engine's asset pipeline, so on desktop a save is instantly live. Want the apple to fall faster? Change the number, save, watch. The inspector's slider became "text plus second-level feedback" — fine for humans, and the only usable form for agents.

5. Previewing: the running game is the viewport

We have no editor viewport, because the preview window is the running game process itself — WYSIWYG in its final form. No import-settings mismatch, no editor-vs-build lighting gap; every frame you see is a frame players will see. And the runtime visual API keeps it expressive: tintable grayscale sprites (one texture, a whole family of colors), rotation, resizing, frame swapping, a full-screen WGSL aurora shader that literally reacts to gameplay — every game's screen-shake feedback also drives the background's energy — plus trauma-decay camera shake, four levels of haptics, and synthesized sound.

Acceptance doesn't rely on eyeballs either: a 677-line headless invariant suite drives every game for tens of thousands of frames and asserts the "game-feel contract" — no tunneling, no teleporting, speed caps, mandatory hit feedback. Editors let humans see. Tests let agents see.

Why this surpasses an editor

Put the five pieces together and you get capabilities an editor cannot offer in principle:

1. Art can be regenerated wholesale. Change one style token → replay the manifest → a fully consistent new art set within the hour. In an editor pipeline this is called "three weeks of rework."
2. Art can be code-reviewed. An art change PR is a manifest diff plus preview images — you can roll it back, blame it, and argue in comments about whether the outline got too thick. Binary scene files will never give you that.
3. Consistency is constructed, not requested. Same prompt DNA, same tolerance table, same pixelation pass. There is no "the new artist didn't know the rules."
4. Gameplay and art share one loop. One agent, one session: tweak the Lua, realize a new asset is needed, call Floniks, drop it in under the contract, hot-reload, run tests, commit. In a traditional pipeline that's two departments, an import step, and a meeting.
5. Conversation is the editor. "Make the apple redder, with a glossier highlight" — that sentence is a complete editing operation: the agent edits the manifest's subject, replays the pipeline, and hot reload shows you the result. Editors map intent onto mouse trajectories; we map it onto natural language. The ceiling of the latter is obviously higher.

And the honest cost: this flow assumes the operator is "one person plus an agent." A traditional artist or level designer who doesn't work through an agent has no obvious place to stand today, and level types that need hundreds of hand-placed objects don't have a comfortable tool yet (the likely answer — levels as data, agent-generated, invariant-tested — is on our roadmap, not in our repo). Fifty years of editor ergonomics are real. We're not saying editors were wrong; we're saying the thing they optimize — human hands — is no longer the bottleneck in our loop.

What we can output today

Not yet supported: skeletal (Spine-style) animation, particles, tilemaps. Each has a concrete plan where the "editor" is again data plus AIGC — a rig is an agent-writable JSON file with Floniks generating layered body parts; tilesets come off the style bible. The full comparison table against mainstream engines and the four-phase roadmap live in the repository docs.

Is it cross-platform?

Three layers, no hedging:

The asset layer: 100% portable, zero lock-in. Everything is PNG, WAV, TTF, WGSL, Lua, JSON — no proprietary scene format, no editor project file, no import database. WGSL compiles to Metal / Vulkan / DX12 / WebGPU. Decide to abandon our stack tomorrow and every asset walks away intact. That freedom is a side effect of having no editor.

The engine layer (Bevy): desktop on all three OSes, Android, iOS, and Web (WASM/WebGPU) are all supported upstream. The command-queue bridge between Lua and the engine is platform-agnostic.

What this project has wired up today: macOS for development (with hot reload) and iOS on simulator and physical devices — Metal, 120 Hz ProMotion, automatic signing, a TestFlight pipeline. One Rust crate builds both. Android and Web are packaging work on the roadmap, not architecture risk.

Questions you might be asking

Can I use this asset pipeline if my game isn't built on this stack?

Yes. The pattern — a style bible that locks prompt tokens, a manifest that declares each asset's name, size, and keying mode, and a script that generates through Floniks and post-processes to exact pixels — works for any engine that loads PNGs from a folder. The repository's tools are small Python files you can adapt in an afternoon.

Does generating assets spend credits?

Yes. Each generation call through Floniks costs credits according to the model used, and failed tasks are refunded automatically. An agent can call get_credit_balance before a batch run to confirm the budget covers it.

What happens when a generated asset doesn't match the style?

You re-roll cheaply. Because every asset is declared in the manifest, regenerating one — or the whole set — is replaying a recipe, not redoing work. The style bible keeps every attempt inside the same locked palette and composition rules, so drift doesn't accumulate across retries.

Do I have to write prompts by hand?

No. The style bible assembles the shared style DNA automatically and each asset only declares its subject. In an agent workflow, even the subject line is usually written by the agent from your one-sentence request.

The editor didn't die. It changed shape.

For fifty years, every advance in game tooling answered the same question: how does a creator's intent become pixels faster? Once the creator works alongside an agent, the shortest path no longer runs through a GUI. We didn't fail to build an editor in time — we spent that effort making "say it in one sentence" the shortest path.

Whether this is the right bet, the eight games in the repo, the sixty AI-generated assets in the tree, and an iPhone running it all at 120 Hz will keep answering for us.

Everything referenced here is verifiable in the open-source repo: maweis1981/rust_bevy_lua_game — see tools/style_bible.py, tools/floniks_manifest.json, tools/floniks_build.py, tools/PACK_SPEC.md, and docs/ for the full essay series. To plug Floniks into your own agent, start at the MCP developer guide.