The craziest bugs, part 1

Every programmer must have encountered these: weird bugs. Unexplainable bugs that make you want to tear your hair out. Bugs that are just plain funny in their bizarreness. Even bugs that are pants-on-head-retarded. I have written about a very out-of-the-box bug and a painful oversight bug before, and since then I have encountered hundreds (or was it thousands?) of other bugs. Today I would like to give you my favourites.

These bugs are from various categories: from funny, to surprising, to dumb library design. Most we have been able to solve, but for some the exact cause still remains a mystery. The one thing they have in common, is that I remember them fondly. Or frowning. Or while gritting my teeth...

Click here for numbers 3 to 1

7. Std::abs differs between compilers

This is one I encountered recently in Awesomenauts. We thought hardly any Mac users would have gamepads, so we had initially decided not to support those on Mac. After launching Awesomenauts on Mac, this turned out differently, and a lot of Mac users requested proper controller support. We decided to try to patch this in quickly before Christmas, but one particular bugs almost kept Mac joystick support from making it into that patch.

It turned out that the sticks would only work if they had full output. Pressing them to anything but fully right or fully left had no effect in the game whatsoever. Somehow, our joystick class outputted proper floats in the complete [-1, 1] range, but once they got to our gameplay code, they were only 0, -1, or 1. I didn't see any spots where they were turned into ints, so how was this happening?

The reason turned out to be std::abs(). Normally, this function only works on integer types, and fabs() is used for floating point numbers. However, in Visual Studio abs() also works fine on floats, and we had used it in that way on a joystick axis value somewhere. This version of abs() does not exist on Mac! When we tried to use gamepads on Mac, the compiler did not print a warning and instead simply rounded the decimal axis value to an int and applied abs() to that. Since at that point the axis value was already in the range [-1,1], this meant that everything but -1 and 1 were rounded to 0...

Luckily, we found this one in time and were able to patch in Mac gamepad support before Christmas. And our Mac users lived happily ever after... (or so I hope!) However, I still find the combination of Visual Studio having extra functionality and the Mac compiler not printing a warning pretty nasty!

6. Editor framerate extremely low around centre of world

This is a bug that our artists at some point started complaining about. When using our in-house animation editor, the framerate became incredibly low, unless they moved the camera away so that the centre of the world was not in view any more. I didn't have time to look into this right away, but strangely over time the bug seemed to grow worse and worse, until the editor was hardly usable any more.



Quite puzzled, I dove in. I quickly discovered that the renderer was responsible for the framedrop, so I started gathering data on what exactly was being rendered. The cause proved to be quite... interesting.

Awesomenauts in total has over 4000 animations at the moment, and these contain some 5500 particle systems. It turned out that in the editor, all of these particles were always rendered, but with 0 particles each. The renderer did not check for this, and set up shaders, textures and matrices for these particle systems, and then proceeded to feed the videocard a whopping 0 polygons to render. Doing this 5500 times per frame is not a good idea... The solution was twofold: the renderer should check for polygon count before rendering, and the editor should hide these empty particle systems to keep them from reaching the renderer at all.

I tested the results of fixing this on two computers, and on one the framerate went from 28fps to 115fps in the editor, while on the other it went from 36fps to 273fps. Those are the nicer optimisations!

But why did this only happen at the centre of the world, and why did it grow worse over time? This is because most animations are quite small, and all their objects are near the centre of the animation, including the particles. After some more experimentation, it turned out that since the particles are not all exactly at the centre of the world, scrolling around would gradually increase the framerate as more of the area near the centre went out of view. Finally, the reason it grew worse over time, was that our artists were quickly producing more and more animations for the skins we were adding to Awesomenauts, adding more and more particles to destroy the framerate...

5. Disappearing textures

This is an issue that I actually haven't been able to pinpoint and solve, but it is so bizarre, that it deserved a place on this list. A user reported that at some point, Awesomenauts suddenly started looking like this:



He also posted a video of this event. What you are seeing here, is that the main view of Awesomenauts has been replaced by a small portion of the Steam overlay. The letters are names and the lowest line even mentions Steam's standard shortcut: shift+tab. On top of that, the Awesomenauts HUD is visible, as it should.

