The skill design system in Awesomenauts

(Note: Swords & Soldiers is currently on sale on Steam! 50% discount! ^_^ )

At Ronimo Games we always try to make innovative games, and in my opinion one of the biggest challenges when doing so is how to enable the game designers to do their work. Game designers work with things like game mechanics and control schemes, but you cannot know whether what you designed on paper is a good idea, until you played it and experimented with. It requires programming to create something playable, so unless a game designer is also a programmer, he cannot really do much on his own.

For artists, this problem has pretty much been solved: graphics tools are so powerful that artists can create most things without need of a programmer (except maybe for polish and performance). For game design however, this is essentially an open problem. There are many methods to empower game designers, but none are ideal. To name a few: scripting lanuages, event based systems, tools like Gamemaker and Virtools, and the most used of them all: just copying everything from existing games and not even trying to be innovative in any way (this also solves a lot of other issues, like the problem of being creative and taking pride in your work).

The approach we use to enabling game designers to create stuff is not ideal either, but it does work really well for us, so I'd like to write a couple of blog posts about the systems that allow our game designers to create game mechanics. Today is the first, and it is about our skill system.

To us it all starts with the coders and the game designers working together closely. Now whenever a programmer builds something, we set it up as flexible as possible, and make settings to control it. Things like speed, size, health, cooldowns and whatever else we can think of are put in settings and our game designers can edit those. Last year I wrote a post about our settings system in Swords & Soldiers that explains the basic idea further.

However, the way we approached this in Swords & Soldiers was also quite limited. All actual behaviour was programmed specifically per unit, so the only thing our designers could do, was tweak them. If they wanted to create a new unit, or even combine properties from existing units, they had to ask the programmer (me) to implement this for them.



In Awesomenauts we set out to make things more flexible. A character in Awesomenauts mainly consists of a list of skills, and which button needs to be pressed to use that skill. We have programmed around 20 skills (things like Shoot, Hit, Jump, Dash and Shield), and designers can create new versions of each skill with separate settings. Designers can also attach several skills to one button to create combinations, so maybe there is a combo skill that shoots a bullet and starts a shield at the same time.



In this trailer you can see how Sheriff Lonestar's set of skills works out in the actual game:



Each of the skills refer to a group of settings that define the exact properties of that skill. So there can be many different Shoot skills, each with different settings. This way some become grenades, other bullets, lasers or mines, and some even spawn new creeps.



Now this is really flexible, and I guess it is quite obvious that building it like this works much better than hardcoding the entire character as we did in Swords & Soldiers. The trick to making this really flexible, though, is to make lots of settings. Throughout development of Awesomenauts, we have constantly been adding new settings to make the existing skills more flexible, so that more things could be made with them.

However, it may seem so, but working like this is not an Obvious Good Idea (tm). It has some serious downsides as well, which all boil down to one thing: skills can be combined in any way and this makes all character code infinitely more complex. If you have 20 skills, then designers can already make 400 combinations of two skills happening at the same time. You can see where this goes once every character has 10 skills...

So implementing this system cost us an enormous amount of time to get all the combinations to behave correctly. A good example of the complexity here is animations. How to choose which animation to play when several skills are active at the same time? There are so many combinations that we kept bumping into situations where an animation did not look good or work correctly because some other skill interrupted it in the wrong way. This is very solid in the final game, but it took us a lot of work to get there. Unfortunately, it is still very fragile code (i.e. it is easy to introduce bugs when working with it).

Another downside of this system is that if you want it to be really flexible, then you need dozens of settings for each skill. The more settings there are, the more difficult it becomes for the game designer to keep track of what each does exactly. During development it happened quite often that our designers asked for a feature that was already there.

Of course, the upside of this is that with so many settings, there are many combinations that achieve totally unique things. Especially the Shoot and Shield skills have been applied by our game designers to do totally different things than what I expected when we programmed them.

So choosing between the flexibility in Awesomenauts and the very inflexible system in Swords & Soldiers, I actually don't think the flexible system always wins. I would even say the system in Awesomenauts might be up to three times as much work.

However, if, like we did in Awesomenauts, you want to spend a lot of time iterating on the game design to find the most fun and varied units, then more flexibility is definitely necessary. So I think we made the right choice for Awesomenauts. It is a choice that cost us a lot of development time, but that also improved the game's quality enormously.

The lamest bug we ever encountered

Yesterday we resolved by far the lamest 'bug' I have ever encountered. We spent almost two whole days with the entire programming team (5 coders) trying to find it, and once we discovered what was happening, it felt so incredibly lame, that I figured it would be a nice story to share. So here's what happened!

In the past half year we have seen a really rare bug occur about once per month in Awesomenauts on the Playstation 3: suddenly the game would freeze for anywhere between 10 to 100 seconds, and then continue normally as if nothing weird had happened. We always have a PC connected to collect logs from the game. However, the log printed nothing interesting and showed simply the framerate, which is printed once per second:

13:48:13 60fps
13:48:14 60fps
13:49:21 1fps
13:49:22 60fps

From this we concluded that the issue must be in some part of code that does not log anything. That leaves 99% and with a codebase of at least 150,000 lines, that is a lot!

Since this issue was so rare and we hadn't seen it in months, we had closed it. We thought it was an anomaly that we couldn't find or fix and that had somehow disappeared.

Until we were testing our latest build last Thursday. We were playing on seven Playstation 3 devkits, when suddenly 4 of them froze for about 90 seconds. Argh! We thought this really difficult bug had magically disappeared, and now it was back, with a vengeance! We cannot leave a bug in that happens so massively on all these consoles at once!

Again, no relevant logging. Yet something really interesting nevertheless: these Playstations were in different online matches, so they weren't even talking to each other! So how could they all freeze at the exact same time? We concluded that the only thing they had in common, was that they all talk to the same Sony matchmaking servers, so we started investigating all our code related to that. However, we couldn't find anything relevant.

So we added a lot more logging, and did some really advanced stuff to get more info on the stack during the freeze (which is difficult to get from an executable that has been stripped of all debugging info), and started playing again. I let the Playstations perform our automatic testing all night, and the bug didn't happen. Then we played the game for five more hours with the entire team and BAM!, it finally happened again on two consoles!

This time, we had more info, and it turned out that the spot where the game froze was different on both freezing consoles, and both did not contain any calls to Sony's matchmaking servers. In fact, it was in between two logging calls, in a spot where nothing relevant was happening. So we concluded there were only two possible causes: either other threads were hogging the entire CPU (due to how the scheduling system on the Playstation 3 works, high priority threads can do this permanently), or the logging itself was broken.

So we started experimenting around that, and now we quickly found the cause of this 'bug': when the PC that is tracking logs goes into sleep mode, the connected consoles freeze a little while later; once the PC is awoken once more, the consoles continue as well a little later. The PC that was tracking the logs automatically went into sleep mode after not touching it for 30 minutes. This only happened during extensive play-testing, because people normally actually use that PC. So it wasn't even a bug in our code! ARGH! Especially since logging is turned off in the release build...

