---
title: Shared Simulation Code in a Mobile Multiplayer Browser Game
description: How decla.red used shared TypeScript game logic, WebSockets, client prediction, and spatial indexing for a team-based browser game.
date: 2026-05-07
projectPeriod: 'Autumn-Winter 2020'
thumbnail:
  src: ./_assets/decla-red.jpg
  alt: The decla.red browser game interface showing a space scene.
tags: ['games', 'web', 'systems']
selected: true
featuredOrder: 4
project: declared
role: Game and backend systems author
stack: ['TypeScript', 'Node.js', 'WebSockets', 'Firebase', 'WebGL']
scale: Multiple servers, each communicating with 16-32 clients
outcome: A mobile-capable online browser game built on top of SDF-2D
audience: technical
links:
  - label: Source
    type: source
    url: https://github.com/schmelczer/decla.red
  - label: Demo
    type: demo
    url: https://decla.red
  - label: BSc thesis
    type: thesis
    url: /media/downloads/sdf2d-andras-schmelczer.pdf
    download: true
media:
  - type: image
    src: ./_assets/decla-red.jpg
    alt: The decla.red browser game interface showing a space scene with team controls and planets.
    caption: decla.red used the SDF-2D renderer in a real-time multiplayer game.
---

`decla.red` was a conquest-style online multiplayer browser game set in space. Two teams fought over small planets, gained points based on control, and could shoot at the other team while moving through a ray-traced 2D scene.

The rendering made the game look interesting, but the architecture was the more useful lesson. The game needed to run on phones, talk to multiple servers, keep clients responsive, and avoid duplicating game rules between frontend and backend.

## The Problem

Real-time multiplayer games have an awkward split. The server should be authoritative, but the client has to feel immediate. If every meaningful interaction waits for a round trip, the game feels broken. If the client is trusted too much, the game becomes inconsistent or easy to abuse.

For this project, I wanted the same game rules to be used by the server and the client. The server would calculate the actual next state. The client could predict locally with the same code and later reconcile with the server.

## Constraints

The project used TypeScript on both sides: browser code for the client and Node.js for the server. WebSockets carried real-time updates. Firebase helped the servers reach consensus about the active server set.

Each server communicated with 16-32 clients. That is not large by industry standards, but it was enough to make careless spatial operations and state updates visible.

## Design

The key decision was a shared library for game logic. Both the client and server linked to it, so the transition rules lived in one place.

That reduced a common source of bugs: the client and server disagreeing about the meaning of an action. It also made client-side prediction more realistic, because the client was not approximating a different system.

As the game logic became heavier, spatial operations needed attention. I implemented k-d trees to reduce the cost of queries over objects in the world. For the object model, I borrowed ideas from message passing, including a version of the Smalltalk-style `messageNotUnderstood` pattern, to keep behavior extensible without pushing every entity into a brittle inheritance tree.

## What Worked

Sharing simulation code was the most important architecture choice. It let the project stay coherent as the client and server evolved.

The project also validated SDF-2D outside a toy environment. A rendering library is more convincing when it survives a game loop, input, network updates, and mobile constraints.

## What I Would Change

I would now spend more effort on observability for synchronization and prediction errors. Multiplayer systems need good visibility into divergence. Without that, debugging becomes a sequence of guesses.

I would also separate the story of rendering and networking more clearly in the codebase. Both were interesting, but they put different kinds of pressure on the architecture.