The reason I have so far not been able to find the cause of this bug, is that it is extremely rare: it has only been reported to us twice. One of my colleagues also had something similar once: a Steam icon had somehow replaced an icon in our own scoreboard. None of these cases ever happened again. Without any way to reproduce or test, I cannot solve this weird bug.

I can guess what is happening, though: somehow a texture from Steam replaced one of my own textures. The reason this replaces the entire screen in the image above, is that apparently the texture being replaced is the rendertexture that is used to apply post effects to the screen. The other report I saw confirmed this: there a different rendertexture was broken, causing only the background to look black (the background is rendered separately to apply depth of field blur, as I previously wrote about in this blogpost).

This makes me suspect that the problem might not even be in our own code: to render their overlay, Steam pretty much hacks into my rendering process every frame. I imagine the problem might for example be that something in Steam's code is problematic with the way I handle threading in my renderer. So this might not even be a bug in my own code... In the meanwhile, since this bug is extremely rare, I have decided to just leave it be.

4. Random programs interfere with my game

I don't know exactly how they manage to do this, but sometimes random programs manage to break Awesomenauts on PC. The worst offender is Adobe Air: this sometimes completely obliterates a player's internet, causing unplayably high ping in Awesomenauts. This doesn't happen for most users, but I have seen a dozen or so reports from players who managed to fix their high ping in Awesomenauts by uninstalling Adobe Air. This isn't just in Awesomenauts: I have also seen reports of the exact same thing in another game by a different developer.

Another example of random other programs messing up our game, was reported by a player. This user had a very laggy, uncontrollable mouse cursor, but only during gameplay. I had no idea what caused this, but at some point the victim reported that the problem had went away. What had he done? He had updated... Java! Java!? What does that have to do with Awesomenauts? Awesomenauts is written in C++ and doesn't use any JAVA components! I still don't know how JAVA is able to break the mouse cursor in Awesomenauts, but it is a nice example of how completely unpredictable PC development can sometimes be. Consoles may be much more complex to develop for, and they may have all kinds of certification requirements, but at least they are always the same! Hurray for that!

That was it for the bugs today! The four bugs above were still somewhat sane, but the rest of this list won't be. Visit back next week for the top 3, where the real insanity happens!

Why Cello Fortress is a twin stick shooter

Cello Fortress could have been any kind of game. The core concept is nothing more than: "a game in which a live cellist controls the game by playing cello, and plays with or against the audience". This idea can be applied to any genre. The cello could control a brawler, a puzzler, a strategy game, a racing game, with some imagination maybe even a point and click adventure. So why did I specifically make a twin stick shooter? A lot of thinking and brainstorming went into this choice, so today I would like to explain that a bit.

Doing something with improvisation on my cello and my computer is a topic I have been thinking about for years, but it wasn't until a year or two ago that it dawned on me that the cello could actually be a game controller. Before that, I was mostly thinking about writing a procedural music generator that could accompany my own cello improvisations. Quite a big step from a game, but it slowly evolved into one from there nevertheless.



Knowing that the game needed to be about a live performance with my cello, with or against the audience, creates a number of requirements for the game design. These requirements fuelled what would become the actual game, and it was quite a challenge to find something that really met them all well enough.

1. Game is fun to play, and also fun to watch for the audience.
2. Playable by as many people in the audience at the same time as possible, while also being playable by only a single player.
3. Such simple controls that no long explanations or tutorials are needed, and that even non-gamers can play.
4. The cellist has room to improvise and play something that sounds good, while still controlling the game in a meaningful way.
5. The influence of the cello is direct enough that players and audience can quickly recognise and understand it.
6. Bonus requirement: the core game itself is original.

Each of these requirements brings a different view on what this game should be. Number 2 for example favours games with a zoomed out view, so that several players have room to move within the same screen. Splitscreen is also an option for this, but didn't seem such a good fit for readability in case of a larger audience where people might be standing further away. Specifically inspiring games for me where Gatling Gears by our Dutch friends at Vanguard, and the WiiWare racer Driift Mania. Both of these games are also excellent fits for requirement number 3, since they require very few sticks and buttons to control, which makes the gameplay easy enough to explain in just a couple of seconds.



