Sunday, 22 September 2013

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

Saturday, 14 September 2013

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:



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.


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!

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!


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!


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!


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
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
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.


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.


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