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:
Wednesday, 23 December 2015
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:
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.
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 resolutionIf 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
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
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
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!
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.
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.
Sunday, 30 August 2015
Opinions needed: which art style for Cello Fortress?
The gameplay of my live performance game Cello Fortress is nearly finished, but the graphics are still basic blocks with some crude textures. Recently I've been working on figuring out what style I want for the game, and I've ended up with two possible styles that I like: one dubbed "Surreal Architecture" and the other "Rough Polygons". Since I have a hard time choosing, I figured I'd just ask here. Which style should I use for Cello Fortress?
I've also added the pros and cons of each style as I see them. Several are just my personal taste so let me know in the comments if you disagree.
The basic idea of this style is that you travel through a world of surreal architecture. The surrealism is of the subtle sort: on first sight it might look like normal classical architecture, but if you stop and think for a second you realise this cannot be: buildings are too big and repetitive, it makes no sense to have a city with nothing but church towers, and why is there an area with giant organ pipes?
This style is inspired by the graphic novel series Les Cités Obscures (also known as Cities Of The Fantastic or De Duistere Steden) by Schuiten and Peters. To get an idea of their style, have a look at these beautiful images. To a lesser degree it is also inspired by the Rork series by Andreas (picture).
The main reason to do this style is that I love classical architecture. I haven't done a lot of 3D modelling recently and this kind of stuff is one of my favourite things to model so I'd love to get back to that. The biggest problems with this style are that the link with Cello Fortress isn't very clear, and that it might distract from what the game is all about: the live cello. So the main reason to do this style is that I'd enjoy making it so much.
As concept art I've made some basic environments in 3dsmax and even rendered a video as if it were the game:
Click for high resolution
Click for high resolution
Pros
Cons
This style is a lot simpler. It is mostly about big, untextured polygons. It has a rough rook and most of the potential beauty of this style comes from the lighting. Using a combination of pre-baked lightmaps and some simple tricks I think I can achieve a global illumination-look as in this image.
A big benefit of this style is that is does not distract from the gameplay. Cello Fortress is such a weird concept that I often need to explain quite a lot to the audience and this style won't distract from the core. It also helps that the gameplay will remain very readable under poor lighting conditions: I often perform with Cello Fortress at festivals and it is not rare to have a beamer projection on a rough wall with too much environment light. Such conditions make the game look a lot less bright and crisp than a normal gaming environment.
Click for high resolution
Pros
Cons
Why am I not sure which style to choose? The Surreal Architecture style is much more fun to make and would stand out more, but it just doesn't seem like the best choice for the game. It has little to do with the rest of the concept and would distract from what it's all about: the live cello performance.
Which do you think I should make, and why?
I've also added the pros and cons of each style as I see them. Several are just my personal taste so let me know in the comments if you disagree.
"Surreal Architecture" style
The basic idea of this style is that you travel through a world of surreal architecture. The surrealism is of the subtle sort: on first sight it might look like normal classical architecture, but if you stop and think for a second you realise this cannot be: buildings are too big and repetitive, it makes no sense to have a city with nothing but church towers, and why is there an area with giant organ pipes?
This style is inspired by the graphic novel series Les Cités Obscures (also known as Cities Of The Fantastic or De Duistere Steden) by Schuiten and Peters. To get an idea of their style, have a look at these beautiful images. To a lesser degree it is also inspired by the Rork series by Andreas (picture).
The main reason to do this style is that I love classical architecture. I haven't done a lot of 3D modelling recently and this kind of stuff is one of my favourite things to model so I'd love to get back to that. The biggest problems with this style are that the link with Cello Fortress isn't very clear, and that it might distract from what the game is all about: the live cello. So the main reason to do this style is that I'd enjoy making it so much.
As concept art I've made some basic environments in 3dsmax and even rendered a video as if it were the game:
Click for high resolution
Click for high resolution| Previz video of the Surreal Architecture style. |
Pros
- More unique and notable
- Lots of fun to make
- Very close to me as a person
Cons
- Lots of work
- Distracts from game's core (the live cello)
- Gameplay less readable for players
- Link between visuals and gameplay less clear
- Needs serious optimisation for good framerate
- Doesn't fit style of existing vehicle and turret art very well
- Not entirely happy with this concept art yet
"Rough Polygons" style
This style is a lot simpler. It is mostly about big, untextured polygons. It has a rough rook and most of the potential beauty of this style comes from the lighting. Using a combination of pre-baked lightmaps and some simple tricks I think I can achieve a global illumination-look as in this image.
A big benefit of this style is that is does not distract from the gameplay. Cello Fortress is such a weird concept that I often need to explain quite a lot to the audience and this style won't distract from the core. It also helps that the gameplay will remain very readable under poor lighting conditions: I often perform with Cello Fortress at festivals and it is not rare to have a beamer projection on a rough wall with too much environment light. Such conditions make the game look a lot less bright and crisp than a normal gaming environment.
Click for high resolutionPros
- Very readable and understandable for players
- Looks good with crappy beamers on bumpy walls
- Faster to make
- Higher framerate
- Fits style of existing vehicle and turret art
Cons
- Less original / notable
- Not as much fun to make
- Strong shadows on the floor might be too dark but are crucial for this look
Why am I not sure which style to choose? The Surreal Architecture style is much more fun to make and would stand out more, but it just doesn't seem like the best choice for the game. It has little to do with the rest of the concept and would distract from what it's all about: the live cello performance.
Which do you think I should make, and why?
Wednesday, 19 August 2015
Cello Fortress micro vlog #1: Big Chord Attack
I've added a new cello attack to Cello Fortress! Check this little video for a demo and explanation. :)
Sunday, 16 August 2015
3D printing Captain August
To use a 3D model for 3D printing it usually needs to be altered quite a bit, since 3D printing adds a bunch of additional requirements that rendering and games don't care about. I've recently done this for the first time so today I would like to explain the process and show the result.
Let's first have a look at the result:
Click for high resolution
I used a model I made in 2007 of Captain August, a webcomic that ran until 2010. The author of Captain August is a friend of mine, Roderick Leeuwenhart, and I made this 3D print as a birthday gift for him. Awesomenauts players might be familiar with Roderick's work as a writer: he wrote the voice scripts for a bunch of the latest additions to Awesomenauts, including Ksenia, Rocco and the Wildlife Documentary Announcer. Roderick also writes books: he wrote the "Pindakaas en Sushi" series. This title means "Peanut Butter and Sushi", which must be a delicious combination since I personally came up with the name. ^_^
Click for high resolution
To 3D print a model it needs to be one mesh without intersecting polygons, and the mesh needs to be without holes. When modelling for normal rendering geometry is often a lot of interesting objects and this mesh is no exception. The arms stick through the body, the eyes through the head, etc. To fix this I filled all the holes in all the individual objects by hand, and then used the boolean union tool to combine all the objects into one mesh and get rid of all the intersections. This crashed a lot because of the high polycounts (and probably also because I use the ancient 3dsmax 2009), but after a bunch of tries it worked and I got a usable model.
For the 3D printing I used Shapeways, a company specialised in 3D printing on demand with all kinds of different materials. They even do expensive stuff like silver, but that wasn't intended here.
I uploaded my 3D model into their system to see whether it would accept it. Shapeways runs a lot of automatic tests to find problem areas and it found a bunch that I had to fix. The biggest thing to look out for is whether walls and wires are not too thin. 3D printers can print fine details, but those might not be strong enough. The limits depend on the material and I suppose also the manufacturing process. With the Color Sandstone material I wanted to use, details cannot be smaller then 3mm (there are some further details to this, check the Shapeways site for more info).
In this case I had to fix things like the long pointy nose and the fingers. The fix was rather easy: I just made them thicker, and in case of the nose I also cut off the thinnest part at the end. I performed the fixes on the original model and then redid the boolean union step (including the crashes).
A bit more subtle is that the model needs to be balanced and not snap. Shapeways describes this as the "Sandcastle Rule: if this structure was made of wet sand, would it break?" However, exactly what the limits are is unclear, so I had no idea how far I could go. To be on the safe side I just made the legs and arm a lot thicker and asked Shapeways whether it would work. Within two days they had a look and emailed it would be fine. The model indeed worked out well so apparently this was enough.
3D printers cannot interpolate normals, so polygon smoothing does not work for them. This means that if you make something for 3D printing, you need to turn off all surface smoothing. If the model is not smooth enough at that point, you need to add polygons to make it smoother. In this case I was lucky: the Captain August model was made entirely through low-poly modelling with meshsmooth in mind. I could just increase the number of meshsmooth iterations to get more polygons and thus smoother surfaces. The end result is around 200,000 triangles.
To do a colour model Shapeways wants either a texture or vertex colours. Since my 3D model is mostly just flat coloured parts I made a quick texture with those colours and that's it.
This is one aspect where I think I could have done a better job: since notches and details are so tiny on a figurine they don't get the shading and sharp shadows that a full-sized model would and thus are less visible. A Warhammer model painter once told me you need to paint the lighting to compensate for this. I didn't think of that for Captain August and I think he might have looked better had I done this. For example, I could have made the insides of the creases a bit darker.
Shapeways does a lot of different materials, at very different price points. I wanted a full-colour figurine and didn't want to pay too much so I went for the Color Sandstone material. This is an interesting material: as the name suggests it looks like sand, but it is really a hard material.
From up close this material looks really weird. I wonder whether it was the inspiration for the strange material of the character Joy in Pixar's brilliant new movie Inside Out. It looks a bit similar. Looking at this concept art it probably wasn't, but I couldn't resist an excuse to mention how awesome Inside Out is (yes, I know, I'm a Pixar fanboy).
An interesting aspect of most current 3D printing techniques is that they print in layers. If you look closely, you can often still see those layers. In this model this is especially noticeable at the top of the head and in the wood. My wood mesh has a noise applied to it to make it look less flat. In the 3D print this generates unintended layer patterns that actually look pretty cool. However, in some spots it looks a bit too much like a map of terrain heights.
It turned out to be surprisingly difficult to make good sharp pictures of an object this small. I tried several lenses and lighting conditions to be able to make sharp pictures. I also tried a bathtub trick that I heard about somewhere: I put the figurine in an empty bathtub, giving an exciting all-white background. Pity the lighting conditions in my bathroom were pretty bad so these photos aren't as good as hoped. Still, funny idea.
To conclude this blogpost, here are a bunch of pictures of Captain August under several angles:
Click for high resolution
I'd love to do more art for 3D printing at some point, but for the moment the price of the actual 3D printing is just too high to do just for the fun of it. I'll first have to look for a good excuse to try this again. Maybe another birthday or something? ^_^
Let's first have a look at the result:
Click for high resolutionI used a model I made in 2007 of Captain August, a webcomic that ran until 2010. The author of Captain August is a friend of mine, Roderick Leeuwenhart, and I made this 3D print as a birthday gift for him. Awesomenauts players might be familiar with Roderick's work as a writer: he wrote the voice scripts for a bunch of the latest additions to Awesomenauts, including Ksenia, Rocco and the Wildlife Documentary Announcer. Roderick also writes books: he wrote the "Pindakaas en Sushi" series. This title means "Peanut Butter and Sushi", which must be a delicious combination since I personally came up with the name. ^_^
Click for high resolutionTo 3D print a model it needs to be one mesh without intersecting polygons, and the mesh needs to be without holes. When modelling for normal rendering geometry is often a lot of interesting objects and this mesh is no exception. The arms stick through the body, the eyes through the head, etc. To fix this I filled all the holes in all the individual objects by hand, and then used the boolean union tool to combine all the objects into one mesh and get rid of all the intersections. This crashed a lot because of the high polycounts (and probably also because I use the ancient 3dsmax 2009), but after a bunch of tries it worked and I got a usable model.
For the 3D printing I used Shapeways, a company specialised in 3D printing on demand with all kinds of different materials. They even do expensive stuff like silver, but that wasn't intended here.
I uploaded my 3D model into their system to see whether it would accept it. Shapeways runs a lot of automatic tests to find problem areas and it found a bunch that I had to fix. The biggest thing to look out for is whether walls and wires are not too thin. 3D printers can print fine details, but those might not be strong enough. The limits depend on the material and I suppose also the manufacturing process. With the Color Sandstone material I wanted to use, details cannot be smaller then 3mm (there are some further details to this, check the Shapeways site for more info).
In this case I had to fix things like the long pointy nose and the fingers. The fix was rather easy: I just made them thicker, and in case of the nose I also cut off the thinnest part at the end. I performed the fixes on the original model and then redid the boolean union step (including the crashes).
A bit more subtle is that the model needs to be balanced and not snap. Shapeways describes this as the "Sandcastle Rule: if this structure was made of wet sand, would it break?" However, exactly what the limits are is unclear, so I had no idea how far I could go. To be on the safe side I just made the legs and arm a lot thicker and asked Shapeways whether it would work. Within two days they had a look and emailed it would be fine. The model indeed worked out well so apparently this was enough.
3D printers cannot interpolate normals, so polygon smoothing does not work for them. This means that if you make something for 3D printing, you need to turn off all surface smoothing. If the model is not smooth enough at that point, you need to add polygons to make it smoother. In this case I was lucky: the Captain August model was made entirely through low-poly modelling with meshsmooth in mind. I could just increase the number of meshsmooth iterations to get more polygons and thus smoother surfaces. The end result is around 200,000 triangles.
To do a colour model Shapeways wants either a texture or vertex colours. Since my 3D model is mostly just flat coloured parts I made a quick texture with those colours and that's it.
This is one aspect where I think I could have done a better job: since notches and details are so tiny on a figurine they don't get the shading and sharp shadows that a full-sized model would and thus are less visible. A Warhammer model painter once told me you need to paint the lighting to compensate for this. I didn't think of that for Captain August and I think he might have looked better had I done this. For example, I could have made the insides of the creases a bit darker.
Shapeways does a lot of different materials, at very different price points. I wanted a full-colour figurine and didn't want to pay too much so I went for the Color Sandstone material. This is an interesting material: as the name suggests it looks like sand, but it is really a hard material.
From up close this material looks really weird. I wonder whether it was the inspiration for the strange material of the character Joy in Pixar's brilliant new movie Inside Out. It looks a bit similar. Looking at this concept art it probably wasn't, but I couldn't resist an excuse to mention how awesome Inside Out is (yes, I know, I'm a Pixar fanboy).
An interesting aspect of most current 3D printing techniques is that they print in layers. If you look closely, you can often still see those layers. In this model this is especially noticeable at the top of the head and in the wood. My wood mesh has a noise applied to it to make it look less flat. In the 3D print this generates unintended layer patterns that actually look pretty cool. However, in some spots it looks a bit too much like a map of terrain heights.
It turned out to be surprisingly difficult to make good sharp pictures of an object this small. I tried several lenses and lighting conditions to be able to make sharp pictures. I also tried a bathtub trick that I heard about somewhere: I put the figurine in an empty bathtub, giving an exciting all-white background. Pity the lighting conditions in my bathroom were pretty bad so these photos aren't as good as hoped. Still, funny idea.
To conclude this blogpost, here are a bunch of pictures of Captain August under several angles:
Click for high resolutionI'd love to do more art for 3D printing at some point, but for the moment the price of the actual 3D printing is just too high to do just for the fun of it. I'll first have to look for a good excuse to try this again. Maybe another birthday or something? ^_^
Sunday, 9 August 2015
Why adding multiplayer makes game coding twice as much work
Most gamers and reviewers these days expect almost any game to have online multiplayer. What they might not realise (or not care about), is that adding online multiplayer makes a game twice as much work to program. Most programmers who build this for the first time hugely underestimate how much work it really is. For those who have never made an online multiplayer game, here are some of the reasons why it doubles the programming effort needed.
Before I start, of course note that the real complexity of building multiplayer depends on the game. Adding a multiplayer match-3 minigame to Mass Effect probably wouldn't be much work compared to the main game, but that isn't realistic: big, complex games usually also have big, complex multiplayer features. Roughly doubling the time it takes to program a game when multiplayer is added is in most cases a good guideline.
Latency
The basic cause of all multiplayer complexities, is that it takes time for a message to travel from one computer to another. This might take anywhere between a few milliseconds and a few seconds. Whenever you need to know something about another player, you always have to take into account that you don't know when the answer will come. To make things worse, it's impossible to know exactly how long any specific messages takes and latency might vary wildly between packets.
Gameplay synchronisation
All players need to have the same view of the game world. When things happen on one computer, packets need to be sent to make sure all computers know about it. This adds a lot of complexity to an otherwise simple game, because the game suddenly needs to be able to put all the information about the game in packets and send those over the internet. And what to do if we want smooth animations while some packets take way longer to travel over the internet than other packets?
Waiting
In a normal game, when you want to start a match, you just do so. In a multiplayer game, computers first need to talk about that to make sure all computers go into the game together. Since sending messages takes time, you need to wait for answers to come back. But what if a message takes longer than expected? Is it indeed coming later and should we just wait, or was the other computer suddenly turned off and is the reply never coming? Basically, any communication you do needs a timer to keep track of how long you are waiting and to cancel communications if the answer takes too long. And, also important: you need to handle if the message unexpectedly comes in after you decided to continue and not wait for it any more!
Gameplay balancing
All the other topics in this list are about tech, but of course game design for a multiplayer game is also really complex, especially in the balancing department. Our game Awesomenauts now features 22 characters and a thousand upgrades, and more are underway. What if some very specific combination of characters and upgrades is way too powerful?
Even with thousands of hours of balance testing you can still be certain further balance issues will be found once your game launches. Even Blizzard, with their extensive beta periods, never manages to get balance completely right at launch. If your game involves any kind of balance, then be prepared to spend ages getting it right, and more ages to improve it after launch.
Bandwidth
Modern internet connections can handle lots of data, but not everyone has such fast internet, so any commercial game needs to be able to run on low bandwidth. Most games seem to settle for something around 10 to 20 kilobytes per second as the minimum bandwidth required to play the game. Awesomenauts is no exception. Updating dozens of characters lots of times per second without using way more bandwidth than that requires some really smart optimisation tricks.
Scalability
If your game uses any kind of servers, then those better be prepared for any number of players. What happens if all of a sudden a thousand players all try to join matchmaking? Writing scalable server code is incredibly difficult. Testing it is a challenge since you can't easily get thousands of people to run your game simultaneously, especially before launch.
With Awesomenauts we once had a free week in which the concurrent player count went from 1,000 to over 12,000 within 24 hours. If your netcode and servers can't handle success, then you won't have it. One workaround for this problem is to not have servers of your own at all: Awesomenauts launched using only the services that Sony/Microsoft/Valve provide. Since those are scalable, so was Awesomenauts. I expect that if it had been 100,000 instead of 12,000 it would still have worked, simply because Valve's system are used to much more. Still, we spent a lot of time before launch analysing and testing our code to make sure it really was as scalable as we thought.
Invites
One particular topic that may seem like a detail, but turns out to be horrible, is inviting people. On modern platforms like Xbox, Playstation and Steam players can invite their friends to play with them. The complexity here is that these platforms allow players to accept invites from basically anywhere. Not just while in the menu or while playing another match, but also during a loading screen, during the intro cinematic, from outside the game or even while joining a game based on an earlier invite!
To give a nice example of something that could happen on the Xbox 360: while a player is in the loading screen, another player on the same console might pick up the second controller, log in with another account, and accept an invitation to play with someone online. Now the first player's match should quit as soon as the loading screen ends, the second player should become the Active Player and should join his match. This particular situation is really cumbersome to handle, and it becomes way worse when you realise there is an enormous amount of similarly weird combinations of events and they all need to be handled correctly.
Console requirements
Which leads me to the final topic here. Modern consoles have long lists of requirements that games need to abide by to be allowed to launch, and this list gets a lot longer if your game has online multiplayer. If any of the weird combinations above goes wrong in the game then Sony, Microsoft or Nintendo might refuse to release it until it's fixed. Of course, console manufacturers are right to demand quality for all the games that launch on them, but it does take a lot of extra work to build.
Debugging
Just starting the game to test your code isn't good enough for an online multiplayer game. Instead, you need to start several instances of the game, make them connect to each other, and then test whatever you just programmed. Also, the number of possible combinations of events explodes in online multiplayer situations, so not only does testing become much more cumbersome, it also requires many more tests.
I could easily have added dozens of other items to this list, but I think you already get a clear picture of how complex creating a multiplayer game really is. Many programmers think they can add online multiplayer to their game in just a month or two, but for a game of significant size it generally takes way longer than that, especially the first time you do it!
Before I start, of course note that the real complexity of building multiplayer depends on the game. Adding a multiplayer match-3 minigame to Mass Effect probably wouldn't be much work compared to the main game, but that isn't realistic: big, complex games usually also have big, complex multiplayer features. Roughly doubling the time it takes to program a game when multiplayer is added is in most cases a good guideline.
Latency
The basic cause of all multiplayer complexities, is that it takes time for a message to travel from one computer to another. This might take anywhere between a few milliseconds and a few seconds. Whenever you need to know something about another player, you always have to take into account that you don't know when the answer will come. To make things worse, it's impossible to know exactly how long any specific messages takes and latency might vary wildly between packets.
Gameplay synchronisation
All players need to have the same view of the game world. When things happen on one computer, packets need to be sent to make sure all computers know about it. This adds a lot of complexity to an otherwise simple game, because the game suddenly needs to be able to put all the information about the game in packets and send those over the internet. And what to do if we want smooth animations while some packets take way longer to travel over the internet than other packets?
Waiting
In a normal game, when you want to start a match, you just do so. In a multiplayer game, computers first need to talk about that to make sure all computers go into the game together. Since sending messages takes time, you need to wait for answers to come back. But what if a message takes longer than expected? Is it indeed coming later and should we just wait, or was the other computer suddenly turned off and is the reply never coming? Basically, any communication you do needs a timer to keep track of how long you are waiting and to cancel communications if the answer takes too long. And, also important: you need to handle if the message unexpectedly comes in after you decided to continue and not wait for it any more!
Gameplay balancing
All the other topics in this list are about tech, but of course game design for a multiplayer game is also really complex, especially in the balancing department. Our game Awesomenauts now features 22 characters and a thousand upgrades, and more are underway. What if some very specific combination of characters and upgrades is way too powerful?
Even with thousands of hours of balance testing you can still be certain further balance issues will be found once your game launches. Even Blizzard, with their extensive beta periods, never manages to get balance completely right at launch. If your game involves any kind of balance, then be prepared to spend ages getting it right, and more ages to improve it after launch.
Bandwidth
Modern internet connections can handle lots of data, but not everyone has such fast internet, so any commercial game needs to be able to run on low bandwidth. Most games seem to settle for something around 10 to 20 kilobytes per second as the minimum bandwidth required to play the game. Awesomenauts is no exception. Updating dozens of characters lots of times per second without using way more bandwidth than that requires some really smart optimisation tricks.
Scalability
If your game uses any kind of servers, then those better be prepared for any number of players. What happens if all of a sudden a thousand players all try to join matchmaking? Writing scalable server code is incredibly difficult. Testing it is a challenge since you can't easily get thousands of people to run your game simultaneously, especially before launch.
With Awesomenauts we once had a free week in which the concurrent player count went from 1,000 to over 12,000 within 24 hours. If your netcode and servers can't handle success, then you won't have it. One workaround for this problem is to not have servers of your own at all: Awesomenauts launched using only the services that Sony/Microsoft/Valve provide. Since those are scalable, so was Awesomenauts. I expect that if it had been 100,000 instead of 12,000 it would still have worked, simply because Valve's system are used to much more. Still, we spent a lot of time before launch analysing and testing our code to make sure it really was as scalable as we thought.
Invites
One particular topic that may seem like a detail, but turns out to be horrible, is inviting people. On modern platforms like Xbox, Playstation and Steam players can invite their friends to play with them. The complexity here is that these platforms allow players to accept invites from basically anywhere. Not just while in the menu or while playing another match, but also during a loading screen, during the intro cinematic, from outside the game or even while joining a game based on an earlier invite!
To give a nice example of something that could happen on the Xbox 360: while a player is in the loading screen, another player on the same console might pick up the second controller, log in with another account, and accept an invitation to play with someone online. Now the first player's match should quit as soon as the loading screen ends, the second player should become the Active Player and should join his match. This particular situation is really cumbersome to handle, and it becomes way worse when you realise there is an enormous amount of similarly weird combinations of events and they all need to be handled correctly.
Console requirements
Which leads me to the final topic here. Modern consoles have long lists of requirements that games need to abide by to be allowed to launch, and this list gets a lot longer if your game has online multiplayer. If any of the weird combinations above goes wrong in the game then Sony, Microsoft or Nintendo might refuse to release it until it's fixed. Of course, console manufacturers are right to demand quality for all the games that launch on them, but it does take a lot of extra work to build.
Debugging
Just starting the game to test your code isn't good enough for an online multiplayer game. Instead, you need to start several instances of the game, make them connect to each other, and then test whatever you just programmed. Also, the number of possible combinations of events explodes in online multiplayer situations, so not only does testing become much more cumbersome, it also requires many more tests.
I could easily have added dozens of other items to this list, but I think you already get a clear picture of how complex creating a multiplayer game really is. Many programmers think they can add online multiplayer to their game in just a month or two, but for a game of significant size it generally takes way longer than that, especially the first time you do it!