Wednesday, 23 December 2015

New Awesomenauts expansion announced: Overdrive!

This Monday we've announced a new expansion for Awesomenauts: Overdrive! Lots of cool things under way, like 4 new characters, graphics improvements, new matchmaking and the Starstorm map! Most of that content will be added in free updates to the base game, while 3 of the characters will be sold as a premium DLC. That DLC is coming in March and can already be pre-ordered on the new Overdrive website (pre-ordering grants a free skin for Professor Yoolip). Here's a cool trailer to show what's cooking:

Saturday, 5 December 2015

Texture formats for 2D games, part 4: Overview

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 matter to specific games, but if things like memory bandwidth are an issue then you are probably making an extremely complex game and hopefully know more about it than I do anyway.

Let me give an example of mixing formats to achieve a specific combination of desired properties. For the original version of Swords & Soldiers 1 on the Nintendo Wii we wanted to minimize size on disk and size in video memory. In video memory we used palette textures, but on disk we also ZIPped those. ZIP cannot be used by the videocard but it makes textures a lot smaller. The downside of this is that unZIPping costs additional loading time when starting the game. However, I didn't care much about loading times because the Wii was quite fast compared to the amount of disk space available for downloadable games, so loading times were going to be fine anyway.

Here's the big overview this blogpost is all about. It compares DXT, ETC, PVRTC, palettes and several more basic formats. Creating these was a lot of work so you'd better click them for a good look! ;)

Click for full resolution

Click for full resolution

If there are any mistakes in the descriptions please let me know in the comments so that I may correct them!

An interesting note here is that Android devices differ so much that texture format support varies from phone to phone. Apparently the solution is to either only use ETC1 and uncompressed formats (since those are supported on all Android devices), or to create different versions of the game using different texture formats per type of phone.

It's important to realise that not everything is always what it seems. The benefit of saving your exact texture format on disk (through DDS or TGA instead of something like JPEG) is that you can load the texture right into video memory. You might think this means fast loading times, but this is not always the case: if reading from disk is slow (for example when reading from a DVD) then this might turn out to be a bottleneck. If your processor is fast and your disk is slow then using ZIP or JPEG might actually give you faster loading times, despite the additional processing needed. Note that in the case of Swords & Soldiers 1 this was not the case: the Wii had a small but very fast hard disk.

One final consideration I'd like to mention is framerate. In most cases texture formats don't really influence framerate: the performance bottlenecks are usually fillrate, polygon count, post processing or something on the CPU. As long as all the textures being used all fit into video memory simultaneously they won't influence performance much. As soon as you grow out of video memory however, you're in trouble. On console your game might crash or show broken graphics due to this. On PC you're less likely to see anything so obvious: PC drivers can start swapping textures between video memory and normal RAM. This is devastating to performance but you might not notice this if you're working on a fast development PC. Be sure to keep a close watch on your texture budgets, even if everything seems to still work fine on your own PC!

Texture formats can also influence fillrate. When reading the texture it might get cache misses, slowing down the GPU. I won't go into too much detail here, but the thing to keep in mind is that making your textures much higher resolution than how they're shown in-game might reduce the framerate. If you zoom in and out a lot then mipmapping is a good solution to solve this. It also helps a lot to use a texture format with few bits per pixel, like DXT1.

Some hardware (including some of the current gen consoles) also support tiled textures. Normally a “tiling texture” refers to a texture that can be repeated, but that shouldn't be confused with tiled texture formats: tiled textures in this case refer to a certain memory layout of the texture that reduces cache misses. I won't go into detail on that here either, but if you're running into performance problems due to slow texture reads it might be worthwhile to check whether your specific platform supports tiled texture formats.

Each game and platform has its own requirements and I hope this series of posts has helped you understand the various options for handling textures. Finally, for those who don't have time to seriously look into this and just want some quick and dirty advice: if you're on PC or console DXT1 is usually the best option, or DXT5 if you need alpha.

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 3: DXT and PVRTC

PS. We're looking for interns for the coming period! We have openings in the fields of C++ coding and 2D art! Check here for more info: internships at Ronimo. Note that a basic understanding of the Dutch language is a requirement.

Saturday, 21 November 2015

Texture formats for 2D games, part 3: DXT and PVRTC

