To me, one of the most interesting aspects of game design is the shaping of the player’s learning curve.
I know of two brilliant pieces on what ‘Fun’ looks like – Pierre Garneau’s 14 Forms of Fun and Marc LeBlanc’s 8 Kinds of Fun - both of which include elements which show us that often part of the ‘Fun’ is the gradual aquisition of skills/knowledge in order to apply a new ability to overcome a challenge in the game.
As programmers, we’re a set of people self-selected to enjoy challenges. We love the feeling of beating the end-of-level boss, whether it’s a giant mechanised robot or a tricky-to-diagnose fatal bug in our application.
Good game designers go to great lengths to ensure that we acquire new skills and abilities just-in-time to make steady progress through the game. In my dream universe there would be a meta-game in which we could learn to program – to get from our first
hello world to complete mastery via a series of satisfying and perfectly pitched challenges that allowed us to pick up new powers without ever feeling like we’ve ‘been skooled’.
The brilliant Rails for Zombies and the Head First books series are a great step towards that fantasy. But what can we take from great game design to make sure that no matter what our current level of ability, we regularly get opportunities to ‘Level-Up’?
Using Facebook games to understand your ‘Level-Up Cycle’
At last, a good excuse to play Facebook games: they are a perfect sandbox in which to observe your Level-Up Cycle in action. So, I’m going to be referring to Zuma Blitz in this post, because it’s my current
time-waster learning-sandbox of choice.
Zuma is a marble popper. Your mouse position determines the direction the frog is pointing in, and you click to fire the next marble, aiming to always make a set of 3 or more of the same colour. If you’re successful, they vanish, and you score points.
At the outset, your only focus is on clearing enough balls that the emerging chain never reaches the end of the track – you quickly learn that this means death. But there’s a lot more to getting a great score in Zuma than just matching marbles – this is where your Level-Up Cycle comes in:
- You’ve probably noticed that some of the marbles had numbers on. This is a stimulus.
- At some point, as a player, you develop awareness that there are numbers on some of the balls. You might start to formulate theories about what this means.
- Based on what you believe it means, you might form an intention to try to hit these balls with the numbers on as frequently as possible.
- At first your conscious practice of this is disruptive – you might hit a few of the numbered balls but the amount of cognitive power being given to this knocks you off your stride and your performance might well drop.
- Any practice in the real world provides feedback that can be used to revise your intentions – for example you might decide to only pay attention to numbered balls which are already part of a set of two or more balls of the same colour.
- Eventually, through a combination of practice and the revision of the practice, you move into integrated conscious practice. You can regularly target the numbered balls without losing your stride, and your performance is improved. More feedback at this stage might revise the intention again – perhaps in terms of how much priority you give to targeting the numbered balls.
- At an unspecified magic moment, you Level-Up – the new skill or strategy is integrated to the extent that you give minimal cognitive effort to doing it – you ‘just do it’.
- You transition into unconscious practice – targeting numbered balls becomes a habit that you implement each time you play.
And there you are – scoring much more than before, and your game play is largely a matter of squeezing extra points out by going as fast as you can, until you notice that there are little egg timers on some of the balls, and the process is repeated.
The rest of this post is about the psychology and neuro-biology of your Level-Up Cycle and how you work with it. If you’re already thinking ‘Shut up and show me the code!’ you can jump straight to Part 2 – Working with your Level-Up Cycle, complete with code-based examples. (And then come back and read the rest of this one, which does have references to tigers).
Not every intention makes it to unconscious practice
If forming an intention always led inevitably to unconscious practice then I’d be super-fit and fluent in three languages. (I mean people languages, if you automatically thought ooh! Python! there then give yourself an extra geek-point).
So why do some intentions make it, and others fall by the wayside?
There is always a cost to adopting a new behaviour.
This cost can be divided into two categories:
- Temporary costs associated with the learning overhead
- Relative costs or benefit of old-behaviour vs new-behaviour
Identifying how much of the cost is attributable to each of these is vital when you’re evaluating a new behaviour. After all, it may be that the way you were already doing X was actually better than the new method will be, even after you become fluent at the new method.
In practice I more often observe people mis-identifying temporary learning-overheads as permanent costsIn practice I more often observe people mis-identifying temporary learning-overheads as permanent costs – most frequently when they argue that TDD is slower. In my experience learning TDD is really, really slow. Doing TDD once you’ve learned how to do it is faster than coding without it (for anything other than a trivial program).
High quality, early concrete feedback is key
Change is scary. Human beings are naturally wary of it, and without early evidence that our new behaviour is actually paying dividends, we’re predisposed to revert to familiar patterns.
We can only get concrete feedback when we actually put ideas into practice – everything before that point is abstract.
The questions we ask when we get feedback will create our beliefs about whether the new behaviour is worth pursuing. Depending on the questions, the decision to continue experimenting, somehow tweak our experiment or abandon the experiment altogether might be different.
We are predisposed to act with certainty even when faced with obvious uncertainty
Early human beings had to make rapid survival decisions about whether the movement in the corner of their eye was or wasn’t a tiger. ‘Maybe’ is potential death in those situations, and so our brain is designed to ignore the 99% of the picture that we can’t see, and make fast and strongly held decisions based on the 1% of the picture that we can see.
Certainty is excellent survival behaviour in the wild. It’s not so useful when you’re a computer programmer trying to integrate a new approach.
The more time you spend moving through the intention, conscious practice, feedback cycle, the more of the picture you’ll obtain, and the better you can adapt the practice to integrate with your work flow, and the greater the chance that you’ll hit that magic moment when you Level-Up.
Often when I do integrate a new practice I chastise myself for having abandoned previous attempts. It’s not simply a case of laziness or business or lack of ability – I’m still pretty proud of having created a secure system for module loading in Adobe Air (because I had no choice), which was a lot more difficult than the transition to using lazy instantiation that took me several attempts to get habitual about.
Increasing your chances of Levelling-Up
There’s no easy way to beat your biology – but if you can maintain awareness of the fact that any time you’re integrating new practices you’re undertaking an experiment, and that you might need to modify the experiment before you get the right results, you have a better chance of avoiding false negatives.
Just knowing that your brain is always working hard to draw conclusions from even the most incomplete information, and that those conclusions are more likely to be based in fear than in possibilities, can help avoid early-exits when you’re trying to add a new practice to your work flow.
Motivation is also key – the greater the initial intention, the more time and energy you’ll likely put in to the conscious practice phase before you abandon it. Having a more complete understanding of what the benefits of a new practice might look like will also help you to ask better questions when you’re evaluating whether to keep trying.
I frequently have debates with other programmers where I eventually realise that we’re speaking in totally different contexts: they’re talking about the flash compiler, and I’m more interested in the human compiler (my tired brain).
No doubt you’ve Levelled-Up a whole bunch of times in the past. You really know it when you look back at code you wrote a year ago and cringe. But how can we create more opportunities to trigger our Level-Up Cycle in ways that echo in-game learning?
When you’ve finished playing Zuma Blitz you can find some ideas based on this, and a concrete code-based example, in Part 2: Working with your Level-Up Cycle.