Another game genre that came to mind was rhythm games. Dance mats are really nice controllers for festival-like situations, since they are so physical. However, this kind of game seemed at odds with requirement number 1: most rhythm games don't have an on-screen hero that onlookers can follow and root for.

Requirements numbers 4 and 5 are where the real complexity of the game design steps in. How does a cello control a game while still making music? For example, going left by playing high notes and going right by playing low notes is way too boring. I needed something more subtle. At the same time, the influence of the cello should be clear to the audience as quickly as possible, to make sure people don't think it is a 'normal' game with only a live soundtrack. The cello actually controls the game and ideally people would understand this without my explanation.

This makes the racing game a difficult proposition. I had in mind that the cello would generate the track. But to give players a chance at reacting to it, the track needs to build up a bit in front of the furthest player. This has the big downside that it happens just beyond where most people are looking.

I also struggled with how to build the track from the music. I thought about things like making difficult, spiky roads if the cello plays in minor, while generating more smoothly curving roads when playing in major. However, this is way too subtle. Most people probably can't even recognise the difference between major and minor well enough, let alone link it to the gameplay. In my mind I tinkered with lots of other ways in which the cello could control the game, but I didn't come up with anything that worked as well and as naturally as the current twin stick shooter.



I arrived at the twin stick shooter as a good genre for Cello Fortress pretty early in the process, yet for a long time I kept brainstorming and looking further. This was because of requirement number 6. Twin stick shooters are a pretty overused genre in games, and it is difficult to still do something interesting with them in terms of gameplay. So I preferred something more original and kept searching.

However, in the end a quote from my former teacher JP van Seventer reminded me that keeping the core game less original might actually be a good thing. JP is a Wise Person (tm) and is also Ronimo's regular outside advisor. He currently works at the Dutch Game Garden to give advice to young Dutch game start-ups. He once said something along these lines:

"Innovating everything at the same time is not a good idea, because it alienates the audience too much. It is better to innovate on a number of aspects of the game, and keep the rest recognisable. That way players can relate to it much better and understand how it works more quickly."

This has been very influential on my thinking about games. Before this I had dreams of coming up with a game that would be totally unique in every possible way, and this quote made me realise that that might often not be a good idea. This quote definitely applies to Cello Fortress.

With Cello Fortress having been in the media quite a bit in the past week, I see now how difficult it is to explain what Cello Fortress is. Even after the very explanatory trailer that I posted last week, I read lots of confused comments online from people who don't really get how it works. So I am happy that I chose a genre in which the core gameplay itself at least is really easy to explain, so that I can focus my communications on the much more interesting side of the game: the way the cello controls it and the way the game is halfway between a game and a live performance.

Cello Fortress trailer revealed!

A couple of months ago I revealed my new project Cello Fortress. Now it is finally time for a proper trailer! Cello Fortress is a unique combination of a live cello concert and a game, and is intended to be played at events (festivals and such). This trailer shows how the game works, and shows a bit of the interaction between the players and the cellist.

Cello Fortress is pretty weird and unique, so I guess so far only those who actually played it, really understood what Cello Fortress is about. Hopefully this trailer will clear it up for others as well!


(Video footage recorded by Dyzlo Film at Indigo.)

In essence, Cello Fortress is a twin stick shooter. Four players cooperate using Xbox controllers to destroy as many cannons as possible. However, the cannons are not controlled by the computer, but by a live cellist! He improvises live music on his cello, and tries to do that in such a way that the game not only does what he wants, but also that the music actually sounds good. In a sense, this is the ultimate in adaptive music!

The current version of Cello Fortress is still in beta and far from finished. The graphics are just some quick prototyping models thrown together, and all kinds of things still need tweaking and improving. Cello Fortress is already touring, though, and has so far played at several events in the Netherlands.



Cello Fortress is a complex project in several ways: playing cello so that it sounds good and controls the game is a big challenge and requires an experienced cellist and a lot of practice. Analysing what the cello plays is also technically very complex and has, as far as I know, never been done before in a computer game. I expect I can write a couple of interesting blogposts about sound analysis now...

