Where the playable loop began
Zombie Citizen did not begin as a complete survival shooter. In October 2025, it was a collection of small systems that needed to become one readable, playable loop.
Our development records from that period show the team working across movement, combat, interface design, resources, weapons, progression, and visual feedback at the same time. None of those pieces could carry the experience alone. The challenge was making them work together so players could understand what was happening without needing an explanation from the team.
Making the player state readable
Some of the earliest completed work focused on the information surrounding the player. The team created and refined the health display, movement and interaction icons, weapon icons, a resource tracker, active power-up indicators, and the first heads-up display.
We were also exploring how to communicate infection, wounds, and changing player conditions. These were not merely decorative screens. They were part of the effort to make the game's systems visible enough that players could make decisions while a run was moving quickly.
Turning actions into a gameplay loop
At the same time, the underlying game started gaining the systems that would support repeatable runs. Movement speed and melee damage were adjusted. Level-ups and buffs were implemented. Enemies began dropping crafting materials. Weapon behaviour moved toward distinct gun types with their own statistics and crafted bonuses.
Ranged combat was also being rebuilt around projectiles for both the player and ranged enemies. That gave attacks a physical presence in the arena and created more room for timing, positioning, and weapon identity.
By themselves, these tasks looked small. Together, they established the first version of the loop we were aiming for: move through the arena, survive pressure, collect resources, improve your build, and keep going.
Building the interface alongside the mechanics
A recurring lesson from this stage was that a system is not finished when the code works. Players also need to recognize that the system exists, understand what changed, and know what action is available next.
That is why art, interface, and programming tasks progressed together. Level-up and crafting screens needed matching functionality. Weapon and resource icons needed to correspond to the actual systems. Damage and health feedback needed to remain understandable while enemies were active.
Many of the later playtest improvements can be traced back to this foundation. As more people played the game, we learned which parts of the interface communicated clearly and which assumptions only made sense to the development team.
What came next
This period was still early development, not the public alpha. It established the foundation that later supported the first arena, enemy spawning, escalating waves, mobile builds, the pre-alpha polish pass, and structured public playtesting.
We will continue sharing how those pieces came together—along with what we changed after watching people play.
