Lessons From 7 Years of .IO Games: What Works, What Doesn’t Work, Where to Go From Here

My name is Nathan Flurry. I've been working on I-O games for seven years. Some titles I've worked on include Krunker, D-E-F, eeveeo, and MooMoo. I'm going to share some tips on game design technology and business decisions that you can use to build a killer I-O game yourself.

Before diving into it, I want to give an overview of what an I-O game is. I-O games are multiplayer web games that are easy to pick up but can be played for hours on end. You can think of it like the tick-tock of gaming by catering to short attention spans with endless gameplay. The whole .IO craze was kicked off in 2015 when a game called Agar.io launched. This game was dead simple. All you could do was move the blob and eat other blobs. The killer feature though was that lobbies had over 50 players in them, so players would have to spend hours on end collaborating with friends to get at the top of the leaderboard, even though the mechanics are dead simple. Agar.io was so popular, it made an appearance in House of Cards in 2016.

A series of games followed suit with simple mechanics, basic graphics and large lobbies including Slither.io, which is a modern take on Snake, and Splix.io, which is a territory conquering game. This led to the creation of Iogames.space which is a popular web portal that features specifically I.O. games. If you played a lot of web games during this time, I.O.games.space was such an awesome site because there was a brand new multiplayer game almost every single day with unique mechanics. Because there was no review process or downloads required for publishing I.O. games, developers could quickly iterate on games, and many of the best games you know today were developed in less than a month and matured over the following years. Older web portals also got onto the trend and started featuring I.O. games to fill out the void that Flash and Shockwave left when they were phased out.

Around 2016, developers started adding deeper game mechanics by adding up great trees. Diep was a game where players could build unique tanks, Mop was an animal based game where players climbed the food chain, and Moo Moo was a PvP sandbox game where players could build forts. This was around the time I started working on some of the original games built by Sydney DeBrese, like Moo Moo and some less known games.

Around 2018, developers realized that many of their players were students in classrooms, playing these games as a substitute for console and desktop games available at home. They started building simplified browser based versions of popular games tailored for short play sessions. Most notably, I worked on Crunker, which is a counterstrike in the browser. Other examples include Zombs Royale and Build Royale, which are 2D versions of Fortnite, and Evo, which brought Destiny-like gameplay to the browser. If you go to a public library today, I guarantee you you'll see players, you'll see students playing one of these games.

Around the same time, some developers realized Io game mechanics could be adapted for mobile, to leverage new audiences and higher ad revenue. Most notably Voodoo adapted games like Paper.io, Whole.io for mobile touch friendly controls, with offline modes with fake opponents. The company Voodoo refined this technique so well that they generated $430 million in revenue in 2021, and had six billion downloads across all of those games. All of these Io games have a few key pillars in common, five second startup times, 60 second mechanic learning times, ephemeral leaderboards, and network effects. If you follow these pillars, your game will be able to replicate what works well for popular Io games.

For five second startup times, as I mentioned earlier, most Io gamers are students in classrooms. To give some context, Gen Z has an average of eight second attention span, and Io games only stick if players can get in the game before they lose interest. Because of that, we ensure that all of our games load within five seconds on low end hardware, which is a tall order for any traditional desktop game. Thankfully, the web is uniquely suited for this. If a web browser can load everything from Google Docs to Figma within a few seconds, it's entirely doable for games too. For example, when working on Kronka, we needed to build an immersive 3D game that still loaded within a five second window. Most important thing we did to achieve this is that we did not use a game engine like Unity. Game engines are great because they give you everything you need out of the box, but that comes at the cost of really long load times. Only one game I've mentioned this entire talk was built with Unity, and this is why.

Another important thing we did was lazily load all nonessential assets. Similar to how web pages lazily load images and scripts, games are exactly the same. If you open Kronka, you'll notice that you'll connect to a server before the textures load or the sound starts playing. That's because everything required to play the game is under five megabytes and the rest is lazily loaded. We also structured the engine so that it could load assets individually as needed, instead of downloading a single large package on startup. For example, there are thousands of scans and weapon models available in the game, but we only download the relevant content when needed. Similarly, we embed as much as possible into the initial JavaScript bundle you load on startup. Everything from the core maps, the class configuration, the character models are embedded into the initial JavaScript package for Kronka.

