The evolution of Sheriff Lonestar

Quite a few players asked to see more concept art of Awesomenauts, so who am I to not oblige to this request? This is actually a great excuse to talk a bit about the design process of Awesomenauts in general, by looking at how Sheriff Lonestar evolved during the three years it took us to create Awesomenauts.



Before I get started, I should mention that today's post is mostly about the great work of my colleagues. I myself am lead programmer at Ronimo, so although I am involved in the design and art process, the real work is done by our designers (Fabian and Jasper) and our artists (in the early stages of the project as described here, those were only Ralph, Martijn, Olivier and Gijs). So all credit for the great work done on finding the right style for the gameplay and graphics should go to them! :)

In our first designs of Awesomenauts, there were going to be only three classes, but each of these three classes was going to have an extremely diverse set of skills. The final version of Awesomenauts still allows for great build diversity within each class, but in comparison to our first plans, it is quite limited. The initial idea was that each of the three classes had a lot of different skills, and the choice of which you bought determined how the class actually fought in battle. Later we let go of part of this idea: we increased the number of classes and made each class more focussed, since having only three classes felt like too small a number, while the complexity of allowing such insane build diversity within each class turned out unworkable for design and balance.

One of those initial classes was the Giant, which would later turn into Sheriff Lonestar. He was called the Giant because his most important skill was that he was able to grow really big. While big, he did a lot more damage and had a lot more health. I don't have a screenshot of the actual Giant playing, but below is what the game looked like at this point, really early during the prototyping phase.



This screenshot dates back all the way to November 2009. Note that all the core elements of Awesomenauts were there already: classes, creeps, droids, turrets, lanes, a shop, upgrades, online multiplayer. The 'core' gameplay of a MOBA game is really big and we first focussed on getting that completely up and running.

I can't remember why we let go of the Grow skill, but at some point it turned into a skill that let you summon a big mech that would fight for you. The player could also mount the mech to steer it himself. The Giant was already evolving into the Sheriff at this point, as you can see in this drawing of the player controlling the spawned mech, which is starting to look a bit like a bull.



For some reason, however, this rideable mech never actually made it into gameplay. Probably because this would have been a relatively complex skill to code, and we needed to keep things simple enough to actually finish the game at some point. Just creating the mech and letting him run forward was way simpler, and made his use in the battlefield clearer: a storming ram that pushes away enemies and catches bullets. In the end, there was nothing "Giant" to him anymore, but he kept that name internally for a very long time, until his working title was changed to "Cowboy".



Now that we knew this character was going to be a cowboy, our art team could finally decide on his looks. They went through several iterations before they reached something they were happy with, as you can see here:



In the current Steam version of Awesomenauts, we also have DLC skins, turning Lonestar into something quite different. Knowing how long and slow the process of finding each character's initial design was, it almost surprises me how quickly our artists come up with alternative designs that are often quite different, but just as awesome as the original. This speed makes sense, of course: creating a variation on an existing design is much easier than creating a new design from scratch.



If you like to see more Awesomenauts concept art, you should definitely check out a couple of my earlier blogposts. In those I talked about what styles our artists came up with for Awesomenauts, what Awesomenauts almost looked like, and about the pre-visualisations our art team made of the final style.

Changing a hero who can grow into a giant, to a cowboy who summons holographic bulls, is quite a profound change. However, even bigger changes have been made during development of Awesomenauts. Next week I will explain the biggest change and most difficult design decision we made during development. See you then!

Hardcore C++: why "this" sometimes doesn't equal "this"

I usually try to write these blogposts in a way that is readable for most game developers and enthusiasts, but today for a change I'd like to dive deep into a detail of C++: why sometimes the this pointer can differ even though it is being used within the same object.

This is a problem that one can spend a lot of time debugging on before finding out what happens. I encountered it last week, and the only reason it didn't cost me several days of debugging to figure it out, is because I ran into the exact same problem during a project at University years ago.

