Camera mapping a comic: the Ward trailer

It has been a while since I dabbled in the awesome fun of camera mapping. Recently I bumped into a good reason to get back to that invigorating topic: the comic Ward was released. Marissa Delbressine was working on a trailer for her comic and she thought having a camera mapping of Ward's cover would be an awesome addition. Marissa threw me a pretty smile to which I couldn't say 'no', so I went to work on it. (Marissa happens to be my girlfriend, so I guess without the pretty smile I couldn't have said 'no' either... ;) )

Here is a compilation of the shots I made of the cover of Ward, plus shots of the meshes used to make this scene:



Marissa used a couple of these shots in the complete Ward trailer, which you can see below. Note that most of this trailer is not camera mapped: I was personally only involved in the shots at 0:43 and 1:12. All the 2D art and the rest of this trailer were made by Marissa and co. I think the result is great: making a trailer for something as static as a comic is difficult and I think Marissa did a great job of bringing it to life. It helps if you know Dutch and can read the text, though... Anyway, here is the complete trailer:



It has been several years since I last wrote about camera mapping on this blog, so let's do a quick recap of what this technique is. The idea is to project a 2D image onto a 3D model, so that you can do 3D camera movements through this 2D image. To do so, you have to first split the image into layers, and then create simple, rough 3D models to represent the objects in the image. Here is how this was done for Ward:


The process of creating the camera mapping of Ward. I only did the 3D parts: colours were done by Shanna Paulissen and splitting into layers and extending them by Iris Adriaansz.

Those who make 2D animations will likely recognise most of this: camera mapping is a more advanced version of a technique that is often used by 2D animators; they also split the scene in layers to create a 3D effect. The difference between this simple layers approach and full camera mapping is that with camera mapping the 3D models aren't just planes: they are real 3D objects that roughly mimick the shape of the 2D objects. This makes the 3D camera movements much more convincing, since the scene is not just a collection of cardboard planes anymore.

The main reason I think camera mapping is such an exciting technique, is that it allows for 3D graphics to achieve unique 2D looks. 3D graphics can look like many things, but there are very few 2D styles that normal 3D graphics can do well. The roughness of a brush or a pencil stroke is something that only really works in 2D, and camera mapping makes it possible to get that look in 3D.

Another benefit of camera mapping is that it only requires very simple 3D models. The details are all in the drawing, so you don't need to model everything and can get away with crude approximations of the real 3D models. Most work in camera mapping is in dividing the scene into proper layers in Photoshop. If the artist already works in layers, this can be a relatively simple thing to do.

The big downside of camera mapping is that objects have no backside, so the camera cannot rotate all around them. In the case of games this makes camera mapping mostly useful for games with limited camera movement, like 2.5D platformers, or games with a perspective like Diablo. In fact, the awesome Diablo III uses quite a bit of camera mapping, but disappointingly refuses to use the technique to create a truly unique art style.



Since it has been so long since I wrote about camera mapping, here are the camera mappings I did a couple of years ago:

• Camera mapping the Evil Pope
• Captain August got camera mapped!
• Camera mapping tips and tricks

I hope to come back to camera mapping some day to create some real-time game environments with it. I already have one quite far finished, but instead of finishing it I always end up spending my spare time on Cello Fortress and writing blogposts, so I don't know when I will actually get to that.

Let's end this blogpost with some blatant marketing for Ward, which is an awesome comic and it currently available in stores in the Netherlands. Marissa drew some amazingly detailed and beautiful art for it, so check it out! Ward is only available in Dutch, and is sold in specialised comic stores and at Bol.com and in the Eppo Webstore.

First steps towards massive replays and spectators in Awesomenauts

One of the biggest challenges for us in the coming period is implementing replays and spectator mode in Awesomenauts. It might not be immediately obvious, but this is actually an incredibly complex problem to solve. We have the very first bits working now, so here is a video in which I show and explain what we have so far:



Our first target with replays is to get them working offline, so you store replays of your own matches on your own harddisk and you can email those files to your friends by hand. Storing and browsing replays through online servers comes after that and is still a long way away. We hope that the offline replays can go in beta before Christmas, but right now it seems like that might still be too early for how complex this all is.

So why are replays so difficult to build? There are a ton of reasons for this. One is that players need to be able to do live spectating. In high-level tournament matches, we currently sometimes get near to 1000 simultaneous viewers for a single match. This is on Twitch, so the bandwidth is handled by Twitch, but for our spectator mode we will need to make that possible ourselves. Handling that kind of user numbers and internet traffic is by itself already a big challenge.

Another problem is that players need to somehow get their replays to a server, live while playing. By itself this is not very difficult, but to keep this from disrupting normal online play, we need to do this in an extremely small amount of bandwidth. We are targeting to stream out a replay from one player to the server in only 1 to 2 kilobyte per second. The total size of a 20 minute match will then be around 2mb. Streaming all data in so few bits is an interesting challenge, but I think it is quite achievable.

Another problem is version management. We release lots of patches for Awesomenauts, and most patches change significant things in our gameplay logic. That means that if we rely on that gameplay logic for playing back replays, then stored replays will often not be playable anymore once we release a patch. A solution for this would be to add version management to the gameplay code, but that would add a kind a code complexity that we definitely don't want there. And I haven't even mentioned how sensitive to bugs that would be... Another solution would be to store legacy versions of the game to play older replays, but that would produce very high loading times when switching between reviews, and would mean loads of downloading to get all those older game versions.

Our solution for this version problem is to store only graphical data in the replay. This way if gameplay logic changes, it doesn't matter for stored replays, since those don't use the gameplay logic anyway. The demo shown above already works like this. However, this does mean that we cannot use any of the current gameplay code or network packages for the replays. We need to rebuild it all from the ground up in a different way. That is why the demo above still lacks animations and bullets and pickups and such: they have not been rebuilt for replays yet.

Another issue in the replays implementation is server bandwidth and loading times. If players view lots of replays, this will cost us a lot of bandwidth and thus a lot of money. Also, if players need to download the entire replay before they can watch it, then waiting times might be long. We even want players to be able to immediately skip to specific moments in the replay without downloading everything in between. With this in mind, the replay system again becomes a lot more complex.

There are several other challenges in implementing replays and spectator mode, but these are the most important. The video shown actually solves the basics of several of those already: there is quite a bit of interesting code architecture behind it. This is also why it took so long before we got anything to show at all: storing and playing character positions is by itself not all that difficult, but doing it in a way that will work with the above issues makes it a lot more time-consuming to implement. I expect I will be able to do a great talk or series of blogposts on this once the whole replays system has been built...

As a conclusion to this blogpost, I would like to say that this is a mightily interesting and fun challenge! We at the Ronimo coding team are greatly enjoying this task: coding puzzles are the best puzzles!

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

Extreme transformation of Nauts during development

Game development is an iterative process. That means we are constantly changing things around. This might be because we experience that certain ideas don't work, or work differently than expected, or just because we get new ideas that are more awesome. This is especially true for characters in Awesomenauts, so today I would like to show a couple of examples of how enormously some Nauts changed in the period from their first conception to their final in-game appearance.

The first one I would like to show is Ayla. She started out as an electricity character called Glint. Ronimo artist Olivier made these awesome concept sketches for him:





Glint's power is that he can move through enemies and damage them while doing so. That is basically exactly what Ayla's Rage mode does, and thus Glint slowly evolved into the Ayla we know today.



Glint's other skill didn't make it into Ayla, as often happens: elements from ideas are combined and morphed until they work, have synergy and are fun. This scrapped second skill is Static Discharge: a fixed amount of damage is spread over all enemies in the vicinity. For example, if the base damage is 100, then if there is only one enemy near, he gets 100 damage. If there are 5 enemies near, they each get 20 damage. So this skill is area of effect, but does not stack damage like normal area of effect skills do. Interesting idea, but so far it hasn't made it into an Awesomenauts character.

Glint is an example of a character that immediately started out with a name and a visual idea. More often however it begins with a pure gameplay concept. An example of this is the character that was internally called the "Bird". He was called this way because he could press jump while in the air to stay up there, just like a bird would flap his wings. From this Awesomenauts players can probably deduce who the Bird became: Vinnie & Spike.

When the core gameplay of the Bird was starting to look good, our art team picked him and started sketching. The first design they wanted to go with is this awesomely crazy alien, drawn by Martijn:



In the end they ditched this idea as well and the Bird transformed into... a flying pufferfish. WUT?! Yes, our artists sure can think outside the box!



Some other examples of characters that evolved a lot during their development can be found in two of my earlier blogposts: Sheriff Lonestar and Genji

Since characters often start out as pure gameplay concepts, there is no proper name for them. Instead something descriptive is chosen by our game designers as their internal name. These working titles are kept internally, so if ones looks up the names of the characters in our settings files now, most go by a completely different name than what they ended up with. These names give a nice indication of what our designers might have first had in mind.

To wrap up this blogpost, here is a fun game for avid Awesomenauts players: can you deduce who each of these characters are?

• Heavy
• Hunter
• Chameleon
• Brute
• Butterfly
• Cowboy
• Captain
• Bird
• Blazer
• Dasher
• Jetter
• Summoner
• Tank
• Maw
• Vampire

Visuals that make ideas much more awesome

A couple of days ago we announced that if our Kickstarter campaign would reach $290,000, we would add a fourth character to the Starstorm expansion for Awesomenauts. Today I would like to talk about the kind of art that came with that announcement. We posted these concept sketches, by Ronimo artist Olivier:



This looks fun, and it is also a nice example of the kind of sketching that works really well to communicate ideas. This kind of concept art does a lot more than just show something: it makes others enthusiastic about the ideas. In a company like Ronimo, where all team members are involved in the core concepts, convincing others that your ideas are good is almost as important as having good ideas in the first place. Several of the devs at Ronimo are masters at this, so today I would like to show you some examples of how art can be used to communicate ideas. (I am really bad at this myself, by the way: my concept sketches for Proun are completely incomprehensible for anyone but me...) Most of these concepts didn't actually make it, but the way they were drawn makes me instantly like them.





The first is Wozzle, drawn by Olivier. This character was actually prototyped in the game, but for some reason wasn't deemed interesting enough to become a full Awesomenaut. I still hear his name echoing through the office occasionally, so maybe in the far future this could still become a real Awesomenauts character, who knows? Wozzle has a bunch of creatures walking along with him to do combat, and he can scream so loud that enemies are stunned.





This one, called Squeedo, is downright eerie: this is an octopus with a hookshot, just like Swiggins. Except that Squeedo was drawn months before the contest that lead to Swiggins! We had totally forgotten about Squeedo and only bumped into him again after Swiggins had been selected by the community. The coincidence at how similar Swiggins and Squeedo are is just baffling...





I don't think this next character was ever even prototyped in gameplay, but that second skill is actually pretty interesting. He grabs an enemy with his beam and stuns him, but the enemy is only stunned as long as he stands still himself and keeps holding him. So you basically stun an enemy by stunning yourself as well. This Naut would very much be a team-player since he cannot use this to kill directly, while it could be mightily powerful with good team-play! The other skill is a rocket barrage, which in terms of gameplay might be a bit boring (just plain damage in a really big area), but could make for some pretty spectacular special effects.

The final character I would like to show today looks very familiar: Gnaw. Here he was still called Groblok, and this Naut turned out almost exactly as Olivier first sketched him. This is how he was first posted on our internal forum:

Groblok Grobling After # successfull base attacks, Groblok can spit out a Grobling, which latches onto the ground and attacks nearby enemies. Reverse Photosynthesis Cells (item) Each living grobling gives you # solar per minute. Acidspray Groblok vomits a stream of acid in a direction, slowing by #% and increasing damage taken by those hit by #%. Hold down (Y) to spray longer. Regurgition Glands (item) Groblok gains # health per second while spitting.

All of the art above is by Olivier, but he is not the only dev at Ronimo who can work magic like that. For example, Ralph is also really good at this, as you can see in the two images below. These are drawings from a storyboard for our Kickstarter video. We chose a different concept for the video, so this storyboard didn't make it into the final video, but looking at it, I can only imagine something that is awesome fun to watch! This is also slightly deceptive, by the way: if two real persons are filmed for this storyboard, much of the fun is gone, unless those two persons are really good comedians instead of game developers...





Next week I'll show some more example of early character concepts, of some characters who changed a lot in the period between first concepts and launch. Also, I still need to post the third and final part of my stats series at some point, but I wanted to post this first. See you next week!

By the way, our Kickstarter campaign still runs until Wednesday, be sure to pledge to make the game grow further and to scoop up some awesome rewards!

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