Cancelled game Snowball Earth playable at Indigo

In 2007, after we had made De Blob, we worked on a big game that was intended to be the first real commercial game by Ronimo Games. It was called: Snowball Earth. However, we couldn't find a publisher for it and the game was cancelled. After that, we went on to make Swords & Soldiers.

Since the game was cancelled, we never showed it to anyone after that. However, this weekend at Indigo, the prototype we made at the time will be playable! It is a 30 minute completely playable demo that shows the visual style and gameplay we were aiming for.



We will soon release a lot more information on what this game was all about, and even the complete playable prototype! I think it has some great original and unique gameplay ideas, so I am actually looking forward to showing those to the world! However, for the moment, enjoy these two screenshots!



To play Snowball Earth this weekend, visit Indigo! Indigo is a yearly exhibition by Dutch Game Garden that shows the best new work by Dutch game developers. This year it is held in Utrecht's town hall, at Korte Minrebroederstraat 2. On September 28 it is open mainly for press and business people, while on September 29 it is open to the general public. Entrance to Indigo is free, so be sure to visit and give Snowball Earth a try! Awesomenauts and my new project Cello Fortress will also be playable at Indigo!

Visit Indigo if you want to give Snowball Earth a try, or follow this blog for more info soon!

Awesomenauts skins out now!

Indeed! We have just released DLC skins for Awesomenauts on Steam! There is an awesome alternative look for every character, as you can see in the new trailer:



This comes together with patch 1.5, which along with skins also contains numerous balance fixes, and some big improvements to the matchmaker to make sure you play more against players of the same skill level.

Announcing Cello Fortress: a unique mix of live concert and game

Today I am announcing my new project: Cello Fortress! Cello Fortress is a really weird game concept, very experimental. I am really happy to finally have started working on it, after having it floating around in my head for years. ^_^

Cello Fortress can only be played live at events, and it will debut at the Indigo exhibition later this month!



Cello Fortress combines a live cello concert with a twin-stick-shooter, in which the cellist plays against the audience. It brings a unique experience in which I control the game by improvising on my cello, simultaneously fending off attacks and making music. The audience takes up controllers and tries to beat the fortress. The result is an exciting interplay between cellist, players and audience.



Up to four players use controllers to navigate their tank, using one stick to move and the other to shoot. They dodge bullets and attack the turrets. At the same time, the game analyses the notes played by the cellist, as picked up by a microphone. Aggressive notes activate the burst-cannons, dissonant chords turn on the flame-throwers, and an ominous melody charges a bombardment.



Cello Fortress is only playable at live concerts given by... me! So I am not only the creator of the game, but also the cellist. The debut of Cello Fortress will be at the Indigo 2012 exhibition on 28 and 29 September in Utrecht, Netherlands. The version played at Indigo will be a fully playable, early prototype, to experiment with this weird concept.

I find this project an incredibly interesting experiment. I have played cello for years, including in a band and currently in the Kunstorkest amateur baroque orchestra. I do lots of improvisation at jam sessions and such. But how does it feel to improvise with a gameplay goal? If I need to suddenly play low notes to fire a certain cannon, then I will need to come up with a melody that brings me to the low notes quickly, without sounding like random notes. After all, I am making music here! Besides the players, there is also an audience listening and viewing, so they need to hear good music as well as see interesting gameplay. Quite a challenge, and I look forward to trying it in front of an audience.

This game contains so many weird elements that it is interesting to list some of the rare and unique aspects in Cello Fortress:

• Using a real musical instrument as a game-controller (like Rocksmith, but this time using a cello and to control normal gameplay)
• Combining concert and game
• Dynamic difficulty adjustment directly by the designer during gameplay
• Completely adaptive soundtrack
• The game is a show in front of an audience

Since the game is still in the early stages, the version playable at Indigo will probably not look very polished yet. However, I am already playing around with the visual style of the game, so here is a piece of concept art for it:



So to play Cello Fortress, visit Indigo! Indigo is a yearly exhibition by Dutch Game Garden that shows the best new work by Dutch game developers. This year it is held in Utrecht's town hall, at Korte Minrebroederstraat 2. On September 28 it is open mainly for press and business people, while on September 29 it is open to the general public. Entrance to Indigo is free, and Cello Fortress will be playable regularly throughout the day. Hope to see you there!

A name and a logo

Shooting animations in Awesomenauts

A challenge that is faced in the development of many games, is how to animate shooting, and other actions that can happen at the same time as general movement. In Awesomenauts, the player can shoot while walking, standing still, jumping, falling and sliding. How to make animations for this?



