Local Multiplayer Prototype
Bullet Freeze
My couch-multiplayer elimination prototype for up to 8 local players, built around movement phases, forced freezes, target selection, and simultaneous projectile strikes.
I structured Bullet Freeze around simultaneous commitment. Players reposition during open movement, lock in targets during aim, and resolve every strike together. The result is a local multiplayer format built for clear reads, sudden reversals, and mutual-kill outcomes.
Core Breakdown
What Makes The Match Distinct
The match flow turns a chaotic party game into a sequence of clear commitments with simultaneous payoffs.
Gameplay Video
Gameplay In Motion
Gameplay footage showing the phase loop, target confirmation, and simultaneous strike resolution.
Bullet Freeze Gameplay
Open movement, frozen targeting, and simultaneous strike resolution.
Round Flow
How A Match Reads Moment To Moment
The round loop creates a simple rhythm: movement creates spacing, freeze creates tension, aiming creates commitment, and simultaneous resolution delivers the payoff.
Phase Diagram
Lobby
Players join and one player starts the match.
Running Around
Everybody repositions during the open phase.
Countdown
The game announces that movement freedom is ending.
Freeze
Players stop moving and the round shifts into targeting.
Aim
Alive players move target markers and confirm their choices.
Shoot
All confirmed strikes fire and eliminations resolve together.
Why Simultaneous Resolution Matters
Queued eliminations prevent the round from being decided by whichever projectile lands first. All outcomes resolve from committed choices, which preserves fairness and supports mutual kills.
Why The Phase Loop Stays Readable
Each phase gives players a single clear task. Running is about spacing, freeze is about timing, aim is about precision, and shoot is about consequences.
Architecture
Managers, Responsibilities, And Runtime Shape
I kept the current build in one gameplay scene. That keeps iteration fast and the runtime easy to follow, even if it also makes the scene wiring more tightly coupled.
Runtime Diagram
Input Devices
Gamepads / Keyboard
PlayerManager
GamePhaseManager
Player Slots
Aim Controllers
Projectile Strikes
Shared Camera
UI / Kill Feed
FX / Audio / Rumble
Input feeds player ownership
Managers drive the phase loop
Combat and presentation split after confirmation
Core Runtime Managers
- PlayerManager: join flow, roster, spawning, resets, alive state, and controller rumble.
- GamePhaseManager: lobby state plus the full round loop.
- ProjectileStrikeSystem: confirmed strikes, blast checks, and elimination timing.
- UIManager: timers, prompts, kill feed, and winner messaging.
- PartyCameraController: shared framing around surviving players.
Presentation Design
Presentation is divided by role: player controllers handle avatars and ragdolls, aim controllers handle target markers, UI handles prompts and end states, and the camera maintains shared-screen readability.
Technical Read
Strengths And Future Work
The current build emphasizes iteration speed, readable local play, and clear simultaneous resolution. Future work would focus on cleanup, input abstraction, and testing.
Current Strengths
- Simple one-scene runtime model.
- Fast iteration and easy mental model during prototype work.
- Strong local-play readability through shared camera and phased flow.
- Simultaneous strike resolution that supports mutual kills and dramatic outcomes.
Future Work
- Archive the legacy join / character-select path still present in the repo.
- Centralize input mapping instead of spreading it across direct polling sites.
- Separate gameplay state from presentation-side text and effects.
- Add tests for round flow, strike resolution, and edge-case outcomes.
- Make phase timing and rules more data-driven.