Saturday, 28 February 2015

Luck and success in the indie business

Luck is an important part in the success or failure of any game studio. Why do some studios succeed while so many others never make a significant amount of money? Regardless of how good your theories are on what makes a successful business, you can never know for sure which games are going to be a hit. Games are entertainment and hit-driven and thus their success is inherently unpredictable. Luck cannot be controlled, but you can help it a bit by making the right choices. Looking at what many starting indies are doing right now, I think a lot of them don't think about luck enough. Here are some of my thoughts on the matter.

The success of a game is determined pretty much equally by three factors: the game, marketing and luck. Marketing and luck are just as important as the game you are making. If you do not market your game, then no one will know it and thus only a LOT of luck can make it a success. Similarly, if your game is not good enough, then it is also very unlikely to sell well.

While luck cannot be controlled, you can make such decisions that you need as little luck as possible. If you make an awesome game, do really good marketing and release it on the right platforms, then your chances are actually pretty good. But luck always remains a factor. Even the very best games can sometimes fail, and even the worst games sometimes become a hit. Anyone remember Psychonauts? It is considered a classic now, but sold hardly any copies at the time. On the other hand Flappy Bird was an enormous success, despite how crappy that game actually is.

When making your business decisions it is of course a good idea to look at what other companies are doing. What games sell, and why? However, it is a big mistake to attach too much importance to the outliers. Lots of people look at Minecraft and try to copy what it did, hoping to achieve similar success. But Minecraft is a one-in-a-million outlier. Of course Minecraft has some great mechanics, but it also required an enormous amount of luck to become that successful. The chances that you can achieve something even remotely similar are practically zero.

The same goes for Angry Birds and Candy Crush. It is not because of great talent that these games became such huge successes: they are well-made for sure, but there are tons of other games of similar type and quality that somehow did not become such hits. Before Angry Birds and Candy Crush became a success, there was no way anyone could have guessed that these would be the titles to become such big hits.

A strategy some studios use is to not make one big game, but instead make lots of small games and then hope one of those becomes as successful as Angry Birds. The reasoning behind this strategy seems to make sense: every game you release is a roll of the dice. Releasing more games gets you more rolls of the dice, increasing your chance at success.

I do not believe this really works. I think a single really good game has a much bigger chance at becoming a success than dozens of lesser games combined. Of course it is impossible to prove a theory like this, but I believe that a better game has an enormously larger chance of becoming a hit. If you can raise your game's quality from a 7 to an 8, or from an 8 to a 9, then you stand a much, much, much better chance. If you can somehow make a game that scores a 9.5 on Metacritic, then you can be almost certain it will sell like crazy. Even then you can never be sure though!

For this same reason I also do not believe in the 'fail early' strategy that some companies use, especially in combination with Early Access or free to play. The idea of 'fail early' is to release your game when it is only half of what it could be, and then see how well it does. If it does well, then you continue development and make it better. Otherwise you just drop the game and make something else. Like above, this allows a company to make more games and thus get more rolls of the dice. I do not believe that this works: the chance of the game becoming a success is infinitely better if the game itself is much better. That game that is dropped because the half-finished version did not sell well might have become a hit if it were actually developed into a good game, instead of a buggy or too small one.

(Note that I do think Early Access and soft launches can sometimes work, but for other reasons: they provide tons of testing and user feedback and it might also help fund the rest of development.)

'Chance' is also why big publishers can be relatively stable over time: they release a lot of big games, so the chance of them all failing is really small. This is the benefit of size, and it is a benefit that indie companies generally cannot have.

A good way to get more rolls of the dice is porting. If your game failed on one platform, it might still do really well on another, especially if that other platform has a different audience.

We have experienced this ourselves: Swords & Soldiers was a hit on WiiWare back in 2009. A year later we released an HD version of the game on Playstation 3, with added online multiplayer, but this sold very poorly. Then we released the game on Steam, and there it again sold really well. In hindsight one can come up with theories on why it failed on Playstation 3, but beforehand we had no idea. Every port is a new roll of the dice. Ports are much cheaper and faster to develop than completely new games, so porting is in general a good idea.

