A tool for analysing colour schemes

During the Christmas vacation I read the fantastic book Color and Light: A Guide for the Realist Painter by James Gurney. It contains a number of really interesting ideas about colour schemes, so I was curious how these relate to existing games. I was especially curious about Proun: when creating the art for this game I did not know anything practical about colour theory. I just tweaked the colours until they looked good. Apparently this was successful, since reviewers were extremely positive about Proun's visuals and vibrant colours. How then do the colour schemes in Proun relate to Gurney's colour theories? To analyse this I have developed a simple little tool that visualises the colour scheme in an image. You can download the tool and source further in this post. So let's have look: what are Gurney's ideas and how do they relate to Proun's art?

The concept I found most interesting in Gurney's book is gamut mapping. To understand this we first need to know the colour wheel. This shows all the colours in a circle. Towards the inside the colours desaturate towards grey. This means that the strongest colours are at the outside. The colour circle is independent of light/dark: each of those colours can still be made lighter or darker.



The idea is that you pick a few colours and only use the colours that can be mixed using those colours. This limits the number of colours that can be used in an artwork. Usually one would pick three colours. This creates a triangle on the colour wheel and we can only use the colours inside the triangle. The area of allowed colours is called the "gamut mask".



The big revelation to me is that this means that only the three chosen primary colours can be fully saturated. All other colours will be less saturated since they cannot be on the outer rim of the colour wheel, no matter how bright the chosen primary colours are. This limits the colour usage and keeps an artwork from becoming a "fruit salad" as Gurney calls it.



The colour gamut can even be on just one side of the colour wheel, greatly limiting the colour scheme in an artwork. While normally an artist would need to be careful not to use colours too much, when using a limiting gamut it becomes possible to aim for using the brightest colours allowed within the gamut and still achieve a harmonious whole.

I suppose experienced artists might have many other tricks to achieve good colour schemes, and there is probably some really good art that totally doesn't fit what Gurney explains. Nevertheless the colour gamuts seem like a very sensible and useful tool to me. This made me curious: how do the colour schemes in Proun relate to them?

To be able to exactly analyse the colour schemes of existing art I have hacked together a little C# tool: Joost's Colour Wheel Visualiser. It simply loads an image (JPG or PNG) and shows which parts of the colour wheel are used in that image. You can download the tool (including source code) here:

Download Joost's Colour Wheel Visualiser.zip (24kB)
(Note that a recent version of .NET is needed to run it.)

Now that we have this tool, what do Proun's colour schemes look like? Let's have a look.



Surprisingly, it turns out that most of these form quite clear triangles. Apparently while searching for colours that look good together I accidentally used Gurney's theories quite exactly! I happen to even vary between the schemes he gives as examples: some gamuts are mostly on one side of the colour wheel, while others are quite exact complementary schemes.

One thing I was never really satisfied with in Proun is the colours of the opponents. Those are only seen all together at the very beginning of a race and I always felt like they didn't look good together. When analysing those colours using my Colour Wheel Visualiser it quickly becomes clear why. As you can see in the image below their colours are random splotches on the colour wheel, unrelated to the other colours in the image.



I think I might have been able to fix this problem by using different colours for the opponents depending on the track, so that I would have been able to match their colours to each track's colour scheme. Next time, Gadget!

I also tried my tool on screenshots from Awesomenauts, which was designed by the Ronimo art team. In the images below you can see that the colour scheme is all over the place. It really is an explosion of colour, as is fitting for the over-the-top eighties themes of Awesomenauts. Nevertheless you can see that even in the top image the colour scheme ignores large parts of the colour wheel, so even there the colour usage is limited. I think our artists did a great job on the art for Awesomenauts, so this is a good example of how not all good art needs to keep to Gurney's colour gamuts.



Here are the colour schemes for a number of other games:



By the way, note how in all the screenshots analysed in this blogpost Proun is the only game that uses the purple/pink/magenta area. This might be accidental, but it seems like this part of the colour wheel is used quite rarely in games.

I am going to try to use Gurney's ideas in the art for Cello Fortress. One particular challenge I see there is that the player's tanks should be immediately recognisable. I currently make the tanks stand out by using extremely bright colours for the tanks, but this will be difficult when using a limiting gamut according to Gurney's rules. I am quite curious how that ends up. If anyone has any tips on how to tackle this, then please let me know in the comments!

Proun+ out now on iOS!

On 27 November Proun+ launched on iOS! The first reviews are extremely positive, both from the press and from users. We also got a big feature in the European App Store, so it seems like Apple itself also likes the game. :) Here are some quotes from the reviews and the launch trailer:

