Sunlight

When people think of concept art, they usually think of the super slick artworks that AAA games release as part of their marketing. However, making such perfected art takes a lot of time and is very inefficient when the goal is to explore many concepts. Today I would like to show the concept art that our artists made for the map AI Station 404 in Awesomenauts , as it is an excellent example of how rough real concept art can be. click for high resolution A couple of months ago I was at a presentation at the Control Conference where concept artist James Daly showed their concept art for one of the Transformers games. Every image looked mindblowingly awesome (have for some examples a look at this , this and this ), but in a sense this is also weird: it seemed like concept artists only make superbly detailed and shaded paintings. Presentations like that give the impression that that is how concept art works, but in practice making such high quality art is highly inefficient. The goal of ...

Games contain many forms of chance. From simply selecting a random character or level to play, to random pick-ups and even completely procedural worlds: chance, luck and randomisation play a huge role. While developing Awesomenauts we have experienced this first hand, especially in the various versions of Leon's crits, which has been changed several times in patches during the past 1.5 years. Last week I mostly talked about the psychology of crits , and today I am going to look at chance in games in general. When a programmer is told to implement a random for something, he will often simply use std::rand() or something similar and that's it. However, in practice it turns out that both players and designers rarely really want a truly random chance. A good example of this can be found in level selection in Awesomenauts: in a practice match there are four levels to chose from, and there is a 'random' button to select random levels. With a true random, the random button m...

Crits (or "critical hits") seem like a pretty straightforward topic: there is a certain chance that you deal more damage, and that's about it. It is easy enough to calculate average damage and balance based on that, and beyond that it seems like just a choice whether your game has weapons with crits or not. However, in practice it turns out that there are a lot of subtleties to crits that are not immediately apparent. In Awesomenauts we have had various implementations of crits and each time more subtleties surfaced. So today I would like to talk about their many aspects. Crits can be applied to any weapon or attack and their core element is chance : there is a small chance that a weapon does extra damage. Usually this chance is low, below 30%. Instead of damage, the crit might also add other effects, like a stun or knockback. Crits are mostly seen in RPGs, where they are a nice way of spicing up the weapon variation. A sword that does 10 damage feels quite different fro...

An important part of making a complex multiplayer game like Awesomenauts is optimising bandwidth usage. Without optimisations, just sending position updates for one character to one other player already costs 240 bytes per second (30 updates per second at 4 bytes each for both X and Y). And this is just a fraction of what we need to send: Awesomenauts can have up to 35 characters running around the game world, and we need to synchronise much more than just their positions. As you can see, bandwidth usage quickly spirals out of control, so we need to be smarter than just naively sending all the data all the time. In the many months we spent on bandwidth optimisation, we employed lots of different techniques. The one I would like to talk about today can massively decrease bandwidth by crunching numbers on the level of individual bits. This technique not only worked great for the multiplayer implementation of Awesomenauts, but I am now also using this extensively for reducing the size of...

It has been a while since I dabbled in the awesome fun of camera mapping. Recently I bumped into a good reason to get back to that invigorating topic: the comic Ward was released. Marissa Delbressine was working on a trailer for her comic and she thought having a camera mapping of Ward's cover would be an awesome addition. Marissa threw me a pretty smile to which I couldn't say 'no', so I went to work on it. (Marissa happens to be my girlfriend, so I guess without the pretty smile I couldn't have said 'no' either... ;) ) Here is a compilation of the shots I made of the cover of Ward, plus shots of the meshes used to make this scene: Marissa used a couple of these shots in the complete Ward trailer, which you can see below. Note that most of this trailer is not camera mapped: I was personally only involved in the shots at 0:43 and 1:12. All the 2D art and the rest of this trailer were made by Marissa and co. I think the result is great: making a trailer for...

One of the biggest challenges for us in the coming period is implementing replays and spectator mode in Awesomenauts . It might not be immediately obvious, but this is actually an incredibly complex problem to solve. We have the very first bits working now, so here is a video in which I show and explain what we have so far: Our first target with replays is to get them working offline, so you store replays of your own matches on your own harddisk and you can email those files to your friends by hand. Storing and browsing replays through online servers comes after that and is still a long way away. We hope that the offline replays can go in beta before Christmas, but right now it seems like that might still be too early for how complex this all is. So why are replays so difficult to build? There are a ton of reasons for this. One is that players need to be able to do live spectating. In high-level tournament matches, we currently sometimes get near to 1000 simultaneous viewers for a sing...

In previous blogposts I shared the statistics of our games, talking about files and textures and about assets and audio . Today we get to the final part of this short series: code! Code is where size matters most. Not because creating 751 different particle systems wasn't a lot of work for our artists, but because unlike with particles, every additional line of code makes every existing line of code more complex. No matter how many particle systems there are, when creating one, an artist only has to care about that single particle system. The rest hardly matters. With code, the opposite is true: the larger a codebase, the more complex it all becomes. Of course, object oriented design principles say everything should be separated as much as possible, and this is a goal we work hard for, but in practice that is just not always doable. For example, the 15 characters in Awesomenauts all need to interact with each other. Any skill from any character needs to be able to handle interfer...