Core Mechanics
What Are the Core Mechanics?
The core mechanics are the heart of a game; they generate the gameplay and implement the rules.
Core Mechanics: The core mechanics consist of the data and the algorithms that precisely define the
game’s rules and internal operations.
***CHANGE SLIDE***
Turning Rules into Core Mechanics
In early stages of design, you may only have a hazy idea of the details of your game’s rules. Early on, you
may say, “Players will be penalized for taking too long to get through the swamp.” Or “Players will have
only a limited time to get through the swamp.” But this alone doesn’t supply enough information to
build a game. There are still other things that need to be considered such as: What is the penalty? And
how long does the player have? When you design core mechanics, you define rules precisely and
completely. That same rule in core mechanics might read “When the avatar enters the swamp, the
black toadstools begin to emit a poison gas that the player can see filling the screen, starting at the
bottom and rising at a rate of 1 game-world inch every 3 seconds; by the end of 3 minutes, the gas
reaches the height of the avatar’s face, and if by that time the avatar is still in the swamp, the avatar
dies. If the avatar returns to the swamp later, the gas is gone, but the process starts over again from the
beginning.”
***CHANGE SLIDE***
What Are the Core Mechanics?
The core mechanics remain the same whether you keep them in your head, write them on paper, or
implement them in any programming language you like. As a project goes through different stages, the
mechanics remain the same, but their implementation varies.
First you document the algorithms in ordinary language in a design document; at this point, if you wish
to change the mechanics, you edit the document. Later you may build a spreadsheet containing the
algorithms and data and tweak them there. Another option is to make a paper prototype that allows
you to play the game, writing the values of the variables on pieces of paper and manipulating them
yourself according to the algorithms you’ve worked out, to see if the algorithms produce the game
experience you want to offer. This is essentially the same as the spreadsheet, but done by hand. Using
what you learn, you may update the design documents or you may have the spreadsheets become the
official implementation.
Eventually the core mechanics should be so precisely stated that the programmers can write code using
your core mechanics document or your spreadsheet as specifications. At this point, if you want to
change the mechanics, you have to ask the programmers to change the code or the data files.
The player does not experience core mechanics directly. They can’t point to something on the screen
and say “Those are the core mechanics.” If you apply player-centric design principles, all of the core
mechanics work together to provide a good game experience even though players don’t know what core
mechanics are and can only infer the functionality of the core mechanics from the way the game
behaves.
***CHANGE SLIDE***
The Core Mechanics as Processes
The relationship between the core mechanics and the game engine is extremely close, because the core
mechanics specify how the engine will behave. If someone says to you “The core mechanics send
triggers to the storytelling engine,” it means the same thing as “The game engine, using algorithms
specified by the core mechanics, sends triggers to the storytelling engine.”
The core mechanics do not dictate what the game engine will do; rather, how the engine carries out
actions is guided by the core mechanics.
Functions of the Core Mechanics in Operation
During play, the core mechanics operate behind the scenes to create and manage gameplay for the
player, keep track of everything that happens in the game world, and work with the storytelling engine
to help tell the story. The core mechanics do multiple things such as:







