Showing posts with label De Blob. Show all posts
Showing posts with label De Blob. Show all posts

Sunday, 15 November 2020

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.

Sunday, 6 October 2013

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! ^_^

Friday, 6 September 2013

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

Sunday, 1 September 2013

The statistics of our games, part 1: General, files and textures

As you might know, we are currently running our Kickstarter campaign for our big Starstorm expansion to Awesomenauts. While we were preparing for that, I was thinking about how much Awesomenauts has grown since launch, and how much further it would grow by creating the Starstorm. Being a programmer, I love numbers and started collecting data on just how much Awesomenauts has been growing. Today I would like to share the first half of those with you! Since I like comparing, I have also added the other games I have worked on: De Blob, Snowball Earth, Swords & Soldiers and Proun. Hopefully you will find this as fascinating to look at as I do!

But first, let me abuse this moment to blatantly market our Kickstarter campaign... ;) We have already reached our main goal, and there are still tons of fun things in the stretch goals, including releasing our editors for modding. So please help make those features possible by backing the Starstorm, and scoop up lots of goodies in the reward tiers!

Below are just our own statistics, so since I love comparing numbers, I would love to see what went into other games! If you are a professional game developer and would like to share your stats, please come back next week to download the complete spreadsheet, fill in any details of your own games you would like to share, and send them back to me! If enough people do this, I will do another blogpost in a while with all the stats that we will have collected.

Enough talk, let's get to The Big Table Of Data!



General

Developerpre-RonimoRonimoRonimoRonimomeRonimoRonimo
Release date30-06-06cancelled May '0815-05-0902-12-1022-06-1101-08-1228-08-13
Graphics type3D3D2D2D3D2D2D
Platforms for this versionPCPCWiiPS3 PC
Mac Linux
PCPC PS3
Xbox360
PC
Mac Linux
All platforms this game was released on at some pointPCnoneWii PS3 PC Mac Linux iOS Android 3DSWii PS3 PC Mac Linux iOS Android 3DSPCPS3
Xbox360 PC Mac Linux
PS3
Xbox360 PC Mac Linux
Time between first version and final version (might contain long inactive periods)5 months1 year1 year2.5 years6 years3 years4 years
Active development duration5 months1 year1 year2 years3 years3 years4 years

Let's first have a short look at what games we are comparing here exactly:
  • De Blob: This is the original student project that the later console games by THQ were based on. We made De Blob with a team of 9 students, of which 5 are among the 7 founders of Ronimo.
  • Snowball Earth: This was to be the first big project by Ronimo. We intended for it to be released as a disc-based console game, but we never found a publisher and it was cancelled after working on it for one year.
  • Swords & Soldiers Wii: Our first real game! This is the original version of the game as it launched on the Wii.
  • Swords & Soldiers HD: This is the port of Swords & Soldiers to Playstation 3, PC and Mac. It added HD graphics and online multiplayer.
  • Proun: This is my personal hobby project, so this is not a game by Ronimo Games.
  • Awesomenauts console, with patch 1.1: Awesomenauts as it is on console right now. This is not the launch version of the game: Coco and Derpl were added after launch in patch 1.1 and this version includes them. That makes this version functionally the same as the PC launch version of the game.
  • Awesomenauts current version: Awesomenauts as it is right now on Steam, on PC, Mac and Linux, with patch 1.22.
Note that "active development duration" does not simply equal how much work was spent making the game. Team sizes have varied enormously for these games. For example, Proun was mostly made by just me, and in my spare time, so Proun's 3 years of development are only a fraction of the 3 years of Awesomenauts development time.

Files

Size of all files in repository?5.5gb7.4gb28.3gb40.3gb97.4gb200gb
Files in repository?179791872336219310503495798288
Installed game size235mb426mb17mb282mb347mb500mb879mb
Files in installed game133110582?801974550716

As you can see here, our repositories are huge. 200gb for just the current version of Awesomenauts! The reason for this is that we store all files in the repository, not just source code. Photoshop files are often hundreds of megabytes and we store it all in the repository. This way everyone has quick access to everything, and it gets backed up automatically. When we started doing this during De Blob, over 7 years ago, SVN was still painfully slow, but by now computers have become so fast that we can do a repository of hundreds of gigabytes easily.

Size is hardly related to amount of work here: Proun has a 40gb repository because of the footage I captured for trailers, but in reality Swords & Soldiers is of course a much bigger production than Proun.

Note how few files the installed version of Awesomenauts has compared to all the other projects, especially taking into account that it is a much larger production (probably as large as all the others combined). Having few files in the installed game is a really good thing: reading 100 files of 10kb each is much slower than reading 1 file of 1mb, so the small number of files in Awesomenauts represents a big optimisation that made loading much faster.

The question marks, by the way, are simply because those games are pretty old and I don't have all the data at hand anymore. I might have been able to dig it up, but that just took too much time.

Textures

Textures260118858763431732504800
Total texture size72mb201mb55mb183mb210mb350mb833mb
Maximum simultaneous texture usage in video memory72mb201mb55mb183mb106mb200mb332mb
Sprite sheets (one sheet often contains several animations)n/an/a6768n/a125255

These numbers nicely show how little relation there is between megabytes and actual amount of work. Swords & Soldiers on the Wii uses only one third of the texture memory of Swords & Soldiers HD on PC and PS3, but these are in fact the same textures, only saved at a higher resolution and with a different compression algorithm. Since our artists had drawn the textures for the Wii version at a much higher resolution than what went into the game, doubling the resolution for the HD version cost very little time. So the numbers are much higher, but the actual amount of work is not. Keep this in mind for all the numbers in these tables: comparing them without context can result in some very wrong conclusions!

Another interesting thing here is the difference between 2D games and 3D games. I am a big fan of the subtle lighting one can get using pre-baked lightmaps, and these have been used in all 3D games here: De Blob, Snowball Earth and Proun. So of the 317 textures in Proun, 275 are actually lightmaps, totalling 150mb. It is important to keep that in mind when comparing to Awesomenauts, where textures are mostly hand-painted. So although Awesomenauts 'only' has 70% more texture megabytes than Proun, those probably correspond to 100x more work!

Since launch, the total texture size in Awesomenauts has increased much more than the texture memory usage. This is because most of those new textures are sprite sheets for characters and skins and we have a dynamic texture streaming system in place that only loads those textures that are actually being used. A whopping 500mb of all textures in current Awesomenauts are character sprite sheets that are streamed this way.

That's it for today! I have collected many more numbers, so next week I will be back with the second half of this post, elaborating on assets, sound and source code. See you then!

Edit: Here are the other parts of this series:
The statistics of our games, part 2: Assets and audio
The statistics of our games, part 3: Code