Style exploration for Cello Fortress

So far I have focussed all my efforts for Cello Fortress on the gameplay. Controlling a game with a live cello is a big challenge, both technically and in terms of game design. Now that that is turning out well, the next step is to get rid of the prototype art and give the game real graphics. I have been thinking a lot about the exact visual style and the goal is of course to make Cello Fortress look really good. While the current version of Cello Fortress does not contain any of these visual ideas yet, today I'd like to show my inspirations, and some visual experiments that I did.

The base inspirational image for Cello Fortress' visuals comes from the special edition booklet to Radiohead's album Amnesiac. It is a really noisy and small image, and the scan makes it even worse, but the core of it is this: extremely low-polygon mountains with extremely low-res textures, so that there are big square pixels on the flat triangles.



Taking this idea, I did a quick experiment in 3D Studio MAX. I just piled some pyramid-like shapes in the scene and put on some textures, without any intend on making a real composition or anything finished. I didn't want it to actually be as rough as the Radiohead image, so I added lighting and depth of field blur to it.



The other big influence comes from an indie game called Teleglitch. In Teleglitch, whenever you shoot the colours on the screen are ripped apart. This gives a very raw and powerful effect, so I wanted something similar. Skip to 58s in this video to see the effect in action:


Gameplay footage from Teleglitch, check the effect after 58s

Of course, I wouldn't want to just copy that, so I came up with something different that was inspired by this effect: bullets and explosions deform the landscape in 3D with a rough noise. I added this effect to my little 3D Studio MAX testscene and made this little previz animation that shows the effect in action, much to my satisfaction:


Cello Fortress pre-visualisation

At this point I actually thought I had copied the effect from another Radiohead video, but I couldn't find it anymore. In my memory, Yorke's head deformed in exactly the same way whenever he held his finger close to his head. After a lot of searching I discovered the video was called "Go To Sleep", but to my surprise the effect is very different here. Instead of deforming, they animate the number of polygons in his head, which looks quite different, as you can see here. (Note that in 3D Studio MAX, this can be done very easily by animating the Optimise modifier.)

So my inspiration turned out to be completely different from what I had remembered, but my own result looks good, so I am happy. ^_^ This kind of process is something I like a lot: if I add my own interpretation to something that inspired me, it becomes something new. This also happened with Proun: it was strongly inspired by Kandinsky and Rietveld, but by adding my own ideas, it became instantly recognisable as something else, something of my own.

At this point, I concluded rawness was my goal. I found another great example of the vibe I wanted in a trailer for Luftrausers, a game by our friends and neighbours from Vlambeer. I really like the extreme vibe they managed to achieve:


Luftrausers by Vlambeer, coming soon to PS3, Vita and PC!

From here, it seems quite simple to conclude what Cello Fortress' visual style should be: raw, pixels, big polygons, extreme effects, noise, screen shakes, grey. However, more recently I discovered some other images that I find extremely inspiring, but that contradict that. They also work with the big-polygons-big-pixels style, but are much less raw. Just have a look at these beauties:







These images from the fantastic Geo A Day and JR Schmidt combine a lot more colour and smoothness with the sharpness of the polygons, and I'd love to make something like that. However, they are quite at odds with the roughness I was previously aiming for.

The final element that has been inspiring me for Cello Fortress, and that I think will combine very well with the images above, is the tilt shift effect that is seen in the new Sim City. It is also found in tons of random videos on Youtube, like in "The Sandpit", which, if you have never seen it before, you need to watch right now. Tilt shift is basically just an extreme depth of field blur that makes everything look small. I also think it looks absolutely gorgeous.


Tilt shift in the new Sim City (which, by the way, is a great game, and much better than the 6.5 Metacritic currently has it at because of those DRM shenanigans...)

Having all these elements, I am not sure yet how I shall mix them. I expect some kind of combination of all of these ingredients, but I am really curious how raw Cello Fortress will end up exactly. Knowing myself, there is a good chance it will turn out a lot more smooth, like my Solid Motion series.

