Category Archives: Design Analysis

The Prototyper’s Dilemma

I’ve been rather quiet of late, mostly because I’ve had quite a bit of design stuff going on. Not only is the LoLCG project now worthy of the title- a project of more than one- but the prototypes for Wild Abyss arrived and getting both sleeved, sorted and played has been taking up pretty much all of my time.

There are other things in the works, too, but I’ll leave those for later. I have the next part of the ERI framework series about half done as well as a bit of writing on bioshock: infinite, but I think the latter has been done to death so it probably won’t see the light of day.

In the meantime, I’d like to talk about a particular issue I run into as a developer, that might be interesting for other people interested in taking their design a bit more seriously. It has to do with that most terrifying of processes, playtesting. I’m also going to use the opportunity to show off some of the goodies I’ve been working on that have been keeping me quiet.



In any game design, it’s important that you go beyond the people you are familiar with for testing purposes. Whether that’s your inhouse studio folks for an indie developer or a regular gaming group, these people will be familiar with you, your style and idiosyncrasies. They’re good for providing people against whom the most basic of tests can be performed, but beyond that any data you get from testing with them is likely to be inaccurate compared to how the game may perform in the market.

So you need to go about finding independent playtesters. If, like me, creating a commercial NDA and paid testing environment is impossible, that means finding volunteers from outside your normal circles.

This is where the prototyper’s dilemma strikes. In a perfect world, you could post your paper-slip prototypes and nascent ideas on the internet and get a bunch of enthusiastic, capable playtesters interested in a moment. In reality things are a little more difficult. Back when I was 14, I spent around 3 years prototyping and developing a warhammer army book. I wanted to make sure this thing was balanced and interesting, so I tried to organise playtesting. That experience taught me more about game development than all my university education put together. If you want to get tests done, you need to present your testers with a product that isn’t entirely dissimilar to the quality of commercial product they are used to… or at least one that looks like it. You need to get them to buy into what you’re doing through giving them a clear indication of just how serious you’re taking this. Hand scrawled notes on notepad paper do not do this.

One of the reasons the LoLCG looks so spectacular is because of those lessons I learned. You cannot get good, unbiased testing happening without that level of production pre-invested in your designs. Enthusiasm will fizzle, tests will be delayed, people will drift away and you will lose momentum or end up getting frustrated and making decisions based on insufficient data. To keep people attached to the project, you have to give them something that, even if it doesn’t play that well, looks and feels like it should.

The dilemma, however, is that a playtester coming in from the cold, especially one with little experience of the development process, will look at yourdesigns and assume that’s the best you can do, that your first prototypes are the equivalent of a videogame public beta, when in reality the guts of the game are about as polished as a rotten stick in a peatbog. This in itself creates expectations and dissappointments- I’ve found people tend to overlook the visual design of the LoLCG cards in order to focus on the text because they feel the text is more important.

While in the long run, that is true, the text of cards and the precise wordings are the last thing that needs polishing during the card design process. First the parameters under which those wordings must be constructed must be established- how much space do we have, what symbols are available, how many can we use before the cognitive burden becomes to high. There needs to be text there for the testing to actually be valid, but the balance of these texts is by nature rough and ready until it can be established what the restrictions under which a polished version must be constructed are.

Unfortunately, the sort of people likely to volunteer for playtesting are the sort likely to fixate on these sorts of discrepancies and thus you end up distracting your testers from simply playing the game in a relaxed, open state where you can get good information on how the areas you want to isolate are working out. Add on the natural focuses of the various kinds of players, whether you use Bartle’s suits metaphor or Mark Rosewater’s timmy, johnny and spike etc, and life is hard.

So this is the Prototyper’s Dilemma: Without achieving superficial similarity to a finished product, you will not be able to attract and retain testers. The more effort you spend in that regard, however, the more your testers will have unnatural reactions to the parts of the material that most need testing.


I’ve discovered that it’s not as simple as simply getting your game to the tabletop or screen as soon as possible, nor is it about polishing like a madman before doing any testing. Like many things in game design, there is an elegant balance to be struck between conveying the identity and overall mechanisms of your game effectively and not jarring your testers into over-analyzing things.

I should note that the impact of this is largely dependent on just how hardcore you take your design. For games like LoLCG and Wild Abyss, everything matters- colour choices, fonts, layouts, grammar, amount of cards, visibility, even the size of a playset.

This might not seem important, but it IS. If I want people to be able to realistically play a game, having a set of cards that will fit neatly into a schoolbag or a hoodie pocket or similar is the sort of thing I take into account
very early in the process. Isolating and testing these kind of dynamics is really important to getting the desired experience for a player. Tweaking and perfecting mechanics are the last priority, not the first.

So, how to resolve this? Unfortunately, the point of a dilemma- in fact the very meaning of the word- is that there is no simple solution. Luckily, unlike the famous Prisoner’s Dilemma, this one isn’t exactly binary in its solution space. For Wild Abyss, I’ve taken what I learned from earlier games and attempted to create a prototype which strikes that balance. The visual designs are colorful at a distance but minimalistic and simply executed.


The result is a game that looks impressive but only took me around 30 hours to prototype from start to finish- less than a week’s work in the evenings. This whole game went from initial concept to first prototype in 16 days

While polished, this is clearly a first prototype- not least because it’s written all over the thing. The ship designs are just too far on the clumsy side to be finalized, the resource card designs are clean and generic etc. I’ve had a good reaction from my playtesters for this game- they’re happy to just play it, and aren’t overly inclined to focus on technicalities. The result is after only a few games I’m getting a lot of good information on where I need to make changes, and after the twenty or thirty more I want to get done with this first prototype set I should be able to make some really significant choices that will benefit the game based on solid, unbiased information.


When winning isn’t the point: actual objective design.

“It’s not winning that’s the point, it’s taking part. Well, it’s not the taking part, really, it’s the sense of hopeless despair”
-Bill Bailey

Today I want to talk about a complexity in dealing with the objectives of a given game. The issue here arises from a simple linguistic failure that has yet to be clarified in formal game design language. When I talk about a game’s goal or objectives I could be talking about two different things:

  1. The stated condition under which a game is considered to be beaten or won, formally codified in the rules.
  2. The actual goal of the game in more general terms- amusement, entertainment, the conveyance of some important idea or emotion etc.

For games designers studying the structural design and development of games, it’s very easy to be caught into only examining 1) when thinking about how to go about designing a given game or, at the very least, considering only how 1) can help achieve 2). 2) however, is perhaps more important in the process of creating a valuable, or at least marketable, product. So much so, in fact, that if 2) becomes the focus of design then 1) simply becomes another obstacle or resource bandied between player and designer towards this end.


Perhaps the simplest and most ready example of why this is rather important is a brief case study of the game Twister. Twister’s objective, to be the last man standing (well, contorting), is relatively meaningless in the face of the game’s actual objective: to facilitate a breaking down of social and personal inhibitions, enabling players to build up a sense of intimacy and familiarity with less risk of causing offense.

In this sense the game’s actual objective (to get people all twisted up around each other) is almost the opposite of its stated or systematic objective (to be the only one left, thus not having anyone else up close and personal)

While the game’s designers have never confirmed if this taboo breaking outcome was a considered goal in their design (not surprising given the somewhat more rigid social customs of the 1960s), it falls in line with a sizeable genre of such icebreaker games like truth or dare and spin the bottle, differing from these two only in that it has the systematic objective (a victory condition) where they do not.

Twister calls attention to the fact that the actual goal of the game may be different to- in fact, may be in opposition to- the systematic objective of the game. In a very literal sense, winning is not the point.


In order to apply this principle as a designer, it’s necessary to take a step back from the challenge of systematic construction and observe the context under which your game may be played. For many games, particularly videogames, the context of play is not a variable considered that deeply. There are, notable exceptions- digitized party games like the Mario Party, BUZZ! And Singstar series. The genre of ‘party games’ are in this way not defined by their systematic content, but by the context under which they are played and their actual objective of being sociable multiplayer experiences.