DXT is the most used texture format in games and it is what we use most in Swords & Soldiers II and Awesomenauts. DXT is easy to use but provides some weird compression artefacts, so a good understanding of how it works is very useful for both artists and graphics programmers. Since DXT is not supported on iOS I will also shortly discuss the quite similar PVRTC format. This is part 3 in my short series on texture formats for 2D games. Here are part 1 and part 2.

Note that DXT is often also referred to as DDS because DXT textures are usually saved as .DDS files. DXT is also known as S3 Texture Compression.

There are several versions of DXT. The most versatile type is DXT5, which stores an alpha channel that can be used for transparency. DXT5 uses only 8 bits per pixel, making it 75% smaller than full 32bit RGBA. If no alpha is needed or only on/off alpha, DXT1 can be used, which is even smaller: 4 bits per pixel, making it 87.5% smaller than RGBA. That's quite a spectacular win, so where's the catch?

The downside is that DXT can bring serious quality loss due to how it compresses textures. The quality impact of this compression heavily depends on the type of art: some textures will look really bad but in most cases it will look fine as long as you don't zoom in on the compression. Zooming in that far is not common in 2D games so DXT is very usable despite the quality loss.

The most basic type of DXT is DXT1. Here's how it works:

This means that if a single 4x4 block contains few different colours, there won't be any significant compression artefacts. Having more colours inside the block is also fine if those colours are near the others. For example, if the block stores red and yellow then it can also store orange well since that is in between. Heavy artefacts occur if the block contains more really different colours. For example, if a 4x4 block contains red, green and black, then one of those will be lost and replaced by one of the others (whichever is nearest to reduce the artefacts).

This sounds absolutely horrible, but the fun part is that we are only talking about tiny 4x4 blocks here. In practice few blocks contain many different colours, and even if they do the next block will be able to choose different colours, so artefacts usually remain small. In practice in 2D games DXT artefacts will mostly appear in spots where three coloured areas touch each other, and around thin outlines. Have a good look at the image below to get an idea of which situations result in serious artefacts and which are fine.

As you can see above, if your art contains lots of thin outlines it will be damaged severely by DXT1. However, fixing this by going from DXT1 to 24bit RGB makes your textures 6 times bigger. Auch! Luckily there is an awesome compromise: if you store your DXT texture at a slightly higher resolution it will look a lot better and still be smaller than RGB. Upscaling makes the outlines (or other small details) thicker, greatly reducing the artefacts. If you make your texture 41% wider and higher it becomes twice as big, which is still 3 times smaller than RGB. As a huge bonus you also get sharper textures, so this probably looks way better than the lower resolution RGB texture would have. We've used this trick in Awesomenauts on all the characters: they're stored a bit higher than required for a 1920x1080 screen to reduce artefacts.

The format I've explained so far is DXT1, while DXT5 is what you'll want to use most. Colour is stored in the exact same way in DXT1 and DXT5. The difference is that DXT1 only has 1 bit alpha, while DXT5 can also store partially transparent pixels. DXT5 stores alpha in the same way as colour, so it stores two alpha values per block. Per pixel it stores an interpolation value for the alpha. So in total DXT5 stores two colours and two alpha values per block, and for each pixel one interpolation value for the colour and one for the alpha. This makes DXT5 exactly twice as big as DXT1 and results in high quality alpha/transparency.

There's also DXT3, but in practice I've so far never found it useful. DXT3 does not store two alpha values to interpolate between: instead it just uses 4 bits per pixel to directly store alpha per pixel. Since it's only 4 bits this means DXT3's smallest alpha step is 16. In other words: DXT3 is really bad at doing subtle alpha gradients, but really good at doing strong alpha contrasts (like object outlines). Since DXT5 is already good enough at doing strong alpha contrasts I've so far never used DXT3 in an actual game.

DXT1 can also store alpha, but only 1 bit alpha, so only on/off. A clever yet simple trick is used for this. Remember that each 4x4 block stores two colours. If the first colour is brighter than the second colour, then a block can store four different colours: the two main colours and two interpolated colours. This is how I explained it above. If however the first colour is darker than the second colour, then the block can store only three different colours. The fourth colour is used for fully transparent pixels. This results in slightly less colour quality around edges in the texture. Unfortunately it's only 1 bit alpha, so any anti-aliasing on object edges is lost.

