Milestone 16 gives Project Nightfall its first hero. Not a finished hero — there’s no experience, no talents, no inventory yet — but the underlying architectural question of what a hero actually is, mechanically, once you strip away the levels and abilities. This milestone answers that question, and the answer shapes everything hero-related built afterward.
A hero is a unit, plus a note taped to it
The tempting approach is to make a hero a special kind of unit — a subclass with its own movement quirks, its own combat rules, its own selection logic. Project Nightfall deliberately avoids that. A hero here is an ordinary unit, the same one the movement, combat, selection, and order systems already know how to drive, paired with a small, separate piece of state that just keeps track of which unit currently represents that hero. Nothing about movement, combat, or selection had to change to make heroes work, because as far as those systems are concerned, a hero is indistinguishable from any other unit on the field.
That separation is also what makes death survivable in a meaningful way. When a hero’s unit dies, the unit itself is removed from play like any other casualty — but the small tracking record isn’t. It sticks around, empty-handed, remembering that this hero still exists and is waiting to come back. That persistent record is the resurrection state. This milestone ships only a bare-bones, no-cost placeholder for actually bringing a hero back, deliberately unpolished — the point here was proving the state survives death cleanly, not designing a real resurrection mechanic.
Training a hero without inventing a new queue
Heroes are trained at a building the same way ordinary units are, through the production queue system built in an earlier milestone. Rather than bolting on a parallel “hero queue” with its own rules, a hero is simply a special kind of entry in the existing queue, which means training automatically respects the same resource costs, timers, and technology-unlock gates every other unit already respects.
One deliberate wrinkle: the hero limit doesn’t just count heroes currently alive on the field. It also counts heroes still waiting in a training queue, and even a hero that’s dead and awaiting revival. That’s a conscious design decision — counting only living heroes would open a loophole where a player trains a replacement while their original hero is dead, then revives the original, ending up with more heroes than the limit allows. Counting every state a hero can be in closes that off entirely, and this check is enforced whenever a player tries to queue a new hero, not just noted as a future rule.
What this unlocks
None of this is a playable hero yet in the sense of experience gain or ability choices — those are separate, later pieces of work. What this milestone establishes is the foundation those pieces will attach to: a hero that moves, fights, gets selected, and can be trained using entirely ordinary systems, with just enough extra bookkeeping to know who it is and whether it’s currently alive. A small manual debug control was added purely so this death-and-revival behavior could be observed and verified by hand during this milestone — it’s a temporary testing aid, not part of the game itself, and is expected to be removed once real resurrection exists.