Luck cannot be controlled, but you can influence it. I would like to finish this blogpost with a great example of this: our own Awesomenauts. Awesomenauts is a big hit with around two million copies sold. Its success is partially due to its excellent release timing, which was pure luck.

Awesomenauts is a complex game to communicate. During the three years it took us to make the game, League of Legends appeared and became a gigantic hit. Suddenly our marketing became really simple: Awesomenauts is platforming League of Legends! This is a message everyone understood and that immediately had people intrigued with this interesting combination of elements. This helped our sales enormously.

There is no way we could have planned for this: the game took three years to develop so at the beginning we had no idea what would happen in the meanwhile. This might make one think that the success of Awesomenauts was all luck no skill, but this not the case at all. More like the opposite! Awesomenauts has a unique concept, is large for an indie game and is high quality. We spent a lot of time on marketing and have so far released the game on four different platforms, giving us four rolls of the dice. All of these combined mean that our chances were pretty good to begin with. Still the game could have failed, and luck was the final push that we needed.

There are two ways to improve your luck: get more rolls of the dice by having more releases, or improve the chance of each roll by having better releases. I personally think each release should be the best possible, by making a remarkable game with good marketing, a fitting payment model and on the right platforms. You can also handle luck by finding an investor who is willing to invest enough to make several games, so that you get more rolls of the dice. There are many possible approaches and it is important to think about luck and make sure your chances are as good as possible.

This is the first post in a short series on the state of the indie business. In the coming weeks I will alternate between these and regular development posts. The next one in the series comes in a few weeks and will hopefully stir up some discussion, as I will be so presumptuous as to list what I think many indies today are doing wrong.

Sunday, 11 January 2015

A tool for analysing colour schemes

During the Christmas vacation I read the fantastic book Color and Light: A Guide for the Realist Painter by James Gurney. It contains a number of really interesting ideas about colour schemes, so I was curious how these relate to existing games. I was especially curious about Proun: when creating the art for this game I did not know anything practical about colour theory. I just tweaked the colours until they looked good. Apparently this was successful, since reviewers were extremely positive about Proun's visuals and vibrant colours. How then do the colour schemes in Proun relate to Gurney's colour theories? To analyse this I have developed a simple little tool that visualises the colour scheme in an image. You can download the tool and source further in this post. So let's have look: what are Gurney's ideas and how do they relate to Proun's art?

The concept I found most interesting in Gurney's book is gamut mapping. To understand this we first need to know the colour wheel. This shows all the colours in a circle. Towards the inside the colours desaturate towards grey. This means that the strongest colours are at the outside. The colour circle is independent of light/dark: each of those colours can still be made lighter or darker.

The idea is that you pick a few colours and only use the colours that can be mixed using those colours. This limits the number of colours that can be used in an artwork. Usually one would pick three colours. This creates a triangle on the colour wheel and we can only use the colours inside the triangle. The area of allowed colours is called the "gamut mask".

The big revelation to me is that this means that only the three chosen primary colours can be fully saturated. All other colours will be less saturated since they cannot be on the outer rim of the colour wheel, no matter how bright the chosen primary colours are. This limits the colour usage and keeps an artwork from becoming a "fruit salad" as Gurney calls it.

The colour gamut can even be on just one side of the colour wheel, greatly limiting the colour scheme in an artwork. While normally an artist would need to be careful not to use colours too much, when using a limiting gamut it becomes possible to aim for using the brightest colours allowed within the gamut and still achieve a harmonious whole.

I suppose experienced artists might have many other tricks to achieve good colour schemes, and there is probably some really good art that totally doesn't fit what Gurney explains. Nevertheless the colour gamuts seem like a very sensible and useful tool to me. This made me curious: how do the colour schemes in Proun relate to them?

To be able to exactly analyse the colour schemes of existing art I have hacked together a little C# tool: Joost's Colour Wheel Visualiser. It simply loads an image (JPG or PNG) and shows which parts of the colour wheel are used in that image. You can download the tool (including source code) here:

Download Joost's Colour Wheel (24kB)
(Note that a recent version of .NET is needed to run it.)

Now that we have this tool, what do Proun's colour schemes look like? Let's have a look.