"A bright, searingly good twitch racer that takes the fundaments of the genre and builds something staggeringly entertaining on top of them."
9/10
PocketGamer.co.uk

"Previously a successful indie release on the PC, it deserves your attention and patience. [...] Throw in a funky jazz based soundtrack and Proun+ has a lot going for it."
4/5 stars
148Apps.com

"this self-styled “journey through modern art” exudes an endearing weirdness that sets it apart and nestles it in your brain. Like that off-beat game you used to play, that you’re convinced only you can remember, which you can’t possibly forget."
4.5/5 stars
Gamezebo.com



Proun+ is available in the App Store for iPhone and iPad for $3.99 here.

Proun+ gets its first trailer!

We have released the first trailer for Proun+, the biggerbetter Proun that is coming to 3DS, iOS and Android! Proun+ is being made together with Engine Software and will have six new tracks and a completely new soundtrack: more songs and all the songs have now been recorded by real musicians for a much better sound. In this trailer you can hear the new version of one of the old songs and see one of the awesome new levels in action, plus footage from some of the original tracks. I am really hyped for the return of Proun, so I hope you like it!

Proun cloning controversy: why indies should complain less about clones

My game Proun was recently 'cloned' by an iOS game called Unpossible. Unpossible isn't the first 'clone' of Proun: games like Synesthetic and Polyrider also copy the core gameplay and many obstacle shapes. Polyrider even goes so far as to copy-paste my main marketing text (DOH!). However, the timing of Unpossible is much more painful as Proun itself is also finally coming to iOS (and Android and 3DS): together with Engine Software I am working on a bigger and better Proun+. Proun+ coming to iOS means that it will be a direct competitor of its alleged clone Unpossible. I saw quite a bit of controversy online about whether Unpossible is a clone or not and whether that would be bad or not, so here is my own take on the matter.

I think most people are worrying way too much about most clones. The only clones that should be considered a big problem are direct rips that add nothing and are clearly only intended as a moneygrab. Most infamous clones are not of this type and indie developers should complain less and instead spend that time making more and better games.

One aspect that seems completely absent from how indie developers react to clones is pride. Usually your game will only be cloned if you make something very good and different from what already exists. Somehow most indies seem to only notice the negative and don't realise what a fantastic compliment being cloned really is. One of the things I am most proud of in my game development career so far is that Swords & Soldiers and Proun have both been 'cloned' many times and that De Blob has directly inspired other games. Indies should focus more on this positive side of cloning!



I think there are three types of clones:

-The "Asset Ripper" is the worst. These are clones that not just copy game mechanics, but even go so far as to rip assets directly from a game. Graphics, sounds, animations: they are just copied directly. We have actually encountered these ourselves once: a Swords & Soldiers clone had used some of our sound effects in their game. However, this was a small Flash game that was played by hardly anyone so we ignored it and didn't take any action. The "Asset Ripper" is the only type of clone that is definitely illegal, since it violates copyright laws.

-The "Art Replacer" is the next step: practically all game mechanics are copied directly and the only things that are changed are the visuals and audio. This is still clearly a clone, but we are already entering a grey area here. If the visuals are changed from a happy fairytale to gritty sci-fi, then the feel of the game itself also changes a lot. It is still lame to copy mechanics directly like that, but this isn't a complete clone anymore and might cater to a different audience. A famous example in this category is Yeti Town, which ripped Triple Town. They switched to a different setting, but the happy feel remained the same. Add that to a literal copying of every game mechanic and rule in Triple Town and it becomes extremely lame.

-Finally there's the "Mild Changer". This is the category Unpossible belongs to, as do famous 'clones' like Ninja Fishing. Mild Changers have a lot of similarities to another game, but add not just their own visuals: they also change the gameplay in some small ways. The core game keeps feeling the same, which is why people cry 'foul' so often for these kinds of games, but they do change things and thus create something new.

Unpossible is a clear example of this latter group. At first glance this game seems to play exactly like Proun, but it does change some things. The camera goes from third person to first person. This doesn't really make the game feel very different, but it is a real change nevertheless. The cable is thicker in Unpossible, so it is more difficult to see what is coming around bends and what is at the other side of the cable. And most importantly: in Unpossible the game immediately restarts when you hit something, while in Proun you can keep racing. This changes the game quite a bit.