This may all seem really obvious in hindsight, but in general when we have a bug/freeze/crash it is in our own code, not in one of the tools we use. With such a big codebase, it is easy to not even think about something else. Also, in the chaos of 14 people playing the game on 7 consoles, it is easy to overlook one specific PC going into Sleep mode a little bit before the consoles freeze... Also, I still don't know why not all consoles connected to that PC froze.

So, this hard to find and very persistent bug turned out not to even be a bug! And what do we learn from this? Two things:
1. Really nasty bugs are often in a totally different spot than where you are looking.
2. Sometimes you encounter the lamest and most frustrating stuff while programming games!

QQQ

In his talk at Quakecon this year, legendary programmer John Carmack (Keen, Wolfenstein, Doom, Quake, Rage) talked about code quality, and how even the very best programmers make lots of mistakes. So he says that every programmer should think about ways and methods that make mistakes happen less. This is something that I totally agree with, and this kind of thinking is the basis of the coding standard and methodology that we use at Ronimo Games.

One of the nicer things that have crept into our coding standard over the years is a tiny little trick that keeps a lot of issues from happening. It is pretty obvious, but I know a lot of programmers who don't do something like this, so I figured it would be useful to mention this one today. :)

Often when you are programming something, you quickly make some changes somewhere else to test one specific situation. For example, maybe you are testing the graphics of a weapon against a specific enemy. If that enemy dies all the time, you need to find another one to test on, so a quick change could be to decrease the damage of that weapon against that specific enemy by 90%. Now the enemy stays around a lot longer and you can test more efficiently.

However, once you are done working on that weapon, it is really easy to forget to remove your little hack. Later someone else spends hours searching through code why that enemy dies so slowly. Only to discover that forgotten hack of yours.

Many coders would say now that this is sloppy programming and you should just be a better programmer and remember these things. However, while programming, there are so many things to consider that it is easy to forget one once in a while, no matter how good you are. It is better to design your working method around the idea that you do make mistakes, then to simply say you should be a better programmer.

Now since these little hacks are a great help when programming, everyone I know uses them a lot. So I came up with a really simple trick to keep track of them. Whenever you do a little hack like that, you add a comment with the text "QQQ". So like this:

if (enemy->getName() == "UrQuan") damage *= 0.1f; //QQQ

All coders at Ronimo do this ('voluntarily'). Before we commit our newly written code to the source server, we search for QQQ to see whether we forgot anything. That gives us a list of all the temporary hacks that are still in there. And because we all use QQQ, and not something different for each programmer, we can quickly find QQQs that someone else forgot to remove.

Since QQQ is basically just a marker to remember something, I also use it when I realise I need to remember to rework or check something later on.

So why the letters "QQQ"? This specific term has the benefit that it never occurs in any normal sentence, and is short enough to quickly put in while working. I actually stole it from my brother and sister, who are both researchers and put it in their texts when they need to fill something in later.

Monster Truck VS Zombies - A cancelled Ronimo project

At Ronimo Games we make lots of stuff that is never released or shown outside our office. Kind of a pity, really, because quite a lot of that is really cool! So I am really happy that today I can show one of the cancelled projects that I personally like most: the insane mockup trailer we made in May 2009 for Monster Truck VS Zombies!



This is a pitch video we did for a big mobile publisher (can't say who, since that's confidential). They wanted fresh games for something, and in a couple of days we came up with a concept, made concept art and produced a pitch video to show all of that.

This was to be a really small game, so we came up with a slightly simpler concept than what you usually see from Ronimo. The idea was to make a side-scrolling stunt-driving game, much like Excite Bike and Trials. You drive a giant monster truck and the goal is to kill zombies through stunt kills. After each level you can buy upgrades and weapons for your truck and driver. But really, the video says at all, so just have a look:



The music is Sad Man's Tonque by Volbeat. Since this is just a pitch video and not an actual product, we used an existing song that fits the game.

The art in this video was of course made by our art team, but I got lucky and could animate the gameplay sequence in the middle (the part with the stick figures ;) ) and do the video montage. Since I am lead programmer at Ronimo, it rarely works to let me do art things: it is impractical for our planning and our artists are way better at it than I am. However, I really enjoy the rare moments when there is an opportunity for me to do some 3D art, animation or lighting! :)

As far as pitch-videos for new concepts go, I think this is a pretty good one. I think it communicates both the style and the actual gameplay pretty well. Through the choice of music and the logo and concept art, it gives a good feel for how the player will experience it.

The gameplay mock-up video in the middle shows what the actual gameplay will be. We deliberately made this with stick figures, so that it is absolutely clear that this is not the graphical style the game would have. Since we wanted to make this video in only a couple of days, trying to show what the real graphics would look like in the final game during gameplay would not have worked: it is simply too much work to make that on a high enough quality level. In practice, it is always difficult for a viewer to look beyond mediocre graphics and realise that the real game is going to look better. So I think if you want to pitch something, it is a good idea to make things either look/play absolutely fantastic, or make it super clear that only parts of what you are seeing represent the final product.

So since the gameplay animation didn't show the graphical style of the game, our artists instead made two concept art pieces for that. One is the 'standard' concept art image. It features the main elements of the game and looks as cool as possible:



However, this kind of concept art is not very useful for anything but setting the mood and character. At no point in the game will you play anything that looks even remotely like this. After all, the game itself is side-scrolling and shows the monster truck from quite a distance.

This is a pitfall that lots of concept artists seem to fall for. How often does a concept artist design a character specifically to look good from the front, even though the game is third person, so you look at his back all the time? So at Ronimo our artists mostly make concept art from exactly the perspective of the actual game. So when we decide on a style or design, we decide based on what things will actually look like in the game. So for Monster Truck VS Zombies, our artists also drew an image of what the actual game would look like in the end:



Monster Truck VS Zombies was cancelled and nothing was ever made for it besides this trailer. So what went wrong with this game? A couple of things. First: the publisher didn't like it, so there was no financing. Then there was the platform: we had never worked with that mobile device before, so doing a new device was going to make the coding team too much of a bottleneck. Especially since I was still the only programmer at the time.

Finally, and this killed a lot of the enthusiasm in our team for this project: we discovered a Flash game that was almost exactly the same. A side-scrolling stunt-racer where you kill zombies with a monster truck. That Flash game was so badly made that it was no fun at all, but still, seeing something so literally the same is far from inspiring. We always try to make something that is at least slightly original and innovative, and this wasn't that any more after we saw that video.

Anyway, I still really like this little over-the-top pitch video for Monster Truck VS Zombies, so it is really nice to finally show it here! :)

Making an HD 2D game look good on an SD television

Awesomenauts and Swords & Soldiers are both 2D games that have been designed for high resolution HD screens. So how do they look on old CRT televisions with their low SD resolutions? The obvious answer seems to be that they should automatically look great: the art is super crisp, because it was designed for a higher resolution. However, what you may not realise, is that too crisp is not a good thing!

The problem lies in anti-aliasing, and in graphical details. Anything that the artists have drawn that is only 1 pixel wide in HD, will start to flicker on an SD screen. This happens for the simple reason that not every pixel will be shown on an SD TV. The art has been made for 1920x1080 pixels on the screen, and only 720x576 of those will be shown on an SD television. As a character moves over the screen, his details will flicker in and out of view as they are sometimes on a pixel, and sometimes in between two pixels.