Regardless of what it ends up being exactly, I hope it ends up both unique and awesome! Next week I will release a new gameplay trailer for Cello Fortress, still with the old prototype graphics, and after that I'll get cracking on these graphics!

Making everything animatable

Everything in our tools is animatable. Not just position, rotation and scale, but also things like colour, skew, taper, texture scroll and the number of particles emitted. This is a feature that I know from 3D Studio MAX and that I had been admiring for ages, so as a programmer I really wanted to come up with a neat system to build this. Being able to animate everything also happens to be really useful for our artists... ;) Today, I would like to explain how we built this.

You might already have seen our animation tools in the Ronitech tools trailer I made a while ago, but that was only a very short fragment, so here is a more complete demo of the animation capabilities of the Ronitech animation editor:



Before I continue, I should note that although I designed most of this system, the real credit should go to Thijs (at the time a coding intern at Ronimo, now a gameplay programmer): he implemented it all, figured out the nitty-gritty details, and built the editor's animation UI.

With so many variables that can be animated, we need a good way on the coding side to hide the actual animation code from everything else. In fact, ideally I would like to be able to just mark a variable as being animatable, and that's it. Relatively simple object oriented design allowed us to do just that.

To make a value animatable, we write a class around it called AnimatedFloat, which handles the animation and contains the data needed for that. This class is updated every frame, and whenever the value is used, we just ask for it in that class. Using our AnimatedFloat in a gameplay object looks something like this:

class WorldObject { AnimatedFloat scale; AnimatedFloat rotation; TexturedRectangle* visualObject; void update(float time) { position.updateAnimation(time); rotation.updateAnimation(time); visualObject->setScale(scale.getCurrentValue()); visualObject->setRotation(rotation.getCurrentValue()); } };

This works simple enough, and AnimatedFloat itself is quite straightforward to implement like this. There are a couple of things in this bit of code that we could try to improve, though. One is those calls to getCurrentValue(). This function returns the value that the scale has at the current moment in time. If we use the scale variable a lot, it might be cumbersome to call getCurrentValue() all the time. Luckily, there is a nice (and rather obscure) solution for this in C++: we can skip calling that function by providing a conversion operator in the AnimatedFloat class. Like this:

