Tanzania Ngamia Booty

In my last three blogposts I've discussed the details of various texture formats. Now that we've seen them, it's time for an overview. Below you'll find a big table that lists the properties of a lot of different formats and shows their results. I'll also discuss some final considerations on performance. The important thing here is to realize that there is no perfect solution: every choice has its own drawbacks, so even with the same art style you might end up with different texture formats depending on the platform. These are the main arguments to consider: Quality Size in video memory Size on disk Download size Loading time Framerate Development time Most of these are pretty obvious and I've already discussed quality and size in video memory extensively in my previous posts. The reason I'm listing them here is that it's important to keep in mind that you can mix and match formats for different goals. There are also more complex things that might m...

After last week's introduction to texture formats we are going to look at palette textures today. Palette textures are an interesting and underused option for 2D games. Using them is quite a hassle since normal videocards don't support them, but for certain art styles they offer high quality and small texture size. Palette formats are similar to GIF files. The idea is that we have a palette, a list of all the colours in a specific texture. In the actual texture we don't store the colour of each pixel, but rather a reference to the palette. If the texture doesn't have a whole lot of colours we can get away with using only 256 different colours. References to these can be stored in 8 bits per pixel, so this format is 75% smaller than uncompressed RGBA. Palette textures are particularly useful for cartoony styles with flat shading, since those have fewer colours per texture. If your textures have more than 256 colours, you can reduce the number of colours. Depending on th...

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

Some bugs and issues can only be found by playing the game for ages in a single play session, or by triggering lots of random situations. As a small studio we don't have the resources to hire a ton of people to do such tests, but luckily there is a good alternative: a fun method is to hack automated controls into the game and let the game test itself. We have used this method in both Swords & Soldiers and Awesomenauts and found a bunch of issues this way. Autotests are quite easy to build. The core idea is to let the game press random buttons automatically and leave it running for many hours. This is very simple to hack into the game. However, such a simplistic approach is also pretty ineffective: randomly pressing buttons might mean it takes ages to simply get from the menu to actual gameplay, let alone ever actually finishing any levels. It gets better if you make it a little bit smarter: increase the likelihood of pressing certain buttons, or even just automatically press ...

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

Last week I shared the first part of the statistics from our games . Today let's look at the second part: numbers about assets and audio. Plus a bunch of (hopefully) interesting contemplations and anecdotes about them. In fact, I had intended to also include stats about code today, but I typed so much text about all of this that I had to split it further. This series is now three blogposts instead of my originally intended two. Before I continue, let me abuse this moment for a short commercial break by (again) marketing our Kickstarter campaign for the Awesomenauts: Starstorm expansion ! Including PayPal pledges we have by now reached the first stretch goal (a new map) and are working towards the second stretch goal: Custom Games! Now, let's get to the actual numbers! Assets Levels 1 1 42 42 5 3 4 Skeletal animations 12 82 n/a n/a 0 n/a n/a Particles systems 2 10 43 43 2 526 751 Animation templates n/a n/a n/a n/a n/a ...

As you might know, we are currently running our Kickstarter campaign for our big Starstorm expansion to Awesomenauts. While we were preparing for that, I was thinking about how much Awesomenauts has grown since launch, and how much further it would grow by creating the Starstorm. Being a programmer, I love numbers and started collecting data on just how much Awesomenauts has been growing. Today I would like to share the first half of those with you! Since I like comparing, I have also added the other games I have worked on: De Blob, Snowball Earth, Swords & Soldiers and Proun. Hopefully you will find this as fascinating to look at as I do! But first, let me abuse this moment to blatantly market our Kickstarter campaign ... ;) We have already reached our main goal, and there are still tons of fun things in the stretch goals, including releasing our editors for modding. So please help make those features possible by backing the Starstorm, and scoop up lots of goodies in the reward ...