This is especially problematic for anti-aliasing: in a 2D game, anti-aliasing of edges is drawn in Photoshop and doesn't require any work from the game. But on an SD television, the pixels that make the anti-aliasing may fall in between two screen pixels, meaning that anti-aliasing is often entirely lost.



(Note that this is a problem that is specific to 2D games: in 3D mipmapping is used to solve this problem, and anti-aliasing is rendered in real-time by the videocard.)

So when we render our HD 2D graphics to an SD television, they look noisy and too crisp. Now how do we solve that?

The solution is actually pretty simple. To get an image that is both smooth and sharp in SD, we use an easy trick in both Awesomenauts and Swords & Soldiers: on SD televisions, the game is rendered at a higher resolution than what is shown on the screen, and then sampled back to the lower screen resolution. This is a standard technique in non real-time rendering and is called supersampling.

So first we render the game at a higher resolution (1080x864 instead of 720x576). Then this high resolution image is rendered to the screen by sampling the area beneath each screen pixel. For each screen pixel, I take four samples from the high resolution image and use the average of that. This way really small details are not lost. Instead, they become more subtle, since they are averaged with the pixels around them.



So what resolution do we use for the high resolution image that we sample from? Easiest would be to use twice the screen resolution, but that requires rendering at 1440x1152, which is really high and wastes a lot of performance. I experimented a bit, and it turns out that rendering at 1.5 times the resolution is already enough to get smooth graphics.

This is a good thing, because twice times the resolution does tend to become quite expensive. In fact, at some point SD TVs had a lower framerate than 720p HD TVs, which is why I started experimenting with the exact resolutions to find a better trade-off between performance and quality. At 1.5 times the resolution, the framerate is smooth again.



The results look good, and they mean that I don't have to bother with storing all textures on different resolutions for HD and SD televisions, which keeps our art pipeline simple.

This post may seem to be about a really minor detail, but on old SD televisions, this really makes a big difference. Without this technique, both Swords & Soldiers and Awesomenauts didn't look good on low resolutions.

I find it really interesting that if you want to make a quality game, you really need to worry about all kinds of seemingly small details. All those little things in coding, art, sound and design are what makes a game polished, and this post has been about just one little example of the kind of polishing we do on our games.

Next week, I expect to have something really cool to show here, so see you then! ^_^

How a lack of art influences prototyping results

It is common knowledge among modern game designers that you have to prototype your game designs early and often. Yet when you do that, you usually don't have any art to put in your prototypes yet: the art team has probably also only just started development. Some game designers might say this is actually a good thing: your game design should be fun even when played with just coloured squares or simple icons, so you should start there and only add art and sound once the abstract core gameplay is fun. I used to agree with that in most cases, but during development of Awesomenauts, I learned that working from such abstract prototypes can also steer your design in certain directions, which is not always an improvement.

What really made me realise this is the jumping mechanics in Awesomenauts. Since we didn't have any art for this new game yet at that point, we made the very first gameplay prototypes for Awesomenauts using characters from Swords & Soldiers. However, these characters don't have any jumping animations, since Swords & Soldiers doesn't feature any jumping.



Now at some point our game designers wanted to add some weight to the movements of the characters, so they proposed that the characters would need to really push off the ground when jumping, and really land after a jump instead of immediately continuing to walk. Since we didn't have any art for this yet, I implemented this by simply adding a short pause before jumping and after landing. So when you press jump, the character takes 0.5 seconds before going up, and after landing he pauses 0.5 seconds before continuing to walk.

In terms of pure game mechanics, this is the entire thing. The only difference between this and what would be in the final game, is that these 0.5 seconds pauses would have specific animations for pushing off and landing. So in terms of abstract game prototyping, this was a complete prototype with all the mechanics in it.

Yet is played horribly: it simply felt like the game's controls were slow and lagging behind, not like the character had more weight and presence in the world. So we threw out the pauses after a couple of short internal playtests.

At this point I realised that the reason these pauses felt bad was not that the mechanic in itself was wrong. The reason it felt bad was that there were no animations. If there is no animations, then the 0.5 seconds pause before jumping is simply a delay on your controls. You press the jump button and nothing happens for a little while. Yet when there are animations, something does happen immediately: the character bends through his knees and pushes off the ground. The delay between pressing the button and moving up is the same with and without animation, yet the feedback is way better when there is animation, because the character immediately reacts to your button press, even though he doesn't immediately start moving up.

To me this was an interesting realisation: it is not always possible to use abstract prototyping to see whether a mechanic works! Sometimes you need proper art and animations to know whether the gameplay is any good.

Note that in this case, squashing the character before and after a jump would already have been a big improvement, because this way at least the graphical feedback would have been immediate.

So the prototype was not a good enough test. But was not having these extra animations a good choice? I still think it was: Awesomenauts is a very fast skill-based game and quick and direct controls are incredibly important, so we would have wanted immediate jumping anyway. So despite the incomplete test, I definitely think we made the right choice.



Of course, this is totally different for each game: for a game like Assassin's Creed, the subtle animations really make the game, and make it feel like the character is really climbing those walls and has real weight. So it really depends on the game whether the delay that is added by in-between animations is a good thing or not.



So whether you have animations in your prototype or not greatly influences the core feel of your gameplay. The same applies to many other assets. Here are a couple of examples of situations where prototyping with or without sound and graphics can make a big difference on what the conclusions of the prorotype are:

-Games are way more fun with sound. Half the intensity and thrill you feel while playing a game comes from the audio. However, often sound designers are contracted rather late in development, so you usually don't have the real sound effects during the first half of development. For Swords & Soldiers, we fixed this in an easy way: we simply copied the sound effects from Warcraft III and used those temporarily. As soon as the real sound effects by Sonic Picnic were created, we threw out all the Warcraft III sound effects. But until that time, we had a much better feel for the actual game, because we actually had any sound at all.

-When looking for the right style of music for a game, a common quick prototyping method is to simply put on the music outside the game and then start playing to see whether it feels right. This is of course a good idea, but it also influences the attachment between the music and the game negatively. The problem is that the timing of the music is not linked to the game when you do this, because you have to start the track outside the game. It works much better if the music is started at the exact same time as a level, because now the music is not part of everything outside the game any more. I noticed this with several games now: music never really feels right until the timing of starting and stopping the music is right. Adding this timing to a prototype is usually really simple and helps a lot.

-A really obvious example is guns in a shooter. The most important thing for a gun in a shooter is that it feels right and has serious impact. Since 80% of the feeling of impact for a gun comes from the graphics and the sound, and only 20% from the actual gameplay and damage of the gun, it is impossible to really prototype guns if you don't add any audio and visuals. However, creating those well is a lot of work, so I guess you have to start without, but until you have sound, I don't think you can really tell whether a certain concept for a gun is an awesome idea or not.

-The Aztec Sun Giant and the Viking Frost Hammer in Swords & Soldiers are rather similar soldiers in terms of abstract game design: slow, specialist units that deal area of effect damage and shortly put the enemy out of battle (through respectively knockback and stun). When playing the game without graphics, one might conclude that they are too similar, except for their large difference in price and health. So maybe more variation is needed? No, not really: when the art is added, these two units feel really unique and different, making them work really well in the game. Again, prototyping without art might not have been a good idea for these two units.



