game-design-attribution-audit

Name: game-design-attribution-audit
Author: Stanestane

34stars3forks

How to install game-design-attribution-audit?

stanestane/game-design-skills-bundle/game-design-attribution-audit

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-attribution-audit

Installs into the current project.

Summary

Audit a game, feature, combat scenario, progression step, failure state, onboarding beat, or reward outcome through the lens of attribution theory: how players explain success and failure. Use when evaluating whether players will blame themselves, the system, luck, or hidden rule

Files · 1

View on GitHub

SKILL.md

1	# Game Design Attribution Audit
2
3	Audit a design by asking how players will explain what just happened.
4
5	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.
6
7	Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
8	Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.
9
10	## Core principle
11
12	Players do not respond only to outcomes. They respond to the story they tell themselves about why the outcome happened.
13
14	Healthy failure attribution usually feels:
15	- internal enough to preserve responsibility
16	- controllable enough to support improvement
17	- unstable enough to preserve hope
18
19	Toxic failure attribution usually feels:
20	- external
21	- uncontrollable
22	- stable
23
24	That combination produces reactions like "the game screwed me" or "this always happens and I can do nothing about it."
25
26	## Attribution lenses
27
28	### 1. Locus
29	Ask whether the player is likely to locate the cause internally or externally.
30
31	- Internal: "I made the wrong choice" or "I misplayed"
32	- External: "the game cheated" or "the system decided against me"
33
34	### 2. Stability
35	Ask whether the player sees the cause as recurring or one-off.
36
37	- Stable: "this is just how this game always works"
38	- Unstable: "that happened this time, but next run could go differently"
39
40	### 3. Controllability
41	Ask whether the player believes they can influence the outcome in future attempts.
42
43	- Controllable: "I can improve this"
44	- Uncontrollable: "nothing I do matters"
45
46	## What to produce
47
48	Generate:
49	1. Attribution profile - likely player interpretation across locus, stability, and controllability
50	2. Perception summary - what the player is likely to think happened
51	3. Fairness diagnosis - whether the outcome feels deserved, understandable, and learnable
52	4. Risk assessment - frustration, learned helplessness, toxicity, or churn risk
53	5. Design actions - specific changes to improve attribution quality
54
55	## Process
56
57	### 1. Define the audit target
58	Clarify:
59	- what exact scenario, feature, or failure state is being audited
60	- what outcome triggered the audit
61	- who the relevant player is
62
63	Write:
64	- Audit target
65	- Outcome type
66	- Player context
67
68	### 2. Reconstruct the event from the player's point of view
69	Map:
70	- what the player did
71	- what the system did
72	- what feedback the player received
73	- what information was visible versus hidden
74
75	Ask:
76	- What action did the player believe they were taking?
77	- What result did they expect?
78	- What actually happened?
79	- What evidence did the game provide about cause and effect?
80
81	### 3. Classify the likely attribution profile
82	For the observed outcome, judge:
83	- Locus - internal, mixed, or external
84	- Stability - stable, mixed, or unstable
85	- Controllability - high, partial, or low
86
87	Use this format:
88
89	\| Dimension \| Likely player reading \| Why \|
90	\|---\|---\|---\|
91	\| Locus \| Internal / Mixed / External \| ... \|
92	\| Stability \| Stable / Mixed / Unstable \| ... \|
93	\| Controllability \| High / Partial / Low \| ... \|
94
95	### 4. Infer the likely player interpretation
96	Translate the attribution profile into player-facing language.
97
98	Examples:
99	- "I got greedy and deserved that"
100	- "That was bad luck, but I could have mitigated it"
101	- "The game hid the rule and punished me"
102	- "This encounter is just broken"
103
104	Prefer the exact sentence a frustrated player might actually say.
105
106	### 5. Diagnose why the attribution landed there
107	Look for root causes such as:
108	- hidden mechanics
109	- weak telegraphing
110	- delayed or ambiguous feedback
111	- inconsistent rules
112	- excessive randomness
113	- low agency or missing mitigation tools
114	- punishment that is too severe for the level of clarity provided
115
116	### 6. Check compounding risk patterns
117	Pay special attention to combinations like:
118	- low clarity + high punishment
119	- high randomness + low mitigation
120	- repeated failure + stable external attribution
121	- weak feedback + complex systems
122	- low control + high stakes
123
124	These combinations tend to create helplessness, blame, and churn faster than any one issue alone.
125
126	### 7. Convert the diagnosis into design changes
127	For each issue, specify:
128	- Problem
129	- Why players read it that way
130	- Suggested change
131	- **Expected percep