Let me first sketch an example of a situation in which this might occur. In some cases a unique identifier for an object is needed, but we don't actually need to do anything with that object, so it doesn't matter what type it is. In such cases, an obvious and easy solution is to simply use the address of the object itself and store it as a void*. This way we can, for example, register whether a call to a function is from an object that already called that function before.

Now the question is: does that always work?

Since I am writing this blogpost, the answer of course is "no". Here's why:

Let's start by looking at this simple case of inheritance:

void printPointer(void* pointer) { std::cout ‹‹ pointer ‹‹ '\n'; } class A { public: void printA() { printPointer(this); } int banana; }; class C: public A { public: void printC() { printPointer(this); } int kiwi; }; void main() { C object; object.printA(); object.printC(); }

This code prints the this-pointer twice, but from two different classes. Since this is from within the same object, basic intuition tells me it will print the same address twice. Here's what it prints:

0018FD8C
0018FD8C

Indeed, the same address twice! But what happens if we add multiple inheritance? Let's complicate the example by adding one more class and inheriting from both at the same time:

void printPointer(void* pointer) { std::cout ‹‹ pointer ‹‹ '\n'; } class A { public: void printA() { printPointer(this); } int banana; }; class B { public: void printB() { printPointer(this); } int ananas; }; class C: public A, public B { public: void printC() { printPointer(this); } int kiwi; }; void main() { C object; object.printA(); object.printB(); object.printC(); }

This looks like we are doing pretty much the same thing as above, so the question is again: do all these calls print the same pointer? Let's have a look at what this prints:

0018FD8C
0018FD90
0018FD8C

As you can see, surprisingly, and totally against my own intuition, they do not print the same address! The call to printB() prints a different, slightly higher address!

Now why is that? Surely there is something broken in C++? Or at least, that is what I thought when I first encountered this situation. There is, however, a totally reasonable explanation for this behaviour.

In memory, when using inheritance, the hierarchy of objects is simply put after each other. So these three objects look something like this:



Now if we we have an object of type C and then on it a function from B, the this pointer needs to point at where B actually starts in memory. It cannot point to where our C started, because the functions of B cannot have any knowledge of that they are inside a bigger object. So this is where all the pointers go:



The difference between 0018FD8C and 0018FD90 is exactly four bytes, which makes sense, since A only contains one integer number, which uses four bytes of memory.

So there you have it: this does not always equal this, even when used from inside the same object!

This curiosity in C++ is another good reason to think again on whether code structures that use void* are a good idea. Bugs caused by something like this are easy to overlook and terribly difficult to find. In fact, I know several good C++ programmers who were not even aware of this phenomenon. When I first encountered this at university years ago, it took me a lot of debugging and asking friends for help before I learned this was happening.

And this is not the only problem with void*: using it almost always means unsafe casting is somewhere near. Void* has its uses once in a while, but it is often avoidable. So whenever you are using a void* in your code, stop for a short moment to think about whether there is another solution that avoids it!

The character animation workflow for Awesomenauts

One topic that I have been asked repeatedly to write about, is how we made the animations for Awesomenauts. This is indeed a big and interesting topic, so today, I would like to discuss that in more detail!

I have previously shown how we make characters aim in all directions and shoot in all directions, but that did not explain the workflow and tools that our artists use to actually make those animations and put them in the game. Today's post will!

The core animation work for Awesomenauts is done in After Effects. This may come as a surprise to people who don't know the tool, since After Effects is mostly known as a video editing tool, but it is actually a great general animation tool.

It is also a big step up in comparison to Swords & Soldiers, which was animated in Flash. The biggest problem with Flash was that it only works well with vector-art. Our artists generally don't like working with vectors and would rather paint in Photoshop instead. This was especially a hot topic in our studio just after the release of Swords & Soldiers, because some commenters on the internet thought the stylised vector-art meant it was a small Flash-game that needed to be free. Flash is a great platform of course, but mostly known for small, simple games. Swords & Soldiers had way more content and polish than most Flash-games, so we felt insulted and wanted to make sure our next game had visuals that didn't remind anyone of Flash. This was an extra reason that we didn't want to use vector-art for Awesomenauts.