I think developers should complain much less about such "Mild Changers". Genres evolve by copying from existing games and improving and adding to that. This is how we as an industry grow and discover new places. Truly new things are hardly ever made without grabbing lots of elements from existing things, in games as in most other subjects. Classic RTS Dune II lacked group control and regrowing fog of war. It is a good thing that other games 'cloned' Dune II and added these crucial elements, bringing the genre forward. A clone that is significantly better than the original is a great evolution and should not be frowned upon. (Not that I feel Unpossible is significantly better than Proun, but it still is an evolution.)

Strangely, if a game is part of a genre with lots of existing games, it is considered okay to only change some small things. But if a type of game has so few games that it can hardly be called a genre yet, then suddenly it is cloning and considered problematic. It seems like the general public thinks 'clones' are a problem if few games do it, but if lots of games all do it for years, then we call it a 'genre' and it is okay.

An interesting question in such cases is whether the developer of a clone knew the original at all. On the Touch Arcade forums Acceleroto claims to not have know Proun until Unpossible was already playable: "I didn't know about Proun until I shared an Unpossible build with some dev friends." My first inclination is to believe him: when I started working on Proun I also didn't know about F-Zero's Cylinder Wave track. (In case anyone is wondering about 2009's Boost 3D: Proun's first versions are way older than that, as can be seen in this forumpost from 2006.) Despite Acceleroto claiming to not have known Proun, when I actually played Unpossible I started to strongly doubt that. The similarities in types of obstacles and game feel are so incredibly strong that I really doubt whether Acceleroto really didn't play Proun until most of Unpossible was designed, especially considering how 'original' his other games are.

At Ronimo we are currently developing Swords & Soldiers II. Do I worry about the many similar games and even clones out there? No, I don't. We are trying to make Swords & Soldiers II better and more fun than the others. If we succeed at that, then the clones won't hurt us. If we don't succeed at that, then we should have made a better game and have only ourselves to blame. Ridiculous Fishing is a great example of this: Vlambeer made their sequel to Radical Fishing so incredibly good that it became a gigantic hit despite so-called 'clone' Ninja Fishing launching much earlier.



Another part of handling clones is that indies should simply make better business decisions. Unpossible will compete with Proun+ on iOS, but this is entirely my own fault: Proun has been out for three years now so I should have jumped on iOS ages ago. Had I done that, then Proun+ would have released well before Unpossible and the whole issue would not exist. This is a situation that often arises around clones: the original developer is very slow at bringing his game to other platforms and when he finally does, he complains that clones have sprouted in the meanwhile. This is especially important with games that are simple to build, like Proun. Ronimo's Awesomenauts and my own Cello Fortress are technically so complex that clones are much less likely to come quickly, if at all.

Before we learned of Unpossible we were already adding more variation and originality to Proun+ by introducing new game modes, more music and new visual styles. Seeing Unpossible can only strengthen our resolve to make the best game we can. If we fail at making a better game, then that is entirely our own fault. If we succeed, then I doubt the existence of so-called 'clones' will be all that relevant to sales of Proun+.

The final series of Proun+ music sketches

For the extended soundtrack of Proun+ I am composing a series of short sketches for grooves for the new songs. I already posted seven of them a couple of weeks ago and today I present the final six. From here on I will select the best ones and start turning them into real songs. I would love to hear your opinions on these, since that will help us choose which to expand on.

Keep in mind that these are quick digital sketches. The final soundtrack will be played entirely by live instruments and produced by professional musician Arno Landsbergen, so they will sound much better just because of the real instruments and good production.









The one below is pretty different from the rest. Arno and I wrote "Groove Sketch L" together and Arno recorded it live. This means that the sound is much better right away, making a comparison to the rest difficult. It also shows that everything is better on a real Hammond organ: what an awesome sound these things have! The Mellotron halfway (starting at 0:25) was added later by Arno and I love it, because it is impossible to not love Mellotrons.



The final piece below is in a much further state already and created entirely by Arno. "Chaingang Rag Dressed Up For Warp Speed" is a song Arno started writing a couple of years ago around the time of the launch of the original Proun, but he never finished it for the actual game. I absolutely love it so we have already decided that Arno will expand this one into a complete song for Proun+.



Working at these sketches is a very interesting process and a personal breakthrough for me. I am a completionist: whenever I start working on something, I want to actually finish it. For some things this is good: Proun would never have existed if I didn't feel like I had to finish it for six years. However, being a completionist also has a big downside: instead of making dozens of prototypes and little ideas, I mostly just create bigger stuff. For example, in the past 1.5 years I worked in my spare time on just this one project called Cello Fortress, ignoring all other ideas I have. I love Cello Fortress, but it would also be nice to try some of the dozens of other concepts that linger in my head.

