Brainrot Tower Defense

Brainrot Tower Defense is a cooperative game that runs inside a channel. Players create or join a lobby, place defenders, survive waves, unlock levels, and publish milestones that the surrounding workspace can observe.

Brainrot Tower Defense running a wave on a garden map with defenses placed along the route.
The visible game is a desktop surface, while durable state and specialist access use separate TAP surfaces.

Why It Was Made

This example tests a stronger claim than “miniapps can render React.” It shows that a miniapp can host a latency-sensitive Rust and WASM game, belong to a channel, coordinate ephemeral participants through presence, checkpoint durable progress, and expose a bounded read model to specialists through a package-runtime MCP tool.

Surface Map

SurfaceWhat this example declaresWhy it matters
UIchat-right, channel scope, one instance per channelEach channel can own a separate game session.
PersistencecheckpointThe host coordinates recoverable game state across realm changes.
Storagebrainrot-td, brainrot-td-progress, brainrot-td-commandsLive state, progression, and command handoff remain explicit.
Presencebrainrot-tdLobby participation is ephemeral and channel-bound.
EventsLobby, player, wave, level, unlock, and checkpoint milestonesOther TAP consumers can react without reading the game's private state.
Headless runtimeQuickJS MCP server and get_game_state toolApproved specialists can read a bounded state projection without controlling the game.
Authoritybrainrot-td.play and brainrot-td.read-statePlaying and observing are distinct grants.

The code uses sdk.authorization, sdk.storage, and sdk.mcp. Rendering and simulation code stays inside the package; TAP owns identity, authority, lifecycle, and the host boundaries.

Walk Through the Product

The channel begins with a lobby. That state belongs to the current channel rather than to the global app:

Brainrot Tower Defense channel lobby with controls for creating, joining, or watching a game.
Presence identifies active participants, while storage holds the durable game and progression model.

Once a level begins:

  1. Rust and WASM run the game simulation and rendering loop.
  2. The surface writes checkpointed state through package storage instead of treating the DOM as the source of truth.
  3. Presence communicates who is participating now, but it does not replace durable progression.
  4. Milestone events such as wave.started and level.completed leave the surface as declared event contracts.
  5. The QuickJS MCP server reads only its declared storage key pattern and exposes one typed get_game_state tool.
  6. A selected specialist needs the separate read-state grant before it can consume that server.

What to Read in the Code

Run It Locally

This example also requires Rust, the wasm32-unknown-unknown target, and wasm-pack 0.15.0.

pnpm --filter @tap-examples/brainrot-tower-defense dev

Link apps/brainrot-tower-defense/dist once. The AI Platform watches the desktop and QuickJS package graph together and uses the coordinated candidate handoff when a build changes.

Browse the source or return to the example gallery.