Sunday, 26 April 2015

Why indies should care less about financial independence

Many people in the games industry think the word "indie" stands for "financially independent", and indeed this is something that a lot of indie game developers care about a lot. Although it is an important topic, I think we should care about it less: being indie should be about creative independence, not about financial independence.

You might argue that one is impossible without the other: if someone is funding your game then of course that someone is also influencing your creative decisions. However, what a lot of people don't seem to realize is that no one funding your game is also a big influence on your creative freedom. You will need some way to get food and pay the rent if you want to spend a significant amount of time making your game the best you can.

Disclaimer: this post is only targeted at those who want to make a living making games. If you are making games as a hobby in your spare time, then please ignore this post and do whatever you want! ^_^

Without enough money to make a game you will often have to cut back on the quality and size of the game. You might even have to choose a different game concept altogether. In many cases this influence might be much bigger than that of a publisher or investor. Game development is always about compromises between time and budget on one side, and the quality of the game on the other side. Having an investor might open up a lot of creative options, even if the influence of the investor also closes some.

Of course you can work around all of this by just making really small games. Nothing wrong with that, but being constrained to making small games only is just as much a creative limitation as a pushy publisher would be.

The ultimate solution is to just have a hit. Then your next game will have a big budget and you will have complete financial independence. But few people have a hit and you cannot just force yourself into one. Until you have that hit, you will have to work with your real situation.

A common solution is to do work-for-hire half the time and spend the other half of the time on your own indie games. This can of course work, but it also means spending half as much time on your own game, or taking twice as long to build it. Often this simply results in spending most of your time on work-for-hire to make ends meet while making a mediocre game of your own on the side. Doing work-for-hire is often more limiting to development than any publisher would ever be.

Another reason it might sometimes be a good idea to let go of your financial independence is that you can focus more on your actual game. The business and marketing of releasing games takes a lot of time, so working with a financial partner who takes care of these things can free up valuable time to make your game better.

Note that actually getting financing from a publisher, investor, platform holder or other kind of partner is really difficult. In that sense it is not a simple choice of yes or no. What I am saying here is that indies should consider this option more often, not that it is an automatic win.

The solution that is all the rage right now is to avoid publishers and investors and go for crowdfunding instead. Crowdfunding is often praised as the ultimate freedom for an indie developer: if you successfully get funded you won't have a pushy publisher and you can make whatever you want with the help of the crowd. If only this were true...

In reality being crowdfunded is an incredibly limiting form of funding. You will have to make a lot of promises of how awesome the game will be to entice players to fund it, especially if you look for funding early in development. But what if during development some of those planned features turn out to not actually be fun? In practice there is a good chance that your backers turn out to be extremely exacting and will demand that you deliver exactly what you promised, even if you have already figured out that what you promised was just a really bad idea. Game development is inherently iterative, so you cannot know what features work until you've built and tried them.

It gets even worse if during development you get a better idea. For example, let's say that during the crowdfunding campaign you promised that the game would feature villages that grow as you progress through the game. What if during development you get some great new ideas for wildlife hunting mechanics that would be much better for the game than those villages. You cannot do everything and during normal development you would be able to just cancel the whole concept of the villages altogether and build the hunting instead. When being crowdfunded there is a good chance that doing such a thing would raise an angry mob. The so-called "financial independence" of crowdfunding might turn out to be very limiting to your creative independence!

A good example of this was recently seen in the rage over Godus. During their Kickstarter campaign they promised all kinds of things that turned out differently or not at all during development. Basically, the game just evolved as 22 Cans worked on it, and maybe it turned out to not be as much fun as was imagined at the beginning. The community reacted so aggressively that they even started threatening Peter Molyneux's family. I happen to also be a backer of Godus and all I ever expected from 22 Cans was to make the best game they could within the spirit of their Kickstarter. But this is not what the majority of the community expects. A specific feature set was promised and that feature set needs to be delivered or Peter Molyneux's family gets it. It is a sad example of the crowd stifling development, not supporting it.

My point here is not that crowdfunding is bad. The community funded the big Starstorm expansion for our game Awesomenauts on Kickstarter. This allowed us to grow the game way bigger and better than we otherwise could have. We are extremely thankful for that and really happy with how the collaboration with the community has been going so far. ^_^ I am just saying that the creative freedom that crowdfunding would give is extremely overrated and you should realise this before starting a crowdfunding campaign. Good communication and choosing the correct wording (like avoiding "promises") might also help a lot.

Of course my point in this post is not that every indie should start looking for a publisher or investor. There are a million ways to get your gig going. For example, I kept living with my mom during the first four years of Ronimo. This way hardly any budget was needed and we could spend as much time as needed to make the best games we could. There are many other ways to make things happen. Some concepts, like my crazy live-performance-art-game Cello Fortress, are just so impossible to make money with that no business would ever want to invest in it, so a different way of 'funding' is needed. My solution there was to just make the game in my spare time and not expect to make any money at all (note that I did get some funding for it from the Gamefonds government fund once I had a basic version running).

