Kazap was our project. We made the first working version in about 2 days, and put another few weeks into it. This trailer was made several months after release. It made about $7k to date.
When Agar.io took the world by storm and kicked off the .io games genre, we found it quite surprising. We knew there was no technological hurdles: Browser-based technology has improved in leaps and bounds in recent years, and with the advent of websockets and WebGL, games were definitely an attainable target. What surprised us was that it could make any money. To understand the process, we created our own game, kazap.io.
Get paid by your free game
Agar.io provides ads on the landing page. A player sees those ads simply by navigating to the game, and they are removed once the player starts playing. Once a player dies, he is sent back to the landing page, where the ads are visible once more. Web-based ads pay on a cost per thousand impressions (revenue per mille impressions, or RPMI). The common earning rate is between $1 and $5 RPMI.
Before you go out and create your own .io game managing costs will be critical. You make very little money on a per-MAU basis and at the very least it must cover its own costs.
Predict the costs
If you don’t know what you’re selling, you probably won’t make money. Worse yet, you might end up owing money. Online multiplayer online games have costs associated with them, and you will need to make sure those costs are covered. For that, you need to a metric to measure your costs.
We started with the concurrent connected users (CCU) who are playing at any given time. A CCU is not actually an individual player, it is a “player slot” that requires processing and bandwidth to provide. There is a problem: While CCUs are directly related to your costs, they are not constant and are not useful for estimating your costs on their own. To solve this, we created a metric called the Monthly Average Concurrently Connected User (MACCU).
CCU is a constantly varying number, so it needs to be averaged.
The MACCU is easy to measure. Simply record your CCUs at fixed time intervals, such as 30 seconds, over the course of the month and average them. You can get a good estimate for your MACCU by doing the average over a shorter time period, though if you go shorter than a week you will likely not get an accurate estimate as your player population varies by day of the week.
How much does the MACCU cost?
If a MACCU is effectively a player slot that people occupy when playing your game, you need to figure how much it is going to cost you.
To calculate the cost we have to make some assumptions. The first is that we will need an online server. Many people will look to Amazon AWS, Google Cloud, or Azure for solutions that are proven to scale. Granted, these are not the cheapest solutions, but if you need a lot of extra machines in a pinch, they will scale faster and larger than smaller vendors can manage if you need it.
If we start with a small but capable server from one of these providers, we are looking at a cost of about $5 per month, if it is running 24/7. A server like this can handle 200 CCU max - more if your server is very efficient. For this, you can just assume a minimum cost $0.025 per CCU. In reality, it could be a bit higher or a bit lower, depending on the number of players you get during a given hour, but this is a good ballpark estimate. As you will see shortly, it is the least of your concerns anyway.
Bandwidth will vary widely from game to game, but we will take a rule-of-thumb: A 64-player FPS will need about 110,000 bits per second of bandwidth - 13,750 bytes per second - for a fluid experience. Providers typically charge you for total bytes transferred each month.
Each MACCU will use 13,750 bytes per second, each second of each day for the entire month. Each month is about 2,635,200 seconds long. That means the total amount of data an MACCU uses is about 36 Gigabytes.
The price per gigabyte varies significantly by region. In North America the cost is generally below $0.10, while in South America it can be as much as $0.25. North America generally has cheaper bandwidth than most of the world, so let’s assume that your average cost comes our around $0.12 per GB, so your MACCU costs about $4 per month - significantly more than the computational cost!
In practice, we’ve seen many .io games out there use significantly more bandwidth than the ‘rule of thumb’, with many reaching into the 300-400kbps range, well over $10 per month! Clearly, reducing bandwidth costs is your highest priority.
That said, most web games don’t use AWS. They use smaller outfits like Linode. These small shops provide a lot of value but have limited abilities to scale. The majority of games are unlikely to require much scale, and can therefore operate significantly cheaper. At the time of this writing, it is possible to get a single-CPU server with 1 TB of transfer for $5 per month. Such as system can easily handle 100s of CCUs. Bandwidth overage costs between $0.06 and $0.12 per GB, which is comparable to the large cloud providers, especially since ingress is free on AWS, and not always free elsewhere.
No matter how you slice it, bandwidth optimization is key to making decent money and your players will appreciate these games not eating into their bandwidth cap so much.
The “Other” Cost
Another cost that adds up is content delivery. It can be significant, especially when you have high player turnover or push frequent updates. In an ideal world, most of your players would be coming back again and again.
We used the Unity game engine to build our game. It is well-known that Unity generates a particularly large runtime, especially if you include features like PhysX client-side. The result is a runtime a few megabytes in size just for the code. Your runtime size can be reduced a myriad of ways - just use another engine that is built for web that only has the features you need.
You will quickly run into another issue: Your assets can easily take up more space than your runtime, if you’re not careful. For kazap, we had this problem. Our assets were simply bitmaps, however they were large and high-resolution. Unity was helpful and automatically generated mipmaps at build time. Our web footprint was 22 megabytes. We reduced our asset sizes, turned off mipmapping, and were careful about other aspect we included, and dropped the runtime with assets down to 8 MB. Still large, but manageable.
Being good AWS customers, we hosted our package on S3, and used Cloudfront to ensure global fast delivery. It was a far cry from the cheapest option. Even at 8 MB, our cost to deliver the runtime was upwards of $5 per MACCU at first, and dropped to $3 per MACCU as players came back and were able to use cached copies. Any time we posted a game update, everyone would re-request the game client which would create a slight uptick on the average delivery cost.
Where’s the Money?
When it comes to monetization, ad revenue is the least effective. In order to turn a profit you will need a large number of impressions served. The cool thing about the MACCU value is that determining how to monetize it is relatively easy. All you need to do is determine how many individual ad impressions need to happen over the course of the month.
If we assume the $4 MACCU cost, with a conservative $1.50 RPMI, you can see that a single MACCU will need to serve just under 3500 impressions to break even over the course of the month. This means that every 12.5 minutes, you have to display an ad to every active player. Increasing the frequency of the ads increases revenue. When we made kazap.io, we designed to show an ad every 4 to 5 minutes. We estimated our revenue to be around $12/MACCU.
Our Real-world Example
Our adsense earnings for the first few months after launch. Not exactly a smash hit, but we learned a lot!
We assembled our game and launched it. We tracked several metrics using Google Analytics events such as how many players successfully loaded the game.
We logged the number of CCU every 5 seconds across all servers. During our peak month, our determined our MACCU number was about 100. Our earnings for the month were $1128.47. It was a little below our estimate. We set up events using Google Analytics to detect various conditions. One of those conditions was the use of ad-block software. We would still allow people to play the game using adblock, we would just present them with a message instead of an ad that took even longer to dismiss. 8% of players used ad blockers - a number that seemed smaller than we expected.
Another thing we noticed, even with our relatively large runtime, our bounce rate was below 20%. This suggests that you can get away with downloads that are a bit larger without too much impact. For comparison, games that have 15MB+ runtimes have bounce rates 4x higher. Generally, people don’t seem to mind a bit of a load time, however once you go over 10MB it will definitely start to take too long. When we tested with another web game that had a 17 MB download, the bounce rate skyrocketed to 80%.
Conclusion
All in all, our game made around $7k over its lifetime. It didn’t go viral, dashing our hopes of making $50k-$200k per month, but it paid its own bills and we learned a lot. I suspect that if we had released now, it would not fare as well. The multiplayer web games space is getting relatively crowded, with a new game or two released almost every day. It’s a great way to prove a concept and maybe find a seed player base, but not really a good place to make money unless you’re very lucky.
At its peak, our game had 150k MAU. Gross revenue around $1130 means we made $0.007 per MAU! Pretty terrible, so clearly web-based MAU have nothing on mobile, PC, or console, at least not in the .io space. about 60% of our gross revenue went to expenses - about $100 for servers, the rest was bandwidth. So, our experiment paid for its usage, but not much else. Only the most viral games win.
Thanks for reading!