[Literature] Fundamentals of Game Design, ch 10: Mechanics

The mechanics are the data and algorithms that define the rules. Mechanics implement the internal economy inside the game engine and present challenges to the UI perspective. Mechanics are also in charge of the NPC AI, mode switching, and links to story engine. The mechanics define how resources can be created/deleted/exchanged, the state or attributes of entities, and the relationships between entities.

Economy

Quantifiable entities are produced by sources at spawn points (health pack in FPS or gold mine in RTS), consumed in drains (shooting consumes ammo, units cost resources), and exchanged through traders (exchange A against B, both A and B exist) or converters (A is consumed, B is produced). Players do not mind getting money for free, but they want to know why they lose some. Explain the drains. A resource is tangible if it takes physical space (space- and weight-limited inventory in Baldur's Gate vs potion stacking in RO vs limitless inventory in JRPG).

If the player has no way to get into a feedback loop, there is a deadlock. Example: when player has no money in Monopoly, she can't buy properties, and can not get money.
Mutual dependency happens when two production mechanisms require each each other's output as their input.
Equilibriums relieve pressure from the player: she can just sit and watch what happens. Therefore, there should be a mechanism to break the equilibrium or require player's intervention (e.g. farms in Age of Empires produce food automatically but expire after 3 harvests). Static equilibrium happens when offer = demand. Players can see their impact instantly in static equilibrium. Dynamic equilibrium happens when the same production cycle repeats itself over time (offer and demand follow patterns). Players may have to wait to know if their actions disrupted the equilibrium.

Mechanics and gameplay

Passive challenges do not require the mechanics to operate (e.g. climbing over a wall). Active challenges (solving a puzzle) have the player progress between states to reach the solution state. However, the player often has the same actions to solve all challenges (jumping, shooting, running).

Guidelines for designing mechanics

• Strive for simplicity: do not make more mechanics than necessary. Occam's razor.
• Do not try to get it perfect on paper. Playtest instead.
• Give enough details to programmers, but do not waste your time going too deep. Minor bugs and misconceptions can be fixed at tuning time.
• From higher-level game design documents, detail what the player is going to do, the flowboard of the game's modes, outline of the story, level ideas and progression, and victory and loss conditions.
• Do your entities: store resources? Are affected by processes? Have state and transitions? Have relationships with others? interact with or by the player (and how)? Also, find verbs these entities will enact.
• Resources: detail how sources, drains, and conversions work.

Debugging tip: always use the same seed in random number generators.