There is another type of quality loss happening with DXT compression that I haven't mentioned yet. Colours are stored with 16 bits instead of the full 24 bits. This means that on top of the compression artefacts already mentioned we also get less colour depth. For most textures this is not a problem, but for subtle gradients it is. For this reason in Awesomenauts and Swords & Soldiers II we don't store pure gradients using DXT. We use simple 24 bit TGA instead. This is much bigger, but gradients are usually very thin, so storing a bunch of 256x1 textures with less compression is no problem.

Since DXT is used by so many games there are plenty of tools and plugins to work with it. For example, Nvidia has released a free Photoshop plugin for handling DDS files. When using this for 2D games, be sure to turn off mipmaps to save some more texture space (unless you actually need those mipmaps of course). Image browsing tool XnView supports DXT right away and I've heard there's even a plugin for Windows to see thumbnails of DXT files directly in Windows Explorer.

A fun aside here is that we've tried writing our own DXT compression tool to achieve DXT with less visual artefacts specifically for 2D games. We indeed managed to slightly reduce compression artefacts, but at the cost of more flickering in animations, so we ended up not using our own DXT compression tool. Maybe I'll get around to writing about that some day, let me know if you're specifically interested in this.

An important note on DXT is that iOS doesn't support the DXT format. Instead it has PVRTC. I haven't made any iOS games myself (Proun+ and Swords & Soldiers 1 were ported to iOS by respectively Engine Software and Two Tribes) so I don't personally have any experience with PVRTC). The rough concepts are pretty similar though. The big difference is that PVRTC doesn't have the little 4x4 block artefacts that DXT produces. Instead, PVRTC's compression artefacts come in the form of a slight blurriness.

One trick to improve quality with PVRTC is the same as with DXT: saving at a slightly higher resolution than what you really need will massively reduce the compression artefacts. Aaron Oostdijk from Gamistry (creators of the mobile hits Gold Diggers and Munch Time) mentions it also helps a lot to first smear the RGB colours our across the transparent areas. “A tool called Solidify B does this very nicely. And sometimes a light dither after that will improve results even more.” Note that I didn't use those tricks when compressing the image below.

On iOS you get the additional requirements that textures need to be square (same width and height) and power-of-two (16, 32, 64, 128, 256, 512, etc.). In many cases these two extra requirements demand a huge waste of texture space, unless you work around them through clever usage of texture atlases. On PC and console these requirements have been abolished around a decade ago, making efficient texture usage much easier there.

DXT results in serious compression artefacts but it provides such powerful compression that it is by far the best option for the vast majority of games. Next week I'll wrap up this series on texture formats by giving a big overview of all the formats discussed. See you then!

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 4: Overview

Friday, 13 November 2015

Texture formats for 2D games, part 2: Palettes

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 the art style this loss in quality might be acceptable. For a style with lots of colours and gradients, it probably isn't.

Most textures in Swords & Soldiers 1 on Nintendo Wii were stored using palettes. Some textures even had few enough colours that we could get away with only 16 different colours in the entire texture. This means we needed only 4 bits per pixel. That's 87.5% smaller than uncompressed RGBA! This would bring a 4096x4096 texture down from 64mb to 8mb. Of course such heavy compression is only suitable for some art styles and some textures.

The big caveat is that most videocards don't support palette textures directly. Older videocards like the one of the Nintendo Wii support it, but none of the modern Nvidia, AMD or Intel cards do. Swords & Soldiers 1 was originally a Wii game so we could easily use palette textures there.

This doesn't mean that using palette textures is impossible, just that it's more involved. It's quite easy to write a pixel shader that uses the colour from a greyscale texture as an index for a lookup in a 1D palette texture.

The problem with doing this yourself is that you can't use texture filtering any more. Interpolating palette indices results in random colours. To implement standard bilinear filtering you need to sample and interpolate the colours yourself in the pixel shader. Including the lookups in the palette this means 8 texture reads per pixel. If you happen to also need trilinear filtering for mipmapping this increases to 16 texture reads per pixel. Luckily not all 2D games need mipmapping, but still: 8 texture reads per pixel is significant and costs performance. However, the fun part is that many 2D games have plenty of performance to waste. If this is the case for your game and you have the time to write a good pipeline for them, then palette textures might be an excellent choice.

