Show HN: TowerPanic – a family party game on a small FastAPI realtime engine (towerpanic.com)
You can try it quickly without an account - I created game demo rooms (EU/US/JP) - links below - just be aware that anyone with a link can access join the game.
Let's start with short description of the game itself:
This is the TowerPanic game - you are standing on one of four towers, during each round some of towers crack, and some of these lean, and finally one of these colapse - you need to watch out to not be on the failing one. It's a multiplayer game for whole family. This can be also used as an icebreaking game - for people in any age. The game is safe for children - no violence, no strangers, no chat, no ads. Parent creates an account (free 14-day trial, then a paid pass) and starts the game - others join using a QR code or a link.
Behind the game there is an interesting backend engine - I willdescribe it in a moment.
Let's start with the history of this whole project: - I was playing with asyncio and fastapi - As an exercise I created a reliable chat application (multiple rooms, in each room each user can reliably broadcast a message to all other users) - I extracted communication to separate layer - creating network/application layer interfaces - 'reliable client' interface for client and 'state machine' interface for the service on server. - With these interfaces - I was able to create other service - an 'sgame' (simple game). With verified interfaces and created services (chat, sgame) I was able to ask AI to generate other tools/games - I was impressed by these results - the games/tools worked well - I deployed them on a remote server - I was surprised that the latency was very good - almost everything worked smoothly
I tested the tools and games with my children and one of the game was really great. I decided to make this game public - I chose 'TowerPanic' name for it.
I prepared an account/payment server for this game (as a separate FastAPI application). This was very good choice: - the game servers keep rooms only in memory - nothing persistent (rooms have expiration date) - the account server keeps all persistent data (it uses database)
Because of this split I was able to figure out how to upgrade and scale frontend and backend independently - without significantly impacting users.
I optimized the communication layer - so that it works in finite memory - only finite number of recent messages is kept, and I sent a full service snapshot (full state) to the lagging clients.
The backend process (FastAPI/python) is limited by python GIL (only one core can be utilized) - to utilize all server cores I used HAProxy with consistent hashing to distribute rooms - so that users can be redirected to proper backend process.
I tested how many rooms a single server can handle - it handles hundreds of active rooms in parallel with no significant latency drop.
Before making it public I noticed that latency in other region of world might be higher and this could influence UX - I confirmed this using artificial delay on my remote server.
I decided to deploy the application in three regions - EU, US, JP - to ensure low latency (below 150ms) in most of the world. The room is created in region closest to the user (best latency from the browser to backend).
I needed also to prepare some legal documents (terms, privacy, refunds) - thanks to AI this was much easier. I'm a backend engineer, frontend/UI/UX were designed by me but code was generated by AI.
To summerize all this work: - I'm happy that I was able to deliver complete game/complete product - I think the whole work took me about 20 evenings - I'm impressed that it was so short - I think this is because the technology I used is popular and all fits well - AI was great as a peer (to discuss the options for distributing the load, discuss were to locate servers, or discuss how auth...
6 comments
[ 190 ms ] story [ 413 ms ] thread