The Art of Game Design (part 4)

As regular readers will know, I've been looking at Jesse Schell's book The Art of Game Design.  Parts one and two covered the fundamental elements of games.  Part three covered the experience of playing a game.

In part four we start to look more closely at one of the major elements: mechanics.

---

What are game mechanics?

Essentially, game mechanics are what is left once aesthetics, story and technology have been stripped away.

For example, Pac-Man is essentially a 2D maze-based object-collection exercise carried out while avoiding enemies; a temporary role-switch allows you to chase the enemies for a fixed period of time.  The game repeats and is played at a faster pace until the player is caught.

This vague description of Pac-Man's mechanics illustrates another problem: there is no single taxonomy for analysing game mechanics; no clear & precise terminology for us to utilise.  (We've seen this problem before and it illustrates the general difficulty of trying to analyse games.)

Space

Schell states that a game takes place in a space of some kind.  This space may consist of discrete points (linked in one, two or three dimensions) or a continuous range (allowing unrestricted movement between constraints in one, two or three dimensions).  One type of space may be nested inside another, creating complex environments.  The specific application of thee terms is not important.  What is important is the fact that there is a set of rules defining where things can be and how they relate to one another.

Objects

He moves on to talk about objects: characters, props, buildings, head-up displays, etc.  As a programmer I'm particularly familiar with object-oriented (OO) techniques: the idea that objects within the game have attributes (a.k.a. properties or variables) which each have a current state (or value).  These objects also have methods (also called functions) which identify an object's abilities -- what it can do.

CLASSES & OBJECTS

Fido is an object.  He has various attributes (location, direction, speed, energy, etc.).

 

What if we wanted Fido to have two friends called Rover and Spot?  They are both the same type of object as Fido, and would also have the same attributes.

What do all three objects have in common?  Well, they're all dogs.

We can design a Dog class which describes the features common to a dog (i.e. attributes & methods).  From this template we can create multiple objects ('instances' of the class) -- Fido, Rover & Spot.

Although they are all based on the same design, their states are independent (for example, Rover's speed might be different to Fido's).

Note:  In many branches of OO programming it's conventional (for historial reasons) to use a capital letter for the class name ('Dog') but lower-case for the object names ('fido', 'rover', & 'spot').  This runs counter to the normal conventions of English (lower case for general type, capital for a name) but I'll be sticking with the OO convention in these posts.

This is a very powerful abstract concept, and is very useful in gaming: we can describe a general mechanic and apply it to multiple objects, which each behave independently according to the rules we have set.

Actions

Schell moves on to talk about actions.  These are the things that happen within a game.  He splits these into two main types: operative actions and resultant actions.

Operative actions are the fundamental actions that a player can take (e.g. moving a piece, firing a bullet, etc.)  An object's methods contribute to this, but there are overall game actions affecting the objects themselves.

Resultant actions are tactics -- methods which are used to achieve a specific objective (according to an overall plan).  Examples of this include hiding a piece behind another piece, shooting to clear a path before running along it, etc.)

Schell does not mention strategy, but this is presumably because it plays a wider role in the game narrative than in mechanics.


This gives a lot to chew on so far, and we're not even half-way through the topic.  The most important thing I've learned in this post is that it's vital to have a very clearly-defined mechanic.