Another reason not to use Flash is that Flash is a rather basic animation tool. More advanced things just don't work as well as they do in After Effects. Looking for an alternative to Flash, we took a little detour around other tools before we found After Effects. We tried some things like Toonboom, but either the interface or the price were not to our liking. Then our former art intern Marlies Barends demoed After Effects to us and to our surprise it was exactly what we were looking for.

After Effects is only one part of our total animation workflow, though. In the end, we combined Photoshop, After Effects and our own tools and exporters to create this pipeline:



Note that although I was the architect of the technical parts of this pipeline, I did not actually write a lot of the code: that was mostly done by our programming interns Niels and Thijs. The art, of course, is all made by our great art team: Ralph, Olivier, Martijn and Gijs, and our more recent additions Koen and Tim. Especially Martijn came up with a lot of smart tricks to speed up the workflow in Photoshop and After Effects.

A particularly important choice here is how to make animations. There are roughly two approaches here. The traditional method is to animate frame-to-frame: the entire character is redrawn every frame. This creates extremely dynamic animation, but also costs an enormous amount of time. So we chose a different solution: the art is drawn in separate elements and these are animated by moving, rotating, scaling and deforming them. These transformations can be interpolated and thus it is possible to create a lot of frames in relatively little time.

After Effects is a great tool for this. Not just is animating basic transformation great there, but it also has tools to do skeletal animation (I believe with plugins, not sure) and, more interestingly, the so-called "Puppet Pins". Puppet Pins make it extremely easy to deform a shape, so that things like bulging muscles are easy and fast to animate. Puppet Pins are a simple concept, but also an extremely nice one, so if you never used them: be sure to give Puppet Pins a try!

Besides After Effects, the scheme mentions a lot of tools, exporters and converters. We made those ourselves and they come with a lot of features. I think they are a pretty impressive bunch, so I'd like to show this trailer of them again, which shows all of our editors in action:



The scheme above is a nice example of how complex game development really is. For an indie game, Awesomenauts is a very big production, but it is still small fries in comparison to the big AAA games like Uncharted and Killzone. Tons of development topics have many details to them, and making the wrong choices can cost so much time, that I can hardly even imagine the complexities of making something like the incredible new Killzone: Shadow Fall for PS4 (Dutch glory, woohoo!). Awesomenauts is small in comparison, but there are still many complex topics like this animation workflow. For example, I previously wrote a similar post about how we make level art for Awesomenauts, and that big scheme didn't even include any info on the foregrounds and backgrounds!

Looking at the animation workflow scheme, you may have noticed that the small image at the top shows concept art for alternative designs for Genji, the new Awesomenauts character that we released recently. Especially the Space Marine Butterfly is so insane that I'd like to show these a bit bigger:


Click for high-res

There are so many interesting details to all the parts of this workflow that I could talk about it forever, but I have to stop somewhere and I hope this blogpost gives a nice overview.

Now, let me get back to the waiting queue for Simcity! I have been looking forward to a new Simcity for years, so looking at a screen that tells me it is going to try to start the game again in 20 minutes is incredibly exiting!

Optimising special effects in Awesomenauts

The latest Awesomenauts patch increased the framerate a lot for players with older videocards, especially during fierce battles. We managed to optimise our special effects without making them look noticeably different. Today I would like to explain how we did that!

Before I dive into the details, let me first give some background. In a 2D game like Awesomenauts, most objects are just a square with a texture on it. The texture contains an image, and you only see that image, not the entire square. However, the videocard renders the entire square. So from a performance perspective, it doesn't matter how much of the texture is actually visible. The entire square is rendered and the every pixel uses performance!



Our artists know this, so they try to crop the image to have as few transparent pixels as possible (without changing the actual looks of the end result, of course).

