Tanzania Ngamia Booty

Most multiplayer games die within a week. Not because the multiplayer doesn't work, but because there aren't enough people playing online. If you look for opponents and don't find any, then the multiplayer mode might just as well not have been made. This is even more of a waste because online multiplayer is so much work to develop, as I recently explained . The vast majority of online multiplayer games ever made isn't playable any more because of this. Partially this is because not all games can be a success, but there is a much more important reason: often the matchmaking is poorly designed for a smaller playerbase. With clever choices multiplayer can flourish even with a tiny community. For an average indie game that is doing okay but isn't a big hit it is pretty decent to have 40 simultaneous players a few weeks after launch. Our own game Awesomenauts did really well so our daily peak is usually above 1000 players, but expecting such numbers is unrealistic for m...

When we started developent of the bots for Awesomenauts , we started with the most complex part: how to do path finding and movement? When people think of path finding, they usually think of A*. This well-known standard algorithm indeed solves the finding of the path, and in games like an RTS that is all there is to it, since the path can easily be traversed. In a platformer however the step after the finding of the path is much more complex: doing actual movement over the path. Awesomenauts features a ton of different platforming mechanics, like jumps, double jumps, flying, hovering, hopping and air control. We also have moving platforms and the player can upgrade his jump height. How should an AI know which jumps it can make, how to time the jump, how much air control is needed? This turned out to be big challenge! Since there are so many potential subtleties in platforming movement, my first thought was that handling it in our behaviour trees might not be doable at all. Behaviour tr...

With the next Awesomenauts patch (patch 2.5) we will release our AI editor and enable players to load modded AIs in Custom Games. The editor is in beta right now and a surprisingly large amount of new AIs have already popped up. Other game developers can also use our AI editor for non-commercial purposes, or contact us to discuss the possibility of using our tool in a commercial product. This all makes for a great occasion to discuss how we made the AIs and what kinds of tools we have developed for this. Anyone who wants to give making AIs for Awesomenauts a try can check this little starting guide that explains the basics. I have previously discussed in two blogposts how we made the AI for Swords & Soldiers ( part 1 and part 2 ). Since then we have changed some of the fundamentals and those blogposts are well over three years old now, so I will write this blogpost assuming you didn't read them. When people think about "AI" they usually think about advanced self-l...

Designing a free to play game with microtransactions is a huge challenge. It is incredibly difficult to find the perfect balance between giving players a strong incentive to pay something while still making the free experience good enough that they keep playing. This challenge is crippling to the game itself. It is impossible to make a game as fun as it could be for both paying and non-paying players. At least one of those groups gets a game that is less fun. Game design is all about making a certain concept as much fun as possible. By tweaking things like difficulty, flow, reward systems, variation and complexity the game designer tries to create the best experience possible. This "best experience" is an invisible target: you can never know whether you have reached it, or whether tweaking some things would make the game slightly better. It is also something that differs depending on the target audience. Some players like a challenge, others like a more relaxed experience. So...

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

Game development is an iterative process. That means we are constantly changing things around. This might be because we experience that certain ideas don't work, or work differently than expected, or just because we get new ideas that are more awesome. This is especially true for characters in Awesomenauts , so today I would like to show a couple of examples of how enormously some Nauts changed in the period from their first conception to their final in-game appearance. The first one I would like to show is Ayla. She started out as an electricity character called Glint. Ronimo artist Olivier made these awesome concept sketches for him: Glint's power is that he can move through enemies and damage them while doing so. That is basically exactly what Ayla's Rage mode does, and thus Glint slowly evolved into the Ayla we know today. Glint's other skill didn't make it into Ayla, as often happens: elements from ideas are combined and morphed until they work, have synergy a...

The most unique aspect of Cello Fortress is how a cellist does a live performance in front of an audience, while at the same time controlling a game. This is completely different from other music games, in which the musician usually plays on a fake plastic instrument, and even if he plays a real instrument, he does nothing but imitate an existing song. In most such other music games, there is hardly any real gameplay: just points based on how well you played the song. Cello Fortress is a completely different affair: here the cellist is controlling a real game, with real choice and interaction. Depending on what his opponents do, the cellist plays different notes. The cellist can even do things like baiting the opponents with a certain attack and then switching to another. So how does that work? What does the cellist need to do to trigger the various attacks? Check this trailer to see (and hear!) how it works: Live video footage in the trailer shot by Zoomin.tv Games at the Indie Game...

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

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

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

This is the first of a series of posts about lasagne. Lasagne is one of the most inspiring things that ever came out of Italy, and thinking about it is truly food for thought (sorry, I know that joke was bad) . In today's post I would like to introduce to you my lasagne theory of game design, followed next week by the lasagne theory of coding. Image from a Tesco lasagne recipe The game design theory I would like to discuss today is probably not super original, but I think lasagne is a useful tool that can be used to analyse a game. The point here is that lasagne contains layers, just like gameplay. A game like our just released  Awesomenauts  at all times has various game systems active in the player's head, and during different phases of gameplay they will vary in prominence and importance. To strike the right balance and make the game fun for a long time, it really helps to recognise and analyse the layers of the lasagne. An example will help to make this clear. Le...

In Awesomenauts , players can buy hundreds of different upgrades. There are around 150 unique ones, and most have two or three upgrade levels, so in total there are probably around 300 upgrades in the game. We wanted our designers to be able to create those themselves, without any work from the programming team for specific upgrades. At the same time, we also wanted the upgrade system to be super flexible, so that the upgrades would be very diverse, and not just all be cooldown reductions and damage increases. When we first started looking for a way to build this, I was really at a loss. How to add a flexible system for upgrades to our settings system ? It took some time, but coding intern Daan and I came up with a system that is easy to use and so flexible, that we ended up not just using it for upgrades, but also for temporary boosts and areas with modified mechanics, like low-gravity areas. The idea is that for every setting, our designers can create modified versions for when a cha...