BubbleBet

category

GAMES

status

ACTIVE

year

2026

role

Product design + full-stack / game systems engineering

core technologies

PostgreSQL · Hetzner VPS · Cloudflare

tags

REALTIME · MULTIPLAYER · NETCODE · POSTGRES

links

Live demo ↗

Build a browser-based, real-time multiplayer arena where players grow through interaction, fight each other, and decide when to stop - while the economic state stays authoritative and consistent throughout.

1. R-01Runs in the browser, real-time
2. R-02Target of approximately 100 players per arena
3. R-03Players grow through arena interaction
4. R-04PvP interaction, including splitting
5. R-05Each player chooses between continuing to grow and cashing out
6. R-06Economic state remains authoritative and consistent

1. C-01
   Arena size
   100-player target per arena.
2. C-02
   Simulation rate
   60 Hz simulation target.
3. C-03
   Server authority
   Game state is server-authoritative.
4. C-04
   Untrusted client
   Financial / economic state cannot be trusted to the client.
5. C-05
   Lifecycle consistency
   Join, active play, elimination, respawn and cash-out must behave consistently across the game lifecycle.
6. C-06
   Verifiable randomness
   Random game outcomes must be independently verifiable.
7. C-07
   Responsive under authority
   The game must remain responsive while maintaining authoritative server-side accounting.
8. C-08
   Arena economy
   Players enter with a 500 BUB buy-in and a playable starting mass of 300 BUB. Taxation and mathematically / RNG-controlled food generation govern value in the arena instead of treating food as free inflation, and player activity, deaths and respawns feed back into the available economy.
9. C-09 open
   Reconnect / disconnect
   pending Exact disconnect and reconnect rules.
10. C-10 open
    Scaling beyond one arena
    pending Strategy beyond a single arena / server.

1. P-01 Responsiveness vs server authority
   problem

   A real-time Agar-like game needs movement and interactions to feel immediate, while the server must remain authoritative over state that can ultimately affect player value. Every client-side shortcut that makes the game feel faster is a place where the browser could disagree with the ledger.

   →↓

   response

   Keep authoritative simulation and economic state server-side, and design the networking / client layer around presenting that state responsively rather than letting the browser determine outcomes.
2. P-02 Player lifecycle
   problem

   Joining, loading, active play, elimination, re-entry and cash-out each change what a player can do and what they hold. Treated as separate UI screens, the transitions could disagree with server state - visible as issues such as flicker on join - and in a game where state carries value, a disagreeing transition is an accounting risk, not just a UI bug.

   →↓

   response

   Unify them into one coherent lifecycle: join / start transitions tracked with attempt IDs, join flicker removed, a Start Demo gate before play, and eliminated and cash-out states handled inside the same lifecycle.
3. P-03 Economy integrity
   problem

   Gameplay continuously changes mass and value through spawning, eating, splitting, food generation, deaths, respawns and cash-outs. In an ordinary arena game mass is visual state; here it is money, so a small accounting error compounds into a real economic error.

   →↓

   response

   Separate simulation / economy policy from presentation, keep the ledger authoritative server-side, and make food / value creation follow explicit economic rules rather than arbitrary client state.
4. P-04 Verifiable randomness
   problem

   Where randomness affects economically meaningful behaviour, players would otherwise have to trust a hidden server-side RNG result.

   →↓

   response

   Use commit-reveal for that randomness, so a result can be checked against a commitment made before the outcome was known.

1. D-01

   chosen

   Make the game server authoritative

   why

   Client-controlled positions, collisions or economic events would make cheating and state divergence unacceptable in a game where gameplay can affect value.

   cost

   More networking complexity, reconciliation work and server load.

2. D-02

   chosen

   Commit-reveal for economically relevant randomness

   why

   Players should be able to verify that a random outcome was not selected after the system knew which result would be favourable.

   cost

   Additional protocol and state complexity compared with ordinary server-side RNG.

3. D-03

   chosen

   PostgreSQL for durable application / economic state

   why

   The durable side of the game needs transactional, queryable state rather than relying on ephemeral simulation memory.

   cost

   Durable persistence should not sit in the hot simulation path, so the game needs a deliberate boundary between realtime state and persisted state.

4. D-04

   planned

   planned

   Introduce Redis as the realtime / ephemeral scaling layer when needed

   why

   High-frequency or short-lived state should not force PostgreSQL to become the realtime coordination mechanism.

   cost

   Adds another stateful service, with synchronisation and failure-mode complexity.