Core Features
Independent Horde Physics
Each zombie moves and collides independently. Followers replay jumps at the same world position, so hazards can cost part of the horde without ending the run.
Procedural City Challenges
Distance-scaled roads, pits, mines, and obstacles create varied runs. Generated sections are checked against the game's movement limits.
Horde-Powered Vehicle Pushes
A large enough horde can push through cars, buses, and airplanes; smaller groups must jump over them or risk losing members.
Development Process
The Challenge
A game with dozens of visible followers can easily behave like a traditional single-character runner with decorative crowd sprites.
Using one shared hitbox would make losses feel arbitrary. Delayed follower inputs could cause rear zombies to fall even after a correct jump. Multiple collision callbacks could also damage zombies while a vehicle was already being destroyed.
Procedural generation introduced another problem: random combinations could become impossible unless the generator understood the same movement physics used during gameplay.
The Solution
- Spatial Input History: Jump presses and releases are stored as world positions. Each zombie consumes the command when it reaches the appropriate point.
- Independent Physics Bodies: Every zombie has an individual body, movement state, animation state, and collision result.
- Authoritative Horde State: The living-member registry is the single source of truth for HUD population, vehicle markers, push eligibility, scoring, and Game Over.
- Locked Vehicle Interactions: A successful grounded push immediately owns the obstacle interaction, preventing competing lethal collisions against the same vehicle.
- Validated Challenge Chunks: Authored patterns are checked against movement limits, landing widths, elevation constraints, and hazard spacing before use.
- Deterministic Automated Testing: Controlled browser scenarios reproduce difficult gameplay states reliably.
Testing & Quality Assurance
The final automated suite contains 115 Playwright tests.
Gameplay and Physics
Coverage includes complete gameplay flow, short and held jump timing, 20, 30, 60, and 120 FPS simulations, civilian conversion, horde growth, individual losses, pits, landmines, terrain collisions, vehicle thresholds and push locking, bus roof and airplane traversal, Flight controls and landing, and long-run entity cleanup.
Progression and Interface
Tests exercise pause and resume, Game Over, results, retry, save migration, missions, upgrades, responsive layouts, and a production browser smoke scenario.
Boundary Scenarios
Scenarios use horde sizes of 1, 5, 10, and 20, plus car, bus, and airplane requirements below, equal to, and above their respective 3, 8, and 16-zombie thresholds. Ninety repeated exact-threshold vehicle interactions cover low, medium, and maximum speed.
Key Technical Decisions
- Real Horde Bodies: Each zombie has a physics body instead of using one crowd collider.
- Spatial Input Replay: Followers replay jumps by world position instead of a fixed delay.
- One Living-Horde Count: HUD, obstacle requirements, scoring, and Game Over read authoritative horde state.
- Locked Collision Resolution: A successful obstacle push locks before later collision callbacks run.
- Physics-Validated Chunks: Procedural challenges are checked against live movement constraints.
- Capped Speed: Speed has a maximum while pattern complexity continues to increase.
- Formation-Safe Flight: Flight remains active until all surviving members land.
- Consistent Pixel Rendering: Generated pixel textures and bitmap text retain a cohesive visual style.
- Bounded Long Runs: Offscreen entities are removed, and debug instrumentation is excluded from production builds.
Key Takeaways
Building Zombie Horde strengthened my experience with 2D gameplay architecture, Phaser Arcade Physics, TypeScript game systems, collision ordering, state machines, crowd movement, procedural generation, level validation, responsive canvas interfaces, pixel-art tooling, persistent browser data, automated gameplay testing, and debugging intermittent physics behavior.
The most important lesson was ensuring that player-visible information always agrees with the gameplay source of truth. When the game displays “4 / 3 PUSH,” the collision system must guarantee a successful vehicle break.