OpenRISK - A Peer-to-Peer Multiplayer Board Game

The game is technically not peer-to-peer—the server relays messages between clients. But it functions like peer-to-peer in that there is no authoritative game state on the server. All clients maintain their own state and must stay synchronized.

The communication layer is defined in multiplayer/playerEventSource.js:

export class PlayerEventSource{
    constructor(callback){
        this.callback = callback;
    }

    sendMessage(msg){}

    onPlayerLeftGame(id){
        return true;
    }
}

This is an interface: a callback fires when a message is received, and sendMessage broadcasts to all peers. The WebSocket implementation handles the actual network communication, including heartbeats to detect disconnections.

The key insight is that handleInput never directly modifies game state. Instead, it sends a command that gets delivered to all clients, including the one that sent it. Every client processes the same commands in the same order, so they stay in sync.

This also means there's no separate code path for "my actions" versus "other players' actions." Everything is a request.

Risk involves dice rolls. If each client generates its own random numbers, the game desyncs immediately—each player would see different combat results.

The solution is seeded random number generation. One client generates a seed and broadcasts it. All clients use that seed, so their "random" sequences are identical.

JavaScript's built-in Math.random() cannot be seeded. I used David Bau's seedrandom.js library instead.

Risk has distinct phases: placing units, attacking, fortifying. Many online implementations simplify this by letting players do everything at once. I wanted the real rules.

Each phase needs different input handling and rendering. I created a StageHandler interface:

export class StageHandler {
    static onPlayerEvent(event){}
    static handleInput(currPlayer, zone, mapView, game){}
    static select(){}
}

Looking back, I should have called this StateHandler=—I didn't realize I was building a state machine until later. The =select method initializes the state, handleInput processes clicks on territories, and onPlayerEvent handles incoming network messages.

Zone highlighting uses the same zone map, but extracting individual territory images took some thought.

First pass: for each zone color, find the bounding box (topmost, bottommost, leftmost, rightmost pixels).

Second pass: extract each zone's pixels into its own image, sized to its bounding box.

With these images cached, highlighting is just drawing a colored overlay. My first implementation didn't cache the images and was 200 times slower. Seeing that speedup after the rewrite was satisfying.