The most important realisation from this whole topic is that the prototyping method greatly determines the outcome. Prototyping gameplay with or without graphics and audio gives different conclusions about which mechanics work, and it is important to realise that this is the case. Of course, I am absolutely in favour of prototyping early and often, even if you don't have any art yet, but I do think trying to add some sound and graphics as early as possible greatly helps, even if they have been ripped from other games for the time being.

There is a more general lesson here as well. This post was just about graphics and audio, but I think the prototyping method always influences the outcome. Paper prototyping, prototyping in editors from other games: always keep in mind that the prototyping method used has some kind of influence on the outcome!

PS. Woohoo, Proun has been nominated for the Dutch Game Awards in a whopping three categories: Best Visual Design, Best Original Game Design and Best Audio Design & Music! Incredibly cool! Only one other game was nominated in that many categories: Killzone 3. That is one really big and really good game, so it is an honour to get the same number of nominations! However, since Killzone 3 was developed by something like 200 people, and Proun by only two, Proun has a hundred times more nominations per person than Killzone 3! [insert evil laughter here] Some other awesome games that got nominations are Radical Fishing (by our neighbours Vlambeer) and Gatling Gears.

The Bouncy Stick Problem

Awesomenauts has really fast controls: if you push the stick in a direction, your character immediately faces in that direction. Many games have smoothing animations in between, making the game look more realistic, and adding a bit more weight to the character's movement. However, this also slows down the game a bit and adds some delay to your input, since the character isn't immediately doing what you tell it to. For Awesomenauts we chose to have really quick controls and not do those in-between animations too much.



However, we discovered an interesting problem with reacting so quickly. It turned out that quite often, when a player walked to the right and then let go of the stick, he ended up facing to the left. Even though he was pressing right. Depending on the controller and the way the player handled the stick, this may never happen, or happen 30% of the times. When this happened it was quite annoying, especially when it happened in the shop: the player would accidentally buy a different item than he wanted once in a while.

So we investigated this issue and my colleague Machiel (of Paper Cakes fame) discovered what was happening: whenever you let go of the stick, it bounces back to its centre position. But the spring that causes this bounce is so strong, that the stick actually bounces beyond the centre position for a very short amount of time. This GIF animation shows what I am talking about:



Note that this doesn't only happen on the Playstation's controller: it also happens on the Xbox 360 controller.

So this explains why the player sometimes ends up looking in the wrong direction: for just one frame, the stick bounces back beyond the neutral position. Awesomenauts reacts to input so quickly, that this results in the player immediately turning around. In slower games, this would not be a problem, but in Awesomenauts, it is.

So I made some measurements on the exact output that the stick is giving each frame. In some cases when you let go of the stick, it just springs back to the neutral position. In other cases, it indeed bounces beyond that.



This doesn't always happen, though. So why is that? As you can see in the measurement, the spring back happens extremely quickly, usually within one frame. My guess is that the bounce beyond neutral actually always happens, but is so fast that it often happens in between two frames. So I can't always measure it and thus the game quite often isn't influenced by this bounce.



I tried this a lot of times, and it turns out that the stick can bounce quite extremely. When in the neutral stick position, the stick has position 0. All the way to the left is -1 and all the way to the right equals 1. Now when I let go with the stick all the way to the right (1), I have seen it bounce back to as far as -0.72 before getting back to 0. So that bounce is almost entirely to the left! This greatly depends on the controller, though: it seems like the bounce becomes worse when the controller is older, so apparently it increases with use.

The solution

So, how to solve this? The first thing that comes to mind is to increase the deadzone: ignore small stick input and hope the bounce falls within the deadzone and thus isn't used. However, since I sometimes measured a bounce of up to 0.72, I would have to increase the deadzone to almost the entire range of the stick, which means the game would only react to stick input when the stick is entirely to the right or left. Not cool.

Another solution also seemed reasonable: since the bounce happens for only one frame, an easy solution would be to ignore input that takes only one frame. However, the game cannot know this until one frame later. So to ignore single-frame input, I would have to introduce a one-frame delay in handling the player's controls. That sucks, because it takes away a little bit from the instant controls that make Awesomenauts play so well.

Now if you look at the graphs, you can see that the user never moves the stick all the way to the right in a single frame: he takes several frames to do this, even on 30fps. Users think they react instantly, but in practice they usually take around 0.1 seconds to move the stick in a certain direction. I tried this a lot and even when I tried to move the stick extremely fast, I am still only very rarely able to move the stick all the way to the right in a single frame. During normal use, this never seems to happen.

The evil bounce, however, always happens practically within a single frame. It is much faster than any real user input. So Machiel came up with a solution that uses this. I implemented his solution and it which works great:

When the change in the stick's position is bigger than 1.05, ignore it for one frame. *

This eliminates all the bounces that I have seen. And in my measurements, it practically never ignores or delays actual real player input. When the player moves from neutral to all the way to the right, that is a movement from 0 to 1. That is smaller than 1.05, and thus always used immediately. When the user moves all the way from the left to the right, so from -1 to 1, then he takes several frames for this. So the movement per frame is still less than 1.05, and is thus not ignored.

So, I implemented this, and we have not been able to reproduce the Bouncy Stick Problem in Awesomenauts ever since. Win! :)

* Edit: As Ben suggested in the comments below this post, it is probably best to use stick position 0 when the output is large, since using the previous frame adds some delay to stopping walking.

What no one told you about the videocard: lagging 1 frame behind

Our new game Awesomenauts is a lot more complex than Swords & Soldiers in every possible way, so we suddenly need to actually have a serious look at performance to get a good framerate on all platforms. Now while trying to optimise things, I found out that I had totally misunderstood an important part of how the videocard works.

I have read several books on programming real-time graphics (including the entire OpenGL Red Book), yet somehow I have never read about this. So when I found out, I spoke to a couple of other experienced graphics programmers, and it turned out most didn't know this either. So I guess quite a few of my readers will find this interesting. For those who already knew about this: why didn't anyone tell me?!?! ;)

So what am I talking about? I always thought that the timing of a frame works like this:



So as soon as you start sending render calls to the videocard, the videocard starts processing them. However, the videocard usually cannot process these calls as fast as it receives them, so when all the calls for a frame have been received, the CPU waits for the videocard to finish, and then proceeds with the next frame.

This scheme is quite nasty, since it contains two periods of waiting: both the GPU and the CPU wait for each other at some point, simply doing nothing in the meanwhile. This wastes performance.

So I have build some timers in Awesomenauts and I saw that indeed the CPU was spending a lot of time waiting for the GPU in calls to things like SDL_GL_SwapBuffers. I tested this in all versions of our engine, so on the Playstation 3, the Xbox 360 and the PC, and this happened on each platform.

So I implemented a multi-threading scheme to do the waiting in a separate thread, so that the next game frame can already be processed while we are still waiting for the GPU to finish the previous frame (this is actually a lot more complex than it sounds, but I will leave out the details for now).

And what happened? NOTHING! PC, PS3, Xbox360: none showed any framerate improvement! Argh! So I asked around to find out what I was doing wrong, and it turned out that the above scheme is entirely wrong. It is simply not how it works. This is how the scheme really works:



So when you call D3DPresent or SDL_GL_SwapBuffers, the time spent there is not spent waiting for the current frame, but waiting for the previous frame. This is actually a really simple and smart solution to the waiting problem I mentioned above. As long as the GPU has more work to do than the CPU, it will never have to wait!

This explains why my optimisation didn't help: as this image shows, the GPU is constantly busy, so improving the framerate of the CPU using multi-threading is totally useless here.

An important thing to mention here is that I am not talking about triple buffering here. Triple buffering is a different subject and this scheme happens regardless of whether triple buffering is turned on or not (although for a good understanding of triple buffering, you would need to take this scheme into account as well).

Note that a side-effect of this scheme is that it introduces some extra input lag: user input (pressing a button to jump, for example) happens in the game state update, and the time between the game state update and the moment when it's results are shown on the screen increases because of this scheme. However, the framerate also increases a lot, so this is definitely a worthwhile trade-off.

Of course, if your game takes more time on the CPU than on the GPU, the GPU will still have to wait:



Now my next question was: does it always work like this on all platforms? It turns out this varies. I asked around, and this is what I learned:



While asking around, I also learned that in some cases on PC, the driver might decide not to wait at all. Someone on the Ogre forums posted here that he had really long input long in his application. It turned out this was because the GPU was a lot more than 1 frame behind, because his CPU had so little work to do. So in his case, the scheme worked like this:



However, I have never seen this happen myself, so I am not sure when this problem would occur. I have heard from a user that Proun sometimes has serious input lag when being run in Wine under Linux. I have not been able to test this myself, but I suspect this is the same problem.

However, this problem is limited by the size of the GPU command buffer: when the GPU is lagging too far behind, the entire buffer will be full of commands, so the CPU will not be able to push in any new ones, forcing the CPU to wait.

This can be solved using fences (an advanced feature of OpenGL and DirectX). Fences allow you to wait until the GPU has reached a certain point. You have to implement this yourself, but it makes absolutely certain that the GPU is never lagging more than 1 frame behind.

To conclude: keep this scheme in mind whenever you try to optimise your game, and be sure to first make sure whether the game is GPU or CPU bound. My fault while optimising Awesomenauts was that I was trying to optimise the CPU, while the bad framerate was being caused by the GPU. Always check your bottlenecks!

PS. My previous blogpost about the sales numbers of Proun resulted in some really painful comments online. I had tried to write a really positive blogpost about how happy I was with Proun's results, but Gamasutra and several other large game sites summarised it simply as "Proun Creator Disappointed With 'Pay What You Want' Results". Some sites and commenters also did some nasty misquotations on how I interpreted the sales data. Lots of people concluded that I am a whiner, and some even did some serious flaming about Proun and me. This is really painful for a game I made for the fun of making it, especially since I am really happy with how Proun did and tried to write a very positive blog post. Interesting how being misquoted can make people online hate me... Anyway, I cannot reach all those people and explain to them how happy I am with the reviews and income I got for Proun, so I guess I can only answer by trying to make more cool games! ^_^

Matisse, Malevich, Warhol, Lichtenstein, Mondriaan, van Dongen

Please ignore that horribly pretentious title, I just couldn't withstand this chance to put my name in that list... ;)

Last week the Stedelijk Museum in Amsterdam had an art game evening, so they put some games in their galleries. The Stedelijk Museum is the biggest modern art museum in The Netherlands and they decided to put Proun in the middle of their throne room, the one with their most important pieces. So there was my Proun, between Matisse, Malevich, Warhol, Lichtenstein and Mondriaan! Awesome! Especially Mondriaan's paintings were an important inspiration for Proun, so it is great to see my game next to six real Mondriaans!



The photo was taken by Richard Boeser, by the way. He is the creator of Ibb & Obb. Ibb & Obb was also there and it is a fantastic game. It hasn't been released yet, but I got a chance to play it and this is one of the most fun coop games I have ever played. Nice! So here is a little bit of marketing for his awesome game, which I believe should come somewhere early 2012. Be sure to turn the sound on to hear the music as well!


Ibb & Obb, by Sparpweed and Codeglue.

Proun sales data revealed: Proun is a big success! Pay What You Want is not!

When I launched Proun three months ago, I promised to release the numbers on how the Pay What You Want model would do. Not that many games are released as Pay What You Want, so a lot of people were curious to see how Proun would do!

This post is a big wall of text. Just skim through the tables and graphs if you feel too lazy to read my explanations and analysis... ;)

It is extremely rare for game developers to release their complete revenue statistics like this. Not many people outside the industry realize that this secrecy that is usually around sales is actually quite problematic. How can you know what the best platform for your game is, if everyone keeps their sales statistics a secret? For small indie companies, knowing where to release your game and for what price is incredibly valuable information! Contracts forbid telling what you sell on XBLA, PSN or Steam, but since Proun is only sold on my own website, I can actually give you this information for Proun!

Before I start with the statistics, though, let me start with something a reviewer wrote. I made Proun purely because I wanted to make something awesome, for the fun of creating games. Obviously, part of that fun is showing the game to people and hearing their reactions. This quote from the Eurogamer review (which scored Proun a 9) is so incredible, knowing that this is what someone thought after playing Proun is enough to make this whole project a tremendous success to me:

"Your role in the proceedings is as a visual conductor, commanding your own hypnosis, sucked into a maelstrom of motion quite unlike anything you've ever experienced."

…

Wow.

Incredible that they are really talking about my little game there!

So, let's get to the numbers:

Units sold per price point

Proun was sold as Pay What You Want, so people could set their own price. So what prices did paying folks choose?



The official minimum price to get the bonus track was $2, so the largest group of people chose the minimum. The other peaks are at $5 and $10, the obvious round numbers. But why is $6 also a peak? I checked the complete statistics, and it turns out that these people mostly also chose $5, but the shop system I used added taxes after typing the price, which is why a lot of $5 people ended up paying $6.

Since $10 or $2 is such a big difference in price, the peaks are actually quite different when we look at the total revenue per price point. Now $10 has the biggest peak, and even $20 pops up, despite only a small number of units there:



Finally, the big question: how many people chose not to pay anything? Unlike many other Pay What You Want games, I chose to actually make 'free' an official option on the home page and even offered a Torrent. As you can see here, way more people chose to get Proun for free than to pay:



The $0 price point here is people who used the same store as the paying folks but filled in $0. They didn't have to fill in there Credit Card details as a result. I cannot know the exact number of Torrent downloads, but since every install of the game contacted my server, I do know the total number of installs, so I can estimate how many people got the game from something other than my server.

As you can also see here, 5 people paid $30 or more. That is incredibly generous for this very small game and I thank them for that! The same of course goes for all the other people who paid me something for Proun: thank you very much! The game was also available for free, so this is pure generosity and niceness! Thank you! ^_^

Overview

So, let's add these numbers, shall we? Here is a single list of all the general numbers of Proun:



There are quite a few remarkable numbers here. The obvious one is my actual income from the game: €14,105. I count this in euros, because I live in the Netherlands, so that is the kind of money that I can actually spend.

