Multi Pong

Multi Pong is the simplest game - Pong - taken a step further. Classic Pong is for two players who defend their side from a mindless dot attempting to breach. Someone might say it's just two rectangles bouncing off a dot on a linear trajectory but I wouldn't listen to them as they don't have imagination. Multi Pong extends this from N=2 players to N>2 players. Imposing a symmetry on the problem - everyone should have equal chance of failing - it makes a few considerations obvious. All players are sides of a polygon and the number of balls increases with the number of players. Personal touch comes from trying to make this game a bit more chaotic - curve paddles, increasing speed, losers can be vengeful.

As for engineering, it's quite simple but hopefully not simpler than it needs to be. Realtime multiplayer needs websockets, persistence and a server. Wanting to play with other folks who don't join at the same time requires queues and some telemetry. My wanting to make this "yet another project" means it's set on my personal "platform" (see internal prototypes should be easy to share). Pods are small but big enough.

Implementation is as one would expect from a small realtime game. FastAPI serves the static UI, creates rooms and holds WebSocket connections. Each room owns a simulation loop. The clients are mostly dumb, in a good way. They send paddle movement and receive snapshots of the world. Server is the source of truth, because otherwise every browser tab becomes a tiny liar with latency. It keeps positions, resolves ball-paddle and ball-wall collisions, counts lives and decides who is still playing.

The game rules are in the same spirit. With N players there are N - 1 balls, everyone starts with three lives and losing all lives doesn't remove your side from the board. It becomes a wall. I like that because the match doesn't simply shrink. It changes character. There is less player agency but more geometry, which is a silly sentence and somehow an accurate one. For two players it's Pong. For more players it's Pong arguing with a polygon.

Rooms are intentionally simple. Create a room, share a code, join a random open lobby if you don't care where you land. Players mark themselves ready and the match starts with whoever is there and ready. There is a small chat because games are better when people can complain about the physics in real time. The room creator can also add or remove bots before the start, mostly so the game is playable even when the number of available humans is the usual disappointing number.

Deployment follows from that. Room state is process-local, which means scaling this horizontally without more work would be pretending. Either rooms need to be pinned to processes or state needs to move outside of the process. I don't need that yet, so I don't have that yet. It runs as one replica and that is a feature, not an accident. The constraint is easy to understand and good enough for a personal project that needs to be online more than it needs to impress an architecture review board.

Visually I leaned into the arcade side because plain multiplayer demos tend to look like tax returns. Multi Pong has CRT colours, loud type and a playfield that only really makes sense once more than two players show up. If I'm making people bounce balls around a polygon on the internet, then I might as well commit to the bit.

You can play it at multi-pong.lasz.uk.