Surprisingly, it turns out that most of these form quite clear triangles. Apparently while searching for colours that look good together I accidentally used Gurney's theories quite exactly! I happen to even vary between the schemes he gives as examples: some gamuts are mostly on one side of the colour wheel, while others are quite exact complementary schemes.

One thing I was never really satisfied with in Proun is the colours of the opponents. Those are only seen all together at the very beginning of a race and I always felt like they didn't look good together. When analysing those colours using my Colour Wheel Visualiser it quickly becomes clear why. As you can see in the image below their colours are random splotches on the colour wheel, unrelated to the other colours in the image.

I think I might have been able to fix this problem by using different colours for the opponents depending on the track, so that I would have been able to match their colours to each track's colour scheme. Next time, Gadget!

I also tried my tool on screenshots from Awesomenauts, which was designed by the Ronimo art team. In the images below you can see that the colour scheme is all over the place. It really is an explosion of colour, as is fitting for the over-the-top eighties themes of Awesomenauts. Nevertheless you can see that even in the top image the colour scheme ignores large parts of the colour wheel, so even there the colour usage is limited. I think our artists did a great job on the art for Awesomenauts, so this is a good example of how not all good art needs to keep to Gurney's colour gamuts.

Here are the colour schemes for a number of other games:

By the way, note how in all the screenshots analysed in this blogpost Proun is the only game that uses the purple/pink/magenta area. This might be accidental, but it seems like this part of the colour wheel is used quite rarely in games.

I am going to try to use Gurney's ideas in the art for Cello Fortress. One particular challenge I see there is that the player's tanks should be immediately recognisable. I currently make the tanks stand out by using extremely bright colours for the tanks, but this will be difficult when using a limiting gamut according to Gurney's rules. I am quite curious how that ends up. If anyone has any tips on how to tackle this, then please let me know in the comments!

Sunday, 4 January 2015

What most young programmers need to learn

In the past 7.5 years I have supervised over a dozen programming interns at Ronimo and have seen hundreds of portfolios of students and graduates. In almost all of those I saw the same things that they needed to learn. One might expect that I think they need to learn specific techniques, algorithms or math, or other forms of specific knowledge. And of course they do, but in my opinion that is never the main thing. The main thing they need to learn is self discipline. The discipline to always write the clearest code you can, the discipline to refactor code if it becomes muddy through changes later in development, the discipline to remove unused code and add comments.

Most of the time I spend supervising programming interns is spent on these topics. Not on explaining advanced technologies or the details of our engine, but on making them write better code in general. I always ask applicants what they think is important in being a good programmer and they usually answer that code should be clear, understandable and maintainable. That is indeed what I want to hear, but it is very rare for a young programmer to actually consistently follow through with that.

Keeping this in mind requires self discipline, because it means not stopping "when it works". If all the variables would have the wrong name the code could still function perfectly, but the code would be super confusing. The step from functional code to clear code brings very little reward in the short term: it worked already and after cleaning it up it still works. That is why discipline is required to take this step. That is also why doing an internship is so useful: a good supervisor is vigilant on code quality (even though the definition of "good code" might of course differ per programmer) and thus forces the intern or junior to always take that next step.

Let me give a few examples of the kinds of things I often see in code written by starting programmers:

Liar functions/variables/classes

These are functions, classes or variables that do something else than their name suggests. Their name is a lie. It is very obvious that names should be correct, but to my surprise it is quite common for names to be completely off.

An example I recently encountered in code written by a former intern was two classes: EditorGUI and EditorObjectCreatorGUI. This is code that handles the interface in our editors. To my surprise it turned out that the code that handled the button for creating new objects was in EditorGUI, while EditorObjectCreatorGUI only handled navigating through different objects. The exact opposite of what the naming suggests! Even though the code was relatively simple, it took me quite a while to understand it, simply because I started with a completely wrong assumption based on the class names. The solution in this case is really simple: rename EditorObjectCreatorGUI to EditorObjectNavigationGUI and it is already much, much more understandable.

This is something I see a lot: names that are simply incorrect. I think this often happens because code evolves while working on it. When the name was chosen it might have been correct, but by the time the code was finished it had become wrong. The trick is to constantly keep naming in mind. You have to always wonder whether what you are adding still fits the name of the function or class.

