Game Design Attribution Audit

Audit a design by asking how players will explain what just happened.

Use this skill to evaluate whether a success or failure is likely to be interpreted as deserved, learnable, and controllable, or as arbitrary, unfair, and outside the player's influence. Focus on player perception of causality, not designer intent or mechanical correctness.

Read references/family-conventions.md when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. Read references/output-patterns.md when you want the preferred recommendation and minimal-fix structure.

Core principle

Players do not respond only to outcomes. They respond to the story they tell themselves about why the outcome happened.

Healthy failure attribution usually feels:

• internal enough to preserve responsibility
• controllable enough to support improvement
• unstable enough to preserve hope

Toxic failure attribution usually feels:

• external
• uncontrollable
• stable

That combination produces reactions like "the game screwed me" or "this always happens and I can do nothing about it."

Attribution lenses

1. Locus

Ask whether the player is likely to locate the cause internally or externally.

• Internal: "I made the wrong choice" or "I misplayed"
• External: "the game cheated" or "the system decided against me"

2. Stability

Ask whether the player sees the cause as recurring or one-off.

• Stable: "this is just how this game always works"
• Unstable: "that happened this time, but next run could go differently"

3. Controllability

Ask whether the player believes they can influence the outcome in future attempts.

• Controllable: "I can improve this"
• Uncontrollable: "nothing I do matters"

What to produce

Generate:

1. Attribution profile - likely player interpretation across locus, stability, and controllability
2. Perception summary - what the player is likely to think happened
3. Fairness diagnosis - whether the outcome feels deserved, understandable, and learnable
4. Risk assessment - frustration, learned helplessness, toxicity, or churn risk
5. Design actions - specific changes to improve attribution quality

Process

1. Define the audit target

Clarify:

• what exact scenario, feature, or failure state is being audited
• what outcome triggered the audit
• who the relevant player is

Write:

• Audit target
• Outcome type
• Player context

2. Reconstruct the event from the player's point of view

Map:

• what the player did
• what the system did
• what feedback the player received
• what information was visible versus hidden

Ask:

• What action did the player believe they were taking?
• What result did they expect?
• What actually happened?
• What evidence did the game provide about cause and effect?

3. Classify the likely attribution profile

For the observed outcome, judge:

• Locus - internal, mixed, or external
• Stability - stable, mixed, or unstable
• Controllability - high, partial, or low

Use this format:

4. Infer the likely player interpretation

Translate the attribution profile into player-facing language.

Examples:

• "I got greedy and deserved that"
• "That was bad luck, but I could have mitigated it"
• "The game hid the rule and punished me"
• "This encounter is just broken"

Prefer the exact sentence a frustrated player might actually say.

5. Diagnose why the attribution landed there

Look for root causes such as:

• hidden mechanics
• weak telegraphing
• delayed or ambiguous feedback
• inconsistent rules
• excessive randomness
• low agency or missing mitigation tools
• punishment that is too severe for the level of clarity provided

6. Check compounding risk patterns

Pay special attention to combinations like:

• low clarity + high punishment
• high randomness + low mitigation
• repeated failure + stable external attribution
• weak feedback + complex systems
• low control + high stakes

These combinations tend to create helplessness, blame, and churn faster than any one issue alone.

7. Convert the diagnosis into design changes

For each issue, specify:

• Problem
• Why players read it that way
• Suggested change
• Expected perception shift

Examples:

• improve telegraphing -> shifts blame from system to player decision
• expose hidden rules -> increases controllability
• add mitigation option -> turns fatalism into recoverable error
• reduce punishment severity -> lowers hostility during learning

Response structure

Use this structure unless the user asks for something else:

Audit Target

• ...

Event Reconstruction

• ...

Attribution Profile

• Locus: ...
• Stability: ...
• Controllability: ...

Likely Player Interpretation

• ...

Fairness and Learning Diagnosis

• ...

Risk Assessment

• ...

Recommendations

1. ...
2. ...
3. ...

Minimal Fix

• ...

Fast mode

Use this quick pass when speed matters:

• What does the player think caused the outcome?
• Does it feel internal or external?
• Does it feel controllable next time?
• Does it feel like a one-off or a permanent rule?
• What one change would most improve perceived control or clarity?

Usage notes

This audit is especially useful for:

• combat deaths
• boss fights
• failure loops
• loot outcomes
• economy punishments
• onboarding mistakes
• puzzle failures
• competitive losses
• high-RNG systems that may be misread as rigged

Common patterns to watch for:

• a system can be mechanically fair and still attract external blame
• a hard loss can feel acceptable if the cause is clear and avoidable
• severe punishment raises the attribution bar: clarity and control must rise with it
• repeated confusion hardens unstable frustration into stable hostility

Working principle

A good failure says, "you can learn this." A bad failure says, "the game just does that."

Use this skill when you need to understand not only what happened, but what players will believe happened.

<!-- license-footer --> Part of the Game Design Skills Bundle by Stanislav Stankovic. Licensed under PolyForm Noncommercial 1.0.0 — free for personal, academic and nonprofit use. Commercial use requires a licence, sold as skill packs. See <https://github.com/Stanestane/game-design-skills-bundle> for terms.

Required Notice: Copyright Stanislav Stankovic (https://www.stane-island.net/)