Since objects in Awesomenauts contain so many (partially) transparent pixels, we cannot easily detect whether an object is hidden entirely behind another object or not. So we always render every object that is on the screen, from back to front, regardless of whether an object is actually visible or not. All objects are rendered on top of each other until the image is complete.



This introduces a big performance issue: massive overdraw. Overdraw is when a single pixel needs to be drawn several times each frame. On 1920x1080, the screen contains over 2 million pixels. If we draw every pixel 10 times, that is already 20 million pixels per frame. Now do that 60 times per second, and we are rendering a whopping 1.2 billion pixels per second. That's a mindbogglingly large number of pixels per frame!

The fun thing, however, is that modern videocards are totally okay with that. However, for slightly older ones, it might become a problem to pull this off fluently...

In a previous blogpost I explained how I abused my depth of field blur as an excuse to render the backgrounds in Awesomenauts on a much lower resolution. This greatly reduces the number of pixels that need to be rendered every frame, but it only helps for the background, since the rest of the scene needs to be sharp.

Since the background are optimised this way already, the biggest remaining overdraw in Awesomenauts happens during special effects, mostly those of nauts' special skills. This is because they have a lot of overlapping particles for smoke, fire, dust and debris. Having several of those special skills on screen at the same time decreased the framerate on older and mobile videocards too much. This is extra problematic because during fierce battles, high framerate is needed most!



Once I figured out that overdraw was the cause of the framedrops we were seeing on older videocards, the solution seemed simple: decrease the number of particles on screen. The difficulty, however, is that it is difficult for artists to optimise things without being able to see what they need to optimise. Having a ton of large particles for thin smoke looks very subtle, but eats performance like crazy. And if an effect needs to be optimised, what part of that effect is the problem exactly?

So I made a small addition to our engine to visualise overdraw. Internally we have a shortcut now to enable this, and when this is pressed, the screen shows how often each pixel is rendered. White means a pixel is rendered 85 times (!), while black means it is rendered 0 times. Technically, this is a very simple thing to make: all objects are simply rendered on a very dark additive blend mode. So each rendered object adds a little bit of brightness.

This is not just informative, but also looks pretty awesome! Have a look at this video of going through the menus and then some gameplay with Skølldir to see how weird and cool this looks:



As you can see, the character itself is not every expensive to render, since it is only one square. The problem comes from the tons of particles.

Using the overdraw visualisation, our artists (in this case mostly Koen, Ralph and Gijs) were able to quickly identify which parts of which special effect needed to be changed. These changes are usually pretty simple: 40 smoke particles that are 10% opaque, look nearly exactly the same as 20 smoke particles that are 20% opaque. So in most cases the trick was to drastically decrease the number of particles and then just modify some colours to compensate for that.

The video above shows what the overdraw looks like after these optimisations were already done, so here are some comparison shots that show how massively the overdraw was decreased while hardly changing the looks of these effects:





We tested the results on our Mac (even fast, expensive Macs usually have mobile videocards, which are not very fast and far from ideal for gaming) and indeed the game runs a lot smoother now. Several users reported that while they could previously only run Awesomenauts smoothly on Normal graphics quality, they can now run on High!

These improvements were released on Steam in patch 1.14 two weeks ago, so I hope players with older videocards are enjoying the smoother framerate they are getting!

The craziest bugs, part 2

Last week I started the top 7 of my favourite bugs with the numbers 7 to 4. The top 3 is where it gets really crazy. Sit back and enjoy to see how amazingly stupid game development can sometimes be!

Click here for numbers 7 to 4

3. Hidden functionality to turn off bugs

On one of the platforms Awesomenauts launched on, we had a lot of trouble getting the internet connection between players to remain stable. After a while the ping would always start slowly increasing, until in the end it got too high and the game disconnected. Sometimes this took a couple of minutes to start, sometimes half an hour, but in the end this always happened.