Cello Fortress may be a music game, but it is nothing like existing music games like Guitar Hero. In Cello Fortress the instrument is a real cello, and real music is played. The cellist is also not scored for playing 'right' or 'wrong' notes. Instead, he controls a shooting game by improvising.

Because the music is so central to the game, I wanted to make sure that the trailer would sound like an actual match of Cello Fortress. In real matches, the music is completely improvised (nothing is composed beforehand), so I decided to also improvise the music for this trailer. I ended up recording over twenty improvisations, and I used the one that I liked most. (The timpani were added digitally afterwards to add a little bit of flavour for the trailer.)

I hope that this trailer will not just get attention in the world of games, but also in the world of music. Cello Fortress could be a revolution in music acts! This makes me quite nervous, though: musicians are bound to hear any mistakes in my playing. Cello is an incredibly difficult instrument to play well. Although it has been a hobby of mine for over twenty years, I can still only hope my playing sounds acceptable to trained ears...



Since this music was improvised specifically for this trailer, it is not entirely the 'real thing'. Luckily, someone recently posted some footage of a match with audible sound (all other video recordings I have contain more audience noises than cello music). The video and sound quality are not super, but nevertheless this gives a good idea of what a Cello Fortress match sounds like:


(Filmed live at the Playful Arts Festival.)

Cello Fortress is a really weird and unique game, but for me it makes a lot of sense: playing cello has been a hobby of mine for ages, and I am a professional game developer. I like to make weird, unique things. How could these ingredients not combine into a game? Coming up with the actual concept for Cello Fortress was more difficult though: cello and computer can be combined in many different ways and it took me years to come up with something that is fun for the audience to play and watch, controllable by a cellist, and allows for beautiful music.

Cello Fortress is a project that I do entirely in my spare time. Nevertheless, I am going to steadily keep improving Cello Fortress, and I hope I can play with it at some exciting events and festivals!

What would you like me to write about?

I have been writing articles for this blog for almost 2.5 years now, and I have strived to cover a very diverse set of topics around game development. I don't really know my readers, though, so having such a broad range of themes has made me curious: what subjects on this blog do you enjoy reading about most? What would you like me to write about in the future?

To the right you can see a little poll with the broad topics, please select your favourite! I'd also love to hear about specific topics you would like to read about. Please leave a comment and let me know! Any other feedback on this blog is also welcome.

In the coming year, I'd like to try to cover some of the requests with (hopefully) interesting articles!

Dynamically melting snow

The most complex graphics effect in Snowball Earth is without a doubt the snow. As the player walks around and heats up the area around him, the snow melts, forms puddles and finally becomes grass. This is completely dynamic: the player can turn his heating on and off at any point, and the snow reacts correctly to that. The snow even has little piles around trees and rock walls, and these piles lower and disappear when the snow melts. So how did we make this?


A slow motion video of how the snow melts around the player.

Before I continue, I would like to mention once more that Snowball Earth is Ronimo's cancelled game from 2008, and that the complete prototype can be downloaded here:


Download Snowball Earth prototype

So how did I implement this melting effect? The basic trick is that for every vertex, I store the 'meltness': to what extend the ground at that vertex has already been melted. A value of 0 means snow, 0.5 means water and 1 means grass. The pixel shader then takes this value and uses it to simply choose between three textures, for grass, water and snow.

To store the correct value in each vertex, the code simply updates all vertices for which the value has been changed. This is done every frame. This would not be very efficient if the vertex count were very high, but it works well enough here. Especially since this is only a prototype and performance isn't as much of an issue as it would be in a released game.

A nice property of storing this value at the vertex, is that the value gets interpolated before it gets to the pixel shader. So if two vertices are next to each other, and one has value 1 (grass) and the other 0 (snow), then a pixel in the middle would get value 0.5 (water). This means that if I smoothly increase the value at the snow vertex during the melting, then the edge of the snow in between the two vertices smoothly moves towards the snow vertex, which looks like the snow is melting at the edges.



The water automatically always becomes a thin edge of water in between snow and grass, because vertices usually rather quickly go from 0 (snow) to 1 (grass).

