Mechanics, Dynamics, Aesthetics and Iteration

Uncategorized

Come back – it’s not as techie as it sounds…

… just some great ideas I picked up on Sunday night from Robin Hunicke ‘s talk She Got Game at the Byte Me Festival.

Robin Hunicke was lead designer on the MySims game written for the wii console. She spoke about what game designers actually do, a bit about the process of game design, and about her experience with tailoring a game for a platform that hadn’t yet been released.

Lots that she said can be related to libraries.

Mechanics > Dynamics > Aesthetics model

Mechanics are the rules and structure of a game – set by the game designers (eg. in chess there are rules about how to move pieces. In The Sims there are rules about how to keep your Sims happy and productive)

Dynamics are the way people behave due to these rules – determined by the players (eg. in chess players think several moves ahead and sometimes make sacrificial moves. In The Sims, people realised they could make the Sims sick and unhappy and did so).

Aesthetics is the way it feels to play the game (eg. chess becomes a solemn and serious battle of wits. In The Sims the experience becomes to savour and create)

How does it relate to libraries? Well, we set up rules, the mechanics for using our data. (eg. to get to an authenticated journal title, you have to do a title search in the catalogue) . How our users relate to our systems is the dynamics (eg. confusion, attempts to enter an article title not journal title, google it instead ) . The user experience is the aesthetics (eg. success or frustration, incomprehension, defeat ) .

What if we started with the aesthetics – the user experience – then worked backwards to produce the mechanics that gave this? What if we acknowledged the layer of dynamics in the system – ie that users may not follow our rules and that this may produce a different aesthetics ? I think this model can apply to our offline activities as well as our online ones.

Waterfall vs Iterative vs Agile product design/testing

Robin contrasted the traditional “waterfall” model of product design with her preferred iterative product design. Waterfall has linear stages like Imagine > See > Handle >Use . Iterative testing builds in constant revisiting of the stages as the product is created.

It made me think about the decisions we make about any system in our libraries. At what point are we building in retesting, review, checking and re-evaluation? How often do we check the external circumstances and see whether the systems are still relevant? Are we building this into our cycle of product use and procedures?

( When researching this post, I found another more recent model, agile testing )

User created content – balancing the work in the fun.

Game users are changing. They are now more interested in the mechanics of games and in “putting them through their paces” (eg. creating downloadable objects for Sims to use). They are not so tied into a compulsive narrative. They want to co-create.

There is a point, however, when co-creation becomes less like fun and more like work. Robin’s example is the real lilfe co-ordination needed to get together a guild for a World of Warcraft raid at a specific time. Or the constant playing needed to go up a level in a game.

The challenge for game designers is to determine and stop short of that point where the creativity, independence and control of co-creation becomes more of a chore than a pleasure.

As we consider allowing our users to co-create our libraries, we need to consider the work / fun balance too. Will the ability to rate items in the catalogue, for example, seem like too much work for little reward?

Let the students be your voice

During question time, I asked Robin (who also works in academia) the best way to get university staff to take gaming seriously – and to understand that that gaming techniques can be a new form of information delivery and human/PC interface . I liked her answer, that it is best to “let the students be your voice”.

What do you think? Let us know.