class AnimatedFloat { float currentValue; void updateAnimation(float time) { //perform actual animation here and update currentValue } operator float() const { return currentValue; } };

The operator float() there is a conversion operator and tells C++ what to do if we use an AnimatedFloat in a spot where a float was expected. It removes the need for calling the function getCurrentValue().

This is a simple and nice solution. However, in practice we ended up not using it in our code, because our AnimatedFloat also has a function getBaseValue() (for animations that perform a periodical animation around a base value), and we felt it was not clear enough which value the conversion operator would return.

A bigger problem in our current design is that it is easy to forget to update one of the AnimatedFloats in a class. If we forget to update it, everything still works, but the object won't animate anymore. With the large number of AnimatedFloats some of our classes have, this is an easy oversight, and forgettig it might not become apparent until an artist actually tries to animate something and it doesn't work. I would prefer it if we could make it so that it is not possible for the programmer to forget updating a single variable.

I imagine there is a solution for this using macros, but I in general I think macros are not very readable, so we avoid them whenever possible.

The solution we came up with, is that values are updated by another class: the ObjectAnimator. The AnimatedFloat itself can only be created by providing an ObjectAnimator. Now the programmer only needs to update the ObjectAnimator and cannot forget about individual variables anymore. It is still possible to forget to update the ObjectAnimator, but then nothing at all will be animatable, so this is much less likely to be overlooked. Our design now looks like this:

class ObjectAnimator { std::vector animatedValues; void add(AnimatedFloat* value) { animatedValues.push_back(value); } void updateAnimations(float time) { for (std::size_t i = 0; i < animatedValues.size(); ++i) { animatedValues[i]->updateAnimation(time); } } }; class AnimatedFloat { //The constructor requires a pointer to an ObjectAnimator AnimatedFloat(ObjectAnimator* owner) { //The AnimatedFloat registers itself for updating owner->add(this); } }; class WorldObject: ObjectAnimator { AnimatedFloat scale; AnimatedFloat rotation; TexturedRectangle* visualObject; WorldObject(): scale(this), rotation(this) { } void update(float time) { updateAnimations(time); visualObject->setScale(scale.getCurrentValue()); visualObject->setRotation(rotation.getCurrentValue()); } };

The clue is that AnimatedFloat's constructor requires an ObjectAnimator. Without an ObjectAnimator, it cannot be created at all, so it is impossible to forget about it in WorldObject's initialiser list.

This is a nice example of a coding principle that is extremely important to me: code needs to be designed in such a way that common mistakes are simply not possible. Of course, this principle cannot be achieved in everything, but at least it is a good goal to strive for. In this case, by changing our class design, we have avoided a future bug that was very likely to happen quite often.

A big flaw in this design is that it currently only animates floats. In reality, a lot of our values are other things, like Colour, Radian and Vector2. The solution to this is to make AnimatedFloat templatised and to rename it to AnimatedValue. This is quite straightforward if you are experienced with templatised programming, but for any programmers less familiar with this weird part of C++, I'll provide a small example of roughly how that looks. Just think of a template as a type that will be filled in depending on what it really is. So T here can be a float, or a double, or a Colour, or whatever you want. In this specific piece of code, substitute the T with something that one can do math on, and it will still be good code.

template ‹typename T› class AnimatedValue { T currentValue; T getCurrentValue() const { return currentValue; } }; class WorldObject: ObjectAnimator { AnimatedValue‹float› scale; AnimatedValue‹Radian› rotation; };

There are some details to this that make the real code a bit more complex, but the core idea remains the same. By using templates, we now have a single AnimatedValue class that can animate any kind of value that we can do math on.

There are several topics that I have completely ignored so far. The first is actual animation. However, I don't want to make this post too long, so I won't go into detail on that. Animations are calculated in the updateAnimation() function of AnimatedValue.

Another topic I have ignored is how to generate an interface for editing these values, how to save them, and how to even have complete undo/redo for editing animation details. That is an interesting topic by itself, so I think I might get to that in a future blogpost at some point.

Finally, there is the topic of performance. Updating all these animation objects uses actual performance, especially if our artists animate tons of values. I had to optimise our animation code quite a bit to still get a good framerate on consoles. In the end, this is a trade-off I seem to encounter all the time: in most cases, the more flexible a system is, the more performance it uses. Luckily, computers and consoles are getting faster and faster, so as this is only a small problem for us now, I have no doubt a couple of years from now the performance of systems like this will have become completely irrelevant in all but the biggest triple-A games.

The fun part of our animation system, is that it is extremely flexible, but at the same time rather simple to build and use. In that sense it is rather similar to our upgrade system for gameplay, which I explained in a blogpost last year. Our artists have made tons of animations with our animation system for Awesomenauts, and it contributed greatly to the lively feel that the game has!

From melee to ranged: the most difficult design decision in Awesomenauts

Many people probably won't realise this, but while Awesomenauts may feel like a logical translation of the MOBA genre (games like DotA and League of Legends) to a 2D platformer, the design process was in fact long and difficult. Striking the right balance between tactical gameplay, platforming combat and match flow took a long evolution, with tons of experimentation and careful design. A little bit of that process shows through Sheriff Lonestar's evolution, which I talked about last week.

Awesomenauts' design originally featured tons of features that didn't make it into the game. Probably the most striking of those is the disappearance of most heros' melee skill. Originally all classes in Awesomenauts had both a ranged skill and a melee skill, including Lonestar. Looking back, this surprises me, since the current distinction between ranged and melee characters feels so natural. It took us a long time to figure this out, though!

Originally we wanted to make something with some similarities to a brawler, so the melee skills that every character had were very strong. They also had a ranged weapon, but in the early balance of the game you had to get close to do some real damage. This was a constant gameplay headache during early development. With all the characters and droids, gameplay is just too chaotic to make melee combat work. Most combat came down to standing in front of each other and just bashing the attack button to do maximum melee damage. Nevertheless, we had a certain vision for the game, and several team members fought valiantly to keep the melee combat central. So we explored lots of melee mechanics to find a way to make it work.

The biggest problem was that everyone just stood in front of each other and bashed the punch button. We first tried solving this by adding depth to the combat. We added combos (every third attack is stronger if you time the button presses right), we added two buttons for a fast and a slow hit, we even added a parry button: a defensive move that if pressed at the right moment would fend off a hit and cause the attacker to be stunned for a short moment.

However, all of these bumped into the same problem: if more than one opponent is standing in the same spot, this quickly turns into massive chaos. For example, it is impossible to time your parries if three opponents stand in one place and attack with different timings.



Other games often solve this by changing the AI. For example, Assassin's Creed lets part of the group wait, so that enemies roughly attack in turn. Another solution for group combat can be found in Shank and Batman Arkham City, where many of your attacks stun or knockback enemies, allowing the player to temporarily keep some opponents out of the battle and focus on one or two enemies at a time. However, both of these solutions totally fail to work if the opponents are human players: being stunned a lot is no fun, nor is waiting for your turn to attack.



Another thing we tried to make the combat more dynamic, was adding a 'lunge' attack. This was a game mechanic where if you are in the air, you can press a button to home in on an enemy and kick him from above. This made it more useful to keep jumping and moving, but definitely didn't decrease the chaos.

We even experimented with letting teammates collide with each other, so that no two players could stand in the same spot. This turned out to feel very frustrating: your allies were now always standing in your way and sometimes you couldn't hit an enemy because a droid was standing in front of him already.

Several team-members really wanted to keep the melee mechanics in the game, but at some point our designers (Fabian and Jasper) got bold and simply removed all melee skills for one playtest. It turned out that this instantly fixed all these problems. Everyone keeps a little bit of distance from each other and you don't need to all stand in the same spot anymore to attack. Also, jumping became way more important, because you can evade bullets and aim at opponents at the same time!

This was one of the biggest breakthroughs in the design of Awesomenauts. The result was so convincing, that of the original six Awesomenauts, only Leon ended up with a melee skill. All the others turned ranged and it worked great!

Announcing Awesomenauts The Movie with a trailer!

We have just released this press release, figured I should share this awesome piece of news with you!

Today Ronimo Games announces that their massively successful platforming MOBA Awesomenauts is coming to Hollywood! Awesomenauts The Movie will be directed by the award-winning director G.G. Abrams. The announcement is celebrated with a teaser trailer:



Awesomenauts The Movie will be released in full 3D and will reach theaters around the globe this Fall. Joost van Dongen, co-founder of Ronimo Games, says "This movie is a dream come true. Plans for an Awesomenauts movie have been in development since we started working on the game, and now that the game has reached such huge success, we have finally been able to break into Hollywood and get the production of the movie started!"

Actors have not officially been announced yet, but rumours currently suggest several famous Hollywood actors might have enlisted to play the roles of Froggy G, Clunk and Sheriff Lonestar.

About Awesomenauts:
The downloadable game Awesomenauts is a unique combination of an action platformer and the MOBA genre (games similar to League of Legends and DotA). Awesomenauts was released on PS3, Xbox 360 and Steam in Summer 2012 and features lovingly crafted 2D graphics. It also happens to come with one of the best theme songs in the history of gaming.

About Ronimo Games:
Ronimo Games is the Dutch indie studio responsible for the downloadable hits Awesomenauts (Steam, PS3, Xbox360) and Swords & Soldiers (Wii, PS3, Steam, iOS, Android), which both won numerous awards.

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!