This means the game is entirely playable immediately on page load without needing to make follow up requests to a server.

Another vital feature in Kronka is players are not forced to sign into account to play the game. This means players can play as a guest and try the game instantly with that reduces bounce rates.

Let's assume you've pulled off that five second load time and now the timer is kicking to keep the player engaged before they get bored and click away. As I mentioned, you can think of IO games like the Tick Tock for the gaming world. Players come for short play sessions and will lose interest painfully fast. Because of that, we found that players need to get the hang of game mechanics within 60 seconds.

For example, we designed Mumu to provide flexible playing styles of a sandbox game but avoid the high learning curve of other sandbox games like Rust or Minecraft. Instead of building a complicated inventory system, we opted to provide only four types of resources, woods, stone, gold, and food. It's immediately obvious to players that wood is acquired from trees, stone from rocks, and food from apple trees. In order to add a form of progress to the game, players can level up and choose the types of structures they want to build from a skill tree. This replaces the complicated crafting system found in most popular sandbox games while still providing a flexible play style. Players learn all of this within 60 seconds of playing the game.

Despite the simplified mechanics, Mumu players had session times comparable to games like Minecraft. In Mumu, players build windmills to passively generate gold in order to reach the top of the leaderboard, but players needed to build a base to defend their windmills and go on to conquest and destroy other players' windmills. The key to keeping players engaged was the list of top ten players ranked by their gold on that server. If a player leaves the game, they will lose all of their gold and have to start from scratch. The top player in each server usually has been playing for at least two hours before getting to that spot. Unlike Minecraft servers where players often have hundreds or thousands of play hours logged, reaching Mumu's leaderboards is accessible in a reasonable amount of time for web game. You'll see this ephemeral leaderboard mechanic replicated in almost every single IO game all the way back to Gario. It keeps players engaged for long periods of time while keeping the barrier of entry very low. The great thing about ephemeral leaderboards is that the state is stored on the game server itself, so you don't need to maintain a database to store persistent leaderboard scores to make this work.

I want to share something that most game developers will find crazy. Almost all successful IO games don't spend a single penny in marketing. Here's why. The first time I played an IO game back in 2016 was at a hackathon. Someone wrote a six-digit code on a giant whiteboard and instructed everyone to go to a place called Agario and enter that code. Within a few minutes, 30 of us were playing together on the same server, and we kept playing for a few hours. That's not something that could have been done before web browsers came around. If you wanted to host a LAN party, you all had to purchase the game, download it, and someone had to start a server, which is a lot of hoops to jump through.

Sharing IO games to play together like this at school is how almost all IO games acquire users. This is the same type of network effect that networks be so ubiquitous, so it's no wonder that IO games are able to grow so quickly without marketing.

There's a lot of ways you can leverage this in your own games. The first is to build a party code system like Agario that lets players play on the same server. The party code needs to be short and be able to be read aloud so someone else can type it in on the website. I also recommend removing frequently conceived characters like 0 and 1 in L.

The second is to allow players to share links to join game servers. It's common for players to ask friends to play with them by dropping server links in Discord channels. Twitch streamers also frequently play IO games as a way to engage viewers so they frequently share server links.

The last point is another thing that most game developers would find completely foreign. The most successful IO games were launched in less than a month. Given that most console games launch in 3-5 years, this is crazy fast. There are three main reasons this works. First of all, IO games are easier to distribute than console games. All you have to do is post a link on a game portal to get traction to your game immediately. You can know within a few hours of launching whether or not it's worth spending more time to work on this game. Other reasons this works is because IO games don't need fancy graphics to do well. Console games invest heavily into graphics because it's important for marketing, but at the end of the day, players stick around for fun game mechanics no matter how the game looks. Finally, there's no marketing budget required to launch an IO game. This means there's no financial risk if your IO game flops, so why not keep building new games and see what sticks. In the case of Krunker, it looked like this at launch, you could only play with a sniper class and the map was manually written in adjacent positions. There was no editor.

