game-design-vocabulary

Game Design Vocabulary

Use this skill to describe how a game produces an experience through interaction. Keep observation, inference, and judgment separate. A precise critique explains which rule or presentation choice caused a player behavior, why that behavior supports or conflicts with the design goal, and what experiment could test an improvement.

Working Vocabulary

• Player action: A possibility the player can intentionally invoke to affect or inspect game state. It is not the same as a physical button.
• Game entity: A person, object, region, resource, timer, relationship, or abstract state that participates in rules.
• Rule: A condition and state transition, including costs, limits, exceptions, and feedback.
• Scene: A bounded unit of play with a distinct purpose, pressure pattern, or set of foreground rules. It is not necessarily a Godot .tscn file.
• Context: The visual, auditory, textual, spatial, and thematic framing that helps players form expectations about rules.
• Resistance: The ways the game delays, redirects, tests, or answers player intent.
• Pacing: The arrangement of pressure, choice, novelty, information, consequence, and recovery over time.
• Audiovisual communication: How image, motion, composition, camera, interface, sound, music, and silence expose state and consequence.
• Narrative: Meaning formed through authored events, systemic cause and effect, and the player's interpretation of what occurred.

These are tools for reasoning, not a mandatory ontology. Rename or adapt them when a team's existing language is clearer.

Analysis Workflow

1. Frame the Question

State:

• The game, build, level, mode, and platform being analyzed.
• The intended audience and experience, if known.
• The specific question, such as why players ignore stealth or why a scene feels exhausting.
• Evidence available: direct play, recording, telemetry, code, design notes, or player report.
• Unknowns and assumptions.

Do not judge a mechanic against an invented goal. If intent is unknown, analyze likely effects under more than one plausible goal.

2. Capture Evidence

Run at least one play pass without proposing fixes. Record timestamps or state transitions for:

• Inputs attempted and actions produced.
• State changes and feedback.
• Hesitation, repetition, mistakes, retries, and abandonment.
• Camera, UI, animation, sound, and music changes.
• Entry and exit conditions for distinct sections of play.

Label each note as observed, reported, inferred, or measured. A rule inferred from one outcome is provisional until repeated or confirmed in code.

3. Map Actions, Entities, and Rules

For each important action, identify its target entities, preconditions, cost, transition, feedback, failure response, and interactions with other actions. Find actions with no developed relationships, entities whose presentation suggests the wrong rule, and exceptions players cannot predict.

Use Actions, Entities, and Rules for the mapping procedure and implementation distinctions.

4. Segment the Experience into Scenes

Divide play where the purpose, foreground rule, pressure, choice breadth, or rhythm changes. For each scene, identify what it introduces, practices, combines, tests, reveals, or resolves. Compare the order to what the player has already learned.

Use Scenes, Context, and Communication to inspect scene structure, visual composition, camera, UI, animation, audio, and redundant cues.

5. Trace Resistance and Pacing

Describe what the player is trying to do and how the game answers. Resistance can be useful even when it blocks an action, provided the response is understandable and advances learning, tension, expression, or consequence.

Plot pressure, available choices, novelty, information, consequence, and recovery across scenes. Look for flat repetition, unexplained spikes, long recovery gaps, and pressure that targets a different skill than intended.

Use Resistance, Pacing, and Narrative.

6. Analyze Narrative Meaning

Ask:

• What actions does the game repeatedly make important?
• What entities receive protection, attention, ownership, or harm?
• Which outcomes are rewarded, punished, ignored, or made impossible?
• Do authored events agree with the player's systemic behavior?
• Which events can players interpret or retell as their own experience?

Do not reduce narrative analysis to dialogue and cutscenes. Also do not claim one definitive interpretation when the system supports several.

7. Produce a Critique

Complete the Original Critique Worksheet. Prioritize findings by impact on the stated goal and confidence in the evidence.

Write each finding in causal form:

Because <specific rule or communication>, players <observable behavior>, which <supports or conflicts with goal>. Test <small change> and measure <expected evidence>.

Avoid prescriptions such as make it more intuitive, improve flow, or add polish without naming the mechanism and test.

Design Workflow

The vocabulary also works in the forward direction:

1. Define the intended player expression or experience.
2. Choose a compact action set.
3. Create entities that give those actions distinct consequences.
4. Specify rules and feedback for successful, failed, and invalid attempts.
5. Arrange scenes that introduce, vary, combine, and reframe the rules.
6. Give each abstract rule a consistent audiovisual and thematic context.
7. Shape resistance and recovery into an intentional rhythm.
8. Decide what narrative is authored, simulated, or left to interpretation.
9. Prototype the smallest scene that can disprove the design.

Verification

Analytical Quality

• Every conclusion points to evidence.
• Observations are not rewritten as assumptions about player emotion.
• The critique distinguishes input, conceptual action, animation, and resulting state.
• Scene boundaries are justified by a design change, not only a loading boundary.
• Audiovisual analysis names the state each cue communicates.
• Narrative claims include rules and outcomes, not only written content.
• Recommendations are small experiments with success and failure evidence.

Unit and Instrumentation Suggestions

• Unit-test rule preconditions, transitions, costs, cooldowns, exceptions, and feedback events.
• Log action attempts separately from successful state changes.
• Log scene entry, exit, retries, deaths, prompt displays, and abandoned goals.
• Test invalid action attempts so the game still acknowledges input appropriately.
• Verify the same rule after pause, reload, remapping, low frame rate, and network delay where applicable.

Visual and Playtest Suggestions

• Capture a clean playthrough and annotate state changes frame by frame.
• Test silhouettes, contrast, UI scale, camera framing, animation timing, and offscreen cues.
• Repeat with color removed, audio muted, effects reduced, and alternate input devices.
• Ask players to predict an entity's behavior before interacting, then compare prediction to outcome.
• Ask for a retelling after play to reveal which systemic and authored events became meaningful.

Edge Cases

• Spectators, co-op partners, or AI agents may possess different action sets and information.
• A menu, dialogue, inventory, or pause state can be a scene if it changes the active decisions.
• Randomness can obscure a rule; repeat with fixed seeds before concluding inconsistency.
• Expert players may skip intended scene order or collapse resistance through system knowledge.
• Accessibility assists can change timing or execution without changing the underlying decision.
• Live-service patches may invalidate a critique; record build and configuration.
• A bug can resemble a design rule. Confirm repeated behavior or inspect implementation before interpreting it.

Expected Output

Return:

1. Scope, goal, evidence, and assumptions.
2. Action-entity-rule map.
3. Scene and pacing outline.
4. Context and audiovisual communication findings.
5. Resistance and narrative analysis.
6. Severity-ranked findings with experiments and verification criteria.
7. Open questions and evidence still needed.