Design Ramblings: Mechanical Hooks

When working on Travelogue, at some point I crossed a threshold where it became hard to come up with new ways to reward the player. The more items I created, the less space there was for interesting, distinctive item properties and effects. This all boils down to an idea I call ‘mechanical hooks’.

A game will end up having some basic set of mechanics – you can move your character, perform an attack, deal damage, get hit, take damage, etc. Each of these basic mechanics gives you a hook that you can use to modify the gameplay later on with items, experience levels, special abilities, and so on. The number of distinctive ways you can hook into these basic mechanics determines the maximum amount of variation you can have in your gameplay – variation you can use to distinguish character classes, reward the player, allow for growth and customization, etc.

In the above example, you could have effects that change movement. If you have an overhead game like Legend of Zelda, then the character’s movement speed is probably the only real hook you have so far. But if you introduce terrain that blocks your movement, each such terrain gives you a new mechanical hook to create an ability to bypass that limit. If you have a side-scroller with jumping, now you can independently modify movement speed, jump height, and even hover time (e.g. the differences between Mario, Luigi, and Princess Peach in Mario 2). If there are other consequences of movement, such as D&D’s threatened squares and Attacks of Opportunity, then these provide another hook.

With ‘perform an attack’, if you just queue up a strike and the game computes the result, you pretty much just have ‘does it hit or not?’ as your hook. If enemies can defend, then you can now have hooks that tie into disabling enemy defenses. And so on.

Its not necessarily the case you want to maximize the number of such hooks you have – you could easily get to a situation where the game becomes too complex for the player to follow if you just indiscriminately create subsystems in order to be able to modify those subsystems later. But I think it is useful when designing the base underlying mechanics of the game to ask ‘what are the hooks that I can modify later, and do I need something richer to support a game of the length and complexity that I’m trying to create?’

Leave a comment