I have not counted how many hours I actually worked on the game, but I estimate if I would have worked on it full-time, it would have taken me 9 months to make Proun. That makes an income of €1567 per month, which is definitely not high, but enough to live from. So if Proun were not made as a hobby project on the side, it would not have killed me. It would not have given me a good buffer for a future project either, though.

However, for a hobby project, this is an enormous amount of money. I already make a living through the games we make at Ronimo Games (like Swords & Soldiers and Awesomenauts), so any money I make through Proun is an extra. Getting €14,105 is one whopping big extra!

From revenue to actual income we go down from $23,043 to $19,947. Where did that money go? There are three groups here: transaction costs (paying with a Credit Card costs a fixed amount of money, for example), taxes (VAT) and the Fastspring fee. Fastspring is the company that manages the actual shop, transactions and downloads for Proun, so obviously they get some money for that as well. All together these make 13% of the revenue. This may sound like a lot, but this is actually very nice. I am not allowed to give any numbers, but let's just say that this is a very good score compared to most other downloadable platforms.

Proun featured a bonus track for those who paid for the game. However, there are quite a few more people who played that track than who paid, so that means that even this Pay What You Want game faced piracy. Not that much, though: 40.78%. This is really low in comparison to the 90% and higher that is supposedly common amongst PC games.

Those who paid, were willing to pay a nice amount though: on average they paid $5.23. That is a price I can totally agree with. Just don't mention that if free players are included, the average price plummets to $0.09...

Sales over time

Next up: is there a so-called long tale for Proun? At a first glance, it would seem like Proun sold all it could in the first few days and stopped after that:



The big drop on day three is because my server went down when so many people were playing Proun. Important lesson learned: always make sure you get a scalable server before launching a game! My new host for the website and highscores (Byte.nl) just scales to a more expensive plan if there is too much traffic. That is way better than the previous host (the really cheap and really lame Hosting2Go), which just closed down the site entirely when it got too much traffic...

Anyway, back to the long tail. The image above seems the move to $0 quickly, but this is actually not true. This graph shows the daily revenue after the initial peak:



As you can see, Proun actually keeps making a little bit of money every day. It seems to have dropped to an average of around $10 per day at the moment, which still makes for $300 per month. That is some nice money for an individual! Also, this blogpost you are reading now will probably generate some renewed interest in Proun, so writing this might generate some extra revenue as well. That alone would be a good reason to write this blogpost... ;)

Sound

There is one more money topic that needs discussing, and this money topic is called Arno Landsbergen. Arno made the sound effects for Proun. He also arranged, produced and generally improved the songs I wrote for Proun. Arno wants me to link to his Facebook when I mention him, but I think his solo album is awesome and since it is available online for free, more people should listen to it. So I am going to like to that instead: Dirty Rock (great free MP3 album!).

Arno is the only person besides myself who worked on the game, and obviously he got a slice of the pie as well. When Arno joined me to work on Proun, I had already been working on the game for five years and was not planning to do anything commercial with it. So Arno got on board just for the fun of it. However, we did sign a little contract that said that if Proun was ever going to generate any money, Arno was going to get 7% of it. So of the €14,105 that I made, €987 went to Arno. A nice bonus for something he did without expecting any money from it! :)

Also, Arno did a great job. He surprised me several times by going in a different direction than I expected, like adding lots of keys (pianos, organs, etc.) to the soundtrack. And each time the direction he chose was way better than what I had in mind, so to me this was one very fruitful collaboration!

Now what was this 7% we agreed to based on? As far as I know, in media 8% of the budget is usually spent on sound and music. I have no idea whether this is true, but this is a number I have heard from various sources. Since the songs had already been written by me, but still needed a lot of work, we settled on slightly less: 7%.

Why do I claim Pay What You Want was not a success?

The title of this blogpost sais that Pay What You Want did not do well for Proun. But didn't I make a lot of money with Proun? More than ten thousand euros, isn't that a lot of money? Yes and no. To me personally, Proun did incredibly well. That is a lot of money to make with a side-project, and since I get to keep most of it myself... wow! That's a lot! Thank you, everyone who paid for Proun!

However, over 250,000 people played Proun. Reviewers loved Proun and the game got lots and lots of media attention. Major PC gaming blog Rock Paper Shotgun (gotta love that name) even wrote an extra post saying that even though they already covered Proun before, they just wanted to remind everyone once more that they should really be playing it: Public Service Announcement: Play Proun.

Through Ronimo and through my connections to indie developers all over the world, I know what kind of money a game that achieves that kind of success can make. If I would not have done the Pay What You Want model and would have done a fixed price on Steam instead, I think I may have made 5 to 10 times as much money. That is while even taking into consideration that without the Pay What You Want model, the game would have generated a lot less buzz and much fewer people would have played it. Of course, this is a "What if" scenario, so I can never know for sure. Yet I dare claim that for the amount of success Proun had, it made a very meagre amount of money.

So there you have it: to me personally, Proun is a tremendous success and made an enormous amount of money! But compared to what a game with this kind of success can make, it did pretty badly.

Lessons learned

So, tons of numbers, and what did I learn?

For starters, Pay What You Want is a tremendous marketing tool. The number of sites that wrote about it is incredible, and both gamers and press love it.

The second lesson I learned is that there are a couple of really good services available for managing payments and downloads. Plimus, BMT Micro and Fastspring all offer excelent services in these regards, and their fees are low enough percentages that it is worth it to use them. I used Fastspring and they did a great job. Even when the Proun website went down due to too much traffic, the Fastspring shop and download system always keps functioning. So no one who paid for the game had to wait for the crashed site to get back up to be able to download it!

And then to the big question: why did only 1.76% of the players pay for Proun? This is definitely not because of the quality, since both press and gamers were almost unanimously positive. The amount of content may have been a factor, though: Proun is a very small game, with only five tracks. IGN said it like this in its review:

"Despite being incredibly thin on content, this one-man indie side project is heart-pounding, euphoric, and very addictive."

Incredibly thin on content. That's true. There is no lesson to be learned for me here, though: Proun is a hobby project and making a lot more content on my own would have cost too much time and would have become a boring crunch. I made Proun for the fun of it. If I had known then what I know now, I would still not have made it any larger.

To seduce people to pay for Proun, I added a bonus track. I think the bonus track was a good idea, but I would have done this differently if I had known these numbers at launch.

I think the main reason why so few people chose to pay for Proun is this: the free version did not require a Credit Card transaction and was thus way easier to download.

People are lazy. Systems that remember your payment details and thus don't require you to fill in anything each time you buy something are tremendously successful. Think Amazon, think Steam.

So I think if I had set a minimum price of $1, way more people would have decided to pay a couple of dollars for Proun. Simply because they already had their Credit Card out for the $1 and figured the game was actually worth a bit more. Fewer people would have played Proun, but I think more people would have paid, making Proun a bigger succes financially. Note the emphasis on financially: my main goal was to get as many people as possible to play my game, and the scheme I used was definitely a good choice for that!

So from today on, I am starting a new experiment:



Proun is still Pay What You Want, though, just starting from $1 now. I realise that most of the buzz around Proun has disappeared now, but Proun is still making some money every day, so let's see whether this increases or decreases the revenue! Just like today, I will post the results of this experiment in a couple of months.