Operate the internal economy of the game. The core mechanics specify how the game or the
player creates, distributes, and uses up the goods on which the game bases its economy. This
function is the most important role of the core mechanics.
Present active challenges to the player via the user interface, as the level design specifies.
Accept player actions from the user interface and implement their effects upon the game world
and other players.
Detect victory or loss, and the termination conditions of the game. The mechanics detect
success or failure in all challenges in the game, and apply whatever the consequences are.
Operate the artificial intelligence of nonplayer character and artificial opponents.
Switch the game from mode to mode. The core mechanics keep track of the current gameplay
mode and, whenever a mode change occurs, the core mechanics switch modes and signal the
user interface to update the UI accordingly. A game mode is a distinct configuration that varies
gameplay and affects how other game mechanics behave. One of the most common examples
of game mode is the single player versus multiplayer choice in video games. Another example
of game modes are power-ups. Power-ups are modes that last for a few moments or that
changes only one or a few of the game rules.
Transmit triggers to the storytelling engine when game events or player actions that influence
the plot occur.
***CHANGE SLIDE***
Real-Time Games Versus Turn-Based Games
Most video games operate in real time, so the core mechanics specify the parameters of a living world
that operates on its own whether the player acts or not. Many of the mechanics will be processes that
operate continuously or for long periods of time. AI-driven characters go about their business, traps
check to see if they should spring upon anyone, banks collect and pay interest, and so on.
In a turn-based game with no artificial opponents, the core mechanics don’t do anything at all until a
player takes his turn. Once he has done so, the core mechanics can compute the effects of his actions
on the game world. Then the mechanics remain idle while the next player takes her turn, and so on. In
some games, all the players enter their intended actions simultaneously while the mechanics remain
idle; once the player finish for that turn, the core mechanics compute the effect of all players’ actions.
In a turn-based game that does have artificial opponents or NPCs, the mechanics don’t remain entirely
idle between turns because they must compute the behaviour of these characters. However, the
artificial characters still act in turns, just like the player.
***CHANGE SLIDE***
Core Mechanics and Level Design
Most games present gameplay in separate levels, each with its own set of initial conditions, challenges,
and termination conditions.
When a level starts up, the core mechanics read the level design data from a file, which includes: the
initial state of the game world for each level; the challenges, actions, and NPCs for each level; and the
victory conditions for the levels. Therefore, the design of the core mechanics should specify how
challenges work in general, but not which challenges each level will contain.
***CHANGE SLIDE***
Key Concepts
To design the core mechanics, you must document the different components that define how your
game works: resources, entities, attributes, and mechanics.
Resources
Resources refer to types of objects or materials the game can move or exchange, which the game
handles as numeric quantities, performing arithmetic operations on the values. Marbles constitute a
resource in your game if your player can pick up marbles, trade them, and put them down again.
Resource does not refer to specific instances of these types of objects, but the type itself in an abstract
sense. So what this means is that, if you have 1 marble, you are in possession of a resource, but if you
have 2 marbles, you do not have two resources. You have 2 instances of the same resource.
The core mechanics define the processes by which the game creates, uses, trades, and destroys
resources.
Games often treat nonphysical concepts such as popularity or vague concepts such as resistance to
poison as resources, even though we don’t normally think of these as quantities that can be bought and
sold.
***CHANGE SLIDE***
Entities
An entity is a particular instance of a resource or the state of some element of the game world. For
example, a light may be on or off. A building, character, or an animal can be an entity, and other things
such as a pile of gold or a vessel of water are also entities. The state of a traffic light at any given time is
also an entity. There are three types of entities: simple entities, compound entities, and unique entities.
Simple entities - The player’s score, or the current state of a traffic light can be completely
specified by a single datum; this is called a simple entity.
Compound entities - It may take more than one data value to describe an entity. In a flying
game, in which characterizing the wind requires stating both its speed and its direction, the
wind is a compound entity. Each of these values is called an attribute. An attribute is an entity
that belongs to, and therefore helps to describe, another entity.
Unique entities - If your game contains only one entity of a particular type, then that is a unique
entity. In most adventure games, the objects that the avatar can pick up are unique entities.
The avatar itself in most games is a unique entity because there is usually only one avatar.
***CHANGE SLIDE***
Mechanics
Mechanics document how the game world and everything in it behave. Mechanics state the
relationships among entities, the events and processes that take place among the resources and the
entities of the game, and the conditions that trigger events and processes. The mechanics can describe
something as simple as a light switch up to something as complicated as the AI of a smart NPC.
Random Numbers and the Gaussian Curve
Random numbers are used all the time in games.
When a random number is chosen, it is between 0 and 1, 0 means an event never happens, 1 means it
always happens.
Pseudo-Random Numbers
If you roll a set of die, and get a certain outcome, and then roll the die again, each roll is different from
the previous roll, but the sequence of rolls is identical.
Pseudo-random numbers are extremely useful when tuning a game’s mechanics. By using the same
seed each time you play, you always get the same random numbers, so the effects of chance don’t
change from one playing to the next. The mechanics become deterministic and predictable. This is also
essential for bug-fixing. If a bug happens by chance, it might not happen the next time someone plays
the game, so the programmer won’t be able to find it and fix it.
Just before a game is ready to ship, the programmers will change the code to take the seed from some
random source, such as the system clock, so the player will get a different experience each time he
plays.
Monte Carlo Simulation
In Monte Carlo simulation, you make a large number of test runs of your system using random inputs,
and record the results in a file. Then you can examine the file and make sure that the outcomes reflect
the behaviour that you expect. As an example: Many sports games let the player manage a team
throughout a whole season, and play each match that the real team would play. The game simulates all
the other matches in the league season (not involving the player’s team) automatically.
You don’t want the machine to play each simulated match through in real time; the player probably
won’t want to wait for it. So you will need to design a mechanic that fakes it; an algorithm that
generates the win-loss results for all the other matches without really playing them. Your mechanic will
probably be based on the attributes (such as the performance characteristics) of the athletes on the
team. To perform a Monte Carlo simulation, randomly generate two teams of athletes, with a variety of
random attribute settings for each athlete, then apply your mechanic to them and record which team
wins. Do this repeatedly, 1000 times or so. Afterwards, analyze the data from the simulations to see if
any anomalies occurred. Did a weak team ever beat a strong team? Did it happen often, or was it a
fluke? If it was a fluke, happening once in 1000 times, that’s OK—if sports matches were completely
predictable they’d be boring. But if it happened often, you know your mechanic has a problem. Some
examples of Monte Carlo simulation would be: to predict profits when people buy products at different
price points, to predict the failure rate of new products, and so on.