Saturday, 25 July 2015

Using key poses to prototype character animations

When creating a new game character it's crucial to get a feel for his in-game poses and movement as quickly as possible. During the visual design of a character you shouldn't just wonder how he looks, but also how he moves. If a character looks cool while standing still but bad while in motion, you have a problem. Not only is this a key part of a character's personality and look, it also helps discover problems early on. Maybe that big weapon is obstructing the dynamic actions your hero needs to do?

This is why our artists first draw key animation poses and throw those into the game as quickly as possible. During early development of a new character for Awesomenauts we playtest with just those key poses, without any animation. Less than 10 frames represent the entire movement set of the character. One frame for a jump, one for a fall, a couple for a walk, one for each attack, for sliding to a halt and for idling, and that's roughly it.

It's surprising how smooth and awesome a character can already feel with just one still frame per action. Doing this also has another benefit: the game design feels much more solid if a character isn't a box and doesn't look like some other character you already have in the game.

Of course, the phase after this is to create the actual animations. A finished character in Awesomenauts consists of hundreds of animation frames. But today I'd like to focus on the prototyping and concepting before the real animations are made.

Most of the characters we added to Awesomenauts during the past two years were animated by Ronimo artist Tim Scheel. Tim is a master at drawing dynamic poses and experiments a lot with the animations.

To show how this works I have dug into our archives and made a video of how Scoop, Nibbs and Rocco moved before they got any real animation. I think it's pretty amazing how powerful these already look!

Early animations of characters in Awesomenauts, using key poses only.

A nice thing to notice in this video is that Tim adds some quick in-engine squash-and-stretch effects to make it look a little bit more dynamic. This is especially noticeable in Nibbs' idle and attack frames.

Before Tim puts anything in the game he first makes animation concept art. This is just a sheet with a lot of sketches of what the various animations might look like. Here are the sketches Tim made for Rocco:

Click for high resolution

In Rocco's first gameplay design he couldn't move while doing special attacks. This allowed Tim to draw some really cool attack poses, as you can see in the sheet above. Later the game design changed and Rocco wasn't forced to stand still during attacks any more. This means Rocco needs to do his normal movement animations while doing a special attack, so the attacks changed from character animation to purely special effects.

A particular challenge when designing a character is the amount of detail. Awesomenauts has a strong cartoony style in which microscopic details don't really fit, especially since characters aren't that big on the screen. This means details that were in the concept art are often removed when the in-game version of a character is created. You can already see this happening in the concept art above: some shots have two little straps in the part around the neck, while others only have one of those, reducing the amount of detail a bit.

Rocco's scars were also a challenge: initially he had a scar on his nose but this turned out too small. The scar around his eyes was kept after making it a lot bigger to be more legible. The headphones had to go for a different reason: they had too little to do with Rocco's backstory and personality.

Another example of removing details can be seen below in Nibbs' animation concept art. Tn the bottom right you can see Nibbs' tongue hanging out while running. This is a little detail that I absolutely love: it makes Nibbs look so much more like an overly enthusiastic puppy dragon. However, it turned out to be too small and illegible in the actual game, so it was removed. How much detail there is, is an important part of any visual style, so this needs to be kept somewhat similar in all characters.

Click for high resolution

Another great example of animation influencing a character's visual design can be found in Ori And The Blind Forest, one of my favourite games of recent years. In a presentation at GDC animator James Benson mentions that Ori has a tale because it helped him show the direction of movement better. It's interesting to hear that a crucial element like a tail is there mostly because of the animation, not because of anything else. Be sure to check out this video of his highly interesting presentation!

Back to Awesomenauts! Because Scoop doesn't have legs, his walk cycle was a challenge. As you can see in the concept art below Tim drew a lot of poses for the walk cycle to try different things and find something that works.

Click for high resolution

When drawing game art one must never forget the goal of the art: to be used in an actual game. The requirements of the gameplay need to be kept in mind. In Awesomenauts this means that melee attacks allow for much more freedom than ranged attacks. Melee attacks are generally just an animation that plays, so Tim go do whatever he wants to make it look awesome. Ranged attacks however need to be aimed at the cursor, which means that the gun-arm needs to be able to rotate freely even during the attack. Not being able to animate the gun-arm is a huge limitation to the animations. Such gameplay limitations are important to keep in mind and this is why Tim enjoys animating melee attacks more than ranged attacks: more freedom!

(For those interested, in 2012 I wrote two blogposts about making 2D characters aim in all directions and about shooting animations in Awesomenauts.)

A couple of years ago I hadn't realised that animations need prototyping and playtesting just as much as any other part of a game. The video at the start of this post gives a great example of this. I hope you enjoyed seeing Tim's animation concepting as much as I did!

Sunday, 19 July 2015

Building your mental toolbox for solving coding problems