Other Pay What You Want games

This post is already way too long, so I am not going to do long comparison with other Pay What You Want games. Instead, I am just going to link to other articles that mention sales numbers of these kinds of models. I only found three similar games, and none of these are a 'regular' game being Pay What You Want at launch. They were either bundles, or short Pay What You Want sales months after launch, so none of these are really similar cases, in my opinion.

• The Humble Indie Bundle: total revenue, charity pie chart, and piracy
• World of Goo: birthday sale results
• Sleep Is Death: Pay What You Want sale

Conclusion

So, has Proun been a success? Yes it has! Proun was made as a hobby project, for the fun of making something unique and showing it to the world. It also made me quite a bit of money, but that is not what Proun is about. Proun is about my personal vision of just one way in which games can be more than what they already are. I am glad that the unique and innovative graphical style of Proun really worked for a lot of people. Many games these days look and feel the same, but Proun is part of class of games that does something different. (In this case graphics, but of course gameplay, narrative and sound are equally interesting.)

However, purely financially, I think Proun could have made way more money if it had been sold in a different way. Yet to me personally, it did make a lot of money!

Let me conclude this longest blogpost I have ever written with a quote from Ars Technica's review of Proun. This and other reactions to my game make me feel all warm inside.

"What's striking about Proun is how it makes you feel. The game is epic without being loud, it's sleek without being cold, and it's joyful without being cute. It's a happy game that's not afraid to bloody your nose if you're not paying attention. The tracks feel both expertly designed and effortless."

Thank you.


PS: another, later blogpost with sales data from after this post can be found here:
Proun's sales statistics after removing the free version

One million races played! Proun's gameplay statistics

When I launched Proun, I promised I would release all the game's statistics. Today, I present the first half of the data: the gameplay statistics. How much did people play each track and game mode? Next week I will release the money numbers, which I expect people will be a lot more curious to read about, so consider today's post as an appetizer to next week's revenue analysis!

In the meanwhile, the gameplay data are also pretty interesting. Since Proun has online highscores, I was able to collect quite a lot of statistics on which tracks were played how often and such. So, let's have a look!

Game modes

One million track times were submitted! I actually waited a couple of days with posting this to be just above that number instead of just beneath it, because yes, there is some magic in such a high number! ^_^



For starters: these numbers are lower than what people have really been playing: my highscore server was down for a couple of days directly after launch, so I probably missed around one hundred thousand highscores near launch.

The Championship Mode is where people could unlock things and have a proper game flow. I designed the difficulties to present a gradually increasing challenge with enough rewards (winning a race, unlocking a higher speed or new track) to keep people playing for a bit. So as expected, this is the mode that was played the most.

To my surprise, hardly anyone played the four player mode. Makes sense that few people play it, but only 0.085% of all the races? That is even less than I expected!

Two player splitscreen fared a lot better, though: 10% of the races were played there, which is a very nice score. The splitscreen is a lot of fun, so I am glad people tried it. Anything above two players required an extra controller, because keyboards cannot register a lot of button presses at once, so the low numbers for three and four player splitscreen do make sense.

I think the best game experience in Proun is the Time Trial. Trying to beat yourself, as your mind gets into "the zone" and your reflexes take over, is to me the most fun you can have with Proun. However, only 11% of the races were played in Time Trial, so I guess most players disagree with me.

Difficulties and tracks



Keep in mind that these numbers are not the number of people who played a track, but the number of highscores submitted. Most players played several races, or even dozens, and these are the total number of times each track was played on each difficulty.

Racing at the higher difficulty settings required winning the championship on the lower difficulties. The difficulties are called Fast, Sonic, Super Sonic and Speed Of Light.

7% of all the times submitted are on the highest difficulty. That may seem low, but I think that is incredibly impressive: unlocking that is really difficult, so apparently quite a few people were hardcore enough to get there!

Strangely, though, this number is higher than the number of highscores submitted for Improvisation #1: Dynamism. This is the bonus track that you unlock together with the highest difficulty. I thought beforehand that a new track is way more interesting than a new difficulty. Apparently I was wrong. I guess this is because this bonus track is not included in the Championship game mode: you have to play Time Trial or Single Race to play it. Since Championship is by far the most played game mode, it does make sense that more times were submitted for the highest difficulty than for the bonus track.

Interesting here is that Composition #1 was played a lot more often than Composition #2. I wonder why that is? I think this is a combination of two causes:
-In Championship mode, if you loose the first race, it is a good idea to start again right away and try the first track again.
-Quite a few people will have played the first track and then concluded that Proun was not for them, thus not playing the other tracks.

User tracks

I included tools with Proun for people to make their own tracks. Doing so requires 3D Studio MAX, though, so not everyone can. I had no idea beforehand what to expect of this. So far seven people have made custom tracks, which is really nice! I consider it a great honour that modders have done this and there are some true gems there! You can see and download the complete list of tracks created for Proun here: Proun User Tracks.

So, how often were these tracks played?



As you can see, Archipelago and Extrude were played the most by far. The main reason for this is that these are the only tracks that were available within a week after the launch of the game. That is when most people were playing. The other tracks came a lot later and thus got less attention. I keep advertising them through my Facebook, Twitter and blog though, so hundreds of people still play each track.

What I find really cool is that new tracks are still begin made. For example, only last week Smurfland Sky was released! That track is so new that it is not in these statistics yet.


Smurfland Sky by dll32

So, that's it for the gameplay statistics! One million highscores submitted, that's a whole lot! I endthis blog post with a cliffhanger: how did the Pay What You Want scheme do for Proun? See you next week!

Proun patch v108 released!

It took way too long, but in the middle of the crunch time for Awesomenauts, I finally found the time to fix a couple of bugs in Proun! This patch only fixes bugs and does not add new features, so no need to apply it you weren't encountering any bugs before. You can find the patch and info on how to use it here:

Proun patch v108

These fixes are mainly for some specific videocards by Intel and Ati. Note however that I do not have these videocards myself, so I have not been able to test this patch well enough. So I hope some people who had trouble running Proun before can give it a try and let me know whether this fixes anything!

Quite a while ago, I wrote a blogpost about The horror that is PC development. Some of the specific issues I fixed in this patch are definitely in that same category, so I find it interesting to discuss what went wrong:

Bug 1: Crash on some ATI Radeon cards

It turns out that ATI cards from around the time of the Radeon X1xxx series are officially liars. These are some pretty old cards, from around 2005. When the engine (Ogre 3D) asks such a card whether it supports shader model 3.0 shaders, it happily says it does. Then when I feed it some really complex pixel shaders, it refuses and gives an error. Turns out these cards support most of 3.0, but not everything! So my depth of field blur crashed on this.

Here is the really frustrating part: I already had a simpler version of these shaders in the game, but because the videocard lies about its capabilities, Ogre tries to load the advanced shader. Crash! Knowing this, the solution was actually pretty simple: I have added rules to the materials that tell the engine that these specific cards need to use the simpler version, regardless of what they claim they can do.

Bug 2: Crash on some Intel cards

