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!