So far the edges between snow and water and between water and grass would still be straight lines, since they are simply based on interpolated vertex values. This looks kind of okay, but it is still too geometrical to be really convincing. I would like to break up the border and add patterns to it, so I have a special greyscale texture that contains puddle-like patters. This texture is used to offset the 'meltness' value: I simply add the texture's value to it. The effect this has, is that wherever the offset-texture contains white, the water will disappear into grass earlier, while wherever the offset-texture contains black, the water will remain longer.

Our artist Ralph jumped on this and created two offset-textures: one for the water and one for the snow. He made the offset-texture for the water so that it contains roundish, puddle-like patterns, while the offset-texture for the snow contains long curves. This works really well in the actual game.



In practice, the grass, water and snow are all a little bit more complex than simply 'a texture'. The snow has noisy specular reflections, the water reflects the sky a bit, etc. So instead of choosing which texture I use, I choose which material to use: snow, water or grass.

I wanted this to run on shader model 2 videocards (pretty ancient these days), so I couldn't use an if/else statement to choose the material, since if/else is not supported in shader model 2. Instead, I used the step(a, b) function, which returns 0 if a is larger and 1 otherwise. With some puzzling, most math that needs if/else-statements can be replaced by step-functions, allowing quite complex things to be done on ancient shader model 2 videocards. This is also how I got the snow/water/grass choice working. Just look at this tiny bit of shader code for how that could be done (note that the final line could be replaced by a lerp(a, b, c) call instead):

float4 grassColour = tex2D(grassTexture, uv);
float4 snowColour = tex2D(snowTexture, uv);
float choice = step(0.5f, meltness);
float4 final = (1 - choice) * grassColour + choice * snowColour;

For a complete look at the shaders described above, you can check them out in the file Data\Assets\Shaders\Snow.cg in the Snowball Earth prototype.



The final element to the snow effect is that the snow has little piles around trees and such, and when it melts, it lowers and the piles disappear. This was done with a simple morph: our artists made two versions of the ground meshes: one low one for the grass, and a slightly higher one for the snow. As the ground melts, the two positions for each vertex are simply interpolated to get the final position. Every snow-pile in the game was made by hand by our art-team, who raised the vertices around trees and next to walls.



Only one of the two meshes for the ground is used to handle physics and collisions. This is the lower grass-mesh. A nice added benefit of that is that all characters walk in the snow and on the grass/sand, giving the snow just that little bit extra.



To add to the atmosphere, there are also two different sets of lightmaps in Snowball Earth, each with different colours. This way I was able to give the snowy world a colder, more blueish lighting than the unfrozen world.

Having two sets of lightmaps also has an added benefit. There are no real-time shadows in Snowball Earth, so normally there would be the problem that objects that appear dynamically (like leafs and smaller plants) cannot cast shadows. Having separate shadow maps for the frozen and melted versions makes it possible to calculate these shadows into the melted world only.

This solution is not completely correct, though. If you look closely, you can sometimes see that if an area near a big plant is already melted while the plant itself is still frozen, it already contains the shadow of that plant, even though the plant itself has not appeared yet. However, this visual error only happens at the transition from frozen to unfrozen and is hardly visible (unless you look for it), so I never really considered that a problem.

That's it for Snowball Earth for the moment! Let me know if there are any further topics about Snowball Earth you would want to read more about! In the coming weeks I'll be getting back to posting about Awesomenauts, Cello Fortress, and hopefully also about some exciting graphics experiments I have been doing!

Snowball Earth's melting effects

The part that I find most interesting and am most proud of in Snowball Earth (our cancelled game from 2008), is the melting effects. Every piece of the world is frozen and covered in snow, and by walking around with the heating turned on, the player can melt it all. In the prototype this had very few gameplay mechanics attached to it, but just seeing and hearing everything come to life is already so much fun that it could carry half the game on its own. Today, I would like to dissect this effect and give an overview of what went into it. (Spoiler: a lot of custom art by our artists Gijs, Ralph, Olivier and Martijn, and a lot of coding by me).


The melting effects in Snowball Earth

