IMG_3785.jpeg

Four examples of transferrable mechanics

1. Transferring a game's core mechanics from one scenario to another

In Blood, Sweat and Pixels, Bruce Straley, the co-director of Uncharted 4, talked about how the team had a prototype of a level where the player would control Nathan through a ballroom dancing sequence. They cut it.

The prototype employed a set of interactions that were only used in that sequence. The player had to learn those interactions, but could never apply them again.

In contrast, core mechanics are small in number and appear again and again in a game. The player can use what they learned in one context and apply it in another. For example, the player can take what they learned about climbing in a mountainous environment and apply it to traversing trucks in a chase.

2. Transferring physical properties of objects to program behavior in Dynamicland

In Dynamicland, programs are attached to pieces of paper. Changing the code changes the behavior. But, because the program is a piece of paper on a desk, its behavior can be changed by doing the everyday physical mechanics you can do with a piece of paper: moving it to put it close to another piece of paper, turning it, drawing on it, sticking post-its on it, using a particular color of paper.

The user already knows how to do all these things and can easily transfer their knowledge to this new medium.

[Thanks to Omar for this example.]

3. Transferring mechanics used for creation over to programming in an end-user environment

In Ink & Switch's essay about end-user programming, they talk about the value of an in-place toolchain. Imagine the user has an environment where they use mechanics to create things. If the user now wants to program in that environment, an in-place programming toolchain would let them do this by employing the same mechanics they have already been using when creating.

They gave an example of a cards-on-a-canvas app. The user can move cards, group them, delete them, add text. In order to program the environment, they can add special daemon cards that run programs. But they can still transfer all the mechanics they learnt to manipulate cards - adding, deleting, typing text - and apply them to this new programming scenario.

4. Transferring mechanics used for writing a program over to debugging a program

If your program is not behaving as you want, one option is to start a debugger. This will put you in a different interface. You'll no longer be writing code. You'll likely no longer be running your program in the same way as you did before. Suddenly, you're ballroom dancing.

Alternatively, you could type console.log and run your program as normal. Which is to say, you could use the same mechanics you've always used.

[Thanks to Omar for this example.]

Traits of transferability

Mastery

A mechanic that is reused can be deeper because the user can build their skill with it over time.