Taking a 1993 strategy game apart to find out how it works
I keep borrowing mechanics from Ogre Battle: The March of the Black Queen for my own game design. But borrowing a mechanic you've only *felt* is guesswork. Could I reverse-engineer its systems properly — write them down as specs — and rebuild the first map to prove I actually understood them?
Marking every rule as confirmed, inferred or unknown changed the whole exercise. It forced me to admit how much of what I 'knew' about this game was inference, and playing the original on an emulator to check promptly proved several of my confident assumptions wrong. The real prize was a design insight I'd never have found by playing: the game doesn't punish you for being ruthless in combat. It taxes you for how you take territory.
Frozen at v1.0 — the first map, Lord versus Warren, fully playable end to end. Freezing was the point: this is a study project, not a product, and the deliverable is the specs. Private study only; the mechanics travel to my own game, the assets never leave the folder.
What this is, and what it isn't
Ogre Battle: The March of the Black Queen (SNES, Quest, 1993) does something almost nothing else does: you give orders on a real-time overworld, squads march, and when they collide the battle resolves itself while you watch. You don't control the fight. You control everything leading up to it.
I keep reaching for its ideas in my own design. So instead of reaching for them from memory, I took the machine apart.
This is private study, non-commercial. The output isn't a game — it's a set of specs, and a rebuilt first map to prove the specs are right. A spec you haven't implemented is a spec you haven't tested.
The rule that made it work: mark your confidence
Every single rule in the specs carries one of three marks:
- ✅ Confirmed — the source says so explicitly, with a citation
- 🟡 Inferred — deduced from the source or known behaviour, no direct quote
- 🔴 Unknown — the source doesn't cover it; approximated, and flagged in the code
This sounds like bookkeeping. It's the entire method.
The primary source is a 700,000-character community guide, and it's extraordinary on what happens and largely silent on formulas. Without the three marks, the silences quietly become assumptions, and assumptions become code that's confidently wrong. With them, the specs are honest about their own holes — and the holes become the to-do list.
Then I played it, and it corrected me
The specs went to v0.2 after I sat down with the original on an emulator. That pass rewrote several rules I'd been confident about:
- Unit deployment cost isn't charged per sortie. It's a daily expense at dawn.
- The day/night cycle runs about 4–5 real minutes, which nothing written down told me.
- The economy is concrete: 30,000 starting currency, dawn settles as balance plus tributes minus expenses.
- There's a boss gate I'd missed entirely — you can't fight the boss until you've liberated the towns.
Every one of those was marked 🟡 or 🔴 before, and every one would have shipped as a wrong rule if I'd trusted my memory of a game I've played for years. Verification isn't a formality at the end. It's where the actual knowledge arrives.
The design lesson I came for
Here's the thing I'd never have found by playing, only by writing it down.
The game runs three separate moral tracks that feed each other but never merge: alignment per character, charisma per character, and a single global reputation meter. And the global one — the one that gates recruits, items and the endings — doesn't move when you fight. It moves based on how you take territory: which unit you send to liberate a town, and the tarot card you draw when you do.
Which produces something genuinely elegant:
A squad of ruthless, low-alignment units is completely legal and often optimal in combat. The system never forbids power. It taxes it at the political moment — the instant you use that squad to occupy something.
My own game had collapsed all of that into a single escalation track. The lesson transfers directly: the global meter should respond to decisions of occupation and control, not to how hard you hit. That's now shaping the escalation system in my own prototype.
A cheaper lesson from the same teardown: a single global scalar — the time of day — changes how entire unit types read and behave, with no per-unit rules. One number, systemic consequences. That's the kind of economy worth stealing.
Building it
Vanilla HTML and JavaScript, no frameworks, same data / engine / UI split I use in my own prototype. The v1.0 slice covers the first map completely: real-time marching with terrain costs over an A* path, a continuous day/night clock, town liberation with the full 22-card tarot deck, the 2×5 formation grid with front-row blocking, automatic combat resolution, post-battle experience and alignment shifts, and the reputation meter responding to who you sent to liberate.
The unknowns are still marked in the code where the guide went quiet — the exact damage formulas, encounter probabilities, movement speeds per terrain. Those get approximated, labelled, and left honest rather than dressed up.
What I'm not publishing
The sprites and the guide text stay in the folder. They belong to Quest / Square Enix and to the guide's author, and this is a study project — the fact that I'm learning from something doesn't give me the right to redistribute it.
What travels out is the part that's mine: the specs, the formulas I derived, and the design lessons. That's the whole point of writing them down.