In a like fashion, one can create new super-genres for many games whose genre definitions rely on systematic content – solitary, social, antagonistic, collaborative, cooperative and so on. These super-genres provide a new reference point for considering the actual objectives of the game. Is a game intended to assist the player in learning certain problem solving techniques? Guide them to a new understanding of an emotive concept? Help in relaxing and untying the mind after a hard day? providing a vessel for social interaction? The more you think about it the more you realise that many games have unstated objectives entirely unrelated to the rhetorics of their systematic content.


Armed with this knowledge a designer can begin to make a lot more interesting choices themselves, not to mention provide more for their player, not the least of which is the recognition that the stated objectives of the game aren’t actually that important to either designer or player. It’s not the winning that matters, it’s the taking part.

Systems like achievements are one example of taking this perspective into account, but are a rudimentary approach even when used to help players experience the real point of the game rather than getting trapped on the win condition. Far more often, sadly, they’re included uncritically and thus do nothing but emphasis the game’s existing systematic focuses, rewarding the player for winning when no such reward is necessary.


Let’s take a hypothetical game whose core gameplay activity is exploration and discovery. The stated goal of the game is to get through various areas by combining objects found in the environment to prosper and proceed. The actual goal is to encourage players to come up with interesting and novel solutions to problems and experience the enjoyment that generates, preferably generating a rube-goldberg shaped trail along the way. As a designer, therefore, so long as a player achieves the latter, it doesn’t actually matter if they achieve the former. If proceeding to victory gives your players that sense of achievement and creation, that’s great! But you can make a game where victory gives little benefit and instead emphasis is placed on prolonging the experience: you can deliberately choose to make victory not the point.

For such a game, I might choose to design an exit that was immediately visible at the start of each level and easily accessible, so easily that any experienced videogamer would look twice. Combined with visually attractive side paths for those players who aren’t accustomed to videogame structures and perhaps some very gentle negative feedback for just running straight through, I could create an environment that encouraged players to explore and find all the fun toys I’d seed throughout the area.

I could emphasise cleverness in exploration by, for example, providing tantalising glimpses of spectacular or mysterious sights and hints of vantage points that can only be reached creatively. Build a psychology of soft rewards for effort to ease players out of the mentality that the only valuable actions give tangible rewards- points, items, narrative sequences and so on- and into the attitude that exploration and ingenuity for the sake of the scenery are their own reward. Provide a rival who becomes increasingly smug if the player rushes through but also provides a gentle reason to proceed after a time simply by reminding the player there’s someone to compete with, even if they’re (hopefully) more interested in looking around


This particular example comes from memories of my childhood, bushwalking through wild Australia. The climb through a scrub forest to a mountain vantage, sliding up and down deep dunes to find an ancient salt lake in the red desert, jumping from great tree-root to tree-root to get tiny, hidden streams. None of these destinations would have been half so wonderful had I not had time to get peeks and build up cramps on the way.

Using this as a basis for design is a perfect example of altering from a systematic perspective to one centered around creating a particular player experience. It’s impossible to systematise the objectives of ‘experience wonder’ or ‘feel a sense of achievement‘, yet these are perhaps truer goals for both designer and player than any ‘score 100 points’ or ‘beat all other players’.

So step back, consider for a moment, what are the actual objectives of your games? Do those games make sacrifices to these for the sake of having a well defined stated objective?

Never get caught up in the rhetoric of your own games- the stated goal is just another lever, just another trick to get the player to experience the world a little bit more like how you want them to. The real goal is more elusive, unstated and infinitely more powerful and rewarding if directly manipulable.


Posted by on May 29, 2013 in Design Analysis


Indepth: economies of time

This week I’m going to have a look at time economies, which is to say the way players allocate their time during games. Economies are a pretty basic part of game design, any time you have a limited resource it generates an economy for that resource. Since the advent of the videogame, time has become an important one of those resources, but even in games that are technically not time-constrained, time is often modeled through limiting actions per turn or some other similar mechanical resource. This article will look at both designing a real-time ‘attention budget’ and and interesting example of a simulated time economy, specifically in Android: Netrunner.


Time is one of the most fundamental resources available for a game designer to manipulate. In videogames you’ll usually find it taken into account either in terms of player attention- providing a greater amount of time spending activities than the player has time to perform in order to force them to make choices about where to focus their attention, or in terms of commitment- going to the store takes 30 seconds, going to the healer takes 30 seconds, and overall time is limited in a very similar manner to a cash-resource system- you only get 30 seconds before the next wave of baddies, so you have to pick one and stick to the decision.

Precisely because it is so fundamental it is easy to overlook as a subject of design and analysis, but examining how time is handled in a game can often be incredibly fruitful in problem solving and generating new ideas.

A particularly valuable exercise, and the one I’ll focus on here, is plotting out how much time you intend players to spend on particular aspects of your game, either overall or focused in on a particular area.

Lets say I’m designing an RPG. How much time do I want my player to spend exploring? Fighting? Reading/watching narrative stuff? Browsing their customization menus?

In a fight, how much time should be spent making actions and controlling characters? How much spent planning and strategising? How much watching the action unfurl?


If my focus as a designer is on the the narrative immersion of the player, I might want weight the player’s time economy on talking to characters, exploring the environment and engaging with the stuff I spread through the game. If my focus is on a particularly elegant combat mechanic set I’d come up with, I’d want to push a player to invest more of their time exploring that to get as much out of it as possible and so on.

So in this way you can start building up a fairly complex ‘spending plan’ for time, something like this:

early game 

  • 40% exploration/familiarisation with setting
  • 40% experimentation/learning mechanics
  • 15% combat/achievement
  • 5% character customisation


  • 20% exploration
  • 30% experimentation
  • 40% combat/achievement
  • 10% character customisation


  • 5% exploration
  • 5% experimentation
  • 70% combat/achievement
  • 20% character customisation

This one is just off the top of my head, but you should be able to get the general gist of it. In the early stages of the game I want to invest the player in the setting, get them comfortable and encourage them to spend time messing around and getting a feel for the mechanics and what does what. Combat and character customization are light and more intended to add flavor and points from which to build learning than challenge

In the main section of the game, I want the player to move their time balance out a bit. Still spend a lot of it figuring out the mechanics, as this is one of the key components of engagement in almost all RPGs, but now they’ve got a model of what’s going on to work with, I want them to spend more time mucking around tweaking their character than digging into the background material.

In the last stages of the game, the world has largely been explored and the plot established. I want the player to have figured out how all the various mechanics of the game interact and so not need to spend time mucking around- they should know how they can approach the challenges the game throws up. So we turn that up to 11 and give them a flood of such challenges to reward the knowledge they’ve built up. As with most RPGs, the last stage will also be accompanied by a fair bit more fine-tuning and tweaking of characters to overcome the challenges thrown up.


By going through the process of establishing a ‘time economy’ you do a very important thing: you give yourself clear targets and goals in your design. You can look at the way your prototypes are developing and say- ‘man, people are just not getting into this setting enough, I need to give them more things to spend time on there’, or ‘people are just fighting all the time, I have to give them incentives to slow down a bit and look at the scenery’

I should be clear that this time economy is the one you think best expresses what your game has to offer. Individual players will always have preferences and will lean towards one or another kind of time spending, so you want to give them room to do so- nothing sucks more than a game that rails you into spending exactly the amount of time the designer prescribes on something, no more, no less. Your designs upon the player’s time should be guidelines, not hard and fast rules (unless you’re using time itself as an acknowledged resource for the player to spend, of course).

This isn’t just a useful tool for videogame designers though- I recently played Eclipse, one of many 4X boardgame attempts. Though it’s apparently one of the more elegant products of its type, I found it incredibly clunky. I did a kind of time budget in my head as I played and for the small scale, three player game mode we were using (which is apparently the fastest and most intense), the time budget for players seemed to be something like

  • 30% setting up the game and putting it away
  • 20% figuring out what you want to do
  • 5% doing it
  • 35% waiting for your turn with nothing to do