People who liked this also viewed

6 picks

Type

game-design-attribution-audit

34stars3forks

View on GitHub

How to install game-design-attribution-audit?

stanestane/game-design-skills-bundle/game-design-attribution-audit

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-attribution-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Design Attribution Audit
2
3	Audit a design by asking how players will explain what just happened.
4
5	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.
6
7	Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
8	Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.
9
10	## Core principle
11
12	Players do not respond only to outcomes. They respond to the story they tell themselves about why the outcome happened.
13
14	Healthy failure attribution usually feels:
15	- internal enough to preserve responsibility
16	- controllable enough to support improvement
17	- unstable enough to preserve hope
18
19	Toxic failure attribution usually feels:
20	- external
21	- uncontrollable
22	- stable
23
24	That combination produces reactions like "the game screwed me" or "this always happens and I can do nothing about it."
25
26	## Attribution lenses
27
28	### 1. Locus
29	Ask whether the player is likely to locate the cause internally or externally.
30
31	- Internal: "I made the wrong choice" or "I misplayed"
32	- External: "the game cheated" or "the system decided against me"
33
34	### 2. Stability
35	Ask whether the player sees the cause as recurring or one-off.
36
37	- Stable: "this is just how this game always works"
38	- Unstable: "that happened this time, but next run could go differently"
39
40	### 3. Controllability
41	Ask whether the player believes they can influence the outcome in future attempts.
42
43	- Controllable: "I can improve this"
44	- Uncontrollable: "nothing I do matters"
45
46	## What to produce
47
48	Generate:
49	1. Attribution profile - likely player interpretation across locus, stability, and controllability
50	2. Perception summary - what the player is likely to think happened
51	3. Fairness diagnosis - whether the outcome feels deserved, understandable, and learnable
52	4. Risk assessment - frustration, learned helplessness, toxicity, or churn risk
53	5. Design actions - specific changes to improve attribution quality
54
55	## Process
56
57	### 1. Define the audit target
58	Clarify:
59	- what exact scenario, feature, or failure state is being audited
60	- what outcome triggered the audit
61	- who the relevant player is
62
63	Write:
64	- Audit target
65	- Outcome type
66	- Player context
67
68	### 2. Reconstruct the event from the player's point of view
69	Map:
70	- what the player did
71	- what the system did
72	- what feedback the player received
73	- what information was visible versus hidden
74
75	Ask:
76	- What action did the player believe they were taking?
77	- What result did they expect?
78	- What actually happened?
79	- What evidence did the game provide about cause and effect?
80
81	### 3. Classify the likely attribution profile
82	For the observed outcome, judge:
83	- Locus - internal, mixed, or external
84	- Stability - stable, mixed, or unstable
85	- Controllability - high, partial, or low
86
87	Use this format:
88
89	\| Dimension \| Likely player reading \| Why \|
90	\|---\|---\|---\|
91	\| Locus \| Internal / Mixed / External \| ... \|
92	\| Stability \| Stable / Mixed / Unstable \| ... \|
93	\| Controllability \| High / Partial / Low \| ... \|
94
95	### 4. Infer the likely player interpretation
96	Translate the attribution profile into player-facing language.
97
98	Examples:
99	- "I got greedy and deserved that"
100	- "That was bad luck, but I could have mitigated it"
101	- "The game hid the rule and punished me"
102	- "This encounter is just broken"
103
104	Prefer the exact sentence a frustrated player might actually say.
105
106	### 5. Diagnose why the attribution landed there
107	Look for root causes such as:
108	- hidden mechanics
109	- weak telegraphing
110	- delayed or ambiguous feedback
111	- inconsistent rules
112	- excessive randomness
113	- low agency or missing mitigation tools
114	- punishment that is too severe for the level of clarity provided
115
116	### 6. Check compounding risk patterns
117	Pay special attention to combinations like:
118	- low clarity + high punishment
119	- high randomness + low mitigation
120	- repeated failure + stable external attribution
121	- weak feedback + complex systems
122	- low control + high stakes
123
124	These combinations tend to create helplessness, blame, and churn faster than any one issue alone.
125
126	### 7. Convert the diagnosis into design changes
127	For each issue, specify:
128	- Problem
129	- Why players read it that way
130	- Suggested change
131	- **Expected percep

People who liked this also viewed

6 picks

Type