game-design-fairness-frustration-audit

Name: game-design-fairness-frustration-audit
Author: Stanestane

34stars3forks

How to install game-design-fairness-frustration-audit?

stanestane/game-design-skills-bundle/game-design-fairness-frustration-audit

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

Installs into the current project.

Summary

Audit a game, feature, failure loop, combat encounter, reward system, progression wall, or high-variance mechanic for perceived fairness and frustration. Use when diagnosing whether players feel cheated, whether difficulty feels deserved, whether randomness, feedback, and challen

Files · 1

View on GitHub

SKILL.md

1	# Game Design Fairness and Frustration Audit
2
3	Audit a design by asking whether it feels fair, understandable, and worth retrying.
4
5	Use this skill when the real question is not merely "is it balanced" but "why does this make players mad?" This audit combines three lenses:
6	- attribution theory: who or what players blame
7	- flow theory: whether challenge and skill stay aligned over time
8	- perceived randomness: whether uncertainty feels exciting, suspicious, or rigged
9
10	Focus on player perception. Mechanical correctness is not enough if the experience still feels hostile.
11
12	Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
13	Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.
14
15	## Core principle
16
17	Players will accept difficulty, failure, and uncertainty when they feel:
18	- the cause is understandable
19	- they had meaningful influence
20	- the challenge matched a learnable demand
21	- luck was visible, bounded, or mitigable
22
23	Players reject the same systems when outcomes feel:
24	- arbitrary
25	- hidden
26	- uncontrollable
27	- disproportionate
28	- repeatedly punishing without teaching
29
30	## What to produce
31
32	Generate:
33	1. Fairness assessment - whether the experience feels fair, questionable, or unfair
34	2. Frustration profile - what kind of frustration it creates and why
35	3. Attribution diagnosis - how players explain the outcome
36	4. Randomness diagnosis - how uncertainty is perceived and whether it is trusted
37	5. Flow diagnosis - where challenge-skill mismatch amplifies frustration
38	6. Design actions - what to change first to reduce hostility and improve retry willingness
39
40	## Process
41
42	### 1. Define the audit target
43	Clarify:
44	- what exact mechanic, loop, or scenario is producing the concern
45	- whether the issue centers on failure, reward, difficulty, or inconsistency
46	- what player segment is feeling the pain most
47
48	Write:
49	- Audit target
50	- Player segment
51	- Observed complaint or risk
52
53	### 2. Reconstruct the player-facing event
54	Map:
55	- what the player tried to do
56	- what the system did in response
57	- what role randomness played
58	- what feedback the player saw
59	- what the cost of failure was
60
61	Ask:
62	- What did the player think would happen?
63	- What actually happened?
64	- What evidence did the game provide to explain the result?
65	- What could the player realistically have done differently?
66
67	### 3. Run the attribution lens
68	Judge whether the likely reading is:
69	- internal or external
70	- stable or unstable
71	- controllable or uncontrollable
72
73	Translate that into the likely player sentence, not just the technical classification.
74
75	### 4. Run the randomness lens
76	Examine:
77	- whether randomness is visible or hidden
78	- whether it changes frequency, impact, or both
79	- whether the player can mitigate, predict, or prepare for it
80	- whether streaks or outliers feel suspicious
81	- whether randomness is being mistaken for execution failure or designer malice
82
83	### 5. Run the flow lens
84	Check:
85	- whether challenge exceeded current skill too sharply
86	- whether the player had enough teaching or support before the demand hit
87	- whether repetition creates learning or just repeated punishment
88	- whether the experience becomes anxious, exhausting, or deadening over time
89
90	### 6. Identify compounding frustration patterns
91	Pay special attention to combinations like:
92	- high challenge + low clarity
93	- high punishment + low controllability
94	- hidden RNG + severe loss
95	- repeated failure + stable external attribution
96	- long retry cycle + low learning value
97
98	This is where frustration often shifts from healthy tension into "I am done with this."
99
100	### 7. Grade the fairness experience
101	Use a direct classification:
102	- Fair - hard, but understandable and teachable
103	- Questionable - some understandable basis, but trust is fragile
104	- Unfair - outcomes feel hostile, hidden, or insufficiently controllable
105
106	State clearly whether the main problem is:
107	- clarity
108	- control
109	- randomness
110	- pacing
111	- punishment
112	- inconsistency
113	- or a combination
114
115	### 8. Convert findings into design changes
116	For each issue, specify:
117	- Problem
118	- Why it feels unfair
119	- Suggested change
120	- Expected emotional effect
121
122	Examples:
123	- add telegraphing -> reduces external blame
124	- expose odds or logic -> reduces suspicion
125	- add mitigation or counterplay -> increases control
126	- soften punishment during learning -> preserves retry motivation
127	- shorten retry cycle -> converts frustration into iteration
128
129	## Respon

