In Part 1 of this post I gave you a damn good excuse to play facebook games in order to get acquainted with your Level-Up Cycle – a process of acquiring new skills where we move from awareness of a possible new behaviour, through the intention to implement that behaviour, spend some time gathering feedback in conscious practice, initially disruptive before becoming integrated, and then – the magic moment – we Level-Up and what was once the idea of a possible new behaviour is a habitual unconscious practice.
Archive for January 2011
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.
Yesterday I had to implement a common, simple bit of functionality in a view. The view is revealed and hidden by clicking a tab button which causes it to slide up or down behind a mask.
It’s not rocket science. The only awkward aspect of the implementation is that it has to be responsive to the user changing their mind mid-move. If I click the tab and then quickly change my mind, the movement should be reversed, and if I click it again it should be reversed again and so on.
This is the kind of behaviour I’ve implemented hundreds of times over the years, and you probably have too. I do it without really thinking about it. Except that these days I’m trying to think more about every line of code I write – inspired by some stuff I read (and now can’t find) where Corey Haines was talking about challenging yourself to answer the “Why stop now?” question when refactoring.
In any software project there are at least five stakeholders in the technical development task:
The client, who has the vision of the finished features
The project manager, who has to organise technical resources and timetables
The architect, who designs the system at a macro level
The current coder, who implements each individual class and component
The future coder, who will maintain and enhance the software in the future
Managing complexity is what we do as programmers, right?
Whether you’re architecting a new application from scratch, or deep into writing a component or class or test method, complexity is the elephant in the room, and our job is to ignore it, or at least keep it in the corner, right?
I mean, complexity in software development is inevitable. Beyond “Hello World”, building and maintaining systems that solve interesting problems is like being in a boat full of holes. Every new thought the client has is another leak and we’re the poor sods standing in the middle with a bucket, scooping up the complexity and flinging it back into the sea as fast as possible, right?
You can tell by now that I’m about to say “think again”, can’t you?