Zombie Mall Project Report
1. The Concept
Zombie Mall is a lightweight, mobile-first web survival game where the player controls one survivor inside tactical mall rooms, avoids zombies, manages noise/stamina/health, searches for items or keycards, and escapes through the exit. I chose this concept because it is more ambitious than a normal one-day utility app, but still small enough to test as a focused prototype. The core challenge was not building a huge RPG. The goal was to prove one tactical room at a time: movement, collision, enemies, objectives, fail states, and shareable results. The original idea started as a choice-based survival game, but during iteration it became clear that clicking choices was not enough. The game needed real player control, moving enemies, collision, timing, and visible consequences. That pushed the project toward a compact real-time tactical room game.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, and PNG game art assets. The project is built as a single-page web app with no framework and no build step. It runs directly in the browser or through a simple local Python HTTP server. The AI Assist: ChatGPT helped shape the early product direction, target audience, tone, level structure, and gameplay design. OpenAI Codex was then used for implementation, asset integration, debugging, layout fixes, and documentation. Generated raster image assets were used for room backgrounds, HUD elements, buttons, survivors, zombies, items, and tactical markers.
3. The 1 Day Sprint
Morning (Hours 1-3): We started with the survival concept and narrowed it down to a Khmer-first, mobile web MVP. The first version was more like a choice game: scenario, choice, outcome, share result. After reviewing the idea, we identified that the main risk was gameplay quality. If the player only clicked options, it would not feel like a real game. The direction changed to a tactical Zombie Mall room with movement, enemies, health, noise, stamina, and survival objectives. Afternoon (Hours 4-6): The coding phase focused on turning the prototype into a playable real-time room. We added character movement, collision, zombies moving on screen, attack timing, health bars, noise/stamina systems, map layout, item crates, alarms, exits, and action buttons. The project also expanded from one room into six levels with unlock progression, new room backgrounds, keycard objectives, zombie types, result screens, and share text. The Finish Line (Hour 7-8): The final hours were spent polishing the user experience. The biggest time sink was responsive layout. The home screen, gameplay action buttons, level select screen, and bottom browser/taskbar spacing all needed multiple passes. We also added more visual variety: three survivor sprites and five zombie variants so the game no longer looked like every human and zombie was the same. Finally, README documentation and this report were added.
4. The Roadblocks
Roadblocks: The biggest roadblock was responsive layout. The game uses large raster UI button assets, dramatic room backgrounds, HUD bars, action cards, and mobile-first positioning. On short desktop browser windows and phone-like viewports, buttons were repeatedly cut off or squeezed. Pixel-based fixes made the problem worse because browser chrome and taskbars changed the usable space. The layout eventually had to move toward percent-based sizing and more compact game rows. Another roadblock was visual consistency. The user specifically wanted real game artwork as PNG assets, not CSS shapes or canvas drawings. That made the game look more professional, but it also created extra work: generating assets, removing chroma-key backgrounds, cropping sprites, and wiring the correct art into the game logic. The third roadblock was scope creep. The project started as a simple survival loop, but quickly needed intro screens, level select, six levels, zombie types, background music, result screens, progression, share text, dynamic backgrounds, multiple survivor sprites, and multiple zombie sprites. Each improvement made the game better, but also introduced new layout and state-management problems.
5. Key Takeaways
What worked best? The core game loop became much stronger after moving away from choice-only gameplay. Real movement, collision, visible enemies, health/noise/stamina, and level objectives made the prototype feel like an actual game instead of a quiz. What worked worst? Responsive UI polish took much longer than expected. Large visual assets look good, but they are hard to fit across all device sizes. The bottom action area, home CTA buttons, and level select screen needed repeated revisions before they became readable and usable. The most important design lesson was that visual variety matters. If every zombie uses the same sprite, the game may have different enemy logic internally, but the player cannot feel it. Adding walker, runner, brute, listener, and crawler art made the gameplay clearer immediately.
My final thought: If I had one more day, I would split the single index.html into separate files, add a proper level editor data format, improve animation frames, and replace procedural audio with real music and sound effects. If I could redo the project, I would define the responsive layout system earlier before adding more features. The game became much stronger, but the UI would have been easier to control if the screen structure had been locked down first.