This is even accounting for the fact I was a first time player, having to figure out all the mechanics on the fly and that there were only 3 players of a potential 6. Any designer worth their salt should be able to look at that outline and immediately see that there’s some seriously frustrating games waiting to happen. People might be willing to tolerate it because, admittedly, the actual gameplay is pretty solid. Tolerance, though, is not a pretty word.


Another note is that I’m using very general stuff for my time economy profiling here. If I was designing half-life, for example, I might budget for things like ‘physics puzzles’, ‘travel’ and ‘recuperation’. Again, by making you put your thoughts down on paper, doing this sort of analysis will help you identify these categories of behaviour and action

One last thing the time economy does is really force you to pin down what you want your game to be about. You only have one hundred %’s to play with. Your player can’t be gazing at your amazing backgrounds 80% of the time and fighting desperately for their life 80% of the time. So planning out a time economy isn’t often a fun task for the designer. Just as much as the player, you want All The Things, but you know as a designer that is rarely a good choice in design. Figuring out your game’s time budget forces you to put, in paper, where you want your player to invest their time and, consequently, where you should invest yours.


The second part of today’s discussion is perhaps a bit more palatable for the more math and statistic oriented crowd. If you don’t like bouncing numbers off each other, however, this next bit might not be for you.

As part of working on the League LCG, I’ve been studying up on the market. In particular i’ve begun to play Netrunner with friends and watch a lot of content there to get a feel for how FFG are managing their LCG model. It turns out Netrunner is a really good game as well and one that has some really nice mechanic/dynamic outcomes that revolve around time as a resource.

Netrunner is somewhere between Magic and chess. Where in Magic you can do whatever you want in a turn so long as you do it at the right time and you have the resources and in chess you can do one thing once per turn, in Netrunner you have a limited amount of actions per turn, but those actions are pretty versatile. Most important for us here are three- you can spend an action (you have 3 or 4 per turn) to draw a card, earn 1 unit of currency (bit) or play a card.

First up, this instantly tells us that these three actions are of equivalent worth. Drawing a card is worth 1 unit of currency, as is playing a card, and so on around in a circle.

So, for example we have a card called Diesel.

It seems pretty amazing (if you’re a magic player anyway). No cost, draw 3 cards. holy moly. But in Netrunner, playing this card costs an action, which you could use to draw a card anyway. So you’re only really up 2 cards. Not only that, but it doesn’t actually do anything for you but give you more cards, when Netrunner puts a premium on getting a lot out of your cards. So that’s really another card down. All in all, you’re up 1 card over just spending an action to draw.

Then there’s a card called Quality Time that costs 3 bits to draw 5 cards. So the card cost is 1 action to play and 3 actions to earn 3 bits to pay for it. Four actions total. In magic, it would be utterly broken, but the time limitations in Netrunner make it, at least without considering synergy, worse than Diesel.

Netrunner, however, is a subtle beast. In general, a card on its own only gets you ahead of your basic actions very slightly- with increasing power based on how hard it is to play. For example, there’s a card that costs nothing to play and gives you 3 bits, for a net bonus of 2. There’s another card that costs 5 to play, but gives you 9 bits, for a net bonus of 3. Because as a condition of play you need to have 5 bits lying around, it’s a little bit more efficient- but only a little bit. Other cards are even more efficient but have trade-offs.

Pad campaign gives you money every turn, but it costs money to play, so you need to keep it alive for 3 turns to break even (1 to pay for the action spent playing it and 2 for the actual cost) . Once you do, however, it’s a gold mine. Because it gives you 1 bit WITHOUT costing you an action, you’re effectively getting an extra action per turn- going from 3 to 4, an increase of a whopping 25% in efficiency from one card. So if your deck can keep it alive, it’s amazing.

Typically, your opponent has to spend 1 action and pay 4 bits to ‘kill’ it, so it costs them 5 overall to get rid of it. If they do that right away, you end up 2 bits ahead, but some cards let them kill it cheaper or give them free money to do it with, so you start getting this incredibly complex time-economy where players are trying to end up coming out ahead by 1 action worth of a resource- be it a card, a bit or something in play. Over the course of the game, a couple of good action ‘trades’ like this can give you a lead to let you do something that would be impossible if both of you were on even footing and thus win the game.


Coming back to our original cards, Diesel is a great card if your deck has, for example, a lot of low cost cards, so each card draw action is worth comparatively more than if your deck was full of high-cost cards that put a premium on taking actions which earn money. If you have a lot of synergy that allows you to efficiently generate bits, then quality time becomes a better card than Diesel, since that 3 bit cost may only convert to one action, not three.

In this way, Netrunner creates a complex dynamic of time management in a non-realtime setting. A player feels incredibly constrained by their few actions, so tools which give them more ability to act feel liberating and powerful. Because pretty much every economy card gives you one or two actions worth of resources overall (excepting some which give you more but as a drip feed like pad campaign), how you fuel your economy is entirely dependent on card synergies and the structure of your deck. Time is expressed as a resource extremely successfully and good, efficient Netrunner decks are all about time management- creating efficiencies that give the player the time to execute the strategies necessary for victory.


So there you have it. Time is something that you can explore as both mechanic and dynamics. As an overall design tool you can plan out how time will be spent playing your game to focus and clarify your design and give you signposts to use during your testing and iteration. You can also use time in a more focused way as a resource in games which aren’t formally time-constrained in order create an aesthetic of intense action without forcing real-time constraints on the player.


Design Theory: Deconstructing Iteration

Iteration is one of the most fundamental practices in the videogame industry. It’s the core around which every major company and almost all the minor ones structure their development. It’s a powerful, reliable tool. It’s also a problem. Like many methodologies that arise in industry, developers adopt the model without critical analysis of where it is best used and where its flaws are. The result is that the universal adoption of iterative process has perhaps done harm as well as good.

For new readers, I adopt a somewhat… adversarial style. I think that the more valuable and awesome something is, the harder you should try and identify the problems with it. So take the pithy negativity with a grain of salt, I’m trying to make you look at something harder than you otherwise might



Iteration is the process of developing a product through incremental adjustment. A product is developed and then tested. Based upon feedback and impressions of the tested product, it is adjusted towards a more desirable state, tested again and so on. The operative words here are adjustment, feedback, impressions and desirable.

Adjustment: Iteration has difficulty changing or reversing directions sharply and nimbly. Once locked into iteration, it’s hard to change broad strokes.

Feedback: Iteration depends upon testing, which means that the more iterative a process, the more bumpy the flow of asset development must be.

Impressions: A given iteration rarely has the luxury of undergoing deep analysis. Adjustments are more often made based upon shallow impressions due to limited time.

Desirable: to iterate towards a desired state, that desired state must be known. The more detail about the desired state is known, the more powerfully and effectively iteration can be directed.




So iteration is fundamentally a polishing tool. It doesn’t reliably create great gameplay from nothing- it just takes what you have and smooths things out. It’s interestingly similar to genetic development* where occasionally some tweak that comes out of the iterative process proves so wildly successful it becomes a genre defining mechanic. Over a whole group of such projects, each adopting the iterative discoveries of their neighbors, you arrive at a kind of progress that is fundamentally quite random, but in practice slowly pushes towards the desired state.

The complications of this model are again similar to those with genetic development. It can’t really make any revolutionary changes, because it must develop in incremental steps from existing templates. A fundamentally flawed template will remain fundamentally flawed no matter how much it is iterated upon and any serious change in direction will require some messy improvisation based upon the existing template. It’s inefficient, since even with a developer directing ‘mutations’, the very premise of iteration acknowledges a lack of surety. The less certain of how to get the desirable outcome it is, the more inefficient iteration will be.

This creates a sort of paradox: the more you understand where you want to end up the less you’re inclined to iterate, but the more powerful iteration will be if you do use it because you can more efficiently make use of the feedback that iteration generates. The less you understand how to get to where you want to be, the more you’re inclined to use iteration but the less efficient and powerful that iteration will be.

