Fractured Soul

This is the fountain where all lost souls go to rest. Defend it from those who haven't been able to make it, maybe help them along when you can.

Shoot the enemies to solidify them, shoot them again to break them apart and release their soul. If an enemy makes it to the fountain, it grows dimmer; if you release a soul it grows. Enough enemies make it to the fountain, then the fountain crumbles. Survive.

The engineering problem

An enemy here is not shot-and-dead. It moves through phases — approaching, solidified, shattered, soul released — and each transition has to be legible to the player in the half-second they have to react, while staying correct if they shoot it twice in quick succession or if it reaches the fountain mid-transition.

The design leans on kintsugi, the Japanese art of repairing broken pottery with gold, which is a neat fit for Global Game Jam's Repair theme: mending a thing is the prerequisite for letting it go, so the sequence is the mechanic. Which means the lifecycle is not an implementation detail you can be sloppy about — it is the game.

How I approached it

Honestly: with a boolean. Solidified or not, flipped on the first hit and read on the second. It shipped, it worked for a 48-hour jam, and I would not build it that way again.

The reason is not tidiness. A boolean answers one question and the game kept asking others — what happens on a hit that lands during the shatter animation, what does a soul released off-screen do, what state is an enemy in the frame it reaches the fountain. Each of those becomes an extra flag or an extra if, and by the fifth one nobody can say with confidence what an enemy actually is at any given moment. What that wants is an explicit set of named states and the legal transitions between them, so the awkward cases are answerable instead of arguable.

That is a real lesson and I would rather write it down than dress the original up as something it wasn't.

What I'd bring to your project

The reason this is worth telling you: I have written the boolean version, so I know exactly what it costs and exactly when it stops being the right call. That is more useful to you than someone who has only ever read that state machines are good.

If your project has a bug that only happens sometimes, in a particular order, and nobody can reproduce it on demand — that is almost always an implicit state machine spread across a handful of flags. Finding those and naming them is a thing I have spent fifteen years being paid to do, in systems where the cost of getting it wrong is measured in support tickets rather than jam feedback.

Scope & role

Programming and production, on a team of five. Unity, with Photoshop and After Effects for art and effects. Global Game Jam, theme Repair.