BunkerBattle
Playable 2026 Roblox prototype
A life-size Battleship-like game where the board is a place you physically move through — built by turning rules, playtests, telemetry, and failure states into one repeatable multiplayer system.
The published experience can be opened directly in Roblox. This capture shows the mobile placement flow, including the next-bunker prompt and the option to play against the computer prototype.
Play BunkerBattle on Roblox →- Category
- Multiplayer game systems & product prototyping
- Timeline
- Active 2026
- Status
- Published playable prototype
- Platform
- Roblox · mobile · desktop
- Role
- Product direction, systems design, testing, iteration
- Workflow
- GitHub · Rojo · AI-assisted development
The game
BunkerBattle started with a deliberately simple question: what happens if Battleship becomes a physical multiplayer space instead of a flat board? Each player occupies a court, hides a bunker layout, then moves through the arena to attack the opponent’s coordinates.
The interesting part quickly became everything around the obvious mechanic: how a court is claimed, how setup stays private, how players indicate readiness, what happens when someone stalls or leaves, how a turn communicates clearly on a phone, and how the arena returns to a usable state after a match.
Physical game loop
Players claim opposing courts, privately place a Battleship-style bunker roster, enter shared neutral ground when ready, cross into the opponent’s court on their turn, plant a bomb, and return through the match rhythm.
Match lifecycle
Claiming, setup, readiness, countdown, alternating turns, hit and miss resolution, victory, forfeit, cleanup, and repeat play are treated as one end-to-end product system rather than isolated mechanics.
Telemetry and persistence
Completed matches write structured records so play can be compared after the fact. The goal is to make iteration evidence-based instead of relying on memory from a playtest.
What real play changed
The prototype is shaped by play rather than by treating the first design as final. Early tests exposed readiness gaps, setup friction, timing questions, boundary behavior, and the difference between a rule that reads clearly in a document and one that a first-time player can understand while moving through the arena.
Three recorded live matches on August 31 produced 217 total turns with four timeouts. Those records also captured setup timing, hits, misses, court state, and friction events. That instrumentation turns each match into product evidence for the next iteration.
Computer opponent
A computer-participant path extends the same match system rather than creating a separate game. The prototype work covers legal bunker placement, targeting, movement, turn timing, ordinary hit and miss resolution, persistence, cleanup, and rematch behavior while preserving the human multiplayer path.
How I work on it
I direct the product behavior, rules, interaction model, priorities, acceptance criteria, playtests, and iteration. Development is managed in GitHub with documented decisions, test plans, provenance, and AI coding agents used as implementation partners. I stay responsible for what the game should do, what counts as correct, what survives a playtest, and what changes next.
Why it matters in the portfolio
BunkerBattle is useful evidence because it is not only a concept or a screen. It is a playable system that has to survive real players, mobile controls, timing, incomplete setup, state transitions, match persistence, and repeated changes. It makes the product and systems work visible.
The broader spatial-game lineage lives in RelicWorld, which documents the earlier iOS field prototype and the spatial interaction ideas that preceded the Roblox work.