This can be condensed into the following: the more solid design and potential in a product before iteration begins, the more it will benefit from the process. The less focus, direction and careful design in a product, the less it will benefit from iteration. It’s a multiplicative thing. To condense it even further, into the realms of profanity: No matter how much you polish a turd, it’s still a turd.



This is the main problem with the iterative model upon which the industry runs. Iteration is viewed as a catch-all method of fixing things up and ensuring a product is marketable. Problems with a basic concept are just assumed to get ironed out in iteration. While this may be the case, the amount of iteration that has to occur to get the product to the same level that a bit of forethought and analysis could achieve is massive. That means money and time wasted, game budgets expanding and general doom and gloom. Not only that, but solutions will more rarely be truly innovative and elegant, hacked together from re-purposed or rushed assets as they must be. The pressure to not go back to the drawing board is immense, particularly for studios working to publisher milestones or with announced release dates.

For all the flaws listed, iteration is supremely reliable. If you put a product through significant iteration it’s going to come out looking better than it did when it went in. This is great, but it can also be deceptive. Without a comparison, that improvement can deceive a developer as to the actual quality of their product. I often see playtest groups start with something utterly awful, get it to a point where it’s barely playable and hear things like ‘we feel like this is in a good spot right now’.

The promise of iteration to refine a game distracts from the need to set goals before development even begins. Specifying certain desired outcomes such as ‘we want players to spend no more than X time and no less than Y time completing this area’ or ‘we want 90% of our playtest group to report a 9 or 10 out of 10 satisfaction with this level’ give iteration something tangible to push towards and, importantly, something set in stone which performance can be measured against. I’m sure that this sort of practice does exist widely in more experienced studios to benchmark specific areas of the game, but I’m not sure that even the industry leaders establish these sorts of design-centered performance benchmarks from the get-go. I certainly know I don’t. To do so requires a significant amount of research and preparation, but on the whole I’ve found that every hour put into such work means ten less in the actual development cycle.


So what’s the alternative? Well, for the most part right now there isn’t one, and that in itself is a problem. This article is more about pointing out that iteration has very definite weaknesses and that it’s worth putting effort into figuring out other development methodologies which might avoid some of these. Iteration will always have a place, but it’s worth considering just where and when that is in the overall process. Too early and you cede your ability to refocus drastically in order to hit your goals. Too late and everything is already too rigid to benefit greatly from the feedback based tweaking iteration provides.

So have a look at your process. Do you really need to begin testing on day one? if so, what does that say about your understanding of what you’re making. Might your time be better invested in research, so you can figure out what you need to test more precisely? This is just one of the questions I ask myself before I begin iteration.

I hope y’all find this useful, or at least thought provoking.


*some will no doubt contest that genetic evolution is truly random and that design iteration is guided by conscious… well, design. This is true, but I’d contend that the goal to which we guide game design at the moment is so vague (Eg. ‘fun’ or ‘rewarding’) that this really only serves to limit truly awful mutations rather than creating significantly more powerful positive ones than random variation would.


Design Analysis: Champion Select


Recently Riot has been talking a bit on their forums about their struggles with player community management. Lyte recently posted this:

There’s no easy solution to Champion Select; in fact, it might be one of the most difficult problem spaces we’ve ever had to tackle. However, it’s currently a major focus of the player behavior team, and we hope to fix the core issues with Champ Select and find a way to really build trust among strangers before the game even begins.”

That sounds like a challenge! Ok, ok, so I don’t think I can punch this issue down in half an hour, but I’m going to have a look at it from a slightly different angle to what we see from Riot’s player behaviour team.

Their methodology is a good one, highly based on statistics and, as far as I can tell, psychological best practice. Unfortunately, while they do talk a lot about what they’re doing and give the player community a lot of stuff to chew on, we also really don’t get the meat of the issue. For example, Riot talks a lot about ‘toxic players’, but as far as I can find have never really stated what a ‘toxic player’ is exactly. It’s one of those tacitly obvious things, apparently (I’m pathologically inclined to be skittish of anything to do with toxins after reading bad science). I don’t doubt that Riot’s crew have some pretty robust work going on back there, but the way they share their discoveries leaves something to be desired in terms of real, usable information.

So I’m going to have to do a lot of making do with what we have. If we shadows have offended and all that.



Champion select is the drafting aspect of League of Legends, where players pick their champions for a game. It’s notoriously antagonistic as players often compete for the glamorous roles and, thanks to the structure of the metagame, get annoyed and frustrated when things don’t go their way. This being the internet, that annoyance frequently boils over into undirected rage and disruptive behaviour or at the very least half-hearted cooperation and a sub-optimal game experience.

As a student of play, I’m fascinated by Champion Select. It’s a kind of distilled example of the differences in psychology between intrinsic and extrinsic rules and how that affects the way people play. Lyte’s comments on building trust strike me particularly strongly, because trust is one of the things that play interfaces with most curiously of all. I also think that as a guy with a heavy focus on play, I’m coming from a different angle to the Riot crew. From his wording I get the feeling the scientists Lyte’s been talking to are the game theory / rational behaviour kind and everything I’ve learned about play says you can’t use those models successfully when play behaviour is involved.

The staple example to demonstrate this is bears and huskies playing in the snow. That sort of animal interaction has been a subject of some research, and formal play rituals have been cataloged among a variety of animals, particularly dogs. The interesting thing here is that there’s a kind of language that establishes trust. You may have introduced yourself to a dog or cat by curling up small or offering them the back of your hand to sniff. To another human, you might show them your open palms or similar. This is referred to by ethologists as a physical lexicon of trust.

Amongst both humans and animals (particularly mammals), there is another level of this sort of interaction, one which establishes an even atmosphere of tolerance and curiosity which occurs before the intimate trust necessary for play. Laughter, teasing, gallivanting, poking and (once you get far enough) play-biting, gumming or nipping someone are all examples of this language. Funnily enough, it’s not so different to the way the dogs and bears show they’re playing- toothless bites and funny walks seem to be a standard across species, while dogs have a particularly well studied signpost called the play-bow.


Online, we can’t interact physically, which is partly why gamer culture is so rife with braggadocio, trash talking and hyperbolic communication- yelling, exclaiming how amazing something is, pithily dismissing an achievement as nothing, etc. It seems to stem from an attempt to convey the physical lexicon of play. Certainly, phenomena like emoticons and avatar emotes are mostly used for this purpose when the players cannot see or interact with each other in a more tangible way.

When you look at champion select you clearly see why establishing trust is difficult. Your team are essentially faceless and the only method of interaction they have is a chatbox, a chatbox that is deprived even of the ersatz tools like emoticons. In the race to get the Champion you want, there’s hardly time to type a word, let alone write some complex text in order to get your team in a playful mood.

So, first things first, Lyte is absolutely correct when he says there is no easy solution. I don’t think you can tweak a variable and get a big improvement here. The problem is a fundamental one. The current structure of the Champion select environment is simply not capable of establishing trust and playfulness in a meaningful way. That is to say, while it is technically possible, it’s not very likely given a random sampling of players.



The first thing, it seems, is to give people the space to communicate with each other. To me that suggests taking away all those pictures of champions and what other people are choosing and putting it somewhere else. Out of sight. Where you can’t touch it. For, say, ten seconds, no choosing your champion, runes, masteries, anything.

(The main reason I want this, of course, is that I’m Australian and constantly, CONSTANTLY get into champ selects where I call a role, am apparently first yet everyone else’s logs say I ain’t. My suffering is eternal. >.>)

Seriously, though. Give someone nothing else to do but communicate and guess what? They’ll communicate. If this seems a little harsh and ham-handed, well, that’s true. But consider that communication doesn’t just have to be typing how your cock is supernaturally large in a chat box. We can have passive communication (someone’s avatar or profile customization for example communicates stuff about them to anyone who has the time to look). We can have non-verbal communication assuming our environment has something manipulable that other players can see- for example if you had a map with a system that let players put virtual pins on it or freeform draw over it, they could communicate through messing around with that. People can turn pretty much anything they can interact with which can be seen by others into a medium for communication, so it’s not so much how to enable communication as to what sort of communication to enable.

