Sunday, 15 March 2015

What many indies are doing wrong

The indie explosion has finally happened. New indie companies and teams appear every day. At the same time a lot of pessimism has entered the scene: so few indies are actually making money! This is mostly because the market simply isn't big enough to support us all. But I believe another cause is that a lot of indies are all making the same mistakes. Here is what I think many indies are doing wrong.

Before I continue, a little disclaimer: this post is about what I think gives indies the best chance at making a reasonable income from their games. If you don't care about that and just want to have fun making games, then none of this applies.

Too small games

Every day dozens of indie games are released. During big game jams this can even be hundreds during a single weekend. To stand out from this crowd more indies should focus on making larger games. If you and your team spend dozens of man-months on a single game, then that game is much bigger than most competing games. This way you aren't being compared to a dozen games per day, but 'only' a few games per week.

Too many gimmick-games

Lots of indie games are based on a super unique idea that is fun... for exactly five minutes. There are tons of games that purely resolve around some weird gimmick. This trend is fuelled by game jams, since it is often impossible to make more than that in just 48 hours. Such gimmicks can be fun and exciting, and can sometimes grow into larger products like the excellent World Of Goo. But too often they don't grow beyond a simple gimmick.

The true skill of the game designer isn't in coming up with something original, but in turning that original idea into a substantial game that is enjoyable for hours. And no, adding a highscore list to your gimmick-game doesn't solve this: very few people will be triggered enough by that to play longer (even if it does work for a few people who might play your game for dozens of hours to get the best score).

Not enough polish, depth and quality

Very few indie games seem to execute on all fronts. Looking at trailers it is rare to see a game that has interesting, original gameplay and a cool visual style and good animation and good audio and etc. A game can't be excellent if not all aspects are at the very least acceptable. Especially animation seems to be something that few indies get right.


Too many bugs

Many indie games launch with a lot of bugs. Early Access seems to have triggered a trend where bug fixing and polish isn't valued as much any more. It seems like many developers think we only need more features and more content. You might want to reply that Minecraft and DayZ were huge successes despite being really buggy, but this isn't the norm and not an example that should be followed. In general, good games sell better than bad games. Don't make a bad game.

Too small teams

All of the points above have one thing in common: you need to spend more time on a game. This is easier said than done of course. What if a lot of indies joined forces and formed larger teams? Ten people all making a game on their own could combine into ten people making one big game together. Not only does this allow making bigger and better games, but it also fixes the problem that one person can't be good at everything. With a larger team it is possible to have specialists on board, instead of only generalists.

We made our first big release Swords & Soldiers 1 with a team of seven people and spent a whole year on it, full-time. Yes, we were lucky that we released that game in a time when there was hardly any indie competition, but that isn't the only factor. With around 100 man-months spent on it (including interns), Swords & Soldiers 1 was much bigger than most indie releases today. So even in today's crowded market it would stand out at least a little.

To avoid confusion: by "bigger teams" I don't mean 50 people. I mean 5 to 15 people who work on a game full-time for something like 1 to 3 years. That is big for an indie studio but still minuscule compared to triple-A.

Too many side-jobs

A lot of the indies I meet make money through work-for-hire and then spend the remaining time on their indie games. I understand the necessity of this of course, but often it doesn't work. If you work on your game part-time, how are you ever going to spend enough time to make a truly polished game? It is possible of course, but not focussing fully on your main game makes it really difficult.

How to fund development then? For me personally the funding was really simple: I kept living with my mom until Ronimo made enough money to live on. This took a whopping four years! I wasn't the only one living cheaply back then: three of the other founders of Ronimo rented a single apartment together. Had we sought a normal job, each of us would have made enough to get a decent apartment of his own right away. If you really really really want to make it as an indie, you have to be willing to make serious personal sacrifices. (Note that my mom is great, so not being able to move out until I was 26 wasn't that bad.)

Too little focus on the craft

Making games is hard. Programming complex systems is hard, drawing anatomy is hard, designing puzzles is hard. To make good games, you need to hone your craft. This seems obvious yet in the indie scene there is very little emphasis on hardcore creation skills. I saw this recently at the Screenshake indie festival in Belgium: hardly any of the talks were about actual development. Of course there should be room for a conference that focusses on other aspects of indie games, but I do think it exemplifies a trend that the only indie conference of Belgium ignores the craft of making games altogether.