A somewhat similar crash happened on certain Intel cards. Intel cards from the GMA 3xxx series (released around 2006) can only do vertex shaders through software emulation. This is not a problem in itself: it just means you get a very low framerate, but everything would still work. However, DirectX handles this in a strange way: when you ask IDirect3D9 whether vertex shaders are supported, it says no. So the Ogre engine thinks these cards won't be able to run Proun at all. The IDirect3DDevice9 on the other hand will say yes. Quite weird, really, but someone discovered this and fixed the Ogre engine to ask both IDirect3D9 and IDirect3DDevice9 and use the best answer.

However, this fix was released around the same time when Proun was released. Since updating your engine version so near release is a bad idea (since it has not been tested well enough), that fix did not end up in Proun. So all I had to do now was add that fix to repair this crash.

Bug 3: Broken math

The final bug is exclusively my own mistake and not about weird PC graphics stuff. It turned out I had a math error somewhere that very rarely crashes the game. I already discovered this crash one week after launch, but because it happened so rarely, I was not able to find the cause. I have some data from the highscore server and I estimate this crash happened once every 10.000 runs through Composition #2. That is pretty rare. But help came from an unexpected direction: the recent user track Cubed has a point where it almost always triggers this situation! So now I was finally able to find out what happened, and fixed it. Turned out this was a mistake in the vehicle math that I made six years ago at the very start of the project!

(For those interested in the math: to get a vector perpendicular to the cable, I do a cross product somewhere with the vector [0,1,0]. When the direction of the cable itself is also exactly [0,1,0], this goes wrong.)

So, what have I learned here? That I should test on even more videocards before launching anything on PC!

EDIT: To my eternal shame, it turned out that the fix for those Ati cards was still not working. Ogre happens to handle some material properties in a different manner than I thought. I fixed it in a more rigorous way now, and it works now!

EDIT 2: An even older Ati series, the Ati X8xx and X9xx turned out to have some other issues. I fixed those as well in patch v108.

Overview of Proun user tracks

Quite a few users have made tracks for Proun already, so I figured this would be a nice moment to show an overview of them! Despite the forum not being very busy anymore, people are still making tracks for Proun, as was shown yesterday when Bigguy11757 posted his new track!

I find it a great honour and really cool that people make new tracks for Proun, so seeing these images together makes me one very happy goldfish indeed!

Shape Factory by Bigguy11757:


Cable Rats by Seikusa:


Cubed by Yooby:


Archipelago by JohnArr:


Solar Coaster by tpapp157:


Extrude by Chris Farrell:


By the way, a couple of people have been asking me when I would release the download and sales statistics of Proun: I will do so somewhere in the next two weeks, depending on when I will have time to do a proper analysis and write a blogpost about it!

Awesomenauts intro cinematic released

We have released the intro cinematic for Awesomenauts! Be sure to watch it with the volume turned up high!



And now watch it again, but this time sing along to the theme song!

We also had lots of people playing at Gamescom, and they really liked the game. The first time the general public plays our games is always incredibly exciting, and I am really glad it turns out they enjoy Awesomenauts!

Solid Motion

A while ago I posted the image below as a little teaser. Quite a few people told me they liked it and asked me what it was. Today, answers are given!


"Solid Motion O" - view high resolution or download ultra high resolution

What you see here, is the Solid Motion of a teapot falling down and bouncing off the ground. Solid Motion is a word I made up for these kinds of shapes. So what does it mean? The idea is that when an object moves from point A to point B, there is an amount of space in between that it moves through. All this space together is what I call a Solid Motion. It is a solid object that covers that entire space.



So to generate a Solid Motion, I need an animated model. This is the animation that created the teapot image at the start of this post:



When you compare the two, you can see all the motions in the Solid Motion. Especially the ending position of the teapot at the bottom of the image is pretty easy to distinguish.

What I find absolutely fascinating in this technique, is that the shapes it creates are at a strange middle ground between abstract and figurative. The image above shows a falling teapot, which is totally figurative. Just a teapot falling down. However, once the Solid Motion has been generated, the teapot is hardly visible any more and the new shape is this weird, abstract thing with lots of interesting curves and spikes in its surface. So the figurative teapot became an abstract Solid Motion!

Another beautiful example is this temple being destroyed by a ball crashing into it. I especially love the curves of the pillars falling down.


"Solid Motion M" - view high resolution



I cam up with the idea for Solid Motion after reading a book about Futurism. Futurism is an Italian art movement from the early 20th century. Futurists were fascinated by movement, especially in the new technology of the machines, planes and fast cars of the time. They did lots of artistic experiments, including theatre with strange angular costumes and even cooking, which apparently resulted in absolutely horrible meals...

The futurists were a strange bunch: they loved modern technology so much, that they were very eager to go into the Great War and play with all this speed and technology. Several of them died during World War I, including Boccioni, their most talented artist (just check this painting and this famous sculpture for an idea of his awesome work).

Futurism resulted in lots of interesting artworks, and their history has so many strange aspects that I could talk about them all day, but lets ignore the story of them trying to become friends with the Italian fascists (Mussolini!), and lets not turn this blog into an art history thing (although I have to admit I would enjoy that quite a lot...). The point here is that one of the things the Futurists tried to do, was to capture movement and speed in a single painting or sculpture. This made me think about modern methods to do that, which resulted in my Solid Motion script.

Enough talk, though! Here are some more Solid Motions, plus the animations that were used to generate them. I had a lot of fun playing around with some really weird materials for these, and I personally think that resulted in some pretty strong and unique images. ^_^ Be sure to check out the high resolution images as well, since they look a lot better when viewed full screen!


"Solid Motion I" - view high resolution or download ultra high resolution




"Solid Motion E" - view high resolution




"Solid Motion J" - view high resolution or download ultra high resolution




"Solid Motion Q" - view high resolution



I made a bunch more, but the others didn't turn out as well as these. You can see the rest here.

So, how did I actually create these Solid Motions? Since this is a new concept (as far as I know), I had to write my own script for 3D Studio MAX to generate them. Technically, it is quite simple. It starts by copying the animating object at every frame of the animation. This gives a good basic shape. To also create a smooth outside surface, I continue to create a polygon from every edge of the model to the same edge in the next frame. And that's basically it!



This does create an insane amount of polygons, though. For example, "Solid Motion J" (the black and white image above) has over four million polygons! Generating that using the always slow MAXScript programming language took a looooooong time! However, since this is only intended to create images, I don't really care about efficiency here anyway.

The first version of this script is already from 2006, and I have to admit that these images were mainly made in 2009, so quite a while ago. I will post some new ones in the near future, but in the meanwhile you can also give it a try yourself! You can download the MAXScript here:

SolidMotion.ms

To use it, animate some objects in 3D Studio MAX, select them, then click MAXScript at the top of the screen, select Run Script and select the script. Be sure to bring some patience, though, since generating them may take a while! The script generates Solid Motions for all selected objects for the entire timeline. Be sure to start out with just a couple of cubes and a hundred frames, though, before trying more complex things. Long animations of objects with lots of polygons are quite likely to crash 3D Studio MAX, so start out simple!

If you make some Solid Motions of your own, then please comment below to show your results! I would love to see what kind of animations and shapes you come up with! ^_^