In my experience as a League player, a lot of the frustration in champ select is not being able to really tell the temperament of your teammates. I can deal with having an aggressive player or a very passive player, the difficulty is in not knowing in advance. So I have to usually blindly pick a champion suited to a kind of play that there’s only an average chance my teammates will be inclined towards. I can talk through this in chat, but more often than not I get no response or it’s too late anyway.

It’s just one manifestation of a more typical problem with online match-made play: systematic anonymity. Outside of RPGs where players build persistent, unique characters, there’s rarely much attempt to allow a player to communicate their own identity in a matchmade game. The same tools used to communicate identity are often used to communicate playfulness, through dressup, deliberate sub-optimisation (I suppose a good example of this in League is ‘troll’-builds, though of course this is sometimes not the sort of play that Riot likes to see).


I think this might be a partial key to unlocking the problem. If players can at a glance see the disposition of their teammates, I think they’ll be far more comfortable communicating and establishing consensus.

Just as a rough concept, imagine if you drop into champ select and you see something like this



Each player here has previously entered

  • Their three preferred champions
  • Their interest in roles (by gameplay-archetype rather than meta archetype, so assassin/mage/fighter/ad carry/ tank/support)
  • A tick if they’re prepared to jungle
  • A meter which shows how their play preference- aggressive or passive.

Instantly, at a glance you can see where the potential conflicts and synergies in your team are- there’s an aggressive Draven player and an aggressive Leona player? Great! Two people prefer mid, but one hates to jungle and the other doesn’t mind it? Easy… Only one guy who can jungle? well, that sucks but it feels a bit better when the dice are rolled so visibly.

As part of this mockup I also added the minimap pinboard, and there’s still plenty of space for hacking together some additional stuff as testing dictates. I think this process would add no more than maybe 15 seconds to the champion select process, and there’s always the potential you can add an option skip it in custom games or team games.

It also makes it clearer when a player is genuinely being unpleasant- if you don’t say a word for 15 seconds before champions are even available and then instalock, ignoring the discussion, you’re ripe for judgement. When the culture is instalock or bust, you can’t surely judge someone for the practice.

In short, it adds a massive amount of both passive and active communication that’s easy to absorb and easy to use in a format that’s hard to abuse. It gives players a larger unique footprint, making it harder to see them as just a nameplate and fighting the problems that systematic anonymity creates.

From my perspective, this also adds the opportunity for players to, well, play. There’s a space added there to show willing, barred from the antagonist environment of Champion select. It’s structured around the free sharing of information and cooperative activity, fostering a more playful, trusting environment. The sort of environment that doesn’t conform to the expectations of those game theory scientists in a really good way, a way that expresses the best of gamer culture, not the worst.


 I don’t contend something like this would fix all the problems with the Champion Select process. But it would add a lot to the game, both in creating a less antagonistic environment and at the same time providing teams with fantastic tools to improve their game and demonstrate their teamwork and creative skills.

I get the feeling this would be a tricky proposition for Riot with the way they’ve had to keep patching together the air client, but there’s always Season 4, eh?


Indepth: Tutorial & training design for competitive games

This week’s indepth article is brought to you by recent developments in the Moba scene with Dota creating a new tutorial system and League revamping theirs. As LoLCG might suggest, I’m quite interested in that style of game, but I’ve also followed competitive gaming of all sorts for quite some time. These games are pushing the conception of videogames as a legitimate arena for competition forward and, as Esports begins to find traction, it’s time to question assumptions videogame designers have made for decades about how to go about that.

In this article I’m going to go over a particular method competitive games use to foster and develop their player communities. I’ll look at how game designers can learn and improve upon these models to create competitive games that foster even more passionate players and fans than they do already. Then I’m going to look at four paragons of the genres of competitive game. League of Legends, Streetfighter, Tribes and Starcraft. I’ll look at the positives and negatives of how these games have approached training their players and the impact those decisions may have had on the games overall. Finally, I’ll bring it together and propose a set of guidelines for designing successful training and tutorial elements for such games, which can be summarised in these goals:

they must be rewarding in their own right

they must clearly communicate context

they must provide a safe environment

they must isolate and identify particular skills

they must support perpetual skill development


Introduction: Something or other about Tennis.

Amongst my library of design proverbs, I’ve found one coming up more than most recently. ‘You don’t learn to play tennis by playing tennis’. I hope I don’t need to draw you a diagram. It’s one of the most lauded properties of videogames that they decrease the need for dedicated training and development. One learns by playing, seamlessly, without even realizing it. As I discussed in my analysis of Portal 2, this capability can be intoxicating for designers, so much so that they miss exactly what it is they’re doing.

Analogue games- more specifically, real-time analogue games with a high mechanical skill component- don’t successfully induct new players or fans by getting them to play even a limited version of the full game. Instead, players are more often introduced by participating in drills or mini-games which isolate and clarify particular mechanical components of the whole. These aspects are then given context and brought together in parts and finally in full, but more limited exercises remain a constant part of training.

I remember, when I was a kid, going to tennis camp. First you got to play with a racquet, then you got to mess around hitting balls against a wall. Over several days you’d move to trying to hit the ball into the other side of a court underhand, trying to hit it back when someone else hit it across (or rallying balls from a ball machine), playing volley games, little best of three rallies and finally moving onto serving and replying to serving, all the time drilling positioning, how to hold your racquet and so on. Just like in videogames, rewards provided a carrot to keep you interested, though unlike videogames these prizes usually went only to the top performers.

There are two important things to learn from here. First is that tennis camp had no illusions about what it was. When you went to tennis camp, you didn’t play tennis (well, much) you LEARNED to play tennis. This doesn’t mean you didn’t play games, they just weren’t tennis, and you knew the purpose of these games were to teach you skills to help you play tennis, which acted as another level of reward for success. Second, the formal reward mechanism used (prizes for the top performers) is antithetical to the best aspects of videogame design- all players deserve rewards for challenging themselves and overcoming their limits. It’s true that in these camp games everyone got a reward- they learned to be better tennis players- but that wasn’t much consolation when Timmy McBuffwrists was scoffing down half a bucket of M&Ms. This is something videogames have shown they CAN do better. In non-competitive games, the reward is most often advancement of the narrative or player capabilities, but in competitive games this often isn’t a great thing to offer. Players want to be become better at the full game, show them they are and that is going to be reward enough for many.

Tennis camp, I’d argue, is a tutorial on how to play tennis. Because of the skills tennis requires, the tutorial can’t just teach you the concepts and allow you to apply them at your own pace (which you can do with a mechanical skill and time insensitive game like Chess). It must actively develop the skills to a minimum level suitable for playing the game itself. To do so, it must isolate and train these skills to a level where their value to the game can be demonstrated to the player in a hands-on way. It’s all well and good telling a player when to apply a smash, but they’re never going to get it until they can actually smash and get a feel for when it’s practical.

Videogame tutorials, on the other hand, remain as kind of interactive rulebooks or introductions to concepts, without really giving players this hands on training. A token gate will often be provided (You shoot things with your left mouse button. Do you know where your left mouse button is? Oh good, proceed), but it’s rarely designed carefully enough to actually test whether a player has grasped a concept (ok, so I got out of that stupid tutorial thing, I’m not exactly sure how…) and this is often most pronounced for the intricate mechanical challenges of competitive videogames. So much so, in fact, that historically videogame designers have left tutoring to their communities, rather than trying to make good tutorials or training aids, they pay them lip-service and hope desperately that some internet personality will go viral with a series of learn to play videos or guides or develop some mods to help others train. Sometimes they get so fed up with the whole paradigm of minimalist tutorials they produce something like this (skip to around 5 mins):

Which, while hilarious, is even more intended for people who are already educated consumers. The problem with this approach is it relies on a very, very slow trickle of players joining, because the normal channels through which people are introduced to new, fun videogame experiences (the games media, forums etc) won’t work- you can’t just drop into the game cold and get the intended experience. It’s a sort of a catch 22 thing. You only get introduced to learning how to play the game if you’re already a member of the community of people who already play, or at least on the fringes of it. This phenomenon is particularly pronounced in the fighting game community and, up until a huge community effort over 2011-12, the Starcraft community.