The first idea might be to simply make an animation for each combination. This means animating both walking+shooting, walking+sliding, walking+jumping, etc. This is a lot of work, especially since in the console version of Awesomenauts, characters need to be able to shoot in 5 different directions. That is just a lot of animations.

And that is not even the worst of it. The real issue is that this doesn't actually work. The player can shoot at any moment in time. This means that shooting can start at any point during another animation, not just at the start of an animation. So if the player is already halfway through his current walking animation, then the walking+shooting animation will not connect. Either the shooting has to be delayed until the walking animation has finished, or the feet will shuffle every time the player shoots (which in most games is very often). Both are unacceptable, as shuffling is ugly, and delaying destroys the responsiveness of the controls.

The common solution to this problem, is to split the upper and lower body and animate them separately. However, as I explained in last week's blogpost, our character designs were not very fit for that. And since Awesomenauts is a 2D game, we also don't have any bones to do animation blending on parts of the body, as is commonly done in 3D games.

So we had to be more creative. We came up with a combination of a couple of techniques. Our solution is somewhat hacky and weird, but I am pretty happy with the result, and the amount of time it took to make was quite acceptable.

Our solution on console consists of two parts. The most visible part is the shoot effect. Whenever the player shoots, an effect is played at the position of his gun. This effect usually contains a light flash and particles, as is very common when shooting in any game. The trick here is that we exaggerate these shoot effects to compensate for that the character's body itself is not playing an animation when shooting.

From there our artists took this even further: some shoot effects contain body parts that are drawn on top of the character. This essentially means that the gun of a character might be visible double during the shooting, but since it goes so fast, the double is not really noticeable (unless you read this blogpost and start looking for it). The recoil animations this makes possible look much more natural and powerful.

The other part of our solution in the console version of Awesomenauts is that we skew the entire character based on his shooting direction. Skewing is a rather crude effect to apply to an entire character, and looks horrible in slow-motion, but when seen at the speed of the actual game, it actually looks like a recoil effect and looks pretty good. Depending on the shooting direction, we also sometimes squash the character instead of skewing him.




This video shows how the combination of a shoot effect and a skew works out in the console version of Awesomenauts, both at normal speed and in slow motion.

This technique works fine for the short burst that each shot is, but doesn't work for some of the longer skill animations. Here we got lucky: most of those don't allow the player to walk while performing them, and many don't have specific aiming either. Clunk's Bite skill is a nice example of this, and was thus pretty straightforward to animate.

The most difficult one here is Lonestar's grenade throw. He can charge this while moving around, and throwing requires an animation in the arm. Luckily, our artists came up with a really simple solution to this: they animated him with his feet of the ground, as if jumping to throw that grenade. This works fine both when Lonestar is in the air, and when he is on the ground. Similarly, Yuri's skills are animated with his jetpack turned on, also resulting in his feet being off the ground. Note that when looking really closely, solutions like this might not look perfect. However, when actually playing, they look totally fine, so I think this was a pretty smart solution from our art team.


A couple of examples of how some of the longer animations simply use a jumping pose to solve the problem of mixing the animation with free movement.