An interesting side effect of reducing the number of colours for a palette texture is that it makes ZIPping the texture much more effective. With less colours in the texture there is less variation so it can be compressed more effectively. This only helps for download size and for the size of the texture on disk: videocards can't handle ZIPped textures so the texture needs to be unzipped before it goes into video memory.

We used this extensively in Swords & Soldiers 1 to reduce download size. Since the Nintendo Wii had an extremely small hard disk keeping the install size of the game small was really important. For this reason we reduced the number of colours even in cases where it didn't make the texture itself smaller. For example, the size in video memory is the same for a texture with 200 colours or 256 colours. However, the texture with only 200 colours can be ZIPped further. Often there is no visible quality loss when reducing the number of colours a bit further, so we did this with a lot of textures on the Wii version of Swords & Soldiers 1.

When saving an image for the web in the GIF format it's common to turn on dithering. Dithering makes a palette texture alternate between two different colours in a noisy pattern to achieve what looks like smoother gradients with fewer colours. This works quite well for the web, but is totally unsuitable for games. Dithering makes the art flicker like crazy when an object moves around, so in games it can only be used on objects that are rendered pixel perfect, like the backdrops in old adventure games.

A huge benefit of palette textures is that team colours and colour variations can be done extremely efficiently. By simply swapping the palette you can change all the colours. This costs hardly any memory or additional performance.

In Awesomenauts we don't use palette textures so we have to store each character twice: once for the red team and once for the blue team. With palette textures this wouldn't have been necessary. To add to the fun this would also have allowed us to let the player customise his team colour (not that we would want that in a team-based game in which the visuals are all about readability). Lots of other fun tricks can be achieved through clever usage of palette swapping.

Since palette textures aren't supported by videocards by default they are quite impractical to use. Their limitation of a maximum of 256 different colours per texture is also very limiting. However, with certain art styles this technique will give you powerful, lossless compression and easy colour swapping, unique benefits that no other texture format can provide.

See you next week for a look into the master: DXT texture compression!

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 3: DXT and PVRTC
-Texture formats for 2D games, part 4: Overview

Friday, 6 November 2015

Texture formats for 2D games, part 1

When making a large scale 2D game like Swords & Soldiers II or Awesomenauts using the right texture formats can make a big difference for visual quality, video memory, loading times and download size. What format works best varies depending on art style and platform and a good understanding of the options helps a lot in making the right choices.

This is a huge topic so I've split it into four posts. Today I'll cover the basics. The other three posts will discuss the more obscure palette textures, DXT and finally a comparison table of all the discussed techniques. This short series will get a bit technical at points but I've tried to make it as readable for artists as possible: knowing how your art will be compressed is important for game artists.

While the texture formats available for 2D and 3D games are the same, 2D games have different requirements, so it is interesting to approach this topic from a 2D standpoint. Also, 2D games usually don't have things like normal maps, roughness maps and reflection maps and mostly don't need high dynamic range (HDR) textures, so I won't be discussing the requirements of such special kinds of textures.

The first thing to realise is that transparency is extremely important in 2D games. While in a 3D game the shape of an object is generally determined by its polygons, the shape in a 2D game usually comes from transparency in the texture. In many 2D games the art is put on the screen by just having a simple rectangle with an image with transparency on it. Transparency is generally stored in the alpha channel, so the quality of the alpha channel is an important factor in 2D games.

The most basic and highest quality texture format is a simple RGBA32 with 8 bits per colour channel. In total each pixel then uses 4 bytes, or 3 bytes if there is no alpha channel. These can be stored in various file formats, like TGA and BMP, but in the end in the videocard it's all the same. At Ronimo we use TGA for these. This image format is lossless: whatever your original image was, you get exactly that in the game. Note that compressed TGA isn't supported by videocards, so when using TGA you will need to use its uncompressed 32 bit or 24 bit format (depending on whether you have alpha).

The big downside of this format is that it's huge. A 1024x1024 texture with alpha is already 4mb this way. Awesomenauts characters have a texture of nearly 4096x4096, containing all their animation frames. With simple RGBA, this would amount to a whopping 64mb of texture space for just a single character texture! This results in a simple conclusion: we need something smaller for the vast majority of our art. Even when you have several gigabytes of texture space available, full RGBA32 will fill it up really quickly. At Ronimo we only use TGA for images that are small and would lose too much quality when compressed. In practice this means we only use TGA for gradients.