This is a serious problem for developers, who want to get as many people playing as possible. That problem is doubled for developers aiming for an Esport presence, as not only do you need a vibrant player community, but an even larger spectator community as well. Player count and fresh blood matter and without a good way of reaching out to them and helping them into the community, competitive games stagnate and slowly become ever more inaccessible.

In order to reach out to truly new players and introduce them to the joy of competition, competitive videogames need to embrace the lessons that can be learned from sport camps. Provide the tools for your players to break down the game and train efficiently. Reward them for that training. Help them understand the game in the same way the best players do, so a conversation can exist between them. These are the objectives of tutorials and training for competitive games, so let’s see how it’s been done so far.

Game analysis

1: Streetfighter (Streetfighter IV)


Street fighter IV features no formal tutorial (the basic controls and goals are covered in the manual), only two modes aimed at helping players develop their skills. Challenge mode gates players through a series of increasingly complex combos, with the goal of showing them the particular capabilities of a given character. Training mode drops players in a sandbox fight where they can adjust the properties of their opponent to test their own skills and devise their own challenges.

What it does well:

Unlike many competitive games, Street Fighter IV recognizes the need for a space in which players can train at their own pace and isolate specific aspects to train formally. The training level’s grid gives players the tools to practice footsies and spacing. The challenge levels attempt to introduce players to the particular capabilities of each character. It even has a rudimentary reward mechanism through unlocking stages a completion meter.

What it does badly:

Pretty much everything else. The training and challenge levels are more intended for players who are already committed to learning the game to a high level and have studied how to do so through online guides accessible, more or less, only to people already deep into the fighting game community. The game makes no attempt to explain necessary skills or help new players reach the point where they are competent at them, other than providing the sandbox area mentioned so they can practice in an undirected way without having Zangief constantly trying to piledrive them. It doesn’t explain where various skills might be valuable, nor what they’re called by the player community (oh, of course that un-named combination of twenty motions ten deep in challenge mode is referred to as an Ultra-FADC. How silly of me not to know that)

There’s no attempt to reward players for engaging in learning activities and training their skills (other than being able to go from ‘helpless cripple’ difficulty to ‘clumsy infant’ difficulty, a tremendous boost to their self esteem). There’s no attempt to teach players concepts that get flung around like misogynist jokes in the FGC. Want to learn how to cancel your dragon punch into a mixup tech bait? Don’t ask here… The game doesn’t even tell you how to block.

The result:

The amount of independent effort required to even learn how to throw a fireball unless you’re already familiar with fighting games is staggering. Given how much more complex real PVP Street Fighter is, it’s no wonder that the game remains a cult phenomenon, mostly spread by people being individually tutored by their friends. Some might argue that mashing buttons is perfectly cool and enjoyable, which is true, but it’s also an example of terrible design. If 95% of your audience is going to just fondle their controller like an awkward teen virgin, why on earth bother spending huge amounts of time and money creating a level of balance and pixel perfect execution that is perhaps the most demanding of all the Esport genres? Would it not be worth the comparatively minimal effort of designing some good in-game introductions to these capabilities that would show novice players the delight that comes from exploiting all this work you’ve been putting in. I certainly think so. Apparently Capcom disagrees.


2: Tribes (Tribes Ascend)


Much like Street Fighter, Tribes has a cultish, ultra-high skilled community and markets itself as a highly competitive, spectacular game. Ascend features a very limited tutorial set which introduces players to the two most basic principles in the game- skiing (how to go faster) and inheritance (why you never, ever hit anything, you noob). There’s a free-roam mode where you can spawn into an empty map and access all weapons, even ones you haven’t bought, but like SF, no attempt is made to explain their use and functionalities to the player. Finally, post release some basic target practice modes were added, but in a very tacked on style.

(Skip to 18 mins)

What it does well:

Tribes sells itself as a high skill, high complexity game. It certainly takes balls to advertise yourself as ‘the hardest game’. While this is debatable, the rhetoric is clear: this is a competitive game, no questions asked. I actually had the pleasure of interviewing the project lead on the game and, when I asked him about easing in newer players with some fun sub-games that might help them master skiing, his response was in the vein of ‘we want people to play a shooter, not a racing game. Interesting idea, but we probably won’t do it any time soon’. I can respect that… sort of. Ascend does use community language throughout the game in such a way that it’s usually easy to interpret, lessening the conceptual burden for spectators or novices trying it out for the first time, but these occurrences are achieved more through luck and referential humor than deliberate design. The addition of some basic training maps post release has given players somewhere to go, but they’re incredibly rudimentary, lacking in direction and give the player no rewards, so the only incentive to try them is getting your ass handed to you against other people.

What it does badly:

Unfortunately, what Tribes: Ascend wants to be is a game that is amazing once you spend maybe 30 hours learning to walk and shoot at the same time. You can play Tribes like a regular shooter, running around on the ground, but it will feel terrible. The whole game is balanced around the assumption that players have mastered some fairly impressive technical skills.

Like Street Fighter, no concession is made to the rookie. If you want to become a Tribes player, you’ll do it sweating blood and tears. For people who enjoy that, or have enough shooter experience to be able to get the feel of it intuitively, great. So, like 10% of your potential audience. Whoopie.

In particular, being able to even achieve lasting damage in the game is somewhat dependent on mastering the aim of some particularly finicky weapons. You have a low ammo count, so amongst newer players it’s not uncommon for two people to run each other entirely out of ammo because neither can actually hit the other reliably enough to stop their halo-style health regeneration kicking in. This is possibly the most frustrating thing I’ve ever experienced in any shooter game and the fact that, at least originally, there was no place you could go and practice against moving targets that mimicked the target profile of another player at all was more than a little awful. Due to negative feedback, the target practice mode was added , if only to save both you and some other guy the anguish that is trying to bite someone strolling across the map with your flag to death because you spent enough ammunition to level a small city block trying to hit his buddy wearing the scifi equivalent of a loincloth and rollerskates. Yet the tacked on style and lack of direction mean that such a training mode is once again only really suited to advanced players, not the ones who really need to train.

This is further exacerbated by the fact that Tribes in its standard format is a teamwork heavy game. Players have serious roles to play that involve things other than shooting at the closest bad guy. There’s no attempt made to explain these necessities and how they’re handled to players, which leads to Moba-level raging when new players do what is completely natural and fly around shooting at people while veterans rip their hair out in frustration. There are tools to communicate what to do, but without the context provided by training, they fall flat for new players. So the typical competitive-rookie divide grows sharper and players are turned away.

The result:

Tribes: Ascend is pretty clearly a failed experiment. It’s not an unsalvagable one and if HiRez persist for a few more years, I think it will resurrect once the level of archived content reaches a critical level that lets people buy into the game without needing the developer’s assistance. But will the servers still be up by then? Who knows.

I think it’s no exaggeration to say that Tribes Ascend has performed poorly specifically because the developers neglected providing sufficient well designed training and tutorial content in the game. Tribes is perhaps one of the most innovative and engaging shooter genres, one that remains more or less unique in terms of its core mechanical concept (high speed player movement combined with low speed weapon projectiles). Like many games, it spiked high on launch, but without the ability to train and grow in a structured environment, the player-base quickly waned and now we’re left with a community similar to the one that tribes has had traditionally. Small, closed, high skilled and insular.


3) League of Legends:

League of Legends has made inroads into improving player experience and play quality, but has it achieved anything in that regard when it comes to helping players learn the game? Perhaps. Perhaps not. The game has yet another very rudimentary, if well executed, tutorial that covers the basic control system and objectives of the game. Like many popular games, the developers seem content to leave players to manage their own training through custom games and other ad-hoc solutions however. League does provide a very well integrated VS-AI mode that gives players legitimate rewards comparable to playing against other people (for a limited time) and so is more enticing than similar play in Street Fighter or Tribes.