Solving complex coding problems is hard. What to do when the solution isn't immediately clear? Sometimes you might just get stuck on something, or you might have a solution but are wondering whether there is a better structure or algorithm. No matter how good you are as a programmer, there are always things that are just too complex to easily figure out. How to handle those? The simplistic answer is that you should simply get smarter and more experienced. This is also a lazy answer, as it means you can just keep doing what you do and hope you get better over time. What you can do right now is work on your mental toolbox, your own personal set of approaches and techniques to help your mind tackle topics that are too complex to otherwise solve.

By "mental toolbox" I basically just mean a bunch of tricks to help you think. Such tricks are very personal: what works for one person might not work for someone else. The important thing is to try different approaches and find out what works for you. In today's post I would like to share my own tricks, hoping some of these can help others as well.

Make schemes

Don't try to create an overview in your head, do it on paper! Draw flowcharts, timelines, mindmaps, UML diagrams, lists, relationship graphs or whatever else that might help you see the entire problem, or see the problem in a different light.



Write down all your thoughts

This is my most personal trick, as I have never heard of anyone else who does this, but it is also my best one. Whenever I am truly stuck I fall back to writing down all my thoughts.

To me the biggest problem when trying to solve something is that at some point my mind grinds to a halt as it tries to hold too many thoughts at once, leaving no room for new ones. This is a common thing in humans: in psychology it is called "The Magical Number Seven, Plus or Minus Two", stating that the average human can hold 7 ± 2 objects in working memory. The problem is that as soon as I have a bunch of thoughts that I think are interesting, I try to remember them and lose the capacity to come up with new ones.

My solution is to just write down all my thoughts, including the bad ones. For a complex problem I might scribble an entire A4 full of miniscule notes. For half of those I realise they are irrelevant before I even finish writing them down, but this doesn't matter. The only point is to clear my mind: whatever is on the paper doesn't have to be remembered, so there is room for new thoughts. Letting my mind ramble on and writing it all down often leads me to a solution. This is by far the strongest tool in my box.

Split the problem into smaller pieces

If a problem is really big it might help to just ignore half of it and only solve the other half. Often the parts of a problem depend on each other and trying to figure out the dependencies might be what makes the problem too complex to solve. Try solving only one part while ignoring everything else. Only once the part is solved, try to figure out how to make it work with the rest of the problem.


(More info in this blogpost on AI movement in Awesomenauts)

Try different angles

It can help to force yourself to try a completely different angle, sometimes to even try angles that might seem ridiculous at first. A good example is randomness: if you can't find an exact solution, you might try to generate random solutions and choose the best one. This is rarely the best approach, but looking at it from an angle like that might generate new ideas. For example, this particular approach makes you think about how to compare random results to figure out which is best. The algorithm for comparing results might be the starting point of a real solution. The goal is to force yourself to let go of your current line of thought and try completely different angles.

Just start coding

Sometimes you already have some ideas on how to tackle parts of a problem, but not the rest of it. In this case it might help to just start coding. The code you write will probably end up being thrown away once you figure out the real solution. This is fine: the goal is to turn general ideas into concrete code so that you understand it better. When using this approach be sure to throw away the garbage code afterwards!

Leave markers to avoid being sidetracked

Often while programming something complex I come up with additional problems that I will also need to solve, or edge cases that need to be handled. Doing those all at once makes me lose focus, but I don't want to ignore them either, because I might not remember them later on. So whenever I think of something, I leave a small comment in my code as a reminder and leave it at that, allowing me to keep my focus on one thing at a time. To be able to find those comments quickly once the core code is finished, I add the letters "QQQ" to them.

The internet

Caption Obvious would like to mention that you can search online for solutions.

Ask for help

Surprisingly, quit a lot of programmers would rather be stuck on something for days than ask for help. I have supervised a ton of interns and quite often they keep chewing on a problem without real progress for way too long before asking for help. Asking a question online seems to have a similar barrier. There is no shame in looking for help or discussing a problem with someone else, and often just explaining the problem to someone else clears up the mind enough that you figure out a solution yourself.

Ignore performance and requirements

Often it is easier to solve a problem in an inefficient way than in an efficient way. Letting go of performance requirements is a great way to open your mind to solutions. Often an efficient solution is just a clever variation on an inefficient one.

The same goes for requirements. If you are stuck, let go of all the additional requirements and first try to solve only the core problem. Then try to adapt your solution to those requirements.



Know lots of programming patterns

I often struggle with finding a really good class structure to make my code as clear and maintainable as possible. For such situations it helps to know a lot of design patterns. Design patterns are common structures that can be applied to specific problems. There is an enormous amount of design patterns and the more you know, the better. Wikipedia has a nice overview, including well-known ones like Observer, Factory, Singleton and Strategy.

Know lots of algorithmic techniques