One approach to reducing texture size is to use vector art and render that directly. This means you hardly need to use any textures at all since most colour and shape are defined by polygons instead of by a texture. It also means that artists need to use special vector tools like Illustrator and Flash. This is extremely limiting: more painterly styles are practically impossible this way. It also uses way more performance because in-game animation isn't simply swapping an image frame any more. Rendering vector art in real-time is a relatively complex and performance-heavy task.

Since vector tools are so limiting and since rendering vectors is a lot of work to program and much slower than textures, we don't use vector art in-game at all at Ronimo. We sometimes use vector tools when specific images are most easily made that way, but by the time they get to the game we always save the result as simple textures. Depending on your art style vectors might be a great option though!

A common suggestion from artists when discussing texture formats is to use JPG or PNG. These formats are excellent at achieving small image size with little visible loss. However, they aren't suitable for real-time games: videocards don't support these texture formats at all. That means that a texture that is stored on disk as JPG or PNG needs to be converted to something else to go into video memory, often growing the texture to the size of an uncompressed TGA. An important goal in choosing a texture format is to reduce the usage of video memory (usually to be able to store even more art there). Since JPG and PNG cannot be stored in video memory, they don't help there at all.

This doesn't mean these formats are entirely useless. In a game where the size on disk is most important you can use JPG for all the textures and then simply put them in the much larger RGB24 format in video memory. A game that famously did something like this is Rage (one of my favourite games of the past years). Rage needs to constantly stream in new textures, so the speed of reading from disk was a problem. To solve this they stored the files in a JPG-like format on disk, loaded that into memory, and then converted it in real-time to DXT to be used by the game. Such hardcore streaming tech is generally not necessary for 2D games though.

Videocards can only handle a very limited set of texture types. The three main approaches to reducing texture size without simply reducing their resolution are to use less bit-depth, to use palettes or to use the DXT format. Note that specific types of hardware might offer additional formats, so it can really pay off to look into the details of whatever platform you are developing for. Palettes and DXT will be separate blog posts, so let's look into reducing bit-depth now.

Using less bit-depth is the simplest approach to texture compression. For example, you can use a 16 bit format. Instead of using 8 bits per channel for RGB, you might use 5 bits for red, 6 for green and 5 for blue. Such an R5G6B5 format is 33% smaller than uncompressed 24bit RGB. It also means less colour depth, so especially gradients will look visibly worse. The difference is quite small though so for most textures this loss in quality is hardly noticeable and totally acceptable. The reason green is 6 bits while red and blue are 5 bits is that 16 doesn't divide by 3 equally. Human eyes are better at seeing in the green spectrum, so the extra bit is put in the channel where it matters most.

If you need alpha there's often something like R5G5B5A1 available, which also uses only 16 bits per pixel, but at slightly greater compression costs. This specific format has only 1 bit for alpha, so pixels are either fully transparent or fully opaque. This not only means that partially transparent pixels aren't possible, but also that anti-aliasing on the image's edges is entirely lost. In 2D games anti-aliasing is usually part of the original art and stored in the texture. Losing this can be pretty bad for image quality, so I generally wouldn't advice using formats with only 1 bit for alpha. There are also other combinations, like R4G4B4A4, giving better alpha but significantly worse colours. If you hate your own game you can even use R2G3B3.

Videocards support many different combinations of bitrates per channel so it's useful to have a look and figure out what works for your purpose. Specifically interesting is L8A8: this is a greyscale texture (L for “luminance”) with high quality alpha. This is 50% smaller than full R8G8B8A8. If the original image is already greyscale this format doesn't result in any quality loss. If you happen to be making a game with many monochrome textures, this might be a relevant option. If you don't need alpha you can half the size again by using L8.

In our own games none of the formats discussed so far are used extensively. We use a little bit of R8G8B8A8 through TGA files for gradients, and L8A8 for fonts. The vast majority of our textures is DXT5, which I will discuss in part 3 of this short series. Next week I will first look into the format we used for Swords & Soldiers 1 on Nintendo Wii: palette textures. This format is often overlooked and usually quite a hassle to use, but for certain art styles it delivers an excellent combination of small textures with little quality loss, as I'll show next week.

See also:
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 3: DXT and PVRTC
-Texture formats for 2D games, part 4: Overview

Monday, 28 September 2015

The future of indie is amateur