What it does well:

League of Legends goes out of its way to be welcoming to new players and reward them for engaging with the game. For new players, playing vs AI is weighted similarly to playing against humans, which helps reduce ladder anxiety for players unfamiliar with competitive gaming. Champion rotations and the F2P economy stagger the weight of information a player has to take on and social mechanics designed to encourage players to be welcoming and supportive help mitigate some of tensions and apprehensions of diving into an unstructured learning environment.

What it does badly:

Despite my good feeling towards Riot, however, in terms of content explicitly designed to help players develop competency and/or mastery, League is still just as flawed in terms of design as Street Fighter or Tribes. If I’m going to point at those games as having terrible implementations, League must be tarred with the same brush. No matter how much you try and paint cute happy faces on it, learning to become a competent League of Legends player on one’s own, or even in most company, is still like toileting with sandpaper.

Given the tremendous weight of community knowledge that players must absorb, a new player to a Moba is orders of magnitude below the capabilities of even a sub-50% hack like me. Mobas take for granted a control scheme that many people have serious difficulty adapting to (inverted keyboard-mouse control where the mouse controls movement and the keyboard controls actions and interactions, whereas in almost every genre but RTS and its mechanical variants the opposite is the case- RTS being one of the most niche genres of videogame in terms of raw player count). Alongside this a player must juggle incredibly complex contextual decisions and situational awareness while performing mechanical operations that can be tricky for even veteran keyboard jockeys.

Like many other competitive games, League gives nowhere for the player to isolate and refine these skills, let alone somewhere which is catered to with League’s otherwise industry-leading player engagement strategies. The result is that, despite its intense popularity, League is still beyond the reach of many who might otherwise be fans if their introduction to the genre was better structured.

The result:

League’s huge playerbase, vibrant and creative community and intense dedication to communication and involvement masks a lot of the flaws the game holds. The sheer weight of external guides and information as well as Riot’s policy of adopting player jargon to give new entrants a handhold to pull themselves into the scene means players are more often able to get the things they need to learn down and, more importantly, why they need to learn them. Where it falls down is providing them the space to do so.

So I have still borne witness to far more people flaming out on League than getting hooked. It was particularly strange to see the infographic proudly claiming, among other epic statistics, that over 90% of league players were male. This despite the fact that, overall, the videogaming market is half female(Pg3) and a majority of those women play on PC. While I imagine those statistics come as a surprise to some, to those it doesn’t this infographic was something like saying ‘hey look at how successfully we’ve failed to reach the majority demographic in this market space!’.

While there might be other reasons, I think that the average western woman is more inclined to learn a game at her own pace without the pressure of competition and with the ability to structure and control the experience. Honestly, I think the average guy is too, but men tend to be more willing to adapt to and pressured into a PVP grinding mindset in the presence of their peers, or take out their frustrations through mindless soloqueing. Perhaps if League introduced content to help new players learn the game at their own pace without someone looking over their shoulder telling them what to do (while frequently being wrong) there might be more ladies willing to take the plunge.

For all its strengths, League still has a lot to learn


4: Starcraft (Starcraft II)

Starcraft is an interesting beast. In some senses it demonstrates best practice for competitive game tutorial/training design. Any way you look at it, the single player campaign is clearly aimed at steadily introducing players to new units and their intended purpose bit by bit. Starcraft also features a challenge mode which trains players on core concepts like multitasking, base building and so on.

Yet, despite the claims of developers that a greater percentage of people are cutting their teeth than ever before, Starcraft still remains a game where only a tiny percentage of buyers are willing to engage in the competitive play that turned a well-received but otherwise unremarkable RTS into one of the most important videogames of the millenium.

What it does well:

Of all the games explored here, Starcraft tries the hardest to introduce players to the concepts and techniques required to play the game in isolated, carefully constructed settings with their own ludic value. The design is still ambiguous in the sense that while learning a particular skill or capability is emphasised, you can usually get by without it: there’s no gating to ensure players have picked up the desired concepts. Starcraft is also the only game of the four to provide a true, focused training mode that isolates core gameplay dynamics, gives them a space for practice and identifies them formally to the player.

What it does badly:

Unfortunately these designs, while commendable, are still not particularly effective. Blizzard’s need to make a singleplayer that is open and enjoyable for freeform play detracts from its value as training for competition, not to mention the fact that units in the singleplayer are often significantly different from their multiplayer incarnations.

The challenge modes aren’t really integrated into the whole game experience that well. They’re not signposted, beyond achievements there’s no real reward for doing them and more importantly the concepts expressed have undergone ‘Blizzardation’. Blizzard seems to shy away from using the same terminology as their community. So ‘defending a rush strat’ becomes ‘defending an early attack’. I mean, who’s ever gone up against a ‘zerg early attack’? This may seem like pedantry, but it creates a cognitive dissonance between players training in the official challenges and the competitive community. Rather than being introduced and involved with the community directly from the game, players must undergo the same linguistic trials as if they were entering the fighting game community. As we talked about in the tennis analogy, it’s important players understand that training is training FOR something. That doesn’t mean it can’t be fun, and it does mean that the skills developed are more likely to be successfully transferred.

Secondly, the challenges cap out very low. Not only can you fudge them by quicksave abuse to just get the achievements, but even not doing so getting the highest tier of the challenge isn’t particularly difficult even for a novice RTS player. An important property of analogue training is that there’s a lot more potential for skill development- since some level of competition is usually involved (often indirect a-la videogame high scores), the ‘top tier’ of the challenge is constantly rising as the skills of the training group increase. Blizzards challenges help players train to a basic level, but don’t help them really push each skill beyond their limits again and again and again in isolation, which has proven the best way of developing a player’s competitive potential for time immemorial.

The result:

Competitive Starcraft remains a game that the average player struggles to get into. A lot of games which feature dual singleplayer and multiplayer experiences have this problem- people tend to buy the game for one or the other. If you get Starcraft for the singleplayer, you’ll generally consider your experience complete if you finish that and then do nothing else but play custom maps or get challenge achievements, which in terms of the competitive side of the game is missing the point entirely.

So there still remains a gap between multiplayer and singleplayer Starcraft. Furthermore, because the challenges are solid introductions to very basic concepts, but do not scale in such a way players can focus on developing their skills to work towards the capabilities of a multiplayer veteran, there is no safe space for players to practice such development in a directed fashion. Like many competitive games the only options are to play free-form games against AI which require the player to internally isolate skills they want to practice. This means they need to understand which particular skills need practicing and why, something the game doesn’t do a great job of conveying.

As a result, very few people who own the game play competitive Starcraft. Anxiety and a feeling of being overwhelmed from going into open play holds many back and frustration with slow progress and continually making the same mistakes creates a high dropout rate. Once again, real efforts by the developer to open up the game to new blood are far more clumsy than they should be given the care put into the rest of the game.


What we can learn:

Let’s just pause to remember that we’re talking about a very specific thing here: tutorials and training players to be capable players of a competitive game. We must assume a baseline of skill to be considered capable– I’m not capable of playing tennis if I serve a game of double faults more than 50% of the time, or even if I do so around 30-40% of the time. I’m not capable of playing soccer if I can’t pass a ball accurately to an unguarded teammate. The same sorts of baseline skills can be argued for the competitive games above- executing a bread and butter combo reliably, hit a guy with enough reliability that you can actually kill them before you run out of ammo, get a few last hits per minute, macro an army that can beat an easy AI. Without these skills- which actually are quite difficult to achieve for non-gamers- a player cannot experience the intended basic flow of gameplay the designers expect them to and are consequently excluded absolutely from the intended play experience.

The absolute minimum baseline of these tutorials/training should be to reliably get a new player with no assumed knowledge or outside assistance whatsoever to this level of ‘capability’. Achieving this objective would allow a game to develop a new audience independent of the efforts of its own community. The more popular a game is and the larger its existing community, the less absolutely essential this is (as in League), but for games with tiny, insular or non-existent communities, it is crucial (as in Tribes). Even for games with large communities, such design might allow new demographics to be reached and brought into the community more successfully (as with women in League of Legends)

