& Zombie GO Remastered
A turn-based puzzle game built from a one-week prototype into an IMGA-nominated title — designed, prototyped, and shipped by a team of four.
Playing Hitman GO sparked a question: how is this actually designed? Rather than just admiring it, I set myself a one-week deadline to prototype a single playable level in the same node-based style — not to copy it, but to understand it from the inside out.
Seven days later, I had a fully playable demo. I showed it to the team. They were in. What started as a personal learning exercise became Zombie GO — a game that would go on to be nominated for one of mobile gaming's most prestigious international awards.
We were four people. I wore most of the design hats: wrote the GDD, designed all 50+ puzzles, coded the node-placement system, handled lighting, and led optimization. One additional developer joined temporarily for specific technical sections.
Game Designer · GDD Author · Puzzle Designer · Node System Programmer · Lighting & VFX · Optimization Lead. The indie reality: if it needed doing, I figured it out.
Move between connected nodes, read enemy patterns, and reach the exit — without getting caught.
Stands fixed on a node. Threatens all adjacent nodes in its facing direction. Predictable — but unforgiving if ignored.
Fixed position, but rotates 180° with every player move. Forces the player to think in turns, not just space.
Moves along a fixed path, back and forth. Timing becomes critical — the player must predict where it will be, not where it is.
The stone-throw mechanic seemed simple on paper: distract an enemy, redirect them, create an opening. But combining it with three distinct enemy types created an emergent complexity problem. Each enemy type had to preserve its own behavioral logic after being lured to a new node — while still interacting correctly with every other enemy type on the board.
A Stationary enemy arriving at a new node should face its arrival direction. A Spinner should start spinning from that position. A Patrol should continue its path forward from the new node. Getting all three to behave consistently in every possible combination required careful systems thinking, not just scripting.
I approached it as a state machine problem: each enemy type carried its own behavioral state that was preserved independently of position. The stone throw triggered a move event, not a reset event — enemies arrived at the new node and immediately resumed their state from where they left off.
This meant playtesting every combination across dozens of scenarios to find edge cases. The result was a mechanic that felt intuitive to players — because the rules were consistent — even though the underlying logic was anything but simple to build.
We self-published without prior publishing experience — which limited our reach. But the players who found it, loved it: a perfect 5-star rating that still holds. The IMGA nomination came unexpectedly; submitted on a friend's suggestion, it became recognition that the design had reached a level worth noticing internationally. In 2023, we brought it to Steam — and the reception matched.
The mechanic-to-level ratio is off. With 50+ puzzles and a limited set of core mechanics, the experience becomes repetitive before the player has fully explored what the systems can do. I introduced mechanics at a pace that felt logical from a design document — but didn't hold up in extended play sessions.
If I were building it again, I'd design fewer levels per mechanic introduction and invest more in the combinatorial depth of the existing systems before adding new ones.
I've thought a lot about Zombie GO's future. The node-based structure has untapped potential for asymmetric PvP — one player setting traps, one player navigating. The systems are already halfway there.
I'd also add at least two new mechanic layers before expanding the puzzle count — giving players more vocabulary before asking them to solve harder sentences. The foundation is solid. It just needs more depth built on top of it.