The number of indie games being released on Steam and consoles has sky-rocketed this last year. At the same time, the amount of money being spent on indie games doesn't really seem to increase. In other words: the average indie game is making much less money! SteamSpy recently released some graphs that show that while total sales for all games together are pretty stable, median sales per game have dropped enormously. You only need to open Steam's list of new releases to see why: so many new games launching every day! Five years ago only a couple of games launched on Steam per week. Now there are dozens launching daily, and they're all competing for the same players. The average income of a new indie game has dropped so far that some even call this current trend the 'indiepocalypse'.

There are several reasons we're seeing this now. The most obvious reason is that marketplaces like Steam have made worldwide distribution easy. They have become more and more open to release games, and not just the cream of the crop. Five years ago, if a hobbyist made a game he put it on Newgrounds and didn't expect to make any money. In contrast, professionally made indie games released as paid products on other platforms and thus competed with hobby developers in a less direct manner, and often in different genres. Today many smaller games can also release on Steam. If Steam keeps going in its current direction, then soon everyone will release their games there. The same goes for other platforms: ID@Xbox isn't anywhere near the speed of Steam yet, but with 21 indie games released in August alone they too are stepping up the pace enormously.

Another important factor is that tools like Unity, GameMaker and Unreal make game development much easier and cheaper than it ever was. Previously many developers were confined to 2D browser games because 3D was technically too complex, as were mobile and console. Licensing a decent game engine that handled this was very expensive. Five years ago only teams with significant technical skill could make such games, yet now these engines don't require much more than the click of a button to reach most platforms.

The final drop is that game dev courses are abundant now. For example, here in the Netherlands we used to have only a few schools teaching game development. Today there are dozens. I'm seeing this same kind of educational expansion everywhere in Europe. More graduates means more people to make games and many of those are starting indie companies straight out of school.

Together these three factors have caused an enormous influx of people all trying to make a living making indie games. Their number is growing much faster than the market, so the average sales of indie games are dwindling. Many indie games that release today won't make much more than a few thousand dollars, far from enough to make a living as a full-time game developer.

What does this mean for indie studios? I recently met a young dev who had started a company with friends and spent a lot of time making their first game. When it launched it literally sold only a few hundred copies. His conclusion? He was going to look for a job and continue making his own indie games – in his spare time, as a hobby.

I think we are going to see this pattern for a lot of start-ups. There are so many games that only a few actually make a decent buck. The rest won't make enough money to sustain the company, causing those indies to bail out of trying to make a living as an indie developer. Many will become amateur indie developers instead.

I don't think this dire financial situation will stop people from making games. Development is just too much fun and that small chance at success just too awesome. What if your game becomes the next Braid or Minecraft? If you can't do it professionally, I'm sure many people will just build those games as a hobbyist instead.

Talented amateurs won't be able to make AAA games like the next Grand Theft Auto, but they will be able to make games similar to what indie teams of only a few people can make. A bunch of highly talented hobbyists working on a game in their spare time for a few years might be able to make the next Banished or Nuclear Throne. This is great of course, but they will be competing for the exact same audience as those trying to make a living as an indie.

Full-time indies competing directly with hobbyist developers will cause the chances of indie games being a financial success to plummet even further than they already have. As the chances decrease, it will become highly infeasible to start a company and 'go pro'. Heck, it probably already has! In the long term people will realise this beforehand and most won't even try to make a living making indie games anymore. I expect they'll just get a job somewhere (hopefully still as game devs!) and keep doing their own projects on the side.

Of course, some will become a hit and be able to make a living. Some others already have an audience and are really good at what they do, so those too will stick around. But in general, the vast majority of future smaller indie games will be amateur games.

Is this bad? No: 'amateur' and 'hobbyist' aren't negative words. They just indicate someone who does something without making money from it. This doesn't mean they can't be good at what they do: just like there are tons of hobby musicians who are actually amazingly good, we will be seeing more and more fantastic games by talented hobby game developers. As well as a lot of bad ones of course, which is fine as long as they too are having fun making games. I expect there will also be a lot of indie games from people who have a regular job as a game developer or freelancer and make their indie games as hobby projects on the side.

I've heard the current trend described as the 'indiepocalypse'. I don't think that word makes sense: this isn't an apocalypse as it isn't the end of indie. Instead it's a shift from professional indie to hobbyist indie. We'll keep seeing awesome indie games and some of those will break through to huge success.