For those who haven't tried it yet: a couple of months ago (in this blogpost) we released the entire prototype we made at the time, so you can download and play it yourself. Note that this is a Torrent file, so you will need something like BitTorrent to download the game. Here is the download link:


Download Snowball Earth prototype

To manage the melting, the game has a big 2D map of the level (a grid, really) and for each point on the map, it stores how much it has melted yet. By walking around, the player turns the parts of the map from frozen to green. This map is then used by all elements in the level to determine to what extend they should show up melted.

A rather simple effect is the smaller plants: they are just scaled to size 0 until they are unfrozen, at which point they grow to full scale with a nice popping animation. For variation, our artists made a couple of different popping animations, but that's about it.

Key to the joyful feeling while melting things, is that every time such a plant pops up, a little bell is heard. These bells have a number of different tones, which form a happy harmony together. When several plants are unfrozen shortly after each other, their popping creates little melodies. Thanks to Aline Bruijns for the sound design on this.

Larger plants, with which the player can have collision, are already there in frozen state. As the player melts them, their texture goes from a frozen version to an unfrozen version. Leafs and such can be made to appear during the melting by setting their alpha to black in the frozen texture, and to white in the melted texture.



To make these plants look more lively, a vertex shader animates them with a simple waving motion. We have a couple of different shaders for different types of plants. Of course, this waving should not happen in frozen form, so this effect fades in smoothly as the plant is unfrozen.

If you have played the prototype, then you might have noticed that it takes a long time to load, and performance isn't quite that good. Current PCs can handle it fine, but in 2008 only the fastest PCs could run the prototype at a high framerate. The main reason for this is that there are a lot of plants in the level, and they are all separate objects that need to be loaded and updated. If the game had not been cancelled, getting this to work smoothly on the Wii would have been a huge challenge...

Performance wasn't only a problem in the game itself: the version of 3D Studio Max we used at the time wasn't up for the challenge either. To make sure our artists could re-use the same plant in several parts of the level without needing to copy-paste the entire plant, I had made a little plug-in script object for 3D Studio. This object would automatically handle an XRef object: a reference to a plant model in another file.

However, the combination of lots of scripted plugins and lots of XRefs totally broke 3D Studio. Near the end of the project, our artists had to restart 3D Studio every hour or so, and had to constantly monitor its memory usage. At some point the memory usage would suddenly go crazy, leaving about 20 seconds to save the work... This made me a little bit afraid to use existing tools in the future again, and I am much happier with our own in-game tools for Awesomenauts now. In our own code we can actually solve brutal bugs like this...

We also wanted grass, and because of the performance trouble, I immediately built that using something similar to a particle system. All the grass in an area is rendered as a single object, despite that pieces of grass can grow individually based on what part of the grass area had already been melted. I even made a nice little brush plug-in for 3D Studio to allow our artists to quickly draw the grass where they wanted it. Programming 3D brushes is immensely fun, it is a pity I haven't needed custom 3D brushes for something since!



Ice walls in the Snowball Earth prototype may look like they were made using physics, but to reduce coding time, their destruction animation was animated by hand by an artist. As a cute little extra, we also have smaller blocks of ice with frozen animals in them. When they are broken, the little rabbit inside starts walking around and makes rubber ducky noises when the player stands on it.



A more subtle element is the sound effects. The game has two tracks of ambience: one with sounds of birds and jungle, the other with chilly winds. These are subtly faded in and out depending on how much of the area around the player has already been melted. Few players will have actively noticed this, but this is incredibly important for the mood of the game. As the player walks from the happy jungle in an area he just finished, to the chilly winds of a new area, he cannot help but feel even more like it is time to melt it all and bring back the happiness!

So far I haven't mentioned the thing that is most noticeable in the melting effects of Snowball Earth: the ground. This is because the ground is my pride and joy in this topic and I find it interesting enough that it deserves its own blogpost! See you next week!

Wacky marketing thingies

In last week's blog post, I mentioned several times that doing marketing as an indie requires creativity. It is easy to buy advertisement space, but it is a lot more challenging to come up with things that are so interesting that press will write about them for free.