Unity and GameMaker are a big part of this: they have made it possible to make games without serious technical skills. This is great but if you don't have those skills then it is also extremely limiting. Many indies wouldn't be able to make tech that isn't available as a standard Unity plug-in. This limits your possibilities and makes it more likely that you will make something similar to what others are making. Our own game Awesomenauts and my hobby project Cello Fortress wouldn't have been possible without serious tech knowledge of respectively multiplayer and sound programming. Having the skills to make whatever you want opens up enormous possibilities to stand out from all of those who are limited by the standard features of Unity and GameMaker.



No originality

This point pains me greatly. Five years ago being indie was all about being original, expanding what games can be and delivering unique experiences. Today so many people are making pixel-art rogue-likes, voxel sandbox games and platformers-with-a-twist that it seems like 90% of al indie games fall under one of these very specific categories. Not to mention zombies... I think it is super lame that 'indie' is now often the equivalent of unoriginal me-too games. This also means that you are competing with lots of very similar games, decreasing your chances of success greatly.

Of course not everyone is doing the same thing, but too many indies are. There are opportunities elsewhere. For example, Reus and Banished each brought a unique twist to the god-game/management genre, and both sold really well. For some reason hardly any other indies were doing this genre so Reus and Banished easily stood out.



Stand out from the crowd

Luck is always involved in success, but my impression is that if you want to stand a decent chance, you need to have at least one of these:
  • A better game than the competition
  • A game that does something truly new
  • Appeal to an underserved niche audience
  • More marketing budget than the rest (and being pro at using it effectively)

That last one only really applies to big companies with big budgets. I think a company like Supercell simply bought the success of Hay Day and Boom Beach through the massive marketing budget they earned with Clash Of Clans. For an indie, the other three are the reasonable alternatives.

A great example of this is Ori And The Blind Forest, currently a big hit on Steam. Not only is it incredibly polished and beautiful, and thus simply better than most other games, it also serves an underserved niche: big metroidvania 2D platformers are rare. Luck is always involved, but this game had really good chances at becoming the hit it is now.


Don't blindly follow my advice! Instead, figure out your own path and find an original way of doing things. There are a million ways to be an indie and many can work. But please stop all making the exact same games and mistakes, and consider what I have explained here. Some of these things are really difficult to achieve, for reasons of budget, skill or inspiration, but that shouldn't be an excuse to not strive for them!

Special thanks to Ronimo producer Robin Meijer for discussing these topics with me and coming up with most of that list at the end. This is the second part in a short series on the state of indie. The first part was about luck and in a few weeks I will write about why I think indies should care less about financial independence.

Sunday, 8 March 2015

The downsides of gameplay variety

An important goal in the game design of Swords & Soldiers, Awesomenauts and Swords & Soldiers II is gameplay variety. We try to make all the classes, units and factions play and feel as differently is possible. This makes it more fun to try them all and allows for much more interesting and varied tactics than if everything feels the same. It seems quite obvious that a game gets better if more diversity is added, as long as you have the budget to do so and it does not take away from the core vision. However, there are some serious downsides that are not as obvious. Adding more diversity can hurt many different aspects of a game, as I will explain in this blogpost.

When striving for variety it is important to be aware of the trade-offs. It does not mean that you should avoid diverse mechanics, far from it: it is a key element of the games we make at Ronimo! But consider the consequences before blindly adding variety.

A great example of such trade-offs can be found in the movement mechanics of Awesomenauts. We try to make every character feel different, not only their combat skills, but also their basic movement. Some characters can jump, others can fly, float, make little hops in the air or double jump. There is also variation in walking speed, acceleration and sliding time. Not all of the 21 characters we have so far are completely unique in their movement, but there certainly is a lot of variety. As the interplay between the different classes in Awesomenauts is a key part of the game, this diversity is really important to us.



So where is the trade-off? The problem is that there is such a thing as the ultimate jump. If a jump has the right duration, height and speed, it just feels excellent. Make it a little bit faster or slower and it is instantly less glorious. The jumps in the old Mario games are a great example of this. They strike a perfect balance and it feels awesome just to hop around.