There is a big downside though: this is very sad news for those who release their first game now. Many will have started their company when the indie scene was still small enough that all decent games sold at least okay, not just the amazing ones. Many will be disappointed when their game launches and doesn't reach an audience. I can only hope they'll realise how awesome it is to have made their own full game and feel proud of having released it. But it's a bittersweet second prize, when you dreamt of making a living as an indie dev.

What does this all mean for the bigger indie studios, the ones with more than ten people working on a single game? I don't know. They're capable of creating bigger, more polished productions than hobbyist developers, making those bigger games stand out from the crowd. Will this be enough for a good chance to earn back the much bigger investment? Time will tell. One thing I expect is that they will make more business deals with publishers, investors and other partners to decrease their risks and gather the required budgets. This will move those bigger indie studios further away from what is traditionally considered 'indie'.

If an indie studio is successful and grows its team, it is often not considered 'indie' any more. I regularly get the question whether our own studio Ronimo is still indie: “Aren't you too big for that now?” If that's true, then 'success' often means 'not indie anymore', as using that success to grow the studio apparently isn't indie. By that definition the only successful indies are those who not only have a hit but also stay small.

From a gamer's perspective I don't think any of this matters much. My favourite game this year so far is Ori And The Blind Forest. For me as a gamer it offers exactly what I look for in an indie game: it tackles a genre that AAA doesn't do (2D platformer), has a beautifully crafted atmosphere and brings a focussed experience that dares to take risks. Yet I haven't seen this game mentioned as being 'indie' at all. Apparently a type of game that I perceive as typically high-end indie isn't called 'indie' anyway.

An odd part in all of this is the new breed of 'indie publishers'. Now that the overflow of indie games has made reaching a bigger audience so difficult it makes sense to look for a partner to work with: a publisher that specialises in marketing indie games. However, I remember 'indie' was originally mostly defined as 'not working with a publisher or investor'. Doesn't that make the term 'indie publisher' a contradictio in terminis?

The result is that 'indie' is a word with very little meaning today. It's more marketing buzzword than anything real. Even the gigantic company EA has published games that they marketed as 'indie'.

Let's piece all of this together. What do we have? The vast majority of smaller indie games doesn't make money. Hobby devs can use cheap, high quality engines to make bigger games. They can release their games on more open platforms to reach more people. And finally, the bigger games often aren't called indie. Combining this can lead to only one conclusion: in a few years the word 'indie' will mostly be interpreted as 'probably made by hobby developers'. In other words: the future of indie is amateur!

Sunday, 6 September 2015

Designing matchmaking for non-gigantic communities

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

Let's consider a four player multiplayer game that has three game modes. We press the quickmatch button and the game starts looking for opponents. If a match takes on average 30 minutes and there are 40 simultaneous players then a player starts looking for a match once every 45 seconds. Since there are three game modes your mode will have one player searching once every 135 seconds. Waiting for a complete match of four players then takes almost 7 minutes.

Seven minutes! Few players are willing to look at a "Searching" screen for that long, so most will just quit and play something else. If a player concludes your game is dead he probably won't try again later and is lost forever. Whatever playerbase you had will quickly disappear. So many multiplayer games die because there aren't enough players for a good experience.

However, with clever design choices this fate can be averted. 40 simultaneous players would have been plenty for a good experience if matchmaking had been designed in a different way.

Reduce game modes

Game modes split the community. If half of your players wants to play Domination while the other half wants to play Deathmatch, then they all have only half as many opponents to play with. In the example above removing two game modes would have reduced the waiting time to 2:15 minutes, which might already have done the trick. Even the gigantonormous League of Legends has removed less popular game modes because there weren't enough players for a good experience.

For exactly this reason Awesomenauts has only one core game mode. There is a custom game option where users can set up all kinds of weird game modes, but these aren't part of the core matchmaking and thus only playable through friend invites. This way there are extra options for players who want them, but there is only one core mode and it has plenty of players to matchmake with. (For a more detailed analysis of player spread, check my blogpost on why good matchmaking requires enormous player counts.)