At Ronimo we greatly enjoy coming up with such weird marketing stuff, so here are some of the most fun/creative/weird things we have done so far, and also some that I did myself for Proun. Some only cost us time to do them, while others did require small amounts of money to produce. Note that not all of these actually worked as well as we hoped, but they are hopefully still fun to see! ^_^



Swords & Soldiers hot sauce! The game's story is all about barbeque sauce, so giving press special branded hot sauce seemed fitting. Of course having these made would be very expensive, so we simply bought standard hot sauce, removed the labels, and put our own stickers on them. All of this was done in a hotel in San Francisco, since importing large amounts of food is probably not allowed. I suppose the hotel still remembers Ronimo fondly for clogging the bathtub drain with soaked labels...



For Awesomenauts we had a little bit more budget for marketing, so we had these special bags of Awesomenuts made to hand out at Gamescom 2011. The naming pun is so good it was just impossible not to!



I still consider this one of our best marketing tricks. For players who got all the achievements in the WiiWare version of Swords & Soldiers, a special code was generated that they could e-mail to us. We promised the first people to do so a bag of Swords & Soldiers swag, which amongst other things included the special poster above (autographs of the entire team are on the back). We announced this before the game launched, and we actually saw quite a few people online discuss how fanatically they were going to play on launch day to win one of the prizes. The buzz was nice, and as a bonus it turned out that one of the winners was a game journalist, who posted the contents of what he won as a news article on a big WiiWare site.



A friendly marketeer was nice enough to help us with some press releases, and he came up with the term "Morefun (tm)", which is something we had apparently come up with in our game laboratory. It made no sense at all, but it was funny and quite a few websites picked up on it. This is a nice example of how something as small as the way you word a press release can already have an impact on how well your game is covered!



For Awesomenauts we had an intro made with a real theme song, for which this great singer was hired. The song turned out to be a great central piece for our marketing efforts. All our trailers end spectacularly on a high note by Jeffrey, and the cheesiness of it all got a lot of buzz going when we first announced Awesomenauts!



Since Sonic Picnic made such a remarkable soundtrack, we figured it would be a good idea to have it printed on vinyl as a gift for press and friends, and as a reward for competitions and such. Having a real vinyl copy of your soundtrack is indeed amazing, and everyone who receives it, seems to love it. Even those who don't even have a record player...



When we learned it was possible to order special shoes themed to your own game, we just couldn't not order them for Awesomenauts. These shoes were recently given away as the main prize in a competition that some website ran.



A lot cheaper to do were these custom Swords & Soldiers Move controllers, since we customised them ourselves. These were given away at a contest on IGN. We had hoped to reach front page with this, but in the end IGN didn't post it that big, so the actual reach of this was limited. Still, fun swag to make!



This is an example from a totally different category. Making more than one or two trailers require that you look at your game creatively. You need to think about how it can be something new and interesting in every video. For Proun I made a video in extreme slow-motion, which differs greatly from the speed of the real game, but is pretty mesmerizing to watch.



I did not choose Pay What You Want for Proun as a marketing gimmick, but it turned out to be a great trick for that indeed! As far as I know, Proun was at that point the biggest game to ever be Pay What You Want right from launch day. The Pay What You Want model was also still quite new to games at the time, so press picked up on this massively and it drove tons of extra attention and sympathy to the game.



Another example of something that was not intended as marketing, but turned out to be great for it: a couple of months after Proun's launch, I released the complete sales data for Proun, plus an analysis of what I thought it all meant. Revealing sales data like this is extremely rare in the games industry and was thus picked up as news by lots of sites. The result was a lot of extra sales, and I think in the end around 10% of the total sales of Proun happened because of that one blogpost.



The main reason De Blob managed to take off and get enough interest that THQ decided to buy the rights and make two console reimaginings, is that we put out entire version of the game online for free. Looking back, our version of De Blob can be considered to have been a prototype for the final version, which we released online as a marketing trick to increase interest in the game, and to see whether the concepts were good enough for a bigger game. Apparently sometimes just throwing your early stuff on forums can be a great marketing trick!


Most of these marketing ideas generated a decent amount of buzz for our games, but of course not all of them turned out successful. However, at the very least we ourselves greatly enjoyed each and every one of them! ^_^