This is how we created the largest game ever played live. We did it at the Sydney Opera House in 2025 - if you want an exciting summary, you can see us explain it to a rat in this video.

Invitation to Australia

We were very lucky to be invited to perform our show Robo Bingo at both Sydney and Melbourne Comedy Festivals in 2025.

Alongside doing Robo Bingo, we were asked to perform at the Comedy Galas at the Sydney Comedy Festival, these are like big showcases of multiple comedians, each doing 5 minutes to give a taste of what's in their hour show.

Our shows work by people playing along with show on their phones through our custom software. We accomplish this by bringing our own WiFi routers and using a local network with our laptop as the server. However for the Galas, this would have to change.

Going Gala scale

We stick to a rule of using one WiFi router per 50 people, and our Robo Bingo show was in a room of 50-100 people, so we used two routers, easy.

The Comedy Gala venues were 1000, 2000, 3000 seaters. So we would need 60 routers. At the time, we owned eight. 52 more routers and cables would cost £5000 and we would need to set them up at the venue beforehand. Luckily we had an excuse not to attempt this big WiFi network: the suitcase was already full.

So we decided to not do an interactive set. We've got stuff where people don't use their phones. We focussed on getting the Robo Bingo hour show ready, and put the thought of the Galas in the back of our minds.

Then once we were in Australia we checked with the promoter if they were expecting an interactive set - they said they were looking forward to it.

We had 11 days to do it. We started working on it on the 11th April 2025, the first Gala was on the 22nd. It was constant programming in our apartment, alongside performing our other show every day, packing everything up and then travelling Melbourne -> Sydney and setting up for our show at the next venue.

Our new website

Time to do a plan so crazy, it just might work.

Instead of WiFi, we would use the audience's mobile data.

But isn't mobile data bad?

Yes!

Never expect it to work in large crowds!

But what else could we do?

• We'd make an incredibly small website
• We'd make the live connection to the server send the smallest messages possible

We would create a version of our game "Avoid the Zeros". It's an infinte runner like temple run, but multiplayer and you play an IT consultant and you must avoid falling 0s. The graphics look like ASCII ART, as if they are running in a computer terminal, as the very first version of the game Peter wrote at a hackathon and it did indeed run in a terminal.

Network

Knowing the game, we were able to make the code do several tricks to minimise network traffic.

Minimising data transfer

The more people in one area, the more one cellular tower has to deal with. This causes data rate to go down, so we did the following.

• Binary messaging serialised using Protobuf, not sending messages as text, e.g., JSON.
• Sync initial state and then only changes to data, e.g., you get all player positions in the first message and then only messages when a player position changes.
• Don't use ints for everything, e.g., player positions can only be in one of 24 cells, so we use an enum of 24 states.
• Don't send an update until they have acknowledged they recieved the last one (we actually have a parameter that can set how many messages are allow in-flight). This self-throttling also prevents messages backing up.
• Sync at most N clients to each player, e.g. only sync 300 players to each phone (replacing them when players are knocked out), this prevents network getting worse for clients as more players join. We synced all players to the screen displayed onstage (we took the risk with our data, some shows we had an ethernet connection, some we were on mobile data ourselves).
• Brotli compression on all assets served by NGINX.
• All sprites are stored in one image as a sprite atlas, compressed to approx 50KB.
• We used Rapid JS, a very small library for graphics.
• On average with all players moving, each player was being sent 8KB/s. Which is very low by today's standards.

Hiding latency

Mobile networks can have higher latency than WiFi, newer technologies like 5G have reduced this but sometimes there are weird setups, e.g., in Australia Lloyd was using an eSIM which sent his data out from the Netherlands, giving him a huge latency.

• Calculate the round time trip from client to server (measure on server how long it takes for a message to be replied to) and offset their position based on this.
• Move the user locally on their device, rather than using the servers position.
• Race track is predetermined on phone, and scrolled into position from a known start time.

Server

We also had to ensure the CPU on the server could handle 1000s of players connected.

• Use C++ for server, not nodejs like we usually do.
• C++ reduces cost of serializing messages that takes up lots of CPU.
• We used uWebsockets library.
• At 3000 clients sending 10 messages a second it used around 60-70% of CPU.

Client and graphics

• On phones we needed to render 1000s of sprites.
• Rapid.js made handling this very simple and ran very fast on all devices.
• We did not use any other library (e.g. React). Just plain HTML.
• Lots of effort went in to gracefully handling disconnects and retrying to connect.

Testing

We don't have 1000 people with phones at the ready to test if it works. So we opt for testing using bots we call "monkeys". It's a small python script which opens a websocket to the server amnd constantly sends random input messages. By launching 1000s of these (usually across several computers), we can stress test the server and monitor it's CPU and memory usage. The main bottleneck we've experienced in older versions of the game is CPU usage going high, hence why we went native code in C++.

Putting it on stage

The setup was our laptop on the floor at the front of the stage with a webpage open at a special spectator URL for the game.

On the first night, in the break before we went on for our five minutes, Lloyd noticed the screen was off on the lapotop. Turns out we forgot to plug the laptop in. A quick reboot later we were ready and it worked.

Of course we prayed to the network gods before, so of course it was going to work.

It continued to work for each of the Galas we performed at, including the Sydney Opera House and an outdoor show at Tumbalong Park, which had the largest audience and we only had a mobile internet connection to work with ourselves.

What next

We've been adding more to the game since, and succesffuly run it for UK musics festivals crowds and as entertainment at large coporate events.

We'd like to keep pushing how many people can play together at once at live events, so like the video says, if you know someone get in contact@foxdogstudios.com (or not if you're a rat).

Thank yous

Big thanks to Century Comedy for bringing us over to Australia and giving us the opportunity to do this in front of these audiences.

Huge shoutout to Night Scratch for Rapid.js, really helped it all come together in a short amount of time