We contacted the support team for the platform-specific networking library that we were using, and their answer was that we used too much bandwidth and sent too many packages. So we spent a lot of time optimising, and we managed to half the number of packages and half the bandwidth. However, the problem remained, and they again told us we used too much bandwidth. Again we halved the bandwidth and the number of packages, but the problem remained. At this point we were well below what they said was the ideal bandwidth usage and we couldn't optimise much more, so we were getting pretty desperate and contacted them again.

And then it happened...

Their answer was that their bandwidth throttling code was quite buggy, so there was a hidden enum that we could use to turn that code off. We used that and... the problem was instantly fixed! So they knew they had a bug, they even had an option to turn that bug off, but they didn't tell us for two months! I spent all that time doing extra bandwidth optimisations and it wasn't even necessary! Blargh!

Of course, using less bandwidth is always an important improvement for a multiplayer game, but we were already enormously behind on schedule at that point and this took a lot of time for a small indie studio...



2. Lying videocards

This has been a personal gripe of mine for years. Some videocards simply lie about their specs. Your game asks the videocard what it can do, and it will proudly brag about features it doesn't actually have!

I have not yet used any of the newer videocard features like geometry shaders, hull shaders and compute shaders, so I have not encountered any lying videocards recently, but I would be surprised if this doesn't still happen when you try to use state-of-the-art videocard features. It sure did a lot around the appearance of shader models 2 and 3. (Note that I haven't used the new shader types because I think they are uninteresting, but that's a long story that I will not go into today. Instead, I will just leave it at the short and controversial statement that they are irrelevant.)

I had to work around such lying videocards in both Proun and De Blob. What happens is that I make special versions of my shaders for different shader models, so that older videocards can still run the game, but with less special effects. The Ogre-engine has a very elegant system to handle this, and thus Proun features proper materials for shader models 1, 2.0, 2.x and 3.0.

The core of this solution, however, is that you ask the videocard which shader models it supports, and then pick the highest allowed for the best quality. This works very well, unless the videocard lies. It might claim to support 3.0, but doesn't really work with it. In the worst case, the videocard doesn't even give a compile error when being fed a 3.0 shader and simply outputs black pixels!

Several older Ati videocards turned out to do this in a horrible way. The solution ended up to hardcode the names of such videocards and feed them different shaders based on their name. If you look in the Proun folder structure, you can see folders with the same materials, but for different videocards, with beautiful names like "NotX8orX9". That last one contains materials that cannot be used on Ati X8** and X9** cards. I even have another set of materials for Ati X1*** and X2*** cards, because they lie in a different way...



1. "If I buy the game, it isn't the demo any more"

Yes, you read that title correctly. This is by far the most hilarious bug report I have ever seen, and easily claims the number 1 spot in this list, despite not even being a real bug. It was reported to us through the bug database though, so it qualifies for this list!

A professional QA testing company that was testing one of our games for us, at some point reported to us that if they bought the full game from the demo, then when they came back to the game, it wasn't the demo any more. It was instead... the full game!

Oh really?

That happens to be the point of buying the game, now isn't it?

When I replied in the bug database that either I didn't understand what they meant, or this bug report was a slight mistake from the tester, a producer quickly removed the bug from the database, so I never received an actual answer to that.

I think the reason they reported this, is that that particular shop (outside the game, not made by us) concluded the buying process with a question like "Do you want to go back to the game?" Whether you chose "Okay" or "Cancel", the shop always brought you back to the game, and apparently the tester concluded from the fact that there were two options that one of them ought to bring you back to the demo, even though the game had just been bought. This is some pretty broken reasoning, but I can imagine where it came from.

(As crazy as this bug report may be, though, I would like to emphasize that this is the only silly report this testing company wrote to us. The rest of the reports made perfect sense, so this one mistake really shouldn't be held against them! That doesn't make it any less hilarious, though...)

That's it, folks! The 7 weirdest bugs I have encountered! Come back next week when I will discussion the Awesomenauts animation pipeline or visual effects performance (I haven't really made up my mind yet which it is going to be...)

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.