An obvious reaction to this post would be that I am "telling indies to be less indie". If your definition of "indie" is "financially independent" then yes, that is exactly what I am saying. And honestly, if that is your definition of indie, then I don't care about indie anyway. The only thing that really matters to me is the creative freedom to make the games I want to make, and that is what I consider "indie". I don't care what financial constructions are needed for that and I definitely don't care whether anyone else wants to call that "indie" or not. The only thing that really matters is to make awesome games.

Sunday, 19 April 2015

The level art tools for Swords & Soldiers II

For our new game Swords & Soldiers II (coming to Wii U on May 21st!) we wanted to create detailed and varied levels. Because of the number of maps and their large size we needed art tools that provide a lot of automation to be able to populate them quickly. At the same time we wanted to allow customisation and control over the details to create unique, designed places. Today I would like to show the tools that Ronimo programmer Machiel van Hooren developed for our artists. Check especially the awesome demo video at the end!

Our starting point was the level editing tools we made for Awesomenauts. Those are very flexible and not tied to a single game, so we could pretty much use all of them directly in Swords & Soldiers II. However, the shape of the levels in Swords & Soldiers II is very different: the Awesomenauts tools are built around rectangular boxes, not curving landscapes. Nevertheless they provided a really strong beginning. I made a short video montage about the Awesomenauts tools for a blogpost a couple of years ago, here it is again for those who hadn't seen it before:

The first thing we needed to add for Swords & soldiers II was curving terrain. The core gameplay takes place on a single line with little slopes and hills. So we made a new feature with which our artists place TerrainNodes in the level, and then the engine automatically generates a smooth terrain that goes through those TerrainNodes.

To calculate a smooth line through those points we use standard bezier splines. We also tried using slightly simpler Hermite splines, but we didn't like the look of those. Bezier splines usually come with additional control points for more control over the curvature. To simplify things we calculate the control points automatically based on the previous and next TerrainNode. This gives slightly less control, but that turned out to be fine for our artists and it makes the tools simpler and faster to use.

The next step is terrain layers. We wanted to add as much depth to our 2D art as possible. Having more terrain layers in the foreground and background is a good way to accomplish this.

The most obvious method is to just allow our artists to create more terrain layers by hand at different parallax depths. However, efficiency was also a goal, so we wanted to avoid creating all those layers by hand. Therefore we made it so that the parallax layers are copies of the main terrain. To be able to create some diversity we added settings for things like random noise, different textures and colour modifications. Not only is it faster to create levels with these copied terrain layers, it also means that if the main terrain is edited (and it often is), then the background and foreground layers automatically change with it. This makes iteration and modification much quicker.

The big limitation this creates is that the hills in the background are the same as those on the playground. Sometimes our artists wanted to break free from this pattern. We could have tried making the terrain tools more flexible to accommodate for this, but often the big background objects aren't hills, but an inn, or a wall, or something else. The solution was simple: the artists just placed a big texture of a hill in the background and that's it.

Plants, small vegetation and other props are all tied to the landscape. To help place those quickly we created ObjectDroppers. An ObjectDropper attaches one or more objects to a terrain layer, allowing an artist to drop a bunch of bushes or flowers on the landscape quickly. Props are dropped using a random seed and the artist can try different seeds to look for one that he likes. With a bunch of prop types a level can have its basic setting in place really quickly, after which the artist can focus on adding the unique flavours. Since the dropped props are tied to the landscape, modifying the terrain also automatically modifies the props, making tweaking the terrain that much faster.

Our level artist Ralph Rademakers even used ObjectDroppers to place bigger objects like trees. By working efficiently with these tools Ralph was able to dress up the simpler levels in just a few days per level, using the textures drawn bij Adam Daroszewski and Gijs Hermans.

The other main tools used for the level art are things we inherited from Awesomenauts: placing textures and animations in levels and recolouring them. You can find some good examples of the power of in-engine recolouring in this blogpost: Using 2D daylight assets to create a night level.

Now that I have discussed the tools, let's have a look at them in action in this little video:

I think the main lesson that can be learned from the Swords & Soldiers II level art tools, is that it's sometimes a good idea to limit control to make the workflow faster. The ObjectDroppers create a lot of objects at once, giving much less control than placing them by hand, but also being much, much faster. Similarly, the background and foreground terrain layers being copies of the main layer is limiting, but also very efficient. Where required our artists had enough other tools to break through the limitations by hand, resulting in a good balance between automation and old fashioned handwork.

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