Indie Games: Designing to Succeed

Originally published in January of 2011.

The discipline of game design is changing.  More accurately, what the world has come to expect from game designers is changing.  Games are becoming ubiquitous, the industry has grown by billions of dollars, distribution is no longer a barrier to entry, and the tools exist to not only for indie designers to make games with passion, but to make games with profit.  As our medium expands, so too do the rifts between the indie crowd and the triple-A studios.  Fewer studios cater to the console market than ever before, and the gigantic opportunity that remains for everyone else is fought for by thousands upon thousands of developers and publishers in a highly competitive, rapidly changing marketplace.  Stories of success are told loudly enough to drown out the countless failures it takes us as a community to get there.  Hours, months, hearts and lives are poured into games, and what they return can be cripplingly low.

It should be the intent of every serious game designer to set out to succeed, in terms of both game design and profitability.  To continue working on what we love, we have to be pragmatic and business minded as well as creative and hard-working.  There are a wide variety of avenues towards this kind of success, and choosing the right ones while avoiding the wrong ones will help create a game that is designed to succeed.

The golden rule of game design is that if the game itself is of exceptional quality, it will succeed despite any shortcomings in its business plan.  Games like this are rare, though we all seem to set out to make one.  What follows here is not a recipe or guide to exceptional game design.  Instead, this essay is meant as a road map to maximize your chances of your game becoming successful, from conception to release.  It looks at everything from coding practices to business practices in an attempt to clarify common and critical mistakes, and point indie developers into a profitable direction.  Everything here is backed up with research and examples, but the game industry is in such a state of transition that the research can never be up to date.  Take this pile of advice and suggestions with a dose of healthy apprehension.



Genius is only a greater aptitude for patience. – George-Louis Leclerc, 1803


Give Form to Ideas – Prototype

In the world of design, from games to architecture to cars, ideas are nearly worthless.  They are common, they are cheap, and they are part of the imagination.  Everyone in the world has an imagination, and yours is no different.  I have imagined no less than a hundred concertos, a thousand paintings, and a million plot twists, despite being inept at those forms of expression.  For your imagination to capture anyone, it has to evolve – you have to give your idea a form, and in the case of game design, that means making a prototype.

Prototyping is fast, agile development where you can test out your ideas and see if they’d actually make a fun game.  Many game designers working in 2-D development will tell you that if you can’t make your idea work and make it fun by the end of a weekend, you should leave it behind.  Not having much programming background myself (or any, before I started my first game), I would say you can give yourself a little longer, but the basic rule stands.  Prototyping means getting in there, throwing some ugly crap on the screen, implementing some basic controls and a simple game loop, and checking to see if there’s any promise there.  If not, your idea didn’t work, so move onto the next one.  If there is a glimmer of promise in an otherwise horrible prototype, make a new prototype and repeat.


I Know My Idea Works, so I Don’t Need to Prototype

Stop.  The only way you can know something is by proof, and if there’s proof out there, then it isn’t your idea.  If you’re cribbing off an existing game design, fine – our industry is built on it.  But if it really is a new idea, you cannot know that it works until you test it out.  Game design may feel like it’s about emotion and conviction at times, but more often it evolves through a scientific process of trial and error, thesis and antithesis, experimenting and testing your ideas.  If you’re not willing to put your own assumptions to the test, then I can guarantee one of two outcomes: either the development will never finish, or the final product won’t be worth the work put into it.


Prioritize Gameplay

This idea is going to come up a lot, and it starts early.  During prototyping (and every phase after), make your gameplay shine regardless of any of the surrounding content.  This is advice that holds from the tiniest indie game to the next Mario platformer.  If your idea is about a narrative, about level progression, or about any sort of static, unchanging content, then you are setting yourself up to fail.  But if your idea is about gameplay, and you can make that fun, then adding that static content later will preserve good gameplay – rather than stellar static content obscuring the fact that the gameplay is much less than it could be.

Think of all the games you’ve owned in your lifetime that you sold or traded or deleted or forgot.  Compare those games to the ones that have been on your shelf or hard drives for years.  The key difference between those one-time game experiences you threw away and the infinite experiences on your shelf is the refreshing gameplay, and little else.


Neglect Static Content

Static content has no place in prototyping, and not a lot of value elsewhere either.  That statement is going to upset some people, but it’s critical for setting yourself up for successful game development.  Designing a game around something static, like a story, is handcuffing yourself.  The static content will force design decisions and prevent you from making better ones.  Countless games fall prey to this – where players continue playing in order to finish the story, or conquer the final level, rather than play the game because the gameplay is keeping them interested.

The replacement for static content is dynamic content.  Dynamic content is content that is procedurally generated by the game, rather than preset into levels or narratives or power creep.  A brilliant example is the difference between a static platformer and a dynamic one.  The Mario games have static levels with minimal dynamic content (the level can vary slightly based on the player’s path taken, I suppose).  The game ceases to be a challenge once the level is memorized.  Meanwhile, Canabalt is an entirely dynamic platformer, using randomization to ensure a challenge on every single play.  Both are excellent games, but as indie game designers, we have to weigh the costs and benefits of producing dozens of static levels against making one dynamic one.


<img> – Introduction of static content and it’s influence on development – One graphic, pie slice.