Muddy classes

Another problem I see is muddy classes: classes that do a lot of unrelated things. Again this is something that happens as you keep working on the same code. New features are added in the easiest spots and at some point classes become bloated with all kinds of unrelated behaviour. Sometimes the bloating is not even in the size of the classes: a class might be only a few hundred lines but still contain code that does not belong there.

An example of how this can happen is if for some reason a GUI class needs to analyse what textures are available (maybe because there is a button to select a texture). If the GUI class is the only class that needs the results of this analysis, then it makes sense to do that in the GUI class. However, then some totally unrelated gameplay class for some reason also needs that info. So you pass the GUI class to that gameplay class to query the texture information. At this point the GUI class has grown to be something more: it is also the TextureAnalyser class. The solution is simple: split off the TextureAnalyser class into a separate class that can be used by both the GUI class and the gameplay class.

The general rule of thumb to avoid this problem is to always wonder: does the functionality that I am adding here still fit the name of the class? If not, then the class either needs to be renamed, or it needs to be split into separate classes or the code needs to go into a different class.

It is usually a Bad Smell if you cannot come up with a fitting name for your class. If you cannot describe what a class does in its name, then maybe what it does is too muddy. It might need to be split into parts that make more sense and can actually be described with a proper name.

Oversized classes

This one is really similar to the muddy classes above: over time more and more is added to a class and it gets bloated. In this case however it all still makes sense to be in one class, but the class simply grows too big. Gigantic classes are cumbersome to work with. Bugs slip in easily as there is a lot of code manipulating the same private member variables, so there are a lot of details one can easily overlook.

Splitting a class that has grown too big is quite boring work. It can also be a challenge if the code in the class is highly intertwined. Add to this that it already works and that fixing it adds no new functionality. The result is again that it requires serious self discipline to split a class whenever it becomes too big.

As a general rule of thumb at Ronimo we try to keep classes below 500 lines and functions below 50 lines. Sometimes this is just not feasible or sensible, but in general whenever a class or function grows beyond that we look for ways to refactor and split it into smaller, more manageable pieces. (This makes me curious: where do you draw the line? Let me know in the comments!)

Code in comments

Almost all sample code that applicants send us contains pieces of code that have been commented out, without any information on why. Is this broken code that needs to be fixed? Old code that has been replaced? Why is that code there? When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code.

Parallel logic and code duplication

Another problem that I often see occurring is to have similar logic in several spots.

For example, maybe the name of a texture gives some information as to what it is intended for, like “”. To know whether a texture can be used for a tree we check the filename to see whether it starts with the word “Tree”. Maybe with the SDK being used we can check that really quickly by just using filename.beginsWith(”Tree”). This code is so short that if we need it in various spots, we can just paste it there. Of course this is code duplication and everyone knows that code duplication should be avoided, but if the code being duplicated is so short, then it is tempting to just copy it instead. The problem we face here is obvious: maybe later the way we check whether a texture is fit for a tree changes. We then need to apply shotgun surgery and fix each spot separately.

A general rule of thumb here is that if code is very specific, then it should not be copied but put in a function. Even if it is super short and calling a function requires more code than doing it directly.

All of the things discussed in this blogpost are really obvious. Most of these things are even taught in first year at university. The challenge is to make the step from knowing them to actually spending the time to always follow through with them, to always keep them in mind. This is why the most important thing that all programming interns learn at Ronimo is not knowledge, but self discipline.

Sunday, 30 November 2014

Proun+ out now on iOS!

On 27 November Proun+ launched on iOS! The first reviews are extremely positive, both from the press and from users. We also got a big feature in the European App Store, so it seems like Apple itself also likes the game. :) Here are some quotes from the reviews and the launch trailer:

"A bright, searingly good twitch racer that takes the fundaments of the genre and builds something staggeringly entertaining on top of them."

"Previously a successful indie release on the PC, it deserves your attention and patience. [...] Throw in a funky jazz based soundtrack and Proun+ has a lot going for it."
4/5 stars

"this self-styled “journey through modern art” exudes an endearing weirdness that sets it apart and nestles it in your brain. Like that off-beat game you used to play, that you’re convinced only you can remember, which you can’t possibly forget."
4.5/5 stars

