RCWeb Tetris

Tetris is an early RCWeb asymmetric prototype that puts two independent Tetris boards on one shared display while phones act as dedicated controllers. It is less interesting as a full game than as a developer example of how early RCWeb apps handled joining, role assignment, and targeted controller updates using plain JavaScript messages.

Icon

Screenshot

The Prototype

The viewer renders two separate Tetris matrices side by side. The first connecting controller becomes Player 1, the second becomes Player 2, and each board runs its own arena, falling piece, score, and game-over flow. The mechanics are classic: move, rotate, hard drop, clear lines, and speed up through score progression.

As an RCWeb example, the main value of this app is that it shows how a display can reserve named roles instead of treating every phone as an identical participant. It is a small prototype, but it demonstrates one of the most common asymmetric patterns in RCWeb: the viewer decides who occupies each seat, then pushes targeted UI changes back to those controllers.

RCWeb Communications

Tetris uses an older raw-message approach rather than a later structured snapshot approach:

• The viewer app runs at /tetris/ and owns both player states.
• The controller app runs at /tetris-control/.
• The viewer redirects all non-viewer clients in the room to the controller app with rc.send(js, "!" + rc.client).

Joining is handled by the controllers themselves:

• Each controller generates its own numeric player id locally.
• While unassigned, the controller periodically sends rc.send("tetris.join(" + player + ");", "tetris").
• The viewer decides whether that id becomes red/player 1 or blue/player 2.

Once assigned, the viewer sends targeted UI commands back to controllers:

• controls.setTheme("red" | "blue" | "default")
• controls.setScore(score)

Those updates are targeted by embedding the assigned player id into the outbound JavaScript and sending it to the controller app. That means the controller app is partly a remote-rendered UI surface controlled by the viewer.

For a developer building a similar RCWeb app, this prototype demonstrates:

• role assignment on the viewer side
• controller-side retry-join polling
• viewer-to-controller targeted UI updates
• keeping game logic entirely on the display while controllers stay thin

Why It Matters

Tetris is a good reference when your RCWeb app needs fixed seats rather than open-ended drop-in entities. The flow is simple:

1. The display advertises a room-specific controller URL by QR code.
2. Controllers connect and repeatedly ask to join until assigned.
3. The viewer binds controller ids to roles.
4. Controllers send only actions such as moveLeft, moveRight, rotate, and hardDrop.
5. The viewer pushes role-specific theme and score updates back to those controllers.

Compared with later RCWeb apps, this prototype is more manual and string-driven, but that is exactly why it is useful. It shows the underlying communication model very clearly: RCWeb is just room-aware JavaScript dispatch, and even a simple two-seat arcade game can be built on top of that with very little machinery.

Launch RCWeb App