Being a completionist also influences my gaming habits: I have to finish almost any game I start and thus play few games. As a game developer it would be much better if I played and experienced a lot of different things a bit, instead of only selecting those games I will actually finish.

Knowing that I am such a completionist makes me scared to start working on something new, regardless of whether it is a game or a piece of music or 3D artwork. I won't be able to happily drop it until it is finished, and I will feel bad if I don't finish it. In fact, I still plan on finishing my 3D design for a baroque villa, despite that it has been on hold since 2004. Twothousandandfour! That is a ten years old project that still lingers in the back of my mind because I feel bad for not completing it.



Not being able to sketch or prototype stifles creativity, so I am glad that for the music for Proun+ I managed to find a compromise that fixes most of my completionist problem. The 'project' I defined here is to make a long series of simple ideas. Each is an incomplete thing, but to me as whole they form a completed group of sketches.

Turning a group of unfinished things into a project that can be finished as a whole satisfies my urge for completing things, so that I won't feel bad for the unfinished pieces.

Back to these groove sketches for Proun+: which do you like most? Any you really dislike?

Proun+ music sketches: which do you like?

Below are seven sketches for the music of Proun+. I am writing an extended soundtrack for this game and the first step is to experiment with the basic grooves. My goal is to try a lot of different things, and then pick the best ones and turn those into complete songs. I am really curious which you like and which you don't like! Please let me know which are your favourites, and which you like the least!

The final version of the soundtrack will be recorded with live musicians, so the exact sound and mix are not all that important right now. These groove sketches are also not real songs with a start and an ending: they just repeat a cool vibe for a while and that's it. What is really important though is whether you think these fit the game. Do you think they will work with the speed and vibe of Proun?

For those who don't know what Proun+ is: my friends over at Engine Software are currently porting my game Proun to 3DS, iOS and Android. Engine Software is quite a famous studio: they are the developers of the new console versions of Terraria. The most awesome part of this is that they are adding new tracks and modes, and that Arno Landsbergen and I are writing new songs together. Proun is not just coming to new platforms, it is also becoming bigger and diverse!

My idea for the music is that I want to write new songs that are as different from the original soundtrack as possible, but still feel like Proun. To achieve this I imagine all the music is being played by an imaginary band. This band can be pretty versatile in what kind of music they play, but they always have the same line-up of drums, double bass, guitar, saxophone and vintage keyboards (things like organ, rhodes, piano). Maybe the sax doesn't play in some songs, and I expect they will also be visited by a guest musician on cello occasionally (a really famous and awesome cellist, euhm... ME! ;) ).

Without further ado, here are the first seven Proun+ groove sketches!















Please let me know which you like and which you don't like! If you hate all of them, or if you think I should be taking the music in a different direction, please also post so below. I am also interested in references to existing music that you feel I should grab some inspiration from. Share your opinion and ideas!

PS. I am still writing more of these and if you want to hear them early and give feedback right away, you can follow me on Facebook or Twitter, where I will be posting the next song sketches daily.

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

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
Developer	pre-Ronimo	Ronimo	Ronimo	Ronimo	me	Ronimo	Ronimo
Release date	30-06-06	cancelled May '08	15-05-09	02-12-10	22-06-11	01-08-12	28-08-13
Graphics type	3D	3D	2D	2D	3D	2D	2D
Platforms for this version	PC	PC	Wii	PS3 PC Mac Linux	PC	PC PS3 Xbox360	PC Mac Linux
All platforms this game was released on at some point	PC	none	Wii PS3 PC Mac Linux iOS Android 3DS	Wii PS3 PC Mac Linux iOS Android 3DS	PC	PS3 Xbox360 PC Mac Linux	PS3 Xbox360 PC Mac Linux
Time between first version and final version (might contain long inactive periods)	5 months	1 year	1 year	2.5 years	6 years	3 years	4 years
Active development duration	5 months	1 year	1 year	2 years	3 years	3 years	4 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.5gb	7.4gb	28.3gb	40.3gb	97.4gb	200gb
Files in repository	?	17979	18723	36219	31050	34957	98288
Installed game size	235mb	426mb	17mb	282mb	347mb	500mb	879mb
Files in installed game	1331	10582	?	801	974	550	716

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
Textures	260	1188	587	634	317	3250	4800
Total texture size	72mb	201mb	55mb	183mb	210mb	350mb	833mb
Maximum simultaneous texture usage in video memory	72mb	201mb	55mb	183mb	106mb	200mb	332mb
Sprite sheets (one sheet often contains several animations)	n/a	n/a	67	68	n/a	125	255

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