Colin Michaels

Loading latest stories

Article

Crash Roboto: Lore, Tech Stack, and Sound Design

Go inside Crash Roboto, our browser-based robot arena game, including its lore, React and Phaser stack, gameplay, sound design, and open-source repo.

By Colin Michaels - Jul 22, 2026

crash-roboto-lore-code-sound-design-inline-01.webp

Inside Crash Roboto: The Lore, Code, and Sound Behind Our Robot Arena Game

TLDR

  • [Play Crash Roboto in your browser](https://colinmichaels.github.io/CrashRoboto/). It is free, and there is nothing to install.
  • [Fork Crash Roboto on GitHub](https://github.com/ColinMichaels/CrashRoboto) if you want to inspect the code, change the rules, add a robot, or turn it into something stranger.
  • We built it with an AI-assisted workflow using GPT-5.6 Sol and Codex, plus React, TypeScript, Vite, Phaser, Vitest, GitHub Actions, and GitHub Pages.
  • The lore is told through the game systems: pilots command competing power grids, Relays protect a central Core, and recovered Vault fragments bring lost machines back online.
  • Sound design is a continuing project. The game already has music, robot voices, recorded effects, and procedural fallbacks, but we are still refining the mix, stage cues, loop edits, and release-rights review.

At some point, a side project stops feeling like a folder full of code and starts yelling at you in a robot voice.

Crash Roboto crossed that line for me when I deployed VECTOR-9, heard the Commander acknowledge the order, watched the enemy grid answer with a Titan-0, and realized I was no longer testing components. I was trying to keep my Core alive.

That is when it became a game.

Crash Roboto is a fast, real-time robot arena strategy game that runs in a web browser. You pick a pilot, choose a battle protocol, build an eight-chip loadout, and send robots, Programs, and Installations into a fight against KERNEL-X.

The match may only last a few minutes. The project behind it took considerably longer than that.

**[Play Crash Roboto](https://colinmichaels.github.io/CrashRoboto/) · [View and fork the project on GitHub](https://github.com/ColinMichaels/CrashRoboto)**

What You Actually Do in Crash Roboto

The simple version is this: protect your network and crash the other one.

Each side starts with two Relays and a central Core. Your Relays defend the left and right lanes. Break an enemy Relay and that route opens deeper into enemy territory. Destroy the Core and the entire command network goes offline.

Before the battle, you choose exactly eight command chips. Four are available in your hand at a time, and playing one cycles the next chip into place. That creates a small but important tension: you can build the perfect loadout, but you still have to react to the order in which it comes online.

Your chips are divided into four families:

  • **Units** move and fight on their own, from the fast Bolt Hound to the structure-hunting Titan-0 and the repair-focused Patch Bot.
  • **Programs** ignore normal lane rules. EMP Flash disables systems, Nano Cloud creates a corrosive field, and Gravity Well pulls enemies into trouble.
  • **Installations** hold ground. Arc Sentry defends a lane, Microbot Foundry creates pressure waves, and Firewall Node reduces incoming damage.
  • **Commander** is the special slot. VECTOR-9 can trigger Overdrive and accelerate nearby allies when the moment is right.

You can also choose the weapon package for each Relay, spend Firmware on permanent loadout upgrades, unlock cards through Victory Caches, and play four different protocols ranging from the balanced three-minute Core Siege to the faster Relay Rush.

crash-roboto-lore-code-sound-design-inline-01.webp

The Lore Behind the Grid

Crash Roboto does not pause for a ten-minute cinematic explaining which robot emperor betrayed which robot parliament. I like lore, but I also like getting to the part where the robots hit each other.

Instead, the story is built into the language and rules.

The pilots—NOVA-7, AXIOM-3, VESPER-6, and RIFT-11—are command identities connected to surviving machine grids. Across the arena sits KERNEL-X, a hostile network running its own towers, machines, and tactics.

The Core is more than a castle. It is the thinking center of the grid. The Relays carry its reach into two lanes, and the Core's weapon remains dormant until one of those Relays falls. The system literally wakes up when it realizes the outer network has been breached.

That is also why the main objective is described as crashing the enemy Core. You are not conquering a kingdom. You are forcing a rival machine intelligence offline.

Progression widens the world. The Ascension Tower moves from the Foundry Grid through Toxic Conduit and Volcanic Depths, then climbs into Void Ascent and the alien Xeno Overgrowth. Each arena feels like another surviving layer of a much larger automated world.

The Vault cards carry another piece of the story. AEGIS-4, Wraith Coil, Scrap Viper, Gravity Well, and Firewall Node begin locked. Victory Caches recover fragments until those lost or restricted systems can be brought back online. Their powers feel appropriately experimental: barriers, phase movement, salvage repair, gravity manipulation, and damage-reduction fields.

The lore is intentionally incomplete. I would rather give players enough pieces to imagine what happened to this world than make them read a fictional database before their first match.

My version is that these grids have been fighting so long that combat has become protocol. Pilots do not ask whether another battle should happen. They choose which version of it to run.

Building a Game Where the Rules Stay in Charge

Crash Roboto was built with an AI-assisted development workflow using GPT-5.6 Sol and Codex. That let us move quickly, but “move quickly” is not the same as “press a button and receive a finished game.”

The hard part was not asking AI to draw a robot or write a React component. The hard part was making hundreds of small decisions agree with each other.

How much Charge should a Siege Rocket cost? Can a Core target across the bridge before a Relay falls? What happens if the timer ends with both grids tied? Does a replay with the same seed produce the same result? Can the lobby load quickly without forcing the browser to decode every arena and Vault asset up front?

Those decisions became the architecture:

  • **React 19** owns the Command Lobby, cards, HUD, progression screens, and other interface state.
  • **TypeScript 5** gives the game rules a strongly typed model for cards, towers, pilots, events, upgrades, and match snapshots.
  • **Phaser 4** renders the arena, moving robots, projectiles, impacts, effects, and three-quarter perspective sprites.
  • **Vite 7** builds and splits the application, including a deferred Phaser bundle so the lobby does not carry the entire arena engine on first load.
  • **Vitest** checks the deterministic simulation, deck rules, battle protocols, progression, audio routing, persistence, and presentation math.
  • **GitHub Actions and GitHub Pages** build and deploy the public browser version from the repository.

The most important separation is between the game simulation and what appears on screen. The match engine decides what happened. React and Phaser both read immutable snapshots of that state. Visual effects and sound respond to typed events, but they do not get to rewrite the result because a frame stuttered or a component re-rendered.

That makes the game easier to test and much easier to extend. It is also what lets a seeded match stay reproducible.

The production artwork follows a similar practical split. Editable PNG sources remain in the repository, while optimized WebP versions load in the game. Assets for the selected deck and arena are warmed first; optional Vault art and other boards can wait until the browser is idle.

crash-roboto-lore-code-sound-design-inline-02.webp

What AI Helped With—and What It Did Not Decide for Us

I think “vibe coded” is a useful description as long as it does not become a magic trick.

GPT-5.6 Sol and Codex helped inspect the project, turn ideas into working slices, refactor systems, create tests, trace bugs, organize assets, and keep documentation close to the code. That made it possible to explore a much larger game than I would have attempted in one pass.

But AI did not decide what Crash Roboto should feel like.

It did not know that the Core should remain dormant until a Relay falls, that a tie should trigger an eight-second Power Drain instead of a boring draw, or that the hand should rotate fairly through an eight-chip deck. Those are design choices. They only became good features after they were played, adjusted, broken, tested, and adjusted again.

That is the part of AI-assisted development I find most interesting. The tool can carry a lot of the construction work, but the person still has to recognize when the result is technically valid and emotionally flat. A game can pass every test and still not make you want to click “run it back.”

The Sound Design Is Still Growing

Sound has been one of the most satisfying parts of the project because it changes how every other system feels.

Crash Roboto currently ships with two lobby tracks and two battle tracks. Music and sound effects have separate volume and mute controls. Character acknowledgements, weapons, Programs, Installations, tower damage, destruction, match starts, round results, victory, and defeat all have dedicated routing.

The current repository includes 75 robot-voice files and 86 sound-effect files. Every playable card has its own short acknowledgement style, and the audio engine can pitch and soften enemy cues so the two sides do not collapse into one noisy pile.

We also kept a procedural sound palette as a fallback. If a recorded file has not decoded yet or fails to load, the event still makes a synthesized sound instead of disappearing. That matters in a game where audio is feedback, not decoration.

Some primary gun, laser, sentry, tower, and impact sounds were built from documented, independently licensed recordings. The rest of the generated delivery is still marked for review. Before treating it as a commercial release package, we need to finish the ownership, model-license, creative-similarity, and usage-rights checks.

There is creative work left too:

  • Produce tighter transitions from the lobby into battle.
  • Add stronger musical shifts for Relay War, Core Surge, and Power Drain.
  • Create final victory, defeat, and round-result stingers.
  • Make clean loop edits and keep lossless masters for future mixing.
  • Continue replacing generic effects with sounds that belong to a specific robot or ability.
  • Tune the mix so important warnings cut through without turning every fight into a blender full of modems.

The goal is not simply “more sounds.” The goal is for a player to hear that a Relay is in danger, recognize which machine just entered the arena, and feel the match escalate before reading the HUD.

You can follow the current implementation in the repository's [audio documentation](https://github.com/ColinMichaels/CrashRoboto/blob/master/docs/AUDIO.md) and the much longer [production checklist](https://github.com/ColinMichaels/CrashRoboto/blob/master/docs/AUDIO_PRODUCTION_CHECKLIST.md).

Why Put the Whole Project on GitHub?

Because Crash Roboto is more interesting as a starting point than as a locked box.

The repository includes the game rules, interface, renderer, art sources, optimized assets, audio routing, tests, extension notes, and deployment workflow. If someone wants to fork it and create a new robot, rebalance the Charge economy, build another arena, replace the soundtrack, or invent a completely different protocol, they can.

To run it locally:

git clone https://github.com/ColinMichaels/CrashRoboto.git
cd CrashRoboto
npm install
npm run dev

The project currently expects Node.js 20.19 or newer in the Node 20 line, or Node 22.12 and newer, plus npm 10 or newer. 

The repository's `npm run check` command runs type checking, the audio asset audit, the test suite, and a production build.

Start with the [Crash Roboto repository](https://github.com/ColinMichaels/CrashRoboto), then read the [architecture guide](https://github.com/ColinMichaels/CrashRoboto/blob/master/docs/ARCHITECTURE.md) and [extension notes](https://github.com/ColinMichaels/CrashRoboto/blob/master/docs/EXTENDING.md).

A Two-Match Challenge

If you play, try two matches instead of one.

For the first, use the balanced loadout and play carefully. Watch how opening a Relay changes where you can deploy.

For the second, choose a Rush or Siege preset and commit to the idea. Do not quietly drift back to balanced play the moment KERNEL-X sends something large down the bridge. That is not strategy. That is panic wearing a headset.

Then tell me which robot, sound, or mechanic felt the most alive—and which part still felt unfinished.

That feedback is useful because Crash Roboto is playable, but it is not frozen. The sound design is still growing. The balance can still move. New cards, arenas, modes, and lore can still find their way into the grid.

For now, the Core is online, the Relays are armed, and KERNEL-X is waiting.

**[Play Crash Roboto now](https://colinmichaels.github.io/CrashRoboto/) · [Fork it on GitHub](https://github.com/ColinMichaels/CrashRoboto)**