Many problems are completely different, but can be solved in similar ways. Often you can find a solution by trying approaches you have seen in other algorithms. The more approaches you have seen, the larger the chance you know something suitable. Here are a bunch of categories of solutions of which it is good to have seen a couple of examples of algorithms that use each approach:

  • Recursive algorithms
  • Heuristics (or: approximate solutions versus exact solutions)
  • Greedy algorithms
  • Dynamic programming algorithms
  • Iterative improvement (running the same algorithm over and over again to improve the result with each run)
  • Smaller steps (splitting a simulation into smaller steps instead of once with a big step, like in this collision trick I used in Proun)
  • Monte Carlo versus Las Vegas algorithms

Take your mind off the problem

If all else fails you can choose to simply leave the problem be for a day or two and work on something else. A solution might pop up when least expected. Under the shower, while cycling or taking a walk. I personally get lots of good ideas on the toilet... Key to this approach is to allow your mind to wander. Don't fill every waking minute of your day with entertainment/work as your mind would be too occupied for new thoughts.

Your mental toolbox is something you can improve and work on. You can experiment with new approaches and ask others what theirs are. Give all kinds of things a try, and see what works for you.

What are your tricks for solving complex problems?

Thursday, 14 May 2015

Swords & Soldiers II introduction trailer

Our awesome introduction trailer for Swords & Soldiers II just went live! Koen made a really nice trailer for our new game, with help from Ralph and Gijs. Swords & Soldiers II is launching on Wii U next week (on Thursday 21 May), exciting times! :D

Saturday, 2 May 2015

Making gameplay stand out against rich backgrounds

Good game graphics are not just about being pretty. Equally important is that they communicate well. The richer and more detailed a visual style becomes, the more difficult it is to communicate gameplay clearly. With the amount of detail and variation we wanted in Swords & Soldiers II it was a challenge to make the units, spells and other gameplay objects pop out against the colourful backgrounds. Today I would like to show the tricks our artists used to make this work.

The reason this is important is that otherwise it would not be clear which objects are interactive and which are not. For example, is a tree a wall that I cannot pass through, or just a backdrop that has no effect on the gameplay? Ideally these kinds of things are immediately and intuitively clear to the player, without requiring any explanation.

Our new game Swords & Soldiers II launches on Wii U on May 21st.

The easiest way to achieve visual clarity is to not have any backgrounds or effects. Just a flat-coloured background with the gameplay objects. This looks horrible of course, so we want to add more art to the game. In general, the more you add to the world, the more difficult it becomes to distinguish gameplay objects from graphical fluff. In truly rich visual styles achieving clarity is a challenging balancing act. Objects should look like they belong in the world but at the same time pop out. The creators of a game can even choose to let go of visual clarity if they value visual beauty more.

At Ronimo gameplay always come first, especially when creating highly tactical games like Swords & Soldiers II and Awesomenauts. This means our artists had to employ a lot of clever tricks to combine the lush visual style with gameplay readability.

Our art director Gijs Hermans is responsible for maintaining a consistent style throughout the game. For this blogpost I interviewed Gijs about the tricks used in Swords & Soldiers II. Our level artist Ralph Rademakers showed me some additional tricks. Below I will be showing the clever techniques they used to make the gameplay stand out.


To make characters, spells and towers stand out against background objects they are drawn in a different style: with outlines and cell shading. The backgrounds are more painterly, lacking outlines and with more brushy and subtle lighting.


In many Disney classics, like Jungle Book (top), animated objects are in a different style than non-animated objects. Our artists love this combination so they even combined the animated and non-animated styles within the Viking base for its different parts. Note the difference in outlines and shading between the animated caterpillar and the ship itself.

(Click for high resolution)
The first version of the Viking base was more in the style of the backgrounds. To make it stand out more the final design was pulled more towards the gameplay style.


Early in development characters had hardly any shading (top), making their shapes less readable. Their final designs (bottom) have deeper shading and more saturated colours.

(Click for high resolution)
Our artists tried a lot of different shading and outline styles for gameplay objects. This image shows a series of early experiments with the goldmine. All the way to the right is the final design. Be sure to click this image for full resolution, since this scale does not show the differences well.


Background graphics are less saturated. Our level artist Ralph even used such atmospheric perspective on objects very close: the house here is directly behind the playground and thus too close for 'real' atmospheric perspective. Ralph desaturated it anyway to make gameplay stand out more.


Sheep are sometimes gameplay objects and sometimes background objects. To make this clearer they are blended a bit towards a single colour when they are in the background or foreground.


Background brightness is often changed to make gameplay stand out more. In both of these images the background is brighter near the gameplay layer, adding contrast. Higher up in the screen no gameplay happens, so there 'normal' colours are used in the background.


Gradients are not the only way to make the playground stand out: here the bushes directly behind the playground don't have snow, turning them into a green border between the snowy playground and the snowy trees. It would be weird if only these objects lacked snow, so snow is also removed from other objects like the rooftop in the background on the left.


Corpses have gameplay functionality but having lots of them really clutters the view. We therefore desaturate corpses to make soldiers walking in front of them stand out more.


Depth of field blur on the background not only adds depth but also makes the foreground pop. We use this trick in both Swords & Soldiers II and Awesomenauts to make gameplay more readable.

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.