While reading this, you might have noticed that I am constantly talking very specifically about the console version of Awesomenauts. This is because on PC, we separated the arms from the body (as I explained in last week's blogpost), and that suddenly makes it a lot easier to do some proper animation while shooting. So on PC, characters have proper recoil in their arms while shooting. Most characters also still have their skewing animations, and the combination of gun recoil, shoot effects and skewing looks great, in my opinion.


Some examples of shooting animations in the PC version of Awesomenauts, where arms are separate objects and can thus have proper recoil animations.

For the moment this is the last blogpost in this short series on animation in Awesomenauts. I would like to get back to this topic later, to talk about our tool chain and the way in which our artists create animations, but for the coming weeks I have some much more exciting topics to pester you with. I have some cool footage coming up of a cancelled Ronimo project (in my opinion a lot cooler than the previously discussed Monstertruck VS Zombies). And, even more exciting: next week I will announce the new hobby-project I am working on! My new hobby project is the weirdest thing I have worked on so far, so be sure to check out it's reveal next week! ^_^

Making 2D characters aim in all directions

In Awesomenauts we have characters that can aim in all directions. How does that work? In a 3D game this would be quite straightforward: you just make animations in a couple of directions and blend those. Blending angles of bone-animations is a really simple thing. To make it easier, you might animate the upper body and the legs separately and blend those parts as well.

In 2D, however, this is a wholly different story. Awesomenauts characters don't have bones: the game simply gets a series of frames for each animation and shows those in order. So how to do this, then?

We started by having a look at several other games. An older game that solves this problem, is Abuse (1996). Looking at footage from that game, I think what they did is that the upper and lower body are animated entirely separately and then combined in the game. The legs just do the walking and jumping and such, and totally ignore the aiming. The arms have been drawn for each aiming direction they support, which I think is as least 16 directions. I get the idea they did not actually animate the arms: they just drew one frame for each direction, and then move the entire frame up and down with the lower body to keep it from being too static. Not sure if this is actually the case, but that is what I think they did.



Another solution can be found in Capsized (2011). Capsized also splits the body at the waist, but to get the aiming directions for the arms, they simply rotate the entire upper body. This is a pretty smart solution, I think, and it rotates very fluently. The character can aim in all directions with very little animation work involved. At the same time it doesn't look very natural, since the upper body very clearly just rotates as a whole, arms and head included.


Aiming animations in Capsized. Note the smart trick they did with the lower body: it contains a bent back that becomes visible when the character looks down. It also glitches a bit at the front when the character looks up, though.

Both Capsized and Abuse have in common that the character has been split at the waist. However, when we were working on this, we already had several characters that didn't have a clear waistline (like a belt or something like that), making it difficult to separate them easily. Since our artists had already rebuilt the first characters several times at that point (they were also exploring After Effects as an animation tool around that time), we decided to not do another redesign with a clear waistline, and to not rebuild the characters in After Effects for this.



By this time, for gameplay reasons we had already decided that characters could only aim in angles of 45 degrees, and could not aim backwards. So the player could aim in only 8 directions. This made the animation problem a lot simpler. We chose to simply animate the character in each of the directions. So for each animation (walk, idle, slide, jump, fall) our art team made animations in each direction. Since the player cannot aim backwards, and since some combinations cannot be done with our control scheme (like walking and aiming straight up), our art team had to make around three directions for each animation. This works great and looks very smooth, as you can see in the video below.


Animations in different directions in Awesomenauts on console. Note how having completely separate animations allowed our artists to do cool stuff like showing Lonestar's teeth and eyes or Froggy's tongue under certain angles.



However, when we got to porting for the PC version, this turned out to not work for that. On PC the player was to aim towards the cursor, and capping that to 45 degrees plays horribly. To solve this problem, our artists were forced to rebuild all animations in a different way. Since some of our characters still didn't have a clear waistline, the choice was made to make only the arms freely rotating. So on PC, the shooting arm always rotates towards the cursor.

Combining this with what we already had, turned out to look fantastic. There are a couple of reasons for this. First of all, our artists had drawn all characters somewhat from the side and with the shooting arm at the back. This means that the rotation point of the arm is always hidden behind the shoulders, thus nicely hiding the ugly rotation point of the arm. The other great thing is that the 45 degrees animations for the body combine well with this: while the arms rotate freely over 180 degrees, the body makes jumps every 45 degrees to follow that. This looks really slick, and makes sure that if the character is aiming upwards, he also looks upwards. This is really important for making it look convincing.

Our art team did have to add the missing directions, though. So now we needed 5 directions for each animation (5, not 8, because our characters still cannot aim backwards).


Aiming on PC is a combination of a freely rotating arm and the 45 degrees body animations from the console version.

Making all of these animations was an enormous amount of work, and part of the reason why Awesomenauts took so long to make. However, seeing the end result, I am incredibly proud of what we achieved, and I think our art team really did a tremendous job.

For the next blogpost, I would like to discuss an important related topic that wasn't covered today: shooting. How to combine shoot animations with a moving character that needs consistent leg movement? We used a couple of quite clever tricks for that (or so I like to think), so I will explain how shooting was made in my next blogpost. See you then!

Our experience with crowdsourcing translations

When we developed Awesomenauts for console, we had the benefit of working with a publisher that helped us with QA (Quality Assurance, also known as testing) and translations. However, on PC we have self-published Awesomenauts, and that means that we had to take care of these things ourselves. Being low on budget and time, we decided to take the more radical route: we crowdsourced large parts of both.

For those who don't know the term: crowdsourcing means asking the public to help you, outsourcing to the crowd. So we did a beta where people could play the game before launch, and tell us if they found any bugs. And we asked players to help us translate all the new texts to German, Italian, Spanish and French. Since crowdsourcing is such a hot topic these days, I figured it would be interesting to share our experience with the translations.

At first, I was quite reluctant about letting players do translations. Despite our budgetary problems a few months ago, I was in favour of paying a translation company to do it, thinking that would be faster, more reliable and better quality. However, my colleagues wanted to give crowdsourcing a try, and so we did. And know what? Crowdsourcing turned out great, way better than even the biggest optimist at Ronimo had expected!

To find translators, we opened up an email-address for players to sign up for translating to a specific language. We promoted this on our Facebook, Twitter and forum. Within a week, we got several dozen reactions, meaning we had enough translators to have backup if someone bailed out at the last moment. It was also enough to have them double-check each other's texts.

Since we had some new and (at the time) secret features (like the new character Gnaw that is coming this week), we asked each of the translators to sign a short NDA (Non-Disclosure Agreement). An NDA is a small contract that simply states that any secrets we share are to be kept secret. I generally dislike the formality of putting everything under contract, but for something like this it is nice to make it very clear to the testers that we really don't want any unreleased information to leak. For an indie studio, the most important marketing tool there is, is which information is revealed when. So keeping that under control is very important for us.

Once that was taken care of, we simply put our spreadsheet with texts on Google Docs and gave them access. From there, the magic happened... I was absolutely baffled to hear that the very next day, everything had already been translated. No commercial translation company we previously worked with ever worked that fast! And they took their job very seriously: in the following days, they checked each other's work (marking what had and what had not been checked), and extensively discussed how to translate some of the genre-specific words. They even made some improvements to the existing console translations!



Awesomenauts has been out for over two weeks now, and we have not heard any complaints about bad translations. So despite that I don't speak Italian and thus cannot check the Italian translations to see whether they are any good, I think I can conclude that the translators did a great job. Players are quick enough to complain about any other issues in the game, so if they didn't complain about this, then it must have been good enough! ^_^

Another benefit of how this turned out is that if we have any new texts, we can just send them to the translators and they usually have new translations for us within a day. Compared to the formal requests for new translations that we had to do to commercial translation companies in the past, and the time it took for those to come back in all languages (usually one to two weeks), crowdsourcing is just incredibly easy and fast!

Of course, we also wanted to give something back to our translators, so we gave all of them a free copy of the game on Steam. More importantly, we also gave them a special icon in the game: the Golden Duck! (This may sound silly, but I think it is important to officially honour people who help us, and what in the world is cooler than a Golden Duck?!?!)



This blogpost so far obviously suggests that crowdsourcing is a great idea. I think it is, and I wonder: wouldn't it be possible to take this a lot further? Why not let players design puzzles for a puzzle game, for example? Looking at how much user-generated-content has been made for games like Portal 2 and Little Big Planet, I think a lot of players would be honoured to contribute a couple of puzzles to a game! Why not ask users to design puzzles before release and include them in the game? In a sense, this might feel like abusing their time, so maybe some kind of compensation would have to be figured out for that. But then again, I think if they got a chance to contribute to a game they love, lots of players would feel honoured, not abused! Making games is one of the most fun jobs in the world, and quite a few gamers would love to be a bit closer to that by contributing to an actual game.

After all this jubilant talk about crowdsourcing, it is time to mention some of the downsides. For one, I think rallying players becomes a lot more difficult if you don't have an existing playerbase yet. Quite a few people already knew Ronimo from Swords & Soldiers and De Blob, and we already had a ton of Awesomenauts players on console. I guess for your first game, it is a lot more difficult to find enough translators who are willing to really help you.

Another problem is that on console, there are a lot of certification requirements. Console manufacturers think it is necessary to define whether a button is pressed or clicked, and if you use the wrong word, your game might fail certification. (This example is not made up, one of the current consoles actually has this exact requirement...!) Working with players is a risk for these kinds of requirements, since they might not know about them. Professional translators know all the certification rules (or at least, they should...).

There is also the risk of a malicious person putting in weird texts. This happened to Minecraft, where an official release contained a racial slur in the translation to Afrikaans. Having translators double-check each other's work helps against this, but it is always a risk that someone changes a text at the last minute and this kind of horror ends up in an official release...



Despite these potential downsides, crowdsourcing has so many benefits, that I feel it is a great idea. It turned out that it is not just cheap for the developer, but also incredibly fast and a fun way to interact with the community and have them add something of their own to the game.

To conclude, we would like to thank our community translators for their great help and support!