People who liked this also viewed

6 picks

Type

game-design-fairness-frustration-audit

34stars3forks

View on GitHub

How to install game-design-fairness-frustration-audit?

stanestane/game-design-skills-bundle/game-design-fairness-frustration-audit

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Design Fairness and Frustration Audit
2
3	Audit a design by asking whether it feels fair, understandable, and worth retrying.
4
5	Use this skill when the real question is not merely "is it balanced" but "why does this make players mad?" This audit combines three lenses:
6	- attribution theory: who or what players blame
7	- flow theory: whether challenge and skill stay aligned over time
8	- perceived randomness: whether uncertainty feels exciting, suspicious, or rigged
9
10	Focus on player perception. Mechanical correctness is not enough if the experience still feels hostile.
11
12	Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
13	Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.
14
15	## Core principle
16
17	Players will accept difficulty, failure, and uncertainty when they feel:
18	- the cause is understandable
19	- they had meaningful influence
20	- the challenge matched a learnable demand
21	- luck was visible, bounded, or mitigable
22
23	Players reject the same systems when outcomes feel:
24	- arbitrary
25	- hidden
26	- uncontrollable
27	- disproportionate
28	- repeatedly punishing without teaching
29
30	## What to produce
31
32	Generate:
33	1. Fairness assessment - whether the experience feels fair, questionable, or unfair
34	2. Frustration profile - what kind of frustration it creates and why
35	3. Attribution diagnosis - how players explain the outcome
36	4. Randomness diagnosis - how uncertainty is perceived and whether it is trusted
37	5. Flow diagnosis - where challenge-skill mismatch amplifies frustration
38	6. Design actions - what to change first to reduce hostility and improve retry willingness
39
40	## Process
41
42	### 1. Define the audit target
43	Clarify:
44	- what exact mechanic, loop, or scenario is producing the concern
45	- whether the issue centers on failure, reward, difficulty, or inconsistency
46	- what player segment is feeling the pain most
47
48	Write:
49	- Audit target
50	- Player segment
51	- Observed complaint or risk
52
53	### 2. Reconstruct the player-facing event
54	Map:
55	- what the player tried to do
56	- what the system did in response
57	- what role randomness played
58	- what feedback the player saw
59	- what the cost of failure was
60
61	Ask:
62	- What did the player think would happen?
63	- What actually happened?
64	- What evidence did the game provide to explain the result?
65	- What could the player realistically have done differently?
66
67	### 3. Run the attribution lens
68	Judge whether the likely reading is:
69	- internal or external
70	- stable or unstable
71	- controllable or uncontrollable
72
73	Translate that into the likely player sentence, not just the technical classification.
74
75	### 4. Run the randomness lens
76	Examine:
77	- whether randomness is visible or hidden
78	- whether it changes frequency, impact, or both
79	- whether the player can mitigate, predict, or prepare for it
80	- whether streaks or outliers feel suspicious
81	- whether randomness is being mistaken for execution failure or designer malice
82
83	### 5. Run the flow lens
84	Check:
85	- whether challenge exceeded current skill too sharply
86	- whether the player had enough teaching or support before the demand hit
87	- whether repetition creates learning or just repeated punishment
88	- whether the experience becomes anxious, exhausting, or deadening over time
89
90	### 6. Identify compounding frustration patterns
91	Pay special attention to combinations like:
92	- high challenge + low clarity
93	- high punishment + low controllability
94	- hidden RNG + severe loss
95	- repeated failure + stable external attribution
96	- long retry cycle + low learning value
97
98	This is where frustration often shifts from healthy tension into "I am done with this."
99
100	### 7. Grade the fairness experience
101	Use a direct classification:
102	- Fair - hard, but understandable and teachable
103	- Questionable - some understandable basis, but trust is fragile
104	- Unfair - outcomes feel hostile, hidden, or insufficiently controllable
105
106	State clearly whether the main problem is:
107	- clarity
108	- control
109	- randomness
110	- pacing
111	- punishment
112	- inconsistency
113	- or a combination
114
115	### 8. Convert findings into design changes
116	For each issue, specify:
117	- Problem
118	- Why it feels unfair
119	- Suggested change
120	- Expected emotional effect
121
122	Examples:
123	- add telegraphing -> reduces external blame
124	- expose odds or logic -> reduces suspicion
125	- add mitigation or counterplay -> increases control
126	- soften punishment during learning -> preserves retry motivation
127	- shorten retry cycle -> converts frustration into iteration
128
129	## Respon

People who liked this also viewed

6 picks

Type