Proun+ is available in the App Store for iPhone and iPad for $3.99 here.

Saturday, 22 November 2014

Why good matchmaking requires enormous player counts

Good matchmaking is an important part of creating an online multiplayer game. One thing you may not realise is that no matter how you build it, truly good matchmaking requires enormous numbers of players. Awesomenauts often has well over 1,000 people playing the game at the same time, which is very high and successful for an indie game. It certainly sounds like a lot to me, but this is only a fraction of what would be needed to do everything with matchmaking that we would want to do. Today I am going to explain why tens of thousands of concurrent players are needed for truly awesome matchmaking.

Matchmaking has two main goals. The first is to let people play together who will have a good internet connection to each other. We would like to avoid Australians playing together with Europeans because their ping will be very high. High ping decreases the quality of the game experience, especially in a fast and highly competitive game like Awesomenauts. Finding good connections is more complex than simply looking at distance: sometimes you have a worse connection to your neighbour than to someone on the other side of the continent. The internet is just very unpredictable and random when it comes to connection quality.

The second main goal of matchmaking is to let people play together who have similar skill. There is no fun in getting beaten by someone who is way better than you, and n00bstomping gets old really quickly as well.

Now that we know our core goals, let's try to estimate how much 1,000 concurrent players really is. I am going to simplify things and use a lot of assumptions, but I think the ballpark figures are realistic enough to communicate my point.

The first step is to look at how often these players are actually available for matchmaking. An Awesomenauts match takes on average somewhere around 20 minutes, so players are available for matchmaking once every twenty minutes:

1,000 / 20 = 50 players per minute

We don't want to matchmake with people who are too far away, and players are spread all over the globe. Let's say that the average player would have a good enough connection to one third of all players. In reality players are not spread equally, since Awesomenauts is more popular in some countries than in others, and because of time zones. Let's work with that one third though:

50 / 3 = 16.7 players per minute

Next step is skill. Let's say we consider one third of all players to be close enough in skill to make for a fun match:

16.7 / 3 = 5.6 players per minute

AUCH! We are already down from 1,000 concurrent players to only 5.6 suitable players per minute, and this is while looking at only the most basic of assumptions...

For perfect matchmaking I would want to split players further. A common request from Awesomenauts players is to have unranked and ranked multiplayer. If we would add this, the split between these modes would probably not be equal: one mode would likely get more players than the other. Let's assume one third of all players would play one mode, and two thirds would play the other mode. We need to split further from the already small numbers we have because even in unranked matchmaking we still want to match players based on similar skill to create fun matches. This is how few players we would have left in the smallest of the two modes:

5.6 / 3 = 1.9 players per minute

Another common request from the Awesomenauts community is to split pre-mades from solo-queuers. A pre-made is a group of people who form a team by hand in the lobby before the match, while solo-queuers are put together in a team with complete strangers by the matchmaker. Pre-mades potentially have a big advantage because they will likely do much better teamwork. In the ideal case pre-mades would therefore only play against other pre-mades. How many pre-mades there are varies wildly with the skill level of the players (highly skilled players generally play in pre-mades much more). Let's assume that on average one fourth of all players are in a pre-made:

1.9 / 4 = 0.46 players per minute

Since we are talking about perfect matchmaking, let's have another look at our skill-based matchmaking. Above I assumed that one third of all players is a good enough match in skill. In reality the top players are way too much better than the rest to make this ideal. The top 5% of players are an enormous amount better than the top 33% of players. The more precisely we could match based on skill, the better. I think we would need to do at least three times better than we did above for ideal matchmaking:

0.46 / 3 = 0.15 players per minute

I can imagine some more criteria for ideal matchmaking (like supporting more game modes in matchmaking), but I think the point is quite clear already. With 1,000 concurrent players it will take 30 minutes to fill a match! Obviously this is totally unacceptable. Here's a summary of all the criteria I have mentioned so far:

Let's say it is fine to let players wait for two minutes for a match to fill up, bringing us to 0.3 suitable players during the available time for matchmaking. To bring us to the required 6 we would therefore need 6 / 0.3 = 19 times as many concurrent players for good matchmaking. We started with 1,000, so we need 19,000 concurrent players. Of course there is a big daily fluctuation in the number of players (there are fewer players deep in the night and early in the morning), so to also have good matchmaking at the slow hours we would need three times more players still. Thus we would need 58,000 concurrent players at peak for good matchmaking. That probably equals over 5 million unique players each month. Holy cow that is a lot!

When building a multiplayer game it is important to think about this. Ideal matchmaking requires enormous player counts, and if your matchmaking is built assuming such player counts will be there you might make something that works really badly for more realistic numbers. Therefore the ideal matchmaking system is flexible: it brings perfect matchmaking when there are tons of players but also makes the best of a small player count.

Despite all of this we can still make big improvements to the matchmaking system in Awesomenauts. We are aware of this and are therefore rebuilding the entire matchmaking system from the ground up in a much smarter and much more flexible way than is currently in the game. I am sure this will bring a big improvement, but at the same time it is important to have realistic expectations: no matter how well we build our matchmaking, the player count required for 'perfect' matchmaking is unrealistic for all but the few most successful games in the world.

Saturday, 8 November 2014

Using 2D daylight assets to create a night level

Changing the lighting in hand-drawn art is a challenge. While in 3D games you can simply modify the light, there is no such thing when using 2D assets. In our new game Swords & Soldiers II all the level assets have their lighting drawn in. Of course you can ask the artist the redraw the image with different lighting, but that costs a lot of additional time and texture memory. We managed to re-use our daylight textures to create convincing nighttime levels, so today I would like to explain the tricks used to achieve that goal.

Today's post is all about the artistry of Ronimo artist Ralph Rademakers. He uses images drawn by Adam Daroszewski* and Gijs Hermans to decorate the levels in Swords & Soldiers II. Ralph keeps surprising me with the unexpected tricks he manages to pull off with our internal tools.

*By the way, note that Adam works as a freelancer these days. He drew most of the level props in this post and you can see some more of his amazing work here.

There is basically a whole series of tricks that Ralph uses to turn day into night. I'll let the images do most of the talking today:

Even in the night a form of atmospheric perspective can be used: in the video below the smoke in the foreground is much brighter than the smoke in the background to suggest additional depth. When I built the recolouring shaders and tools I never expected them to be used on almost every object in the levels. Also, note how the stars have been made using particles to make them blink and appear in random places for a more lively look.

As a starting point Ralph usually chooses one colour multiplier for all objects in the level. He tweaks the colour per object to make it look exactly right. In the end few objects use the same colour multiplier, but they all started from the same point.

It surprises me how often these gradients are reused. From fog to lights to lens-flares and even just for hiding objects that should not be visible from certain viewpoints. The big downside of this approach is that it results in a lot of overdraw, which is also the main performance bottleneck in Awesomenauts. Good thing modern videocards are so insanely fast...

The lights in the bar below blink to make the scene more dynamic. However, blinking lights attract the eye too much while the focus should be on the gameplay. Therefore the blinking is not between on and off, but between the more subtle slightly-bright and extra-bright. Also note how the blinking lights illuminate the barmaid's arm.

This bar is also a great example of Ralph adding tons of little animating details, like the drunk guy on the roof. Many of those details will likely not be seen by most players, but the total effect of having such a detailed world is very strong, even for players who don't look at it specifically.

As a programmer when thinking about lighting in 2D games I immediately start considering technical solutions. I would look at things like normal maps (very possible in 2D) or automatic rim lighting. However, more creative, art-driven solutions often work much better, especially when creating a visual style with such a painterly look as in Swords & Soldiers II. The simple yet clever techniques Ralph used to create this nighttime level are a great example of this.

Saturday, 25 October 2014

Proun+ gets its first trailer!

We have released the first trailer for Proun+, the biggerbetter Proun that is coming to 3DS, iOS and Android! Proun+ is being made together with Engine Software and will have six new tracks and a completely new soundtrack: more songs and all the songs have now been recorded by real musicians for a much better sound. In this trailer you can hear the new version of one of the old songs and see one of the awesome new levels in action, plus footage from some of the original tracks. I am really hyped for the return of Proun, so I hope you like it!