This is where variety bumps its beautiful head. If every jump is to feel different, they cannot all hit that sweet spot. They can feel good in their own way, but it is practically impossible to make them all feel equally super. My colleague Fabian Akker, currently lead game designer on Awesomenauts, recently voiced this very clearly during an internal meeting: "Yes I can make this character faster and yes he will play better then, but I can't make them all be Mario because they will all feel the same." Adding variety will often make the individual parts feel slightly less good than possible, because there is only one "best thing in the game" and not everything can be that thing.

Another example where movement diversity can hurt a game is in graphics. In early prototypes of Awesomenauts we had a skill to walk on ceilings and another to walk on walls. For various reasons both were removed, and one of those reasons was how limiting this would have been to the graphics. To communicate clearly where the player can walk, floors need to be mostly straight and clear. If characters can also walk on ceilings and walls, they would have to be straight and clear too. That would have been a huge limitation to our art style! In this case adding diversity to the gameplay would have removed diversity from the graphics because of the restrictions imposed by the necessities of walkable surfaces.



Diversity is also a problem for balance. The easiest way to make a game perfectly balanced is to have but a single character. Boring, but definitely 'balanced'. As soon as you add more characters, balance quickly becomes infinitely complex and often practically impossible to achieve perfectly. In a previous blogpost I discussed how there are many sides to balance. Even if you manage making all the characters equally strong for pro players, they might still be imbalanced for beginners, in specific team compositions, or in some other way.

A great example of this can be found in map design. It is fun to have a bunch of maps that all play differently. But even the smallest difference can cause problems. If one map is larger than the rest, slow characters will be at a disadvantage. You might try to solve this by giving slow heroes buffs suited to large maps, but that probably introduces other problems. The simple truth: the more diversity, the more impossible it becomes to achieve perfect balance.

And yet balance is so important! How to handle this then? In Awesomenauts we had the problem that one map (AI Station 404) had a single lane at the centre, bunching up everyone. This gave characters with strong area-of-effect attacks (like Raelynn) too much of a benefit. We ended up modifying this map (into AI Station 205) and removing the old version from ranked matchmaking. The downside to this solution is that we lose some diversity in map layouts.



This is just one solution. Another would have been to show the players which map they were getting, so they could avoid certain characters when they feel they are underpowered on a specific map. This would allow us to keep the maps diverse, but at the cost of character diversity, since each map would probably see a more limited set of characters being used. In an ideal world one would find balance tweaks that influence only specific characters on specific maps. However, balance is so complex that such solutions do not always exist, or cannot be found.

Variety can also make a game too complex. I recently finished Advanced Warfare, my very first Call of Duty experience. At the beginning I was immediately overwhelmed by the number of guns, grenades, dashes and options. This is likely due to the series' yearly updates, which force them to add something every time to make it fresh again. At the end of the campaign I still couldn't remember the buttons for half the things I could do. This increase in possibilities adds burdensome complexity, requiring more explanations and tutorials.



We also see this in Awesomenauts: with every character we add it becomes more difficult for beginners to get into the game. In every match they encounter another new Naut they don't know how to fight yet. Having more characters adds longevity and depth, but might make the experience during the first few hours worse for some players.

As a final example I would like to discuss my own hobby project Cello Fortress. Cello Fortress is a hybrid between game and live performance, which means that players only play it for ten minutes each during an event (have a look at this trailer to see how it works). In such a short playsession I can hardly explain anything, so the game needs to be extremely simple. Sometimes players come to me afterwards and ask why I didn't add more diverse weapon. The answer is really simple: because there already is so much I need to explain and communicate during those ten minutes. Variety often adds complexity and there is a limit to how much a player can stomach in such a short session.



I love gameplay variety. My favourite game of 2014 is Far Cry 4, exactly because there is such a big open world where I can do all of these different things. Variety is also super important in our own games Awesomenauts and Swords & Soldiers. But it is important to keep in mind that adding diversity almost always comes with a cost somewhere, so you shouldn't be reckless with it. Add variety, but do it deliberately and take into account the trade-offs it always brings.

Special thanks to Roderick, founder of Leeuwenhart Publishing, for helping me improve my English writing skills. Roderick is the writer of the young adult book Pindakaas & Sushi (in Dutch) and did some freelance writing for Awesomenauts.

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. Part 2 is more controversial and will hopefully stir up some discussion, as it is about what I think many indies 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 Visualiser.zip (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 “TreeBackground.dds”. 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."
9/10
PocketGamer.co.uk

"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
148Apps.com

"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
Gamezebo.com



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.