Here are what I would say are the crucial design goals of such an endeavour:

  1. It must be rewarding in its own right

The most important value of any videogame design is that any activity the designer desires the player to undertake must be rewarding, either through engagement or some kind of external reward. Activities which have lower engagement necessitate a larger external reward and vice versa, though that’s not to say you can’t make an activity both engaging and rewarding.

So training or tutorials must be fun in and of their own right. If they’re not, a player needs to already have the desire to be a competitive player to endure them, something we want to avoid- this training should help show people why they would enjoy competitive play, not the other way around.

  1. It must clearly communicate context

Tutorials and training must communicate their purpose in the larger scheme of things clearly and in language that is in common use amongst the existing player community. It’s no use creating a masterful minigame in which people are trained to do X perfectly if they don’t realize that X is a feature of the larger game, or they do, but can’t recognize when and when not to apply their skills. This often means stepping outside the fourth wall and talking frankly to the player, which may on the surface break immersion and engagement. What this fails to recognize is that learning a game is an immersive experience, on a level up from the narrative setup used to draw the player along. You may break their immersion in the story, but you won’t break their immersion in the game.

  1. It must provide a controlled environment

Training is something that a player must have control over. As I discussed in my article on Portal 2, the tutorial’s function is to provide a safe, contained environment for skill development away from the wild world of emergent challenges. Tutorials should emphasize a player’s development and ability to proceed at their own pace. Training should be able to be smoothly stopped, restarted, made easier or harder. Rewards provide incentive for players not normally inclined to push themselves to do so. Every attempt should be made to ensure a player has the flexibility to control their own development.

  1. It must isolate and identify particular skills

The purpose of tutorials and training is to give a player the chance to focus on understanding and developing a skill or skillset in isolation. This is a far more efficient and rewarding way of developing skills than simply participating in the full, formal game. Training and tutorial systems should carefully identify and break down skills required for gameplay and present them in such a way that their relevance to the main game is understood, but that the tutorial environment gives the player the freedom to focus on them one by one or in smaller combinations, without the pressure of being in an environment that taxes other skills as well.

  1. It must support endless development

Perhaps the most important quality of competitive training is the ability to scale with the player’s skills. Training should always be capable of raising or lowering the bar, as it were. It’s not as if this is a foreign concept to videogame design: it’s the core idea that popularised the first videogames at the dawn of the medium. A single, simple mechanical exercise that grows in difficulty until eventually the player can’t keep up. Victory is not in absolutes, but in beating a personal best. Thus, every round can provide a new victory and every player can find their own limits and test them constantly.


So those are my thoughts. As with all my indepth articles, this is a springboard for future discussion and design practice. I’d like to talk about the community designed micro and macro maps in starcraft, how League might go about integrating training modes with their reward models and so on, but I think you’ve probably all had enough for one day XD.


Towards a more useful discussion of game design.

After every GDC the conversation about definitions blossoms once more. This time, it’s Raph Koster and Leigh Alexander heading the sides. It’s always a fun time to listen in and see what got mulled over at the latest conclave, but it’s also very frustrating for me at times.

The discussions are always vivacious, passionate and filled with fantastic examples of interesting things being executed within the medium, yet I find they lack something: a desire to reach useful conclusions.

I have a pretty stringent conception of useful, which may rankle with some folks who love a good chat about what this or that means. I was brought up in an environment saturated with science and scientific literature, so Popper has been sitting on my shoulder for a long time and Kuhn has been whispering in my other ear. Their work was directing science to its modern understanding of itself- the practical search for useful information. The usefulness of information is directly related to its capability to successfully predict things. So the statement ‘Any time you have a triangle where the sum of the squared values of the shorter two sides is equal to the square of the longer side, the two shorter sides form a right angle, so it is a right angled triangle’ is extremely useful, as it predicts a very specific phenomenon with 100% accuracy. The statement ‘Any time you have a game, it is a set of rules with an objective’ is… not useful at all. It is descriptive, not predictive.

So useful here is used in a specific way- the ability to predict something (with the important possibility that the prediction might be demonstrably wrong). Our definitions of games are not useful definitions, because they don’t predict anything. They don’t come out of a set of useful ideas, like ‘right-angled triangle’, about which we can make predictions. If I have a right angled triangle, I know it will behave in certain ways, because through a lot of effort it has been shown to do so beyond reasonable doubt. Currently ‘rules’ and ‘objective’ are not useful ideas because they tell us nothing of that sort. They are just definitions, we don’t actually know what they do, what their footprint in the non-hypothetical universe is.

This kind of property in a concept is crucial to any practical field, be it engineering, medicine, chemistry or what-have-you. Design is one of the most practical fields of all, since its whole raison d’etre is about figuring out how to build things from ideas. If those ideas are not predictive, we can’t use them to make design decisions. These discussions of the definition of game, while fascinating to me as a scholar and thinker, are next to useless to me as a designer. They don’t make predictions, they don’t render themselves wide open to testing. Given they come from a community of people who identify themselves as ‘game designers’, I am, perhaps now more understandably, frustrated.


The main frustration for me is this calls attention to a broader lack of purpose in the discussion around game design. We are perpetually involved in observation and examination, but rarely do even those most qualified to do so offer a useful statement. Each designer stands alone, reliant on their own experience to form their own system of useful guidelines and rules upon which to base their design.

It is true that we have some useful design rules, ideas about maximizing engagement and immersion, structuring game flow and so on, but these typically are on the vague side of useful. Given the design community’s fascination with genre and detailed analysis of gametypes, I’m continually disappointed at the scarcity of people offering testable predictions of a more focused sort, ideally with them presenting a well defined and rigorous test they performed themselves.

I’m not saying that the design community should turn into a bunch of whitecoated statisticians, but it’s important to recognize the value of presenting discourse in such a way as to generate useful ideas. Not only does it give new designers a handhold to pull themselves into challenges of the field, but it will, eventually, aid in the development of a consensus on these nebulous definitions we love to argue about.

So when you want to talk about something cool you’ve found in design, think a bit about what the underlying idea you think it demonstrates really is. Is there a way you can show that? Can you say something like ‘This demonstrates the principle X, which suggests that if I did Y, with this or that parameter ensuring I’m just testing X, I would get an outcome within the bounds of Z.’

Even if you can’t do such an experiment, constructing your thoughts about an idea this way will help you figure out whether the idea really is that interesting for other designers. The more elegantly you can demonstrate your observation a falsifiable way, the less time you have to spend arguing with people on the internet about it. You’re either right or you’re wrong. If you’re right, the design community gets some really useful information. If you’re wrong, the design community gets some information that is not quite as useful, but still way more valuable than most.

To tie this back into the recent debates, I’ll quote Leigh:

My main idea is that we have much more to learn and gain, at least for now, by eschewing definitions than we do by prescribing them.”

This sentiment is probably informed by the same feelings I have. Our definitions are not founded upon useful values. By ignoring broad categorical definitions for now and focusing on studying their components to produce more practical understandings of how those components function in reality, we will achieve more than trying to wrangle definitions that are ultimately not that beneficial to designers, as much enjoyable banter as they create.


PS: again, I will stress, I’m deeply interested in conceptualizing and understanding the concepts of games and play for my own pleasure. I just find these thoughts impractical when I get my hands dirty, compared to more functional psychology, sociology, physics and so on. Relying on these disciplines to provide our predictively tested information is all well and good as a juvenile discipline, but if game design seeks to stand alongside other fields, we need to create our own research agenda grounded in practicality and applicability to real-world design tasks. I think this approach should be championed and promoted more by the luminaries who act as role-models for the design community.

I’m also not saying that general discussion around game design is not useful in a more casual sense. It’s absolutely necessary for giving us insight into where the more stringently defined useful information can be discovered and why it might be important. It’s just that mistaking that sort of discussion for the most important, serious level of analysis in the community is a real problem that’s holding game design as a field back.