Posts

The evolution of Sheriff Lonestar

Image
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...

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

Image
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 i...

The character animation workflow for Awesomenauts

Image
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 ...

Optimising special effects in Awesomenauts

Image
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...

The craziest bugs, part 2

Image
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 ba...

The craziest bugs, part 1

Image
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 d...

Why Cello Fortress is a twin stick shooter

Image
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 ...