DANIEL ARIAS // STARQUIXOTE

A playable XCOM-style demo in Godot, built without opening the editor

// The question

Two questions stacked on top of each other. Design: my tabletop universe needed a digital tactics demo, and I decided to borrow 97% of it from XCOM on purpose — grid, two actions, cover, line of sight, overwatch — so that the remaining 3% could be genuinely mine. Tooling: could an AI agent build that in a real game engine, Godot, without me ever having to open the editor to check its work?

// What I learned

The 97/3 split is a discipline, not a shortcut. When almost everything is a known quantity, every design conversation is about the 3% — in my case, a resource called Echo that lets you manipulate the structure of the turn itself. And the tooling answer is yes: everything in a Godot project is plain text, so the agent writes scenes and scripts, runs the engine headless, and proves the build works with automated tests and screenshots before I ever see it.

// Why it stopped here

Phase 1 is frozen: one mission, the full XCOM loop, 58 headless tests green. It stays frozen until I play it and tune the balance file myself — the AI currently opens with a brutal alpha strike, and no test suite can tell you whether that's *fun*. Phase 2, the Echo and the cards, only starts after that.

Why copy XCOM at all

My game universe, Escalation Protocol, already has one digital prototype exploring Ogre Battle-style army movement. This demo asks a different question at a different scale: what does a single squad engagement feel like?

Rather than invent a tactical system from scratch, I fixed the frame deliberately: 97% XCOM, 3% mine. Grid movement, two action points, directional cover, line of sight, hit percentages that fall off with distance, flanking criticals, overwatch — all of it borrowed openly, because it's a solved, well-understood machine. The 3% is the reason the demo exists: Echo, a resource you earn by capturing objectives and harvesting fallen enemies, spent on cards that bend the turn structure — extra actions, initiative shifts, rewinds, delays. If the demo proves anything, it should prove that, not my ability to reimplement cover mechanics.

The workflow: headless or it didn't happen

The build rule for this project: I only open the Godot editor to play. The agent does everything else, because a Godot project is entirely plain text — project.godot, scenes, GDScript — and the engine runs from the command line without a window.

So the loop looks like this: the agent writes code, runs the project headless, executes the test suite (58 tests green at the phase 1 freeze), renders verification screenshots from a demo mode, and only then tells me it's done. I get a build that is already proven to run before I spend any of my time on it.

Two architecture decisions make that possible:

  • Pure logic, separate view. All the rules live in scripts with no scene nodes, testable headless. The 3D presentation is one script on top. The tests exercise the game, not the graphics.
  • Rules as data. Balance lives in a JSON file; the mission map is ASCII art in another. I can rebalance the game or redraw the map in a text editor, without touching a line of code. That's my interface into the project.

What the machine can't tell me

The honest limit, and the reason phase 1 is frozen: the test suite proves the rules work, and proves nothing about whether the mission is any good. Right now the enemy AI — six against my four — concentrates fire on turn one, and I suspect that's oppressive rather than tense. But suspecting from reading code is exactly the kind of confident guess this log keeps teaching me to distrust.

So the next step in the pipeline is the one only I can do: play it, feel it, and edit the balance JSON. The Echo — the whole point — waits until the borrowed 97% actually feels like XCOM.

← Back to log