But it was fun, so we kept with it. Now that you're familiar with the foundations of building IO games, I want to share some difficulties that you'll run into. Everyone knows that kid in school who played games on their TI 84 calculator in class. I guarantee you that kid didn't go home and play on their calculator. They likely had a console where they played something way more fun. IO games are similar to that game on that calculator. Players can play IO games in their Chromebooks in school, but they will usually play other games on other platforms when they get home.

Players can play IO games in their Chromebooks in school, but they will usually play other games on other platforms when they get home. You're going to run into two big challenges with this. The first being that traffic can drop up to 50% over weekends or over school breaks. This means that summertime is not a good time to launch new games. The other challenge is that it's difficult to monetize with in-app purchases because players aren't as invested in IO games as they are with games on other platforms.

It's unlikely you're going to be able to generate in-app purchase revenue comparable to mobile, but getting players to play your game outside of school will push you in the right direction. On Krunker, we invested a lot of resources into the Krunker hub, where players can buy and trade skins and compare rankings. This got players more invested in the game to the point where resale weekend traffic and in-app purchases increased as a result. Another tactic is to push users to install your game on other platforms, such as desktop or mobile, by providing unique perks. Krunker had a unique advantage on desktop since packaging the game in an electron wrapper let us tweak some performance flags to make the game run faster. Anyone who was serious about the game would download the desktop app and play it more frequently. Getting Krunker players to play to move from web to mobile took a little bit more creativity. We implemented a daily reward system on the mobile app where players could receive free in-game currency for watching ads on their phone once per day. This encouraged users to open the mobile app every day and also generated significantly more revenue given the higher RPM of mobile reward ads. Given that at the end of the day your game needs to be comparably fun to other games, fun is really the only way to compete with other platforms. That's a tall order given the massive budget that AAA games have making their games sticky but it's possible.

Ads make up 90% of revenue for most IO games, largely because it's incredibly difficult to get users to make in-app purchases from web. If your game is incredibly engaging and users want to spend money on it, you're going to have a much harder time collecting payments on web than mobile or Steam. On all other platforms users credit card information is saved so makes making a purchase much easier. On web if user wants to make an impulse purchase for in-game credits to buy a skin, you have to collect credit card information from the user. The added friction of inputting their credit card or accessing their parents credit card makes purchasing much less common. While the request payments API launched in 2017 should help, most users haven't saved their credit card yet and opt to manually input it into their website. One thing you can do to help alleviate this is adopt Paypal since many younger gamers have a PayPal account. However the best thing you can do to increase in-app purchase revenue is to convert users to play their game on a different platform where it's easier to monetize them.

Hopefully you have a good idea of what it takes to launch an IEO game today. Before wrapping up I want to briefly look at what's coming soon for multiplayer web gaming. Web games are hard to monetize but game developers for other platforms are paying attention to web as a user acquisition strategy because of its low barrier of entry and its network effect. Given the recent improvements in web gaming standards it's making it easier to publish more resource intensive games to web. Very few gamers download game demos but being able to play a game with a friend in a web browser before downloading or purchasing is enticing. One notable example is this game called bat-bat.

It's a free to play battle royale game primarily distributed on steam but fully playable in the browser. Numerous web standards have also been recently stabilized or are coming soon which will open the door to better web games. Specifically for multiplayer games adopting web transports, unreliable transport and congestion control will make low latency games to run much smoother than over web sockets.

I'm really excited to see what developers also do with web GPU, wasm threads and wasm cindy. I was happy to see that Apple included support for WebXR and the vision pro given that their poor track record for supporting web standards. we have had WebXR enabled devices for a long time but I believe WebXR will be a unique way to share cross-platform multiplayer games without having to share go through the cumbersome app store and meta store review process.

There are a lot of companies trying to tap into roblox's success with user-generated content. One of roblox's strengths is the ability to play on all platforms including desktop mobile console and VR. But the only major platform roblox does not support is web. We'll probably see a few notable user-generated content platforms leaning heavily into web to reach larger audiences. Thank you for attending my talk. I spend day in and day out working with multiplayer games so please don't hesitate to reach out to me on Twitter.