If you really want to have more game modes, you can also choose to force players to play whatever is available. Maybe players can select a preferred game mode and the matchmaker looks at all the preferences and tries to find the best match-up. If there aren't enough players in your favourite game mode, then you just play a different game mode. The downside of this approach is that players would probably complain a lot that they aren't put in their favourite game mode. Not having an option at all might in some cases feel better than having an option that you can't actually play...

Allow solo play while waiting

The above approach tries to reduce the waiting times. An alternative is to make waiting more fun so that players are willing to wait longer. In our 2010 game Swords & Soldiers we allow players to play all single player content while waiting for an opponent. If you start the matchmaker a little icon appears in a corner of the screen and you can just play some skirmish against the computer until another human becomes available to play with. This works wonders: players are willing to wait much longer, increasing the chance they actually find an opponent.

This can be improved further by having content that is fun to play repeatedly. A story campaign isn't so much fun to play every time while waiting, but a highscore mode is. In Swords & Soldiers I usually played the endless Survival mode while waiting. Of course it sucks to be thrown out of your highscore run because an opponent is found, so our solution was to auto-save the solo match when starting a multiplayer match. You can continue your single player challenge after the multiplayer has ended.

A while ago a colleague of mine tried playing Swords & Soldiers online. Even though the Steam version of the game is almost five years old now and there are only a few people playing, he got three different opponents in just an hour. There were never more than four people playing Swords & Soldiers simultaneously that evening, so he got a surprisingly good multiplayer experience with such a microscopic community. Amazing!

Playing against bots

For Awesomenauts we chose a different approach. Here we let the match start even if there aren't enough players for a full 3vs3 match. The missing spots are filled with bots until more players are found. The result is that even if there are very few players online, you never have to wait long and can always start playing.

Initially Awesomenauts just started a match right away regardless of how many players were found, removing waiting times altogether. The big downside of this is that it doesn't work well with a competitive mentality: it feels unfair if bots already lost a tower before you even joined. For this reason we later added waiting time, but with a countdown timer that shows the maximum waiting time left. Since Awesomenauts has plenty of players most of the time the match will be full well before the timer runs out, so you rarely start with bots.

This drop-in aspect of the game is a constant source of complaints from our userbase, but players often don't realise that without it, Awesomenauts might not have survived its first months. It took nearly half a year before our playerbase reached a constant good amount on PC and even with those smaller numbers there were never long loading times.

Adding more players

So far I have focussed on making the most out of a your existing players. Another important approach is to maximise the numbers of players. This can be done in various ways. Many multiplayer games are free-to-play, increasing the size of the playerbase (although there are also plenty of free-to-play games that don't actually manage to gather a significant playerbase).

The developers of Verdun chose a hybrid approach: at some point their game had a free browser version and a paid Steam version and they all played together online. The free players didn't bring in a lot of money directly, but they made the game more fun for the Steam players, increasing sales there.

Even when not going free-to-play it is a good idea to not make a game too expensive. The average indie game seems to have recently gone up in price, but I would heavily advice against pricing a multiplayer-only game above $15: this will decrease the size of the playerbase. Selling more copies is more important for the long term income of a multiplayer game than the short term income of a higher price. Awesomenauts is $10 and we often drop its price heavily during sales, by as much as 90%. This boosts the playerbase enormously, more than making up for the low price.

Extreme measures

If you want to make a multiplayer game playable with below 10 simultaneous online players you might have to resort to extreme measures to keep something going. Several devs told me they promoted a specific moment, like one specific evening every week, as multiplayer evening. This way everyone comes online at the same moment, creating a somewhat lively community once per week. One dev even went as far as taking the multiplayer functionality offline altogether during weekdays, only allowing multiplayer during weekends.

I can imagine other, more subtle ways to get players online at the some moment. Like allowing players to send a challenge to other players who are near them in the leaderboards. The game then sets up a time for them to play against each other, giving them a good reason to come online at one particular time. Asynchronous multiplayer is also a good way to do this, but this only works with certain types of games. For highscore based games asynchronous multiplayer can be an excellent way of boosting the competition within the community.

There are many other ways to make the most out of a small community. For example, things like clever lobbies, a rematch option and showing the expected waiting time per game mode. Key is to consider matchmaking a real part of game design, something to brainstorm about and come up with creative solutions. If you just make something then you might end up killing your community much quicker than needed. If you aren't Blizzard or Riot then thinking about how to make the most out of a smaller online community is crucial to the success of your multiplayer game.