Greetings, Commanders.

In Fragile Allegiance there is a well-known tactic where you fire a dozen cheap missiles at an enemy colony. Most of them are only there to absorb the anti-missile fire, so that the real warheads behind them get through. It feels like an exploit, or something the designers did not intend. But this is exactly how the original game works, and it is one of the reasons people still play it thirty years later.

Details like this are the reason I design the remake the way I do. People sometimes ask how I'm rebuilding Fragile Allegiance, and the answer is that I don't have the source code. What I have is a decompilation project that analyzes the 1996 DOS version instruction by instruction and documents what it finds. I think that is even more useful. The decomp is my game design document.

The Original Is the Spec

This changes the design process. Instead of first asking "what would be fun?", I always start by asking "what does the original actually do?". Then, as a separate question, I ask "should I keep it?".

Every system in the remake is checked against this. The two random number streams that generate the universe. How asteroids are created. The ten ores and how they are distributed across the field. How mines extract them. When the decomp showed that the original's RNG behaves in a certain way, I reproduced the same behavior. The goal is that the asteroid belt you survey in the remake is statistically the same belt that K240 players remember.

The Faithfulness Policy

The rule I decided on is: the mechanics are faithful, the presentation is mine.

Faithful means the simulation layer. The universe generation, the ore economy, the life-support math and the missile logic. These are the physics of the game, and I try to port them as carefully as possible.

Mine means the interface. The original runs on a 640×480 DOS screen, and copying it directly would not work well on a modern monitor. So I redesigned it in the same spirit as the original: a fictional in-game operating system ("FMC OS") with a 90s terminal style, Orbitron and Rajdhani fonts, and gold on black.

When the two conflict, I choose the original. A lot of the strange things in the game are what make it good: missile-first strategies, sabotage agents, cheap missiles used to absorb anti-missile fire, and traders that are worth befriending because they sell specific items. That depth is why the game still has a following, and I don't want to remove it. If all of that is removed, what is left is a generic 4X game with the Fragile Allegiance name.

Decisions That Shaped the Code

Three technical decisions came directly from this approach:

  • Custom game clock. The original updated the whole world on its own rhythm. Unity's Update() is not really a game loop, so I built my own. It has a per-frame Tick() and a per-second TickPerSecond(), and the work is spread across frames with a time budget so a busy asteroid belt does not cause stutter. The game runs on game time instead of frame time, like it did in 1996.
  • ScriptableObject state machine. The player flow (colony view, asteroid field, build, launch) is a data-driven state machine. Adding a new screen means adding a new state asset instead of rewriting a controller.
  • HTN planner for the AI. The rival corporations plan what they do: colonize, attack, defend and patrol. They make decisions one game-second at a time, and the goal is that they only use the same information you have. I don't want the AI to cheat.

Lessons from the Decomp

Some things I have learned from working with the decomp during the last months:

  1. The original did not tell you everything about your economy. The life-support math for air, food, water and power had quirks that the manual never mentioned, and the decomp found them. Whether I keep a quirk is always a design decision. Some of them are balance and some are bugs. I kept the ones that make the game feel like Fragile Allegiance.
  2. Reverse engineering is slow work. Every claim in my design documents has a status: confirmed, hypothesis or "?". When new analysis shows that an old conclusion was wrong, I update the documents the same day. If you design on top of things that are only half true, the remake slowly turns into fan fiction.
  3. Playability can be better than in 1996. Range-select in the sidebar, hover fixes and a tutorial are not against the spirit of the original. I think they are things many of the original players would have wanted.

What's Next

Now that the faithfulness side is clear, the next posts will go back to the systems you will actually use. Probably a closer look at the economy that the decomp revealed, and how the roadmap priorities compare to what the original game really does.

Signing out,

  • Jari