(i.e. all game development is a 5% circle, and introducing static content narrows all choices to a single slice of that pie – and continues to do so.  (easier to divide)


Aside: The Curse of Franchises

Existing franchises from other media (like film or toys) are poison to game design and you should avoid them wherever you can.  Even the most magical and game-ready franchises can rarely be turned into a half-way decent game.  Content is vastly prioritized over gameplay, but even if that’s not the case, the content shapes and molds the gameplay in thousands of invisible ways.  Working with a franchise is like painting a landscape, but the foreground has already been crayoned in.  It becomes your job to make the best of it, a task no one could fault you for failing.

As a quick case study, imagine your character running around in an environment dominated by water.  In order to make your character’s weapon pop out, you’ll want to pick a colour that stands out against the background.  The best possible design choice for this particular game is a glowing gold weapon – except you’re making a Pirates of the Caribbean game, and your main character wields a very specifically designed sword.  It’s only one choice to compromise on, but there are always more.  The number of fights, the variety of settings, the range of playable characters, the fact that the story can’t be interactive since it’s already been determined, the music, and more.

The counter-argument is that great works can arise from great restrictions, as many artists will attest to.  Franchises can produce good games – Batman and Star Wars both come to mind – but they are franchises that tend to have an amazing pool of choices to pull from. Batman has been interpreted by thousands of artists, so audiences are primed to accept new designs and directions without question.  Star Wars has a universe-sized mythos and is no longer restricted to existing narratives.  But the cards are still stacked against the developers as the restrictions are always going to be more abundant than the opportunities.  If they can rise up to meet the challenge, all the power to them, but it’s a recipe for disaster much more often than a recipe for success.


Progress, Obstacles and Resources

All games, from chess to the latest Halo epic, share three primary mechanics in different forms.  This is the basis of all game design, and it’s important to identify where your balance lies while prototyping.

  • Progress is the idea of growth, development, and escalation.  For most games, the simplest example of this is a score, but it stretches much further to level progression, character enhancements and an evolving story.
  • Obstacles are barriers to progress that must be overcome.  It doesn’t have to be destructive like killing an enemy – it can be transformative instead, like a quest.  But for it to work, it has to stand in the way of progress.
  • Resources are the tools you give players to use against obstacles, and occasionally spend on progress.  They can be infinite like jumping or running, or finite like power-ups or hit points.  They can also be much more abstract, like board position or even the player’s own creativity.

It’s important to look carefully at your balance between these three early and often.  A game with lots of obstacles for little progress is a grind for players.  A game with too many resources can get convoluted if there aren’t matching obstacles to use them with.  If progress is constant and eternal, the game becomes boring and repetitive.

But backing away from the game design a little, it’s critical to identify your progress, obstacles and resources so you can think about how this game is going to make money.


Identifying Your Sales Opportunities

Assuming you’re taking a microtransaction business model, you’ll want something to sell in your game.  This is where breaking your game into Progress, Obstacles and Resources comes in handy.

As a general rule, selling obstacles isn’t very profitable and it takes a lot of work to create.  This extra content, like extra levels or more story, should be paired with additional progress rewards for overcoming the obstacles.

Selling progression alone can be profitable, but it’s nearly impossible to do without angering your users.  Where progress is for sale, it’s most commonly sold outside of a game system by a black market – buying save files and online characters, for instance – and your core players won’t stand for it.

Selling resources, on the other hand, is a highly profitable and player-accepted form of monetizing your game.  While prototyping, you have to keep this in mind, because a good game design may leave you no options for selling any resources.  If there are no limited resources, nothing for the user to replenish or increase, then suddenly you are in the business of selling obstacles and their progress rewards, which is a much tougher business model.  It’s not a bad business model, or the worst, but you’re making the conscious choice to leave the prototyping stage with a weakness.

Above all, be creative.  Resources include anything that you can enhance or power-up – anything variable or constant in your game that you can double might be a source of tremendous revenue.  If you can find something, (or preferably, many things that you can choose from later), then you’re on your way, and can begin development.



Work would be terribly boring if one did not play the game all out, passionately. – Simone de Beauvoir, 1966.


Architecture for Success

As a programmer, no matter the programming environment or tasks in front of you, someone out there has made something for you to use and learn from.  Your first job is to go look for it.  No matter how you choose to develop, and in what language, there are hundreds of libraries from simple animation helpers to pixel-blitting engines, massive physics simulators to 3-D modelling.  If you’re choosing to build it all yourself, make sure you’re doing it for the right reasons.  Developers have a habit of getting stuck building the perfect game engine or coding as if it were for a master’s thesis.  There’s plenty of great code from your peers out there.  Use it.

Of course, you should also code well, and code well the first time.  All of the principles of object oriented programming are important to programming games as a whole, but it is the principle of modularity that most benefits quick, agile design.  Make test cases, swap them in, swap them out, change everything about them, reverse them, plug them back in and keep developing.  The better your code can handle big gameplay changes with simple class or variable swaps, the more options you have open to you in a day of development.


Aside: Variable Driven Development

I’m a huge proponent of setting up my files in what I call “variable driven development”.  In one or a small group of classes, I set up lists of constants that have a number for everything.  Everything.  Camera zoom, aspect ratio, player height, base speed, enemies per wave, damage per cannonball, hit points per enemy, reward per kill – everything.  When I create constants, they’re often multiples of other constants.  And when I create individual classes, I make sure to reference these constants rather than internal numbers – so when I want to speed up an entire simulation, I can do so by changing one constant from 50 to 100, and the game automatically manages everything a massive gameplay change like that could possibly touch.

The other great thing about developing in this way is that you can set up a live panel to adjust your variables on the fly while play testing, instead of re-compiling every time.  Would the game be more fun if I doubled the number of power-ups but halved the player’s timer?  Two key strokes and I can find out.

<img> – Simple TumbleBall screenshot with a variable / output panel

While I’m on the topic – when you’re tweaking your variables to get the right balance, start by either doubling or halving the number in question.  Chances are it won’t feel right – but it will feel different enough to let you know if you’re on the right track.



Get strangers to play test your game at every single stage of development.  They will often ask the stupid questions and make stupid comments, while your stock answer will be “I haven’t built that part yet”.  But they will also provide you with insights that come from things they find obvious but you can’t see while mired in code.

This is such an important step that I’m going to say that all again.

You cannot see some of the most obvious problems with your game without another set of eyes.  The more sets of eyes you have, the more insight you’re going to get into your game.  Get out there, and get people to give you feedback.  Identify problems early, and identify them often.


Keeping it Simple

Simplicity is your friend while developing:

  • The simpler your game is, the more likely you are to change something that isn’t working.  As it becomes a lumbering behemoth of dependencies and one-off bug-fixes, those changes become a lot less enticing to make.
  • Releasing a simple game is the best way to test the market.  You have to consider the possibility that despite your best attempts, the game may be a flop.  Releasing the simplest possible game that still is in line with your vision will test your core design against the market and its unpredictable forces.  You can always make a sequel.  Always.
  • Simple designs keep the fun visible.  Your game was fun as a prototype – stray too far too fast and you’ll lose it.  Try omitting seemingly critical gameplay while developing to keep your mind searching for more fun.  It’s a simple matter to try your game without a lose condition (or a win condition) – if it’s more enjoyable, then it’s worth considering for the final product.

Complex systems are still vitally important for some of the deepest aspects of your game, but take the time to master the components (and cut the ones that you find aren’t needed) before stringing everything together.


Leaving Doors Open

At some point in development, you will have to start making design decisions that are set in stone instead of sand.  That’s a great place to be – but during core development, you are not at that point.  Every decision should be malleable and reversible.  The easiest place to do this (for some developers, anyway) is leaving the game art and sound until the last possible moment.  Work with stand-in sprites and the like – when you suddenly decide that your game could go a lot faster if your player sprite was three times larger, there’s no harm done.  Doing the game art early just means those changes become more painful to make – and you’re less likely to make them.

A lot harder job for developers is resisting the siren call of static content.  Building those challenging levels and writing that epic narrative is just so compelling to us.  But every piece of static content that gets included locks down a huge variety of potential design choices.  It might not seem to be an issue – but when it’s time to start polishing up the game for release and your players get insanely frustrated at the lack of double-jumps, all of the sudden those levels you spent so long on are dead weight.


The Magic Solution

The ultimate way to leave doors open for yourself and your game is having as much of your game as possible be dynamic content.  Procedurally generated content can be changed late into the development cycle without a significant cost.  What’s more, you can add new game mechanics, completely re-balance resources, and generally change your mind (and have the means to test your ideas without losing too much valuable time).

<img> – Repeat of pie slice graph outlining dynamic content benefit.

Static content has boundaries that you must design within; wander outside of it, and that content needs to be remade.  Dynamic content has changing boundaries that react to your development.  It’s the difference between placing content inside a fun game, and making a game inside some repetitive content.


Aside: How to Develop Like Nintendo

I wouldn’t dare argue that static content, like levels, story, narrative, unlock trees, character progression and more are not good tools in a game designers toolbox.  Many of the games we as designers look up to are brilliant melds of content and gameplay, seamless and brilliant.  But if you are trying to maximize your chance at success, you have to be more like Nintendo and less like Microsoft.

Nintendo is one of the most successful entertainment companies on the planet, and it doesn’t come from content.  Their graphics are simple, their characters are re-used over and over again, their stories are rare and their levels are re-visited many times in a game.  Their least successful ventures (like Fire Emblem) have high-end graphics, compelling stories and a strict linear progression.  But regardless of the game, the gameplay is always given top billing.

Microsoft is capable of taking captivating gameplay and applying amazing content – stunning graphics, compelling story-lines, natural linear progression, and well defined characters.  But they spend more and make less than Nintendo per game.

Nintendo has long made their money in innovation rather than perfection.  They create markets like the desire for touch screens and motion control, pet simulators and 2-D platformers, then back out of the markets they created (or re-invigorated) when players like Microsoft throw their incredible talent around, offering a more refined, complete experience that relies on new content rather than new gameplay.

There’s room for both strategies and there will be for years to come.  But innovating new gameplay is a valid business model for anyone.  Applying new content to existing gameplay is a business model best suited to major companies with powerful marketing.  For developers like Capcom or EA, if 80% of their games flop, the other 20% will make enough to pay for those failures.  If an indie game flops, there is no backup plan.  To maximize your chances at success, better to follow a gameplay driven development rather than content driven development.  There’s more room in the market, a higher chance of success, and less cost to get there.


Developing Your Community

Depending on your business plan, it may rely on a community.  Building one around your game can seem like alchemy.  The best games will inspire their own communities, but there are many, many things you can do to help.

  • What’s My Name?  Those high score boards are going to look pretty empty unless you’ve got some names next to the numbers.  Getting a name is a difficult matter and can require a lot of coercing.  But knowing who else is out there – and how many there are – helps the image of a thriving community (even if it’s not there yet).
  • Who Am I?  If your players can’t express any identity in your game, they have no reason to express it to anyone else.  Comments, avatars, their own little room – anything that promotes personalization will encourage players to show their work to other people.
  • Who Are You?  If your players don’t have a means to express themselves to anyone else in-game, then they also don’t have a way to see a community beyond themselves.  And they aren’t going to join a community that they don’t know exists.  Hiding players from each other is a sure way to kill your community before it starts.
  • Why am I Important?  Give your players a way not only to assert their own identity, but what the community should think of them.  Rankings, titles, stars next to their name and wearables will all help define and separate players from each other while also giving them a sense of place and belonging.
  • Why am I Here?  As great as your game is, it’s not the only thing in the world.  If you don’t provide a way for people to get off-topic, they’ll only ever communicate to each other about your game.  Great for your ego, but bad for your community; it will just become stagnant and die.
  • What’s the Point?  Providing a reward for jumping in the community is a good idea.  Continuing to provide rewards for being in the community is a great idea – and keeps everything alive.
  • Is it in a Community I’m already Part Of?  Piggybacking onto an existing community (like Facebook) opens all of these doors and allows for you to worry less about building your community and more about your core game design.


Despite your valiant efforts, your community may never fly.  As important as building your community may be, make sure it’s not essential to the game experience, or your game could suffer from a permanent stigma of having no community – which is a self-fulfilling prophecy.  Consider a mix of off-line and on-line community, so that your users don’t have to be online at the same time to enjoy each other’s company.


The Power Law

There are many options for game designers to make money, and I’d suggest pursuing a few at once (better safe than sorry).  But currently the most successful model for the indie crowd is giving it away, free-to-play, and selling add-ons to your joyous users later.  The reason for this is because the vast majority of your revenue is going to come from the vast minority of your users.  In statistics and business, this is called the Power Law and free-to-play games depend on it.  Your success is going to hinge on your ability to convince your top tier fans that what you’re offering is worth their money.  But there’s a problem – humans are horrible judges of value.

Value to you, the builder of all of this content, is proportional to how many hours something takes to build.  Extra content is highly valuable.  Wearables are a miniature form of extra content, so they have some value.  Power-ups are literally doubling a single number, so it has the least value to you.

Your players see value exactly the opposite to you.  Doubling a variable is something they’ll spend money on, but your 1000 hour opus of extra content isn’t nearly as valuable.

Not only that, but value is subjective to us humans.  To you, building three hats as wearables takes an equal amount of time.  But price them differently, and your players will see their values as wildly different.  My favourite anecdote is about the $10 hat that is far too expensive for players.  Add a $100 hat, and suddenly that $10 hat looks kind of reasonable.  Add a $1,000 hat, and the $100 hat looks reasonable – and the $10 hat looks cheap.  It’s a steal.

And that’s how the power law, embarrassingly, works.  The vast majority of your users will never give you a penny.  If they give you any money at all, they will get that $10 hat and will make up maybe 20% of your overall revenue.  But the users that buy those $100 and $1,000 hats are the ones that are generating the lion’s share of your income.  Make sure to treat them well.


What to Sell (And What Not to Sell)

A small (or in some cases large) mistake that’s been made over and over again is selling content.  Maps, level editors, more story, more levels, more characters.  Based on all the numbers I’ve seen, this is the least successful way to monetize games.  Users are extremely wary about buying additional content.  Many feel entitled to it and are enraged at being asked to purchase it.  Others are just happy with the content you’ve provided for free.  You can make money selling content – but content can be a lot of work to create, and it’s for the least amount of return.  Don’t be afraid to offer it as an option – but as a business model, it’s the weakest of your options.

A step up in profitability is selling wearables.  These are items with little or no in-game value outside of aesthetics.  It’s a non-obtrusive way to ask your players for money – give me some cash, get a hat.  It’s also fairly easy to implement from a development perspective – far simpler than adding a chapter on your story or designing a new character.

Note that if everyone can see each other’s wearables, a feeling of superiority is promoted in your game.  These big spenders are paying for higher status in your game, and your community will look up to them (or at least the buyers will feel that).

The most profitable category for games in general is power-ups.  More powerful weapons, better armor, grind-reducers, and the like.  When you’re working on this, keep in mind that most English speaking audiences despise the concept of paying for a competitive advantage.  Figure out ways to provide power-ups while keeping the playing field level – or at least the appearance of it.  This can include experience boosts, paying for something that can be unlocked in-game, or keeping your scoreboards separated.  If you can integrate paid power-ups without angering your players, your sales will show that they appreciate it.

<img> – Numbers taken from gamesbrief, revenue per resource.  Mention source.



When you have completed 95 percent of your journey, you are only halfway there. – Japanese Proverb.


Polish: A Definition:

Polish is one of those vague, catch-all terms for the final “five percent” of a game’s development.  It’s the difference between a bad game and a good game; a good game and a great game.  Polish is about tightening the code, improving the assets, and tweaking the gameplay.  And if you’ve been a well-behaved developer with your architecture, it should be fun too.

The obvious bug fixes and known problems aside, you’re probably wise to start with a few checks on memory management (if you’ve been neglecting it).  Flash developers are blessed with a garbage collector that removes objects from memory automatically – but a single reference attached to a dead object will keep it in memory.  (It also won’t eject from memory anything too big – which is exactly the sort of thing it should do to prevent problems).  As for optimization, don’t be too academic about it – if it works on a low-end device, then stop optimizing.  The only reason to go beyond that would be because the gameplay is suffering from the limitations of your system.


The Asset Pile:

Working through your assets – music, sound effects, menus, graphics, animations and more – keep an eye out for anything that removes you from the experience of your game, even slightly.  You want your game to be a unified whole – if something doesn’t fit, change or cut it.  Just because a lot of time and money went into that massive intro animation doesn’t mean it’s a good idea.  It can be extremely tough to make those cuts to some excellent pieces of work, but if it doesn’t contribute to the game as a whole, you’re better off without it of it.

<img> – Steambirds first pass at art, and it’s final style

This is one of those cases where we as a human beings are better off without our higher functions.  We have a terrible, terrible notion of value, assigning past costs to current value.  It’s the same reasoning we use when we keep pouring money into a broken car – we’ve already put ten grand into fixing it, so spending another thousand dollars is better than losing the money we’ve already ‘invested’.  Do yourself a favour and ignore the ‘value’ of whatever asset it is you’re judging.  It is worth absolutely nothing unless it helps your game.


Aside: Upending the Tea Table

There are a variety of stories from Nintendo’s various development teams when Shigeru Miyamoto comes to visit.  He has a habit of ‘upending the tea table’, essentially telling development teams to discard massive amounts of work after spending a few hours evaluating it.  In their mind, the value of that work could be measured in months of development and thousands of dollars.  In Miyamoto’s mind, if what he saw wasn’t working, then it was hurting the game and was worth less than nothing.  The ability to identify these problems combined with the authority to throw out the work behind them have made Miyamoto a legend.  It is a skill well worth honing.


The Tweak Phase

What changes about your game when you reduce your ammunition to a single bullet?  Is it more fun without that power-up you built?  If you’ve done a good job in your development, making these sweeping and radical design changes should be easy and prove fascinating.  But at this point, you may no longer be the best judge of design changes.  What makes your game interesting to you may turn away the audience you need to succeed.  To start nailing down the details that will turn your good game into a great one, you need some responsive and honest players to set you on track.


Feedback is King

I’m just going to come out and call it: getting fresh player feedback is the most important step in game design.  You have all of about thirty seconds for your player to have a nearly calcified impression of your game (which is why you need your testers to be in constantly fresh supply).  The psychology of it suggests an even lower number – that first impression, that “Blink” reaction that Malcolm Gladwell identified, takes a fraction of a second.  So if it takes just a few seconds to get a player’s summation of your game, and a few more seconds for them to put it into words for you, it should only take a minute or so for you to get some honest feedback from someone.  But it may not be useful feedback – they may tell you something you already know, they may hate your game concept for reasons you can’t discern, or they may just be unable to communicate what exactly their impression is.  Alternatively, your testers may not be honest about their feedback.  So you have a minefield to navigate in order to get constant, useful feedback, and that’s only if you have a supply of users at your disposal.  But if it’s the most important step in game design, how do you go about doing it well?  For years the answer was either to have lots of money or lots of resources.  But today, we’ve got a much cheaper and far more accurate tool: analytics.


Supplying Yourself with Meaningful Analytics

There are a number of tools you can use for analytics – everything from making a custom solution for yourself to using something like what Playtomic offers.  But no matter what you choose, you need a fast and reliable method for both collecting and making sense of reams of player data.  How long they play for, when they quit, if they turn off your music, how many times they die, how long they stare at your launch screen, if they leave it inactive for a while, if they come back, if they name themselves, if they encountered any errors… the list of useful data can go on forever.  But since those first few seconds are so formative in the player’s minds, your analytic data should be front-loaded.  Every single expected step for your player to take – from clicking on the start button to the end of your introduction – should set off an analytic flag.  It may sound like overkill, but finding out that users spend a disproportionate time before their first button press may point you towards a major design problem that you wouldn’t find otherwise.

<img> – Graph of TumbleBall’s adoption rate in the first five minutes.

You can assume a tremendous amount from looking at the graphs your analytics have provided you with, but you also need a method to ask your players some simple feedback questions at various random points.  Asking them to rate the game out of five based on their experience so far is a great start – as long as you have some data to pair it with.  Low ratings coming from users who have played for two minutes and high ratings coming from players who’ve played for five minutes points to a design problem that comes in the first two minutes of play.  You can either rely on your own ingenuity to solve the problem, or simply ask your players for a little help.  A comment box, matched again with your analytics, can be extremely helpful.  The more users you have testing out your game, the shorter those comments should be, to keep your sanity in check.  Ask yourself what would be more helpful – a dozen articulate comments or an entire word cloud made up of hundreds of contributions.  Different games and different stages of testing will call for different approaches.  Keep it fluid, keep it agile, and keep it current.

Remember too that statistics that are interesting to you are not necessarily the statistics you should be basing your design on.  Rockstar, the makers of Red Dead Redemption, released statistics showing that players killed more birds than any other species in the game, and participated in bird shooting far more often than any other in-game activity.  It was interesting, but it showed nothing meaningful to the design.  Were birds picked on because they were a challenge to shoot?  Because they were plentiful?  Valuable?  Annoying?  Because they were bait?  Because they didn’t fight back?  Or was it due to a significant design flaw – that at anything less than a 42” HD television, birds are highly visible and all other animals blend into the landscape?  With no way to separate and evaluate the numbers you’re collecting, you may make design decisions that are completely contrary to the problem those numbers are trying to reveal to you.


Why is there a Button for Crouching?

One of the gorgeous innovations in gaming – or in interface design as a whole – came with the realization that a dozen in-game actions didn’t require a dozen buttons.  Context-sensitive action buttons saved ridiculously complex designs from themselves while providing players with more control then they were ever given before, and all with a single button.

Then the design world, from Apple to Nintendo, started to give their users less control.  They dropped functions and abilities in exchange for simplicity, but kept that context-sensitive approach to their remaining buttons.  Apple reduced it all to a finger swipe.  The console manufacturers reduced it to a flick of the wrist.  And with those impossibly simple actions, entire worlds have opened up.

<img> – Wii Tennis, a hugely successful game with no movement input.

What does that mean for your game?  It means that your audience is not just expecting but demanding an interface that feels minimal in interaction and robust in function.  When they run up to a toppled concrete pillar for cover, they don’t want to press an extra button to crouch behind it – they want their interaction with the environment to be understood by the game.  It should be automatic.  Look at your interface, the buttons, commands and functions you have.  Can any of them be automated?  If so, do it, and you’ll immediately retain more users.  Canabalt, a platformer, has no button for moving forward.  A significant barrier to the enjoyment of the game was removed – that’s a winning design choice.

After that, you’re left with the functions that you consider essential to your design.  Now your task is to further simplify it.  Can any of them be combined?  Can any of them be sub-functions to a more general command?  And most daringly, can any of them be omitted?  An elegantly simple interface should eventually feel automatic, and not something you have to teach.  Which is good, because the next thing you’ve got to worry about is teaching your players how to play.


The Tutorial

If you’re anything like me, you were brought up on console and PC games, which as a whole have horrible methods of teaching you how to play the game.  The implication is that because you’ve invested money in the product, you’ll also invest time in learning how to play it.  In a free-to-play market, that is no longer the assumption.  The working assumption now is that the game has to present itself to the player loaded with in-game learning and repeated reinforcement of that learning.

If you haven’t worked out something brilliant yet, now is the time to nail down teaching your game to your players, and assuming you’re breaking new ground, you have a lot to teach.  There are at least three things you need to consider:

  1. What is the minimum the player needs to know to get going?  What are the core actions of your game?  What is the absolute minimum you have to directly instruct the player on?  What can you assume they’ll discover on their own?
  2. How can you let the player learn at their own pace?  How do you keep your instruction brief and informative, but still make sure that everyone gets it?  How do you make sure the appropriate lesson has been learned before letting your player progress?
  3. How do you integrate it seamlessly into your game?  Can you use the same language and characters that you use for the rest of your game as instructional aids?  Can you keep the mood of your game (i.e. urgency) present in a learning environment, or will it need to be subverted somehow?


There’s nothing simple about teaching something simple – you have to assume that you’re teaching both idiots and geniuses all at once.  Thankfully, there are a few methods that are tried and true:


  • The Demo (i.e. Pac-Man, Joust, Super Smash Bros): This is where the game’s major concepts are presented to the player without their interaction.  It’s better than a page of instructions because it has visual reinforcement – but it’s still lacking.  Still, it’s sufficient for a game with arcade-style play.
  • The Guidepost (i.e. the God of War & Grand Theft Auto series): This is the idea that when the players need to know what to do, your game will tell them, through text, signposts, on-screen prompts, a ‘hint’ feature, or something similar.  It’s a kind of ongoing contextual teaching, breaking down highly complicated actions into a series of learning points.  Good for games that are built on sophisticated interactions between the player and their environment.
  • The Sandbox (i.e. Super Mario 64, The Zelda Series, Braid): This is the idea of starting your player inside a safety zone while they fiddle with the controls.  Long time gamers will proceed along the path you’ve provided them to more dangerous grounds.  Those less video game inclined will fiddle with the controls and concepts you’ve presented to them.  This keeps your player from getting over their head – the first time they encounter a problem, they’ll already have an idea of how to handle it.  Great for exploratory games and physics based games.
  • The Level Zero (i.e. Pikmin, Steambirds):  This is the safety level, a level with no option of failure, only progress and learning.  The best level zeroes are entirely player dictated, where their learning curve is dictated by themselves and not the game.  Keep in mind that it should be able to be completed in much less time than the first level; if it’s too long, you may find you’re better off without it.  Good for games where the depth comes from the strategic execution of given mechanics, rather than the depth of a hundred commands and features.
  • The Sensei (i.e. Sim City, Nintendo’s Super Guide feature): The Sensei is the game-long guide that lets you make mistakes and then suggests how to correct them.  It assumes that your player’s willingness to learn from their own mistakes is greater than their willingness to be taught up-front, and is more about subduing frustration than anything else.  Great for long-form games about growth and games with lots of unique obstacles.


Pick a solution that’s best for your game, integrate it, and let the players get through it at their own pace.  Above all, remember that you are showing the player what to do, not telling them.  It’s much more psychologically rewarding to be ushered towards the answer to a problem rather than outright told.  It’s as simple as the difference between “Press the Space Bar to Jump” and “Press the Space Bar”.

<img> – Braid Space Bar in Hill

After all of that, if you’re having trouble communicating to your users exactly what it is that you want them to do, there may be a design problem.  You may have made a game that’s too complex, and now are forced to either release a game that’s dead on arrival, or cut mechanics that you were proud of but that confuse your players.


Are You Asking Your Players for Money?

I have seen countless game developers sell themselves short and cut deeply into their profits with a simple, regrettable, and fixable mistake: they do a bad job of asking for their user’s money.  They bury their offers in a corner of the main screen, or even a sub-menu.  Worse still, the players can go on for hours without ever seeing any option to buy anything.  In marketing terms, that’s a complete failure.

A big part of your polish phase heading into release is making sure that your offers for in-game items and content in exchange for their money is repeated, transparent, and enticing.  And get over your fear that advertising is inherently annoying.  It’s only annoying when it takes you out of the experience – embed it into your game seamlessly, and no one will complain.

Repetition of your offers is about making sure that the player can always purchase things between levels or between deaths.  It’s not about always asking for their money, but rather always offering them more to play with.  Put your free (or in-game currency) offers with your paid offers so that your players get used to looking at them.  If you make a habit of hiding them, your players will only get annoyed when they see them.  Regularly pitching your wares to players will ease them into the idea of buying from you.

Transparent offers are more enticing than mysterious or poorly described offers (which is partially why selling a hat is more successful than selling a level).  When your player makes a motion in your game for more information (by clicking or hovering or whatever) then you should make that information readily available and totally transparent.  Don’t lie, don’t exaggerate, and don’t leave anything as a surprise.  The phrase “… and more!” only works if you actually tell them what the ‘more’ is – leave them hanging, and it’s no longer a transparent deal.  You stop sounding like a source of information and more like a salesman, which will aggravate where you meant to inform.

Enticing your players to buy your wares is an art.  Obviously, the pricing can be significantly enticing, especially if there are ‘bulk’ deals.  But regardless of your pricing structure, the most enticing thing you have to offer them is information.  If you’re being transparent, you’re halfway there.  But you can show them much more than you can tell them, so let your players play.  If what they are buying is not a direct extension of something they’re already experiencing (like a power-up to an existing mechanic), then let them try it as a trial or demo.  Let them see a small version of the paid experience in action – if it’s worth their attention, then it will be worth their money too.

Remember that during all of this, feedback is still king – getting new users to try your tweaks and additions on a regular basis will provide you with vital information about the direction you’re headed in.  Once those users are confident in your game, then you should be too.



My play was a complete success.  The audience was a failure. – Ashleigh Brilliant, 1984.


The First Platform

The first decision you have to make regarding your release (a decision you’ll make during development) is the target platform.  This very concept is in flux at the moment: a game developed in Flash and distributed as a SWF can be added to Google’s App Store, but different developers will argue about what exactly the ‘platform’ is in that example.  Regardless, your players have to have a way to play your game, and you hopefully have some method in mind, such as…

  • Facebook:  Facebook has set their policy for games based on the policy they’ve pulled out for the behemoths already working in the space, which is at best a mixed blessing.  It has flawless distribution, incredible traffic, and a very robust series of tools to access their community.  The downsides include some million dollar competition and adhereing to their platform rules.
  • iThings: Apple has an enviable position as the distributor of a massive number of applications to an audience that can’t seem to get enough of them.  Apple has a strict developer agreement and takes a 30% cut of your revenue, and the best-selling apps tend to continue to be the best-selling apps, with very little movement at the top.  It’s a highly competitive market with the vast majority of the money being spent on very few games, but there’s certainly room for new ventures.  Don’t overestimate their audience though – apps are big business, but Apple isn’t nearly as omnipresent as Facebook.
  • Other Mobiles: No other mobile device has the marketing power that Apple has made for themselves, but the Android market is picking up.  Remember too that those markets are under-served: what may go over tepidly on Apple’s store could fill a need in the rest of the mobile market.  (i.e. Spryfox’s Kindle games)
  • Browser-Based (Flash): Flash games are a huge market that traditionally has had problems monetizing itself.  That’s changed recently, but some of the major Flash portals are still extremely resistant to developers making any money besides sponsorship and advertising deals.  The majority of the success stories have come from developers testing the waters in the Flash world and making their money through sponsorships, then releasing an updated version which seeks to monetize through app purchases or micro-transactions in a sequel.  The Flash market makes more money every year though, and despite new competition, hasn’t slowed.
  • Browser-Based (Other Plugin): Unity is the major alternative to Flash but its track record as a successful business model for developers is slim to none.  Other plug-ins are a dark horse market that can definitely be pandered to, but the chances at success are low.
  • Browser-Based (No Plugin): There’s been a lot of talk about HTML5 and javascript replacing Flash as the primary method to have game-like content on the web, but until there is a method of simple distribution to thousands of sites (as there is for Flash), it’s a fantasy.  It’s still a great method for browser-based games that don’t require wide distribution though, especially with Google’s recent push to make the browser the access point for all of their apps, and Abode demoing a program that converts an entire Flash file into HTML5.
  • The Big Three: Releasing for Sony, Nintendo and Microsoft was once a pipe dream unless you had an established pedigree and a lot of money.  That’s changed, but the vast majority of the indie games for all three services started on other platforms and were updated for their markets.  It’s becoming more common for one of these to become the last platform a game is released for.
  • Steam: Valve’s Steam service has a relatively small user base (compared to Flash or Facebook) but because Steam has such control over their content, the user base has come to expect excellence and tends to spend a fair amount of money.  It’s a rough process to be approved for release through Steam, but once you’re in, the income is all but guaranteed.  It’s worth trying for, but unreliable to plan for.
  • Desktop Downloadable: Minecraft has proven this is not a dead concept, but between piracy, hacking and a general platform abandonment, the PC is one of the toughest platforms to target, especially with Google muscling into the operating system market in 2011.  Still, an under-served market can be a fantastic opportunity.


That is by no means a comprehensive list, nor is it an advertisement for one platform over another.  There is no correct platform to choose, because it depends largely on your strengths as a developer, and the audience you’re trying to reach.  A fiercely single-player game probably won’t explode on facebook.  A game that is played best in hour-long sessions will be looked over in an iPhone release.  A game with an on-going tutorial probably won’t succeed in the a browser-based game where the attention span is fleeting at best.  Pick out the advantages and disadvantages of each market and match them up with the unique opportunities in your game.


The Illusion of Completion

If you’ve been listening in on the world of design and art, you’ll notice that there’s talk about the devaluation of the “finished product”.  Museums are displaying more interactive works, artists are coming up with new ways for their works to be active and changing even when they are no longer involved, and audiences are more frequently sought for their input in the creative process.  Major advertising, which mirrors society as a whole, is increasingly showing us more of the process and less of the product.  We are becoming more interested in the malleability of our culture and its never-ending remixes then we are with the finished projects.

What does that have to do with your game?  Simple – even if you think you’re finished, your game won’t ever be ‘complete’.  Software companies and developers that insist on releasing stable and bug-free products nevertheless suddenly find themselves with a need or a desire to send out an update of some nature.

What that ultimately boils down to is three major considerations: the ability to update, the ability to tweak, and the ability to know when those are needed.


  • Updating: The ability to update your game for your users is either helped or hindered with every decision you make about distribution.  If you are in complete control, then updating your game can be as easy as uploading a single file.  If you’ve given control to the people and organizations that are helping your distribution, make sure that they have a painless update protocol in place.
  • Tweaking: Tweaking your game in response to your users should be painless and shouldn’t even require a full update.  Use a method like storing the values of some of the variables in your game on a server, so you can change them at a whim.
  • When to Update and Tweak: You need a way for you to find out, reliably, what your users are experiencing so you can provide timely and accurate adjustments and fixes.  You could pour through comment threads for glimmers of insight, but you’ve already implemented a tool for this: analytics.



Analytics should give you a breakdown of just what your players are doing in your game, from which weapons they choose to how far they get to how often they die.  Look at those numbers on a chart, and you’ll find out precisely where your problems are – if there’s a big user drop-off in users during level four, and a corresponding spike in the average number of level four deaths, then there’s absolutely no guess work about what needs to be done.  And if after your users buy that power-up they use it and never buy again, then you know that item has a problem that you should fix.  If your analytics are well done, then fixing these issues with a crystal clear view of the underlying problem should be a snap, provided you’ve got a tweaking and updating procedure in place that’s easy to rush through.

<img> – That famous Playtomic graph.


Setting Your Price

If you are releasing to a market that will actually pay for the download of your game (like Apple’s store), then you are forced into a decision at your launch about how much you should charge for your game.  Even in the days of shareware prices never went as low as 99 cents, but that’s the new standard price if the game isn’t free.

The pricing decision on release comes down to a simple either / or proposition – either you charge for admission to your game, or you don’t.  If your entire business model relies on making money up front, then this is a no-brainer.  But if you’re trying to make money in-game from consumables or wearables, then your choice is a lot more muddled.  Do you give away your game for free and hope that your in-game sales make up for that lost revenue?  Or do you charge up front to help cushion against a failure?

There are a lot of variables to consider, and the biggest unknown variable is success.  There is no right answer here, but there is a right direction, and it goes back to the power law.  


The Las Vegas Business Model

For years a “free-to-play” business model was counter-intuitive outside of the glittering lights of Las Vegas.  Nevada has long been ahead of the curve on this one, with a business model that media around the world is beginning to emulate.  Las Vegas does the vast, vast majority of their business with a small minority of their clientele.  These are the big rollers, the convention hall renters, and the title fight organizers.  These top 5% are responsible for 95% of the Vegas income.  So what’s the point of catering to the millions of tourists who only make up 5% of their bottom line?

Two reasons.  First, every person in that bottom rung is a potential convert to the to 5% who pay for Vegas for everyone else.  The second reason is this: in order for the high rollers to feel like hot shots, it’s not about the money – it’s about the status.  You need those throngs of people swarming around, or else the elite suddenly doesn’t feel so elite anymore.  And Vegas goes out of their way to make them feel on top – the more you spend, the better the perks, from drinks at the tables to a free stay in the presidential suite and far, far beyond.  And their customers keep spending.  It’s the power law in full effect.


Making Your Game Free

The free-to-play business model is similar to the Vegas business model, but in many ways more powerful.  The first part is meeting your customers expectations on what they are willing to pay.  Let’s say you make a game and people like it.  At $10, people who really enjoy it will buy it up, but anyone who thinks it’s worth $5 is left with two options – don’t play it, or pirate it.  Drop the price to $5, and you have the same problem with people who think it’s only worth $1.  Drop the price to free, and suddenly you’ve maximized your audience – no one can claim that the price isn’t right.  You now have an audience that Vegas is jealous of.

After people have your game, you need a way to get $1 out of the people who think it’s worth $1.  You need another way to get $5 out of the people who think it’s worth $5.  And you need yet another way to get $10 or more from those super-customers, the ones who are in love with your game and willing to pay to continue playing.  Every playing customer is a potential paying customer.  Price your game at anything but free, and you’ve excluded thousands of players – and therefore, paying customers.  They will never join your top five percent of users who make up the majority of your bottom line.

This can seem risky and even reckless.  But if you and your test-audience have confidence in your game, you should be confident that it will make money provided you ask players for it.


Adjusting Your Price Points

Of course, the great thing about releasing in a digital network is that no decision is ever final.  Provided your publishing partners allow it, you are free to change your pricing as often as you want.  Launch at a premium price, test the waters, and drop (or even increase) your prices as you see fit.  Or better yet, offer a free version and widely advertise that it’s a limited time offer, then jump the price up for a while and see how it goes.  You have direct influence over your market – don’t be afraid to use it.

These changes will be fairly few and far between though – the pricing you have to monitor and tweak on an ongoing basis is your prices for microtransaction goods.  Using your analytics, identify your big sellers and under-performers, and tweak your baseline prices to encourage a nicely rounded in-game economy.  The closer you can align the pricing of your goods with your user’s valuing of those goods, the better off your financial situation is going to be.

And of course, don’t forget the allure of limited time offers and sales.  You can either provide regular sales of a random assortment of deals (which will generate timely buzz) or you can provide user-specific sales, tied into their gameplay history and style (or their birthday – get creative!)  Better yet, provide both kinds of sales and track the analytics on them to see how your energies are paying off.


Going Multi-Platform

Assuming a certain basic success, your game will be stable and active enough to encourage you to shoot for other platforms.  This is the only time I will ever encourage you to create new content: a new platform is an excellent opportunity to launch new features, new game modes, new animations, new music, or pretty much new anything.  It’s a fantastic way to give your community the kinds of things they ask for while at the same time making them pay for it all over again.  Re-releases on new platforms have inherently bad connotations, including assumptions of greed, that you’ve turned your back on your original fans, and that the port to a new platform will be inferior in some way.  By adding new content into your re-release, you can turn all of those assumptions on their heads, and turn bad publicity into good publicity.  Everybody wins, and you get to try out a little something you cut from your game montsh ago because of feature creep.

At this point, congratulations.  You’ve designed your game for success, and it’s paid off.



There are a few takeaways that I think are the most important pieces of game development in the current market:

  • Prototype – Your idea isn’t proven until you prove it.  Get it done before anything else.
  • Gameplay is All – Gameplay is your top priority from early in development to late into polish.  If your gameplay is obscured, start cutting until you can see it again.
  • Content Kills – Creating a static puzzle with one solution is a needlessly risky path for indie developers.  Creating a dynamic puzzle with infinite solutions is a much more viable path to success.
  • Feedback is King – Without a constant supply of fresh pairs of eyes, your design is slowly going to need major changes to get it back on course, which are admittedly hard to justify.  Get feedback, get it often, and get it from new sources to save yourself from yourself.
  • Mind the Power Law – The bulk of your revenue is going to come from the best five percent of your users.  Make sure you have a way in your game for them to give you money, or you’ll never get it.


Above all, the most important takeaway is that this entire essay has been a suggestion.  Take it, cut it apart, test it, argue with it, ignore it; as long as you give it some thought.  We’re a community of like-minded individuals and peers.  Here’s hoping that all of our next games are successes.


Aside: Notes and Thanks

I feel I should mention that I am by no means an expert in this field.  This essay is as instructive to me as to anyone else – writing it was a process of research and not of intuition.  It is a combination of everything I learned making a game and watching it’s release, and my more recent research on successful game design.  What I don’t know could fill an astounding number of books, which in fact it has.  Again, taking my words with a grain of salt would be advised.

Many of the insights here are reiterations of four industry pros in particular: Daniel Cook, author of Lost Garden and one of the heads at SpryFox, Andy Moore, Steambirds creator and prolific blogger, Nicholas Lovell, author of How To Publish a Game and the writer of GamesBrief, and Ben Lowry, the man behind Playtomic and a huge proponent of analytics in games.

1 Comment

  1. Hi, your article is spectacular with so many good insights, many thanks for that.

    I’ll be following your blog and read your articles, I’m a web developer that are studying to make the first game in Unity for Android apps and this article really really help in my study, I really appreciated.

    Hopefully in the future when I launch my simple game I can make some profit thanks to your tips.

    Sorry for the english, I’m Brazilian.


Leave a Reply

Your email address will not be published. Required fields are marked *