5 years below minimum wage: the financial history of Ronimo

Starting your own game company is fun and exciting, but it’s also challenging. It takes courage and skill, but above all: patience and perseverance. Some become successful quickly, but in many cases it takes years to achieve financial success and actually make a decent living out of your own game company. It might take long to make your first product or get your first deal, and that first achievement might only be a stepping stone towards a next step that brings financial stability. Today I’d like to show an example of just how long that can take by sharing the financials of the first five years of Ronimo, the company I co-founded with 6 friends nearly 14 years ago.

TLDR: The very short summary is this: it took us 2 years to make any money from Ronimo at all, 4 years to earn (almost) our country’s official minimum wage and 6 years to receive a more decent monthly salary from our own company. During that period we were near bankruptcy twice. Why did it take so long? Read on and you shall know!

A note before I continue: this blogpost is partially about how long it took us to “make a decent living”, but the cost of living differs hugely per country. The Netherlands is a wealthy country so cost of living is relatively high. A quick internet search shows that cost of living is much higher in some countries and only half in others. Since most revenue is worldwide, the same sales might mean financial stability in one place, but not enough to pay the rent in another.

Also, for anyone used to reading US dollars instead of euros: if you just replace the € sign with a $ sign, you’re in the right ballpark (especially given that the exchange rates between dollars and euros have varied a lot over the years).

In our second year of studying at the Utrecht School of the Arts our classmate Fabian Akker brought up the idea of starting a company together, with a group. Around that time we had done a couple of school projects that had failed quite miserably, so my first thought was: “we suck, let’s not.” However, the third year was to bring the first major game project, so we figured that if we could make something awesome there, then maybe we could also start a company making our own games.

The resulting game was De Blob: a huge success! We put it online and got attention from gaming press and even had some publishers contacting us, wondering whether they could buy the rights to De Blob.

(Note that De Blob was not exactly made by Ronimo: of the 9 students who made De Blob, only 5 were part of the 7 founders of Ronimo.)

Convinced by De Blob’s success, we decided to really go through with starting our own company. However, each of us still had to do a 7 months graduation project. We combined them and made starting Ronimo our graduation project. Getting school to approve of that was a bit of a struggle, but once they did, we even got our own office inside school.

At the time, 'indie' as it's known today hardly existed and we had definitely never heard of it. We thought the only way was to make retail games and that required funding from a publisher. So we set out to make a pitchable prototype: Snowball Earth. This was intended to be a Nintendo Wii game and we hoped to find publisher funding once we had graduated. At this point Ronimo didn’t make any money at all, but that was okay since we were still students.

September 2007. We were so focussed on pitching to publishers that we did our graduation stuff on the side and crunched for what came a few weeks later: Games Convention in Leipzig, Germany! There we pitched to at least a dozen publishers. Some were interested and continued conversations with us afterwards. Hopeful, we continued work on the game, looking to improve it and increase our chances of signing a deal.

Our very first presentation was for a then pretty famous person from a big company. He was so excited that… he feel asleep during out presentation. Jet lag. Or disinterest. Or both. When we woke him up, he proceeded to try to sell us his own middleware and hardly looked at our game.

By this time we had graduated and had moved to our own office in Utrecht. A very small office for 7 people, but it was cosy and exciting. What we didn’t have, however, was money. We did some minor work-for-hire jobs, but since we weren’t fully committed to that, we hardly made any money there. Just enough to pay the rent of our office, but definitely not enough to provide ourselves with any income.

This is something I've seen quite a lot: studios who want to make their own games and finance that with work-for-hire rarely succeed at both. Either they hardly make any money from the work-for-hire, or they spend so much time on that that they can hardly focus on their own game. Often the result is that the game takes many years to build and turns out mediocre because of the lack of focus and time. The reason for this is simple: doing work-for-hire well and making it lucrative is hard and it's rare for that to work as an aside, especially for inexperienced recent graduates.

So, we didn’t make any money and we weren’t students anymore. How did we not starve? This varied amongst the founders. First of all, in September 2007 we managed to sell all the rights to De Blob to THQ, a then major publisher that’s now defunct. (Note that THQ Nordic is a different company that later bought the rights to the name and games of THQ, including De Blob.) For this we were each paid a nice amount (can’t disclose it due to NDA unfortunately), enough to pay the rent for quite a while. However, only 5 of the 7 Ronimo founders were part of the De Blob team, so 2 others didn’t have this.

Six of the founders had an additional source of income: the now defunct WWIK government subsidy. This paid recent art graduates around €600 per month. That’s less than half of the official minimum wage in the Netherlands at the time, but enough to not starve. To live cheaply, three of Ronimo’s founders rented an apartment together with one more person.

I personally didn’t get WWIK because I had some savings and thus didn’t qualify, so I went even cheaper: I kept living with my mum until I was 26 years old. I have a lovely mum though so I totally didn’t mind. Thanks, mum!

This is also a good moment to mention how privileged we are to be doing this in the Netherlands. In many places in the world all of this would have been much harder.

So, how did the pitching go? A few publishers were interested and one even flew over to do due diligence: judging whether we would really be able to make the full game. In the end none of them actually offered us a deal because Snowball Earth was too unique and we were too inexperienced to be trusted with that much money. We were asking for €1.5m development budget. Not much for the big game we envisioned, but definitely too much to give to a bunch of students who had so little clue about business and production processes.

Snowball Earth was too big a game to finish without funding, so we ended up cancelling it altogether. Years later we did release our prototypes, which you can still find here together with videos and screenshots.

What next, then? By this time indie was on the rise and we had managed to get Nintendo Wii devkits. We decided to make something small that we could finish and publish ourselves: Swords & Soldiers for WiiWare (the predecessor of the current Nintendo eShop).

We estimated we could make this game in 3 months. One year later, we finished and launched it. I’m still impressed that we managed to make something of that size and quality in just one year, and I’m even more impressed that we were stupid enough to think we could make something like that in just 3 months...

Throughout this year we still didn’t make any money, but we did hire interns. In the Netherlands internships are a standard part of many schools and are not paid like normal jobs. So for only €200 per month we could have a game student work for us full-time. Despite that low compensation, those interns were getting more money from Ronimo than we were! On average, we had 2 or 3 interns at a time helping with development.

In May 2009 Swords & Soldiers launched on Nintendo Wii. It got critical acclaim, reached the #1 selling spot on WiiWare in Europe and #3 in America. In total it sold 30k copies and made €146k during the first year (and very little on WiiWare afterwards). A big success for us at the time, but not that much money in retrospect.

In August 2009, after 2.5 years of working full-time with seven people, we were finally able to pay ourselves a monthly income. A whopping €600 per month! Oh wait, that’s super little… but it certainly felt like a big step forward!

Something we hadn’t realised yet at the time is the importance of porting our games to different platforms. That is, until Sony offered us money to make a PlayStation 3 port of Swords & Soldiers, including multiplayer.

To make this port and continue work on our next game OMG Space! (which would later be renamed to Awesomenauts) we needed more programmers. Up until this point I had been the only programmer at Ronimo (besides interns) and that wasn’t enough to make a port and a new game. We hired two programmers. Unlike us, those coders were paid real wages (though not very high ones). And so, while we the founders finally made more than our interns, we instead now had employees who made way more than us.

In September 2010 Swords & Soldiers released as a downloadable game on PlayStation 3. Unfortunately it didn’t make break even, so the only money we made from this was the initial porting budget we got from Sony.

Now that we realised that porting is a super important source of revenue, we also ported Swords & Soldiers to Steam and released that in December 2010. Making a port is only a fraction of the effort of making a full game, and every new platform is a new roll of the dice: a new chance at success. And indeed, while the PS3 version hardly sold, the Steam version would make us €120k in its first year and €35k in its second year.

Now that we had employees and paid ourselves a little bit, we had significant monthly costs. Too much to carry ourselves, so we were looking for a publisher for Awesomenauts. Near the end of 2010 this was becoming dire: we were only a few months away from being out of money altogether.

We were saved when we signed a publishing deal with DTP (yet another company that doesn’t exist anymore). The total development budget we got from them was €300k. Not much for a game of this size, but it was a lot for us! As is common, we received that money spread out over milestones and not all at once.

Awesomenauts was a very ambitious project, with complex multiplayer and simultaneously launching on two platforms that were new to us (Xbox 360 and PlayStation 3). We needed more programmers to pull that off. Good thing the budget we got from the publisher allowed us to grow a bit more. In the first half of 2011 we hired two more programmers and a producer, bringing the team’s total size to 12 full time employees. On top of that we usually also had 3 or 4 interns working with us.

The funding also allowed us to finally pay ourselves almost minimum wage: €1400 per month. Still less than our employees got, but at least we felt like we were finally making real money.

In March 2012 we managed to secure some additional income: Swords & Soldiers was included in the Humble Android Bundle and this made us €37k. Towards the end of the year it got included as a bonus in another Humble Android Bundle, making us another €10k.

This money was needed desperately, since Awesomenauts had seen numerous delays at this point. I don’t remember the exact original planned release date, but I think in total the console release got delayed by around half a year. The publisher didn’t give us extra budget for that, so we had to make do with the money we had.

In May 2012 Awesomenauts finally launched on Xbox 360 and PlayStation 3. But not before our publisher DTP went insolvent a mere week for launch. This made everything extremely complex and we didn’t know whether we would see any royalties at all. We got lucky: we had some unreleased DLC they wanted so we managed to strike a deal with the trustee for the insolvency so that the DLC would be released and we would still get royalties.

Nevertheless, Awesomenauts initially didn’t sell all that well on consoles and it took long before we got any royalties at all. We were nearly out of money but had one more card to play: a Steam port of Awesomenauts. Finances were so tight that we couldn’t pay ourselves anymore for a short period. We continued to pay our employees though, so only the founders were hit.

Then in August 2012 Awesomenauts launched on Steam and this version turned out to sell way better than the console versions. We were saved! And we had gotten lucky again with our publisher: since DTP was insolvent, they couldn’t pay for development of the Steam port of Awesomenauts, and thus we got the full rights to that version.

Awesomenauts kept doing very well so we supported it for 5 more years with tons of additional content. It also allowed us to finally switch what type of company we were: we switched from being a V.O.F. to a B.V. These are Dutch legal terms so let's not go into the details here. What it comes down to, is that a V.O.F. is strongly tied to the owners’ personal finances. If the company goes bankrupt, so does the owner personally. Being a B.V. is much safer, since now the company can go bankrupt without giving creditors the right to come after your personal belongings as well.

Being a B.V. does come with a requirement here in the Netherlands: unless you have good reason not to, the company needed to pay the active owners at least €2300 per month (after taxes). So in February 2013, six years after we started the company, we finally started to make a wage significantly higher than minimum wage. And even then it wasn’t that much: this excludes some insurances that are standard for employees but not for owners, and for me personally as a programmer: I’m pretty sure I could have made more had I worked elsewhere.

As far as I can tell, most game startups take several years to become financially successful. I think it might have taken us longer than most, but we made it at all and that’s already special. In fact, since the 'indiepocalypse' happened a few years ago most people who start a game company never manage to make a living at all (as I've previously said: the future of indie is amateur). With Ronimo we were lucky that we happened to start our company at a time when indie was hip and happening and it was relatively easy to reach players. Today, competition is much tougher than it was when we started, so chances of success are lower as well.

What’s the moral of this very long story? It’s simple: to start a game company, you don’t need just skill, vision and bravery, but also perseverance and a willingness to make little money for a long while.

The challenge of finding enough playtesters

I recently watched Jan Willem Nijman's great talk on The Art of Screenshake and noticed an interesting YouTube comment to that video by someone named SquidCaps. SquidCaps mentions that for an unknown developer, it's really hard to find playtesters who actually test regularly. I agree that this gets a lot easier the more well-known you are, but I think it might also help to try a different approach to playtesting. So I figured it would be interesting to discuss how we approach playtesting at Ronimo and how to find playtesters.

Let's start by having a look at SquidCaps' comment. It's quite long so I've selected only the parts that I'm going to reply to:

Heh, "let people play your game and iterate".. quite a bit easier to say when you have plenty of gametesters already in the office.. For solo, unknown developer, having just ONE game tester that suffers 10 minutes per week is too much.. What you need is full game, with menus, high scores save games etc, basically a beta before you get any testers and then you get plenty of them.. When it's still in alpha and the biggest, most revolutionary stuff is happening, then you are alone. Something that developers who are already successful almost always forget; you get plenty of free resources at one point. [...] The truth is that your mates play for a while but without actual team behind you, you can't support them enough, interest dies down and soon, you see that no one downloaded latest build.. [...] I've been on half a dozen playtesting groups with hundreds of members and they all fail.. The sad truth is that no one cares until you are almost done. big teams have people who they employ that can do playtesting and can even afford to pay for playtesting.. [...]"

Playtesting versus QA

Before actually getting into SquidCaps' comment, I'd like to start with making a clear distinction between playtesting and QA (Quality Assurance, not to be confused with Q&A which means Questions & Answers). QA is all about finding bugs, while playtesting is all about making the game more fun, more understandable and finding the right difficulty curve and balance.

QA is usually an extremely boring and repetitive task. For example, in our game Awesomenauts we've had cases where we hired people to systematically test whether all upgrades in the game function correctly. Awesomenauts has around 1200 different upgrades, so you can imagine that systematically testing them all is not a fun job. Another example of something that's done in QA, is trying to walk into walls to see whether collision is correct everywhere. This usually involves running into all walls in a game and is an incredibly monotonous thing to do. Since QA is so little fun, it's usually not done by volunteers or friends, but instead by professional testers who get paid to do this. Often QA is outsourced to specialised companies in low-wages countries. An alternative is of course that the devs do such testing themselves.

The goal of playtesting on the other hand is to figure out whether the game is fun to play, whether players understand how to play the game and whether the difficulty and balance are right. This is a completely different way of approaching testing. Someone who systematically goes through all 1200 upgrades in Awesomenauts is never going to have fun, so QA's way of testing is not going to tell you anything about how fun individual upgrades are to play with. To find out whether something is fun, you need to let testers play in a more natural, unforced way. You can then just observe how they play and ask them afterwards which things they liked and which they didn't.



Now that we have a clear distinction between QA and playtesting, let's get back to SquidCaps' comment. SquidCaps talks about getting people to play new versions of the game every week. For most purposes of playtesting I think you shouldn't just let the same people play every week. Of course it's helpful, since you can ask them questions like "Is the game more fun now than it was last week?", but you won't get a wide diversity of opinions from a small group. Also, these playtesters play with a preconceived notion of the game based on previous playtests, so their opinions will not represent what fresh players will experience.

For these reasons for Swords & Soldiers 2, spread out during development we invited around 120 people into our office so that we could observe them playing. Every few weeks half a dozen people would come in on a Saturday, play for a few hours and share their opinions. We made sure these were different people every time, so that we would get fresh, unbiased opinions.

For figuring out whether the mechanics and tutorial are clear you also need fresh players every time. Anyone who has already played the game can't truly judge whether the tutorial explains it well, since they already know how it works beforehand. Same for difficulty: after practice you get better, so you can't judge anymore whether it's playable for someone who's new to the game. This is also why the devs themselves are horrible playtesters: they know exactly how the game is intended and are usually really good at it, so they can't judge difficulty and clarity.



When to playtest

This is where I totally agree with SquidCaps: playtesting should start early on: "When it's still in alpha and the biggest, most revolutionary stuff is happening." I regularly encounter developers who think you need complete and bug-free gameplay to do your first playtesting, but there's no reason to wait that long. As soon as you've got something playable, you can let others play it.

Sure, in an early stage you probably need to sit next to the tester to explain a lot of stuff, but you can still learn a ton about which parts of the game are fun and which are not. It might even happen that the playtesters don't enjoy the core but really enjoy some other aspects of the game and this might lead you to change the direction of the game altogether. Or maybe they share some great ideas that you didn't think of yet. If you're wondering "Should I wait for the game to be more complete before testing?", the answer is almost always "Nope, just test anyway and see what you can learn!"

Finding playtesters

This is SquidCaps' main point: it's really difficult to find playtesters if you're not successful. I'd like to add to this that it's even difficult to find playtesters when you are successful: at Ronimo we've sold millions of copies of our games, but finding playtesters is still sometimes hard and takes time.

I think the best playtesting happens in person. That way you can see what the other person is doing and ask questions or help out if needed, especially when testing an early version of a game that doesn't contain a tutorial yet and might be full of bugs. That's why SquidCaps' approach of sharing builds online and joining playtesting groups is not something we'd consider until very late in development. We usually only share builds online for players to test in case of betas, like we do with Awesomenauts updates.

Instead, we mostly search in our local communities. For example, I occasionally talk at game dev schools here in the Netherlands. Whenever I do that, I end my talk with asking people to sign up for playtesting. Usually around 20% of the students in the audience do so, so we now have a significant number of email addresses of potential playtesters we can invite. Unfortunately in practice few of them actually respond, but it's still enough to get dozens of playtesters for a game, usually spread out over a bunch of Saturday afternoons.

When our mailing list runs dry, we look further. We've asked around at local game development schools, where students are often eager to visit a real game dev company and play a secret, unannounced game. We've also asked on social media, hoping enough gamers from the Netherlands follow us to actually get some visitors.

In total these usually get us enough playtesters. However, you can go further than that when needed. Here are some examples:

• I know a game company where the devs took an iPad version of their game, went to Gamescom and let people who were standing in line for some big triple-A game play their game. Queuing people don't have anything better to do so it's rather easy to get them to play for as much as fifteen minutes or more.
• Similarly, you can go to a random public space with a laptop and just ask people to play. If you're a student this could be the hall of your own school, or it could be a station, or anywhere really. This requires getting over some awkwardness when approaching strangers, but really, this is very doable.
• If you've got some budget you can also get a booth at a game event like Gamescom or PAX. Booths are not just nice for marketing but also for playtesting. Lots of different people will play your game and you'll get the most honest feedback in the world: the moment they don't like it anymore, they'll just walk away. Painful, but very useful information.
• You can organise local playtesting events together with other devs. Here in the Netherlands Adriaan de Jongh organises PlayDev.Club, which is simply a gathering of local devs who play early versions of each other's games and share feedback. If there's nothing like that in your community, you can organise something like that yourself, as long as you're in an area that has enough game devs.

None of these approaches will easily get us people who play our game for a huge number of hours. However, if our game isn't that fun yet then maybe that shouldn't be our focus and the focus should be on making that first hour super awesome. Once the core game is a lot of fun, it becomes easier to find playtesters who are willing to come back and invest more hours to get to the advanced tactics and pro skills.

While all of these ideas are easier if you're a more well-known developer and are better connected, with enough effort an unknown dev can also find playtesters in such ways. Before we released our first game Swords & Soldiers we also managed to find playtesters, despite being an unknown studio at the time. Finding playtesters takes initiative, creativity and effort, but in most cases it's doable even for those of us who aren't well-known.

These were some of the things we do at Ronimo and that I've heard from other developers. How do you find playtesters? What are your challenges and have you got any clever tricks?

Entertaining players while waiting for matchmaking

In a game where high quality matchmaking is important (like competitive team-based games), waiting times to find suitable opponents are often unavoidable. Today I'd like to discuss the problems we had in Awesomenauts with our initial approach to this and how we made waiting a bit less boring later on.

Until the launch of the Galactron update in 2016, this is how it worked in Awesomenauts: when you started searching you got into a matchroom right away. You selected your character, and then you had to wait in the loading screen until the match was full with 6 players. This could take several minutes and there was no interaction possible whatsoever: just a loading screen that says the match isn't full yet. To show progress we did have six tickboxes that showed how many players had joined and whether they had already selected their characters, but that was it.



A static screen with no interaction possible is probably the most boring type of waiting imaginable. Compare this to current Awesomenauts, where you wait in the menus instead of in a loading screen. Still not ideal, but this means that while waiting you can chat with other players, check out the skills and items of all characters and watch replays and live matches. Awesomenauts has a system where it lists the ten most exciting matches happening right now and also automatically selects a match of the day that you can watch. We hardly advertise watching replays while waiting though, so I think many players don't realise that you can watch a live match or replay while waiting for matchmaking.

An important thing to realise when thinking about waiting times is that on PC, players can simply alt+tab and browse the internet while waiting. This isn't possible on console, but there's always that other option: mobile phones. I don't have any statistics on this, but I wouldn't be surprised if a lot of players ignore menus, replays and chat during waiting times and just randomly browse the internet instead.

While I think current Awesomenauts is a huge improvement in terms of diversions while waiting for matchmaking, I don't think it's ideal. Waiting times for a proper match can be rather long (which is unavoidable if you don't have a giant playerbase and prefer better match-ups over quicker matchmaking) and clicking through menus isn't the best entertainment in the world. I like the solution that PlayerUnknown's Battlegrounds has: players get thrown into a little area where they can walk and jump around, punch each other, voice chat and generally goof around a bit. It's still clearly a waiting area, but it's so much more fun and interactive than a menu or a replay.



Even better is to have some kind of mini-game while waiting. During early development of Awesomenauts we experimented with having a little death match arena where you played until the real match started. It's similar to what PlayerUnknown's Battlegrounds does, but even more game-like since it's real deathmatch. I can't quite remember why we decided not to put this into the game, but I imagine the mean reason was probably a lack of time: we were making a really big game with a small team and needed to cut features in order to finish it before funds ran out.

There might also have been concerns internally that it might be frustrating to be in a deathmatch game and then we thrown out into the main game all of a sudden. Knowing that it can end any moment might potentially make that deathmatch more frustrating than fun. In Swords & Soldiers we solved this frustration by letting the player do single player while waiting and storing the state of that single player as soon as an online match started. This way the player could continue the single player session after having finished the online match. However, this approach doesn't work with an online deathmatch. Still, I think having gameplay instead of menus is probably preferable anyway.



Despite all of this I do think we had some nice touches in the original waiting screen in Awesomenauts. One is that we showed the maximum waiting time left. Waiting for a few minutes is a lot more acceptable if you actually know how long you're going to be waiting than if you don't know whether you need to wait one more minute or ten. If after a few minutes the match was still not full, it would just start with fewer players and add bots to complete the teams. This way the player had a guarantee that when the timer ran out, gameplay would definitely start.

In the new matchmaking system we also want players to know how long they're going to wait, so we still show a number that says how long it takes until the next matchmaking round happens. Only now it's shown in the main menu instead of in the loading screen. This can be frustrating if the time is long (worst case it can be as much as 7 minutes), but at least you know what you're getting into.

In the waiting screen of the old version of Awesomenauts you also heard the theme song of the character you had selected. Every character in Awesomenauts has their own jingle and this adds loads of personality to the game. Since this was basically the only entertainment during this waiting screen we even made these songs longer: jingles for the initial characters were only around 20 seconds, while later on we started aiming for 1:30 minutes to reduce repetition.

In the current system where you don't select a character until the match is full we do miss this great opportunity to let the character jingles shine. Instead you now only hear a short bit of the character jingle after selecting the character. The other way to hear these jingles is in the menus while browsing character stats. Having less focus on these awesome theme songs is a pity.


Ideally your multiplayer game has an infinite number of players and you can find equally skilled opponents right away. However, very few games live in this ideal world, so everyone else needs to think cleverly about how their matchmaking works. Just building basic matchmaking and assuming it'll work out isn't going to cut it. If you're interested in reading more on this topic I recommend reading my previous post on designing matchmaking for non-gigantic communities as well.

In the end I think the main reason we ended up with that waiting screen in Awesomenauts for years is that we underestimated how hardcore our community would be. We had designed Awesomenauts as a casual, fun alternative to the other MOBA games. We thought starting with bots right away and adding players as soon as they came online was way more fun than waiting for a full match. Our players disagreed: joining a match that's already in progress is a disadvantage since the bots might have already lost some ground by the time you replace them. Matchmaking issues quickly became the number one complaint about Awesomenauts in our community, so we increased the waiting time before a match actually starts to 2 minutes (or less if the match is already full). This did increase the chance of everyone being there at the start, but we still got complaints about matches not always being full, so we increased the waiting time even further to 4 minutes.

Since we thought we were making a more casual game we hadn't anticipated that our players would prefer long waiting times to be able to play in a more competitive way. We did adjust the system based on this feedback, but the result was waiting in a loading screen. I'm glad we got to improve that situation when Galactron launched later on.

Texture formats for 2D games, part 4: Overview

In my last three blogposts I've discussed the details of various texture formats. Now that we've seen them, it's time for an overview. Below you'll find a big table that lists the properties of a lot of different formats and shows their results. I'll also discuss some final considerations on performance.

The important thing here is to realize that there is no perfect solution: every choice has its own drawbacks, so even with the same art style you might end up with different texture formats depending on the platform. These are the main arguments to consider:

• Quality
• Size in video memory
• Size on disk
• Download size
• Loading time
• Framerate
• Development time

Most of these are pretty obvious and I've already discussed quality and size in video memory extensively in my previous posts. The reason I'm listing them here is that it's important to keep in mind that you can mix and match formats for different goals.

There are also more complex things that might matter to specific games, but if things like memory bandwidth are an issue then you are probably making an extremely complex game and hopefully know more about it than I do anyway.

Let me give an example of mixing formats to achieve a specific combination of desired properties. For the original version of Swords & Soldiers 1 on the Nintendo Wii we wanted to minimize size on disk and size in video memory. In video memory we used palette textures, but on disk we also ZIPped those. ZIP cannot be used by the videocard but it makes textures a lot smaller. The downside of this is that unZIPping costs additional loading time when starting the game. However, I didn't care much about loading times because the Wii was quite fast compared to the amount of disk space available for downloadable games, so loading times were going to be fine anyway.

Here's the big overview this blogpost is all about. It compares DXT, ETC, PVRTC, palettes and several more basic formats. Creating these was a lot of work so you'd better click them for a good look! ;)

Click for full resolution

Click for full resolution

If there are any mistakes in the descriptions please let me know in the comments so that I may correct them!

An interesting note here is that Android devices differ so much that texture format support varies from phone to phone. Apparently the solution is to either only use ETC1 and uncompressed formats (since those are supported on all Android devices), or to create different versions of the game using different texture formats per type of phone.

It's important to realise that not everything is always what it seems. The benefit of saving your exact texture format on disk (through DDS or TGA instead of something like JPEG) is that you can load the texture right into video memory. You might think this means fast loading times, but this is not always the case: if reading from disk is slow (for example when reading from a DVD) then this might turn out to be a bottleneck. If your processor is fast and your disk is slow then using ZIP or JPEG might actually give you faster loading times, despite the additional processing needed. Note that in the case of Swords & Soldiers 1 this was not the case: the Wii had a small but very fast hard disk.

One final consideration I'd like to mention is framerate. In most cases texture formats don't really influence framerate: the performance bottlenecks are usually fillrate, polygon count, post processing or something on the CPU. As long as all the textures being used all fit into video memory simultaneously they won't influence performance much. As soon as you grow out of video memory however, you're in trouble. On console your game might crash or show broken graphics due to this. On PC you're less likely to see anything so obvious: PC drivers can start swapping textures between video memory and normal RAM. This is devastating to performance but you might not notice this if you're working on a fast development PC. Be sure to keep a close watch on your texture budgets, even if everything seems to still work fine on your own PC!

Texture formats can also influence fillrate. When reading the texture it might get cache misses, slowing down the GPU. I won't go into too much detail here, but the thing to keep in mind is that making your textures much higher resolution than how they're shown in-game might reduce the framerate. If you zoom in and out a lot then mipmapping is a good solution to solve this. It also helps a lot to use a texture format with few bits per pixel, like DXT1.

Some hardware (including some of the current gen consoles) also support tiled textures. Normally a “tiling texture” refers to a texture that can be repeated, but that shouldn't be confused with tiled texture formats: tiled textures in this case refer to a certain memory layout of the texture that reduces cache misses. I won't go into detail on that here either, but if you're running into performance problems due to slow texture reads it might be worthwhile to check whether your specific platform supports tiled texture formats.

Each game and platform has its own requirements and I hope this series of posts has helped you understand the various options for handling textures. Finally, for those who don't have time to seriously look into this and just want some quick and dirty advice: if you're on PC or console DXT1 is usually the best option, or DXT5 if you need alpha.

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 3: DXT and PVRTC

PS. We're looking for interns for the coming period! We have openings in the fields of C++ coding and 2D art! Check here for more info: internships at Ronimo. Note that a basic understanding of the Dutch language is a requirement.

Texture formats for 2D games, part 2: Palettes

After last week's introduction to texture formats we are going to look at palette textures today. Palette textures are an interesting and underused option for 2D games. Using them is quite a hassle since normal videocards don't support them, but for certain art styles they offer high quality and small texture size.

Palette formats are similar to GIF files. The idea is that we have a palette, a list of all the colours in a specific texture. In the actual texture we don't store the colour of each pixel, but rather a reference to the palette. If the texture doesn't have a whole lot of colours we can get away with using only 256 different colours. References to these can be stored in 8 bits per pixel, so this format is 75% smaller than uncompressed RGBA.



Palette textures are particularly useful for cartoony styles with flat shading, since those have fewer colours per texture. If your textures have more than 256 colours, you can reduce the number of colours. Depending on the art style this loss in quality might be acceptable. For a style with lots of colours and gradients, it probably isn't.

Most textures in Swords & Soldiers 1 on Nintendo Wii were stored using palettes. Some textures even had few enough colours that we could get away with only 16 different colours in the entire texture. This means we needed only 4 bits per pixel. That's 87.5% smaller than uncompressed RGBA! This would bring a 4096x4096 texture down from 64mb to 8mb. Of course such heavy compression is only suitable for some art styles and some textures.





The big caveat is that most videocards don't support palette textures directly. Older videocards like the one of the Nintendo Wii support it, but none of the modern Nvidia, AMD or Intel cards do. Swords & Soldiers 1 was originally a Wii game so we could easily use palette textures there.

This doesn't mean that using palette textures is impossible, just that it's more involved. It's quite easy to write a pixel shader that uses the colour from a greyscale texture as an index for a lookup in a 1D palette texture.

The problem with doing this yourself is that you can't use texture filtering any more. Interpolating palette indices results in random colours. To implement standard bilinear filtering you need to sample and interpolate the colours yourself in the pixel shader. Including the lookups in the palette this means 8 texture reads per pixel. If you happen to also need trilinear filtering for mipmapping this increases to 16 texture reads per pixel. Luckily not all 2D games need mipmapping, but still: 8 texture reads per pixel is significant and costs performance. However, the fun part is that many 2D games have plenty of performance to waste. If this is the case for your game and you have the time to write a good pipeline for them, then palette textures might be an excellent choice.



An interesting side effect of reducing the number of colours for a palette texture is that it makes ZIPping the texture much more effective. With less colours in the texture there is less variation so it can be compressed more effectively. This only helps for download size and for the size of the texture on disk: videocards can't handle ZIPped textures so the texture needs to be unzipped before it goes into video memory.

We used this extensively in Swords & Soldiers 1 to reduce download size. Since the Nintendo Wii had an extremely small hard disk keeping the install size of the game small was really important. For this reason we reduced the number of colours even in cases where it didn't make the texture itself smaller. For example, the size in video memory is the same for a texture with 200 colours or 256 colours. However, the texture with only 200 colours can be ZIPped further. Often there is no visible quality loss when reducing the number of colours a bit further, so we did this with a lot of textures on the Wii version of Swords & Soldiers 1.

When saving an image for the web in the GIF format it's common to turn on dithering. Dithering makes a palette texture alternate between two different colours in a noisy pattern to achieve what looks like smoother gradients with fewer colours. This works quite well for the web, but is totally unsuitable for games. Dithering makes the art flicker like crazy when an object moves around, so in games it can only be used on objects that are rendered pixel perfect, like the backdrops in old adventure games.



A huge benefit of palette textures is that team colours and colour variations can be done extremely efficiently. By simply swapping the palette you can change all the colours. This costs hardly any memory or additional performance.

In Awesomenauts we don't use palette textures so we have to store each character twice: once for the red team and once for the blue team. With palette textures this wouldn't have been necessary. To add to the fun this would also have allowed us to let the player customise his team colour (not that we would want that in a team-based game in which the visuals are all about readability). Lots of other fun tricks can be achieved through clever usage of palette swapping.





Since palette textures aren't supported by videocards by default they are quite impractical to use. Their limitation of a maximum of 256 different colours per texture is also very limiting. However, with certain art styles this technique will give you powerful, lossless compression and easy colour swapping, unique benefits that no other texture format can provide.

See you next week for a look into the master: DXT texture compression!

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 3: DXT and PVRTC
-Texture formats for 2D games, part 4: Overview

Designing matchmaking for non-gigantic communities

Most multiplayer games die within a week. Not because the multiplayer doesn't work, but because there aren't enough people playing online. If you look for opponents and don't find any, then the multiplayer mode might just as well not have been made. This is even more of a waste because online multiplayer is so much work to develop, as I recently explained. The vast majority of online multiplayer games ever made isn't playable any more because of this. Partially this is because not all games can be a success, but there is a much more important reason: often the matchmaking is poorly designed for a smaller playerbase. With clever choices multiplayer can flourish even with a tiny community.

For an average indie game that is doing okay but isn't a big hit it is pretty decent to have 40 simultaneous players a few weeks after launch. Our own game Awesomenauts did really well so our daily peak is usually above 1000 players, but expecting such numbers is unrealistic for most games.

Let's consider a four player multiplayer game that has three game modes. We press the quickmatch button and the game starts looking for opponents. If a match takes on average 30 minutes and there are 40 simultaneous players then a player starts looking for a match once every 45 seconds. Since there are three game modes your mode will have one player searching once every 135 seconds. Waiting for a complete match of four players then takes almost 7 minutes.

Seven minutes! Few players are willing to look at a "Searching" screen for that long, so most will just quit and play something else. If a player concludes your game is dead he probably won't try again later and is lost forever. Whatever playerbase you had will quickly disappear. So many multiplayer games die because there aren't enough players for a good experience.

However, with clever design choices this fate can be averted. 40 simultaneous players would have been plenty for a good experience if matchmaking had been designed in a different way.



Reduce game modes

Game modes split the community. If half of your players wants to play Domination while the other half wants to play Deathmatch, then they all have only half as many opponents to play with. In the example above removing two game modes would have reduced the waiting time to 2:15 minutes, which might already have done the trick. Even the gigantonormous League of Legends has removed less popular game modes because there weren't enough players for a good experience.

For exactly this reason Awesomenauts has only one core game mode. There is a custom game option where users can set up all kinds of weird game modes, but these aren't part of the core matchmaking and thus only playable through friend invites. This way there are extra options for players who want them, but there is only one core mode and it has plenty of players to matchmake with. (For a more detailed analysis of player spread, check my blogpost on why good matchmaking requires enormous player counts.)

If you really want to have more game modes, you can also choose to force players to play whatever is available. Maybe players can select a preferred game mode and the matchmaker looks at all the preferences and tries to find the best match-up. If there aren't enough players in your favourite game mode, then you just play a different game mode. The downside of this approach is that players would probably complain a lot that they aren't put in their favourite game mode. Not having an option at all might in some cases feel better than having an option that you can't actually play...

Allow solo play while waiting

The above approach tries to reduce the waiting times. An alternative is to make waiting more fun so that players are willing to wait longer. In our 2010 game Swords & Soldiers we allow players to play all single player content while waiting for an opponent. If you start the matchmaker a little icon appears in a corner of the screen and you can just play some skirmish against the computer until another human becomes available to play with. This works wonders: players are willing to wait much longer, increasing the chance they actually find an opponent.

This can be improved further by having content that is fun to play repeatedly. A story campaign isn't so much fun to play every time while waiting, but a highscore mode is. In Swords & Soldiers I usually played the endless Survival mode while waiting. Of course it sucks to be thrown out of your highscore run because an opponent is found, so our solution was to auto-save the solo match when starting a multiplayer match. You can continue your single player challenge after the multiplayer has ended.

A while ago a colleague of mine tried playing Swords & Soldiers online. Even though the Steam version of the game is almost five years old now and there are only a few people playing, he got three different opponents in just an hour. There were never more than four people playing Swords & Soldiers simultaneously that evening, so he got a surprisingly good multiplayer experience with such a microscopic community. Amazing!



Playing against bots

For Awesomenauts we chose a different approach. Here we let the match start even if there aren't enough players for a full 3vs3 match. The missing spots are filled with bots until more players are found. The result is that even if there are very few players online, you never have to wait long and can always start playing.

Initially Awesomenauts just started a match right away regardless of how many players were found, removing waiting times altogether. The big downside of this is that it doesn't work well with a competitive mentality: it feels unfair if bots already lost a tower before you even joined. For this reason we later added waiting time, but with a countdown timer that shows the maximum waiting time left. Since Awesomenauts has plenty of players most of the time the match will be full well before the timer runs out, so you rarely start with bots.

This drop-in aspect of the game is a constant source of complaints from our userbase, but players often don't realise that without it, Awesomenauts might not have survived its first months. It took nearly half a year before our playerbase reached a constant good amount on PC and even with those smaller numbers there were never long loading times.



Adding more players

So far I have focussed on making the most out of a your existing players. Another important approach is to maximise the numbers of players. This can be done in various ways. Many multiplayer games are free-to-play, increasing the size of the playerbase (although there are also plenty of free-to-play games that don't actually manage to gather a significant playerbase).

The developers of Verdun chose a hybrid approach: at some point their game had a free browser version and a paid Steam version and they all played together online. The free players didn't bring in a lot of money directly, but they made the game more fun for the Steam players, increasing sales there.

Even when not going free-to-play it is a good idea to not make a game too expensive. The average indie game seems to have recently gone up in price, but I would heavily advice against pricing a multiplayer-only game above $15: this will decrease the size of the playerbase. Selling more copies is more important for the long term income of a multiplayer game than the short term income of a higher price. Awesomenauts is $10 and we often drop its price heavily during sales, by as much as 90%. This boosts the playerbase enormously, more than making up for the low price.

Extreme measures

If you want to make a multiplayer game playable with below 10 simultaneous online players you might have to resort to extreme measures to keep something going. Several devs told me they promoted a specific moment, like one specific evening every week, as multiplayer evening. This way everyone comes online at the same moment, creating a somewhat lively community once per week. One dev even went as far as taking the multiplayer functionality offline altogether during weekdays, only allowing multiplayer during weekends.



I can imagine other, more subtle ways to get players online at the some moment. Like allowing players to send a challenge to other players who are near them in the leaderboards. The game then sets up a time for them to play against each other, giving them a good reason to come online at one particular time. Asynchronous multiplayer is also a good way to do this, but this only works with certain types of games. For highscore based games asynchronous multiplayer can be an excellent way of boosting the competition within the community.





There are many other ways to make the most out of a small community. For example, things like clever lobbies, a rematch option and showing the expected waiting time per game mode. Key is to consider matchmaking a real part of game design, something to brainstorm about and come up with creative solutions. If you just make something then you might end up killing your community much quicker than needed. If you aren't Blizzard or Riot then thinking about how to make the most out of a smaller online community is crucial to the success of your multiplayer game.

Luck and success in the indie business

Luck is an important part in the success or failure of any game studio. Why do some studios succeed while so many others never make a significant amount of money? Regardless of how good your theories are on what makes a successful business, you can never know for sure which games are going to be a hit. Games are entertainment and hit-driven and thus their success is inherently unpredictable. Luck cannot be controlled, but you can help it a bit by making the right choices. Looking at what many starting indies are doing right now, I think a lot of them don't think about luck enough. Here are some of my thoughts on the matter.

The success of a game is determined pretty much equally by three factors: the game, marketing and luck. Marketing and luck are just as important as the game you are making. If you do not market your game, then no one will know it and thus only a LOT of luck can make it a success. Similarly, if your game is not good enough, then it is also very unlikely to sell well.



While luck cannot be controlled, you can make such decisions that you need as little luck as possible. If you make an awesome game, do really good marketing and release it on the right platforms, then your chances are actually pretty good. But luck always remains a factor. Even the very best games can sometimes fail, and even the worst games sometimes become a hit. Anyone remember Psychonauts? It is considered a classic now, but sold hardly any copies at the time. On the other hand Flappy Bird was an enormous success, despite how crappy that game actually is.

When making your business decisions it is of course a good idea to look at what other companies are doing. What games sell, and why? However, it is a big mistake to attach too much importance to the outliers. Lots of people look at Minecraft and try to copy what it did, hoping to achieve similar success. But Minecraft is a one-in-a-million outlier. Of course Minecraft has some great mechanics, but it also required an enormous amount of luck to become that successful. The chances that you can achieve something even remotely similar are practically zero.

The same goes for Angry Birds and Candy Crush. It is not because of great talent that these games became such huge successes: they are well-made for sure, but there are tons of other games of similar type and quality that somehow did not become such hits. Before Angry Birds and Candy Crush became a success, there was no way anyone could have guessed that these would be the titles to become such big hits.



A strategy some studios use is to not make one big game, but instead make lots of small games and then hope one of those becomes as successful as Angry Birds. The reasoning behind this strategy seems to make sense: every game you release is a roll of the dice. Releasing more games gets you more rolls of the dice, increasing your chance at success.

I do not believe this really works. I think a single really good game has a much bigger chance at becoming a success than dozens of lesser games combined. Of course it is impossible to prove a theory like this, but I believe that a better game has an enormously larger chance of becoming a hit. If you can raise your game's quality from a 7 to an 8, or from an 8 to a 9, then you stand a much, much, much better chance. If you can somehow make a game that scores a 9.5 on Metacritic, then you can be almost certain it will sell like crazy. Even then you can never be sure though!

For this same reason I also do not believe in the 'fail early' strategy that some companies use, especially in combination with Early Access or free to play. The idea of 'fail early' is to release your game when it is only half of what it could be, and then see how well it does. If it does well, then you continue development and make it better. Otherwise you just drop the game and make something else. Like above, this allows a company to make more games and thus get more rolls of the dice. I do not believe that this works: the chance of the game becoming a success is infinitely better if the game itself is much better. That game that is dropped because the half-finished version did not sell well might have become a hit if it were actually developed into a good game, instead of a buggy or too small one.

(Note that I do think Early Access and soft launches can sometimes work, but for other reasons: they provide tons of testing and user feedback and it might also help fund the rest of development.)



'Chance' is also why big publishers can be relatively stable over time: they release a lot of big games, so the chance of them all failing is really small. This is the benefit of size, and it is a benefit that indie companies generally cannot have.

A good way to get more rolls of the dice is porting. If your game failed on one platform, it might still do really well on another, especially if that other platform has a different audience.

We have experienced this ourselves: Swords & Soldiers was a hit on WiiWare back in 2009. A year later we released an HD version of the game on Playstation 3, with added online multiplayer, but this sold very poorly. Then we released the game on Steam, and there it again sold really well. In hindsight one can come up with theories on why it failed on Playstation 3, but beforehand we had no idea. Every port is a new roll of the dice. Ports are much cheaper and faster to develop than completely new games, so porting is in general a good idea.



Luck cannot be controlled, but you can influence it. I would like to finish this blogpost with a great example of this: our own Awesomenauts. Awesomenauts is a big hit with around two million copies sold. Its success is partially due to its excellent release timing, which was pure luck.

Awesomenauts is a complex game to communicate. During the three years it took us to make the game, League of Legends appeared and became a gigantic hit. Suddenly our marketing became really simple: Awesomenauts is platforming League of Legends! This is a message everyone understood and that immediately had people intrigued with this interesting combination of elements. This helped our sales enormously.

There is no way we could have planned for this: the game took three years to develop so at the beginning we had no idea what would happen in the meanwhile. This might make one think that the success of Awesomenauts was all luck no skill, but this not the case at all. More like the opposite! Awesomenauts has a unique concept, is large for an indie game and is high quality. We spent a lot of time on marketing and have so far released the game on four different platforms, giving us four rolls of the dice. All of these combined mean that our chances were pretty good to begin with. Still the game could have failed, and luck was the final push that we needed.

There are two ways to improve your luck: get more rolls of the dice by having more releases, or improve the chance of each roll by having better releases. I personally think each release should be the best possible, by making a remarkable game with good marketing, a fitting payment model and on the right platforms. You can also handle luck by finding an investor who is willing to invest enough to make several games, so that you get more rolls of the dice. There are many possible approaches and it is important to think about luck and make sure your chances are as good as possible.

This is the first post in a short series on the state of the indie business. Part 2 is more controversial and will hopefully stir up some discussion, as it is about what I think many indies are doing wrong.

Finding bugs through autotesting

Some bugs and issues can only be found by playing the game for ages in a single play session, or by triggering lots of random situations. As a small studio we don't have the resources to hire a ton of people to do such tests, but luckily there is a good alternative: a fun method is to hack automated controls into the game and let the game test itself. We have used this method in both Swords & Soldiers and Awesomenauts and found a bunch of issues this way.

Autotests are quite easy to build. The core idea is to let the game press random buttons automatically and leave it running for many hours. This is very simple to hack into the game. However, such a simplistic approach is also pretty ineffective: randomly pressing buttons might mean it takes ages to simply get from the menu to actual gameplay, let alone ever actually finishing any levels. It gets better if you make it a little bit smarter: increase the likelihood of pressing certain buttons, or even just automatically press the right button in certain menus to get through them quickly. With some simple modifications you can make sure the autotesting touches upon many different parts of the game.



This kind of autotesting has very specific limited purposes. There are a lot of issues you will never find this way, like if animations are not playing, texts are not displaying, or characters are glitching through walls. The autotester does not care and keeps pressing random buttons. Basically anything that needs to be seen and interpreted is difficult to find with autotesting, unless you already know what you are looking for and can add a breakpoint in the right position beforehand.

Nevertheless there are important categories of issues that can be found very well through autotesting: crashes, soft-crashes and memory leaks. A soft-crash is a situation where the game does not actually crash, but the user cannot make anything happen any more. This happens for example if the game is waiting for a certain event but the event is never actually triggered. Memory leaks are when the game forgets to clean up memory after usage, causing the amount of memory the game uses to keep rising until it crashes. Especially subtle memory leaks can take many hours before they crash and are thus often never found during normal development and playtesting.

Another category of issues that can be found very well through autotesting is networking bugs. This one is very important for Awesomenauts, which has a complex matchmaking system and features like host migration that are hard to thoroughly test. Our autotesting automatically quits and joins matches all the time, potentially triggering all kinds of timing issues in the networking. If you leave enough computers randomly joining and quitting for long enough, almost any combination of timings is likely to happen at some point.

Recently we needed this in Awesomenauts. After we launched patch 2.5 a couple of users had reported a rare crash. We couldn't reproduce the crash, but did hear that in at least one case the connection was very laggy. Patch 2.5 added Skree, a character that uses several new gameplay features (most notably chain lightning and spawnable collision blocks). This made it likely that the crash was somewhere in Skree's netcode.



We tried reproducing the crash by playing with Skree for hours and triggering all kinds of situations by hand. To experiment with different bad network situations we used the great little tool Clumsy. However, we couldn't reproduce the crash.

I really wanted to find this issue, so I reinvigorated Awesomenauts' autotesting system. We had not used that in a while, so it was not fully functional anymore and lacked some features. After some work it functioned again. I made the autotester enter and leave matches every couple of minutes. Since I didn't know whether Skree was really the issue I made the game choose him more often, but not always. I also made the autotester select a random loadout for every match and made it immediately cheat to buy all upgrades. The autotester is not likely to accidentally buy upgrades otherwise, so I needed this to have upgrades tested as well.

I ran this test on around ten computers during the soccer match Netherlands-Australia. While we beat the Australians our computers were beating this bug. Using Clumsy I gave some of those computers really high artificial packet loss, out-of-order and packet duplication.

Watching the computer press random buttons is surprisingly captivating, especially as it might leave the match at any moment. Simple things like a computer being stuck next to a low wall become exciting events: will it manage to press jump before quitting the match?

Here is a video showing a capture of four different computers running our autotest. The audio is from the bottom-left view. Note how the autotester sometimes randomly goes back to the menu, and can even randomly trigger a win (autotesters are not tactical enough to destroy the base otherwise):



And indeed, after a couple of hours already three computers had crashed! Since I had enabled full crash dumps in Windows, I could load up the debugger and see exactly what the code was doing when it was crashing.

The bug turned out to be quite nice: it required a very specific situation in combination with network packets going out of order in a specific way. When Skree dies just after he has started a chain lightning attack, the game first sends a chain lighting packet and then a character destroy packet. If these go out of order because of a really bad internet connection, the character destroy packet can arrive first. In this case the Skree has already been destroyed when his lightning packet is received. Chain lightning always happens between two characters, so the game needs both Skree and his target to create a chain lightning.

Of course we know that this kind of thing can happen when sending messages over the internet, so our code actually did check whether Skree and his target still existed. However, due to a typo it also created the chain lightning if only one of the two characters existed, instead of if they both existed. This caused the crash. Crashes are often just little typos, and in this case accidentally typing || ("OR") instead of && ("AND") caused this crash.

Once we knew where the bug was, it was really easy to fix it (the fix went live in hotfix 2.5.2). Thus the trick was not in fixing the code, but in reproducing the issue. This is a common situation in game programming and autotesting is a great tool to help reproduce and find certain types of issues.

The statistics of our games, part 3: Code

In previous blogposts I shared the statistics of our games, talking about files and textures and about assets and audio. Today we get to the final part of this short series: code!

Code is where size matters most. Not because creating 751 different particle systems wasn't a lot of work for our artists, but because unlike with particles, every additional line of code makes every existing line of code more complex. No matter how many particle systems there are, when creating one, an artist only has to care about that single particle system. The rest hardly matters. With code, the opposite is true: the larger a codebase, the more complex it all becomes. Of course, object oriented design principles say everything should be separated as much as possible, and this is a goal we work hard for, but in practice that is just not always doable.

For example, the 15 characters in Awesomenauts all need to interact with each other. Any skill from any character needs to be able to handle interfering with any other skill correctly. With weird stuff like timebubbles, cocoons and chains, and more weird stuff for every new character, it becomes nearly impossible to truly untangle all the code into small, clear subsystems that don't suffer from the complexity of the rest of the code. Now add to that our goal to make everything editable by our designers in real-time while playing, and it just explodes.

This is why the 290.156 lines of code in current Awesomenauts looks like so much to me. Handling gameplay complexity in code is to me the biggest challenge in coding. It is something that is hardly taught at computer science schools and of all coding topics, this is the most difficult thing to do well, in my opinion. We have tons of discussions internally on how to structure gameplay code as well as possible, and it remains a fascinating and interesting topic that with experience can be done better and better, but always remains a complex challenge.

Note that another reason why Awesomenauts is so many lines of code, is that most of our tools are in-game, and are thus part of this count. Having in-game tools gives great features and a much better workflow, but also inflates the codebase quite a bit.



Let's have a look at the actual statistics:

Source code
Programming language	C++	C++	C++	C++	C++	C++	C++
Number of files	153	385	717	1077	215	2495	3221
Code lines (excluding comments / whitelines)	12814	35000	67790	112096	19220	216572	290156
Lines of comments	1067	3331	3568	7108	1530	12423	16986
Whitelines	2926	8356	14280	24977	4504	56457	73547
Total size	436kb	1204kb	2241kb	3866kb	712kb	7877kb	10912kb
Classes/structs/enums (approximately)	70	180	190	500	100	1050	1350
Average lines per file	109,85	121,26	119,44	133,87	117,46	114,41	118,19
Percentage comments	6,35%	7,13%	4,17%	4,93%	6,06%	4,35%	4,46%
Percentage whitelines	17,41%	17,90%	16,67%	17,32%	17,83%	19,78%	19,32%

An interesting thing here the difference in code size between Swords & Soldiers Wii and Swords & Soldiers HD. That is 65% extra code for essentially the same game! This extra code is spread out over three different topics: new platforms (PC/Mac/PS3), new control schemes, and, above all: online multiplayer. I have said it before and I'll say it again: adding online multiplayer as a feature to a game makes it twice as much work to program. These numbers show it, and our experience building online multiplayer in Swords & Soldiers and Awesomenauts definitely shows it. Online multiplayer is really complex and a lot of work to create! No matter how complex you think it is, if you have never made a commercially released game with proper online multiplayer (including invites and all that kind of stuff), then no matter how much work you think it is, you are probably underestimating it.

One thing I think is quite funny here, is how constant the number of white-lines is in all of these projects, despite having various different programmers working on them and many years in between. The reason for this is that we still use most of the coding standard I designed early, and this explicitly states how white-lines are used, since they are a form of communication and can be used to structure code. So no matter who codes at Ronimo, the pattern in using white-lines is always quite similar.

(As you might have guessed from this, our coding standard is very strict in comparison to what most other companies use. This is a very deliberate choice I made, so I might get back to why that is and share our complete coding standard in a future post at some point.)

This ends my analysis for today. As I said last week, I'd love to see such numbers from other games! So if you are a professional game developer and would like to share your stats, please do so! I'll collect whatever people send me and post the results here in a future article (assuming anyone sends their stats, of course). My email-address is at the top of the spreadsheet. If you don't feel like sharing specific things, then just leave those out, and only share whatever you are willing or allowed to. I did the same with some of the extra stats I added to the document. You can download the spreadsheet, just fill it in and send it back to me. I have added some extra fields for those who wish to share more. If you have extra categories you'd like to add, feel free to add them at the bottom. Here's the document:

Statistics Spreadsheet.xls

I counted my source lines and such with Microsoft Line Of Code (LOC) Counter. This tool does not give a whole lot of data, so if anyone knows a tool that can actually give more stats on code, then please let me know! I'd love data like number of classes, number of variables per class, average function length, number of functions per class, etc. I couldn't find a tool to get that kind of information, so let me know in the comments below if you do.

That's it with the numbers for now! I hope you enjoyed viewing these as much as I have! ^_^

The statistics of our games, part 2: Assets and audio

Last week I shared the first part of the statistics from our games. Today let's look at the second part: numbers about assets and audio. Plus a bunch of (hopefully) interesting contemplations and anecdotes about them. In fact, I had intended to also include stats about code today, but I typed so much text about all of this that I had to split it further. This series is now three blogposts instead of my originally intended two.

Before I continue, let me abuse this moment for a short commercial break by (again) marketing our Kickstarter campaign for the Awesomenauts: Starstorm expansion! Including PayPal pledges we have by now reached the first stretch goal (a new map) and are working towards the second stretch goal: Custom Games!

Now, let's get to the actual numbers!

Assets
Levels	1	1	42	42	5	3	4
Skeletal animations	12	82	n/a	n/a	0	n/a	n/a
Particles systems	2	10	43	43	2	526	751
Animation templates	n/a	n/a	n/a	n/a	n/a	1774	5582
3D models	835	2240	n/a	n/a	332	n/a	n/a
Text lines (per language)	?	?	1250	1611	?	2200	3200
Languages	1	1	6	6	1	6	6
Settings	71	267	2200	2200	183	22500	59820
AI/script files	n/a	6	83	103	106	44	69
Vertex shaders	8	22	0	3	12	3	3
Pixel shaders	7	22	0	14	25	32	32
Materials	146	1038	n/a	n/a	283	n/a	n/a

Here it becomes immediately obvious how ridiculously large a production Awesomenauts is. For almost all the numbers here, Awesomenauts is a big factor larger than the other games. That is why it took us a full three years of development to finish that game... Had we known it was such a monster production, we probably wouldn't have started working on it in the first place, but seeing what an enormous success it is now, this makes it totally worth it!

The other thing to notice here is how much Awesomenauts has grown since launch. Going from 8 to 15 characters is a big jump, as is adding a new map and skins. I have seen some questions as to why we are doing a Kickstarter for Starstorm, and I think these numbers make it quite obvious: there is just an enormous amount of work in creating all this new stuff! The 22 major patches we have done since release represent an enormous effort on our side, and to make an even bigger step now with the Starstorm expansion, we need new funding. And we are getting it: the Kickstarter has already achieved the main goal and the first stretch goal, so let's see how much further these numbers will grow in the coming period!

Comparing AI files in these projects is unfortunately pretty meaningless, since their structure and size vary too much. For example, in Proun AI files are simply recordings of me racing the track, each AI file costing only a couple of minutes to create. In Swords & Soldiers and Awesomenauts however these can be massive scripts, made by our designers in our AI editor (which has evolved quite a lot since the blogpost in that link, by the way).

The craziest number here is the number of settings in Awesomenauts. Almost sixty thousand! These settings govern the exact behaviour of all gameplay: weapons, skills, characters, turrets, etc. Many of those settings are set to neutral: for example, Lonestar's standard bullets don't have gravity, stun, silence or blind. So a large portion of these settings exist, but are not 'active', so to say. Nevertheless, those settings do exist. Managing so many settings became a big problem for our game designers, so a while ago we built a special dedicated editing tool for them. This greatly simplified categorising, searching and managing settings. This tool was built by our former coding intern Eric Castermans, who got a job at Triumph after he graduated. He is now working on the awesome Age Of Wonders 3, one of the games I am personally looking forward to most at the moment. The guys at Triumph demoed it to us recently and it is looking to be incredible fun, can't wait to play it myself!

Audio
Sound effects	58	166	89	89	39	288	530
Sound effects: size on disk	3.5mb	100mb	1.7mb	1.7mb	2.2mb	37mb	60mb
Voice samples	0	0	105	105	0	429	1180
Voice samples: size on disk	0mb	0mb	1.6mb	1.6mb	0mb	80mb	208mb
Music: number of songs	5	2	4	4	4	32	48
Music: total duration	13:59	9:43	9:59	21:48	9:33	1:17:35	2:03:29
Music: size on disk	12.7mb	13.3mb	2.6mb	20.6mb	8.8mb	97mb	146mb

I think the most surprising thing in these audio numbers is how short the soundtracks of Swords & Soldiers and Proun are, while this hardly bothered anyone while playing. If you listen to a lot of game soundtracks, this is something you might have be aware of: game soundtracks are often surprisingly short, without this ever being a problem during the game. For example, a boss fight with a one minute loop is often totally fine. So if you are working on your first game and think you need a full hour of music, then think again: you can probably do just fine with much less. (The more the better, of course, but that goes for many things.)

The duration of the current Awesomenauts soundtrack is quite bloated by the fact that our killing spree songs change into normal songs after about a minute. Those normal songs are also in the soundtrack, causing those parts to be double. So about one hour of music should be deducted from the length of the current Awesomenauts soundtrack for a fair comparison. In the launch version of Awesomenauts about 30 minutes should be deducted for the same reason.

These numbers also show nicely how everything becomes more complex as a game grows. If you make the same game with twice as many assets, it is much more than twice as much work. You can see this here in the size of the voice samples for Awesomenauts. This grew from 80mb to 208mb in the past year. 80mb is still an acceptable size to just put into memory entirely. With 208mb, it is getting to the point where having all of that in memory at once might be problematic for older computers. So as it grows even further, there might come a point where we need to build some dynamic streaming system for voice lines. This would depend on which characters are in a match, just like we have a multithreaded streaming system for character textures. When such a system becomes necessary we will need to store voices differently to make them easily streamable. We will also need to categorise them to know which file belongs to which character, and we will need to built that whole streaming system. A lot of extra work! This makes everything more complex while it remains essentially the same game, just with more voice lines.

One final thing to note here is how ridiculously small the Swords & Soldiers Wii soundtrack is on disk: only 2.6mb for 9:59 minutes of stereo music! And it actually sounded pretty good: we never got a single complaint about low sound quality. This was made possible by the OGG sound format, which can achieve astoundingly good sound quality at ridiculously low file sizes. In general, OGG is smaller and higher quality than MP3. Combine that with the fact that using an MP3 decoder costs licensing money, and I am quite surprised that MP3 is still used so much more than OGG.



That's it for today! Tune in next week for the final part of these statistics: source code!

Edit: Here are the other parts of this series:
The statistics of our games, part 1: General, files and textures
The statistics of our games, part 3: Code