Skill: stanestane/game-design-perceived-randomness-audit (version 1.0.0)

--- name: game-design-perceived-randomness-audit description: Audit a game feature, combat system, loot table, reward loop, procedural system, chance mechanic, or uncertainty-driven design by how players are likely to perceive its randomness. Use when you need to evaluate whether a system will feel fair, streaky, rigged, sabotaging, manipulable, or skill-undermining; when players may misread independent events as patterned; or when randomness may sit too close to player action and create frustration. Analyze expectation gaps, gambler's-fallacy-style reactions, hidden pattern-seeking, input-versus-output randomness, perceived fairness, exploit risk, and ways to reshape presentation or mechanics. --- # Game Design Perceived Randomness Audit Audit not just the math of randomness, but the psychology of how players will read it. Use this skill when the core question is not only "is this random system balanced?" but also "what story will players tell themselves about this randomness?" The goal is to catch places where independent events will be perceived as rigged patterns, where streaks will feel malicious, where uncertainty undermines competence, or where the game could use presentation or structure to make randomness feel fairer and more legible. Read `references/perception-patterns.md` when you need the key psychology behind randomness perception. Read `references/audit-checklist.md` when you need a compact checklist of design risks and mitigation levers. ## Core behavior - Keep the analysis practical, not statistical-for-its-own-sake. - Audit player perception, not only formal probability. - Distinguish actual randomness from perceived randomness. - Identify where players will imagine patterns, sabotage, or "the game knows what I need and withholds it" behavior. - Check whether randomness happens before the decision or between the decision and the outcome. - Treat randomness that interferes directly with player action as more dangerous than randomness that shapes the environment. - Look for streak pain, expectation mismatch, control illusions, and competence damage. - Recommend concrete fixes in system design, UX, communication, and presentation. ## What to ask first Prioritize these questions: 1. What is the feature or random system? 2. What outcomes are random? 3. What does the player know before acting, and what is hidden until after acting? 4. What player action is this randomness attached to? 5. What does the player usually want in the moment when the random outcome occurs? 6. How often does the randomness happen, and how visible are streaks? 7. Is the system meant to feel exciting, fair, learnable, punishing, suspenseful, or skill-testing? 8. Are there safeguards, pity rules, weighted drops, rerolls, previews, or player-choice layers already present? If information is missing, infer cautiously and state the assumption. ## What to diagnose Quickly identify: - whether the player is likely to assume hidden patterns in independent outcomes - whether gambler's-fallacy-style expectations will make the system feel unfair after streaks - whether players will expect conditional fairness such as "I have not gotten X lately so I should get it soon" - whether randomness is input randomness, output randomness, or an unhealthy blur of both - whether the system damages the feeling of competence by making deliberate actions resolve unpredictably - whether players can meaningfully react to uncertainty using skill - whether the presentation helps players understand the randomness or makes it feel rigged - whether the mitigation method creates exploit risk or false promises ## Response structure Always organize the answer using this structure. ### System Read - describe the random system in plain language - state what is actually random and what is not ### Player Expectation Read - explain what players are likely to expect from the system - identify likely mistaken assumptions about balance, streak correction, fairness, or hidden intent ### Perceived Fairness Risk - explain when the system is likely to feel fair, unfair, rigged, streaky, or malicious - highlight the most likely frustration story players will tell themselves ### Randomness Placement - identify whether this is mostly input randomness or output randomness - explain whether randomness happens before the player chooses or after the player commits - say whether that placement supports or undermines skill expression ### Competence and Agency Read - explain whether players can adapt to the uncertainty with skill - identify where randomness is likely to invalidate intentional play - note whether the system feels like a challenge to respond to or a sabotage of action ### Risk Diagnosis - give the top 2 to 5 perception risks - include streak pain, hidden-intent suspicion, exploitability, or expectation mismatch where relevant ### Recommendation - recommend specific design, UX, or messaging changes - separate must-fix from optional polish when useful ## Common risk patterns Raise these when relevant: - truly independent drops being perceived as "due" - players believing the game withholds exactly what they currently need - random combat resolution making skillful decisions feel invalidated - pity systems that help fairness but become exploitable if too legible - procedural/input randomness producing wildly different challenge levels with too little response time - opaque weighting creating conspiracy theories - visible streaks without framing, smoothing, or counterweights - systems that are mathematically fair over long runs but emotionally awful in short runs ## Useful mitigation levers Only recommend what fits the design intent. - move randomness earlier so the player reacts to it rather than being blindsided by it - reduce output randomness on high-stakes actions - add soft streak smoothing or pity protection - batch outcomes into more even distributions when fairness matters more than pure entropy - provide player choice among random options - expose clearer odds or stronger telegraphing - separate excitement randomness from core skill resolution - use presentation to give the player a clearer sense of authorship or controlled reveal - shift reward pools by context carefully, while watching for exploit loops ## Strong use cases This skill is especially useful for: - loot drops and chest rewards - gacha, pity, and streak-protection systems - crit chance, hit chance, dodge, and proc systems - random combat resolution - procedural encounter or room generation - event reward pools - roguelike runs with variable offer quality - randomness-heavy retention loops - any design where players say the system feels rigged ## Weaker use cases This skill is less useful for: - systems with no meaningful uncertainty - purely economic balance review without a perception question - broad game critique where randomness is not a major issue ## Style guidance - Be concrete. - Do not hide behind statistics if the player-facing feeling is bad. - Do not assume mathematically fair means experientially fair. - If a system is perception-safe even though players may still complain sometimes, say that too. - If the right fix is presentation rather than probability tuning, say so. - If the right fix is to remove randomness from a player action entirely, say so directly. ## Fast mode Use this compressed flow when the user wants a quick answer: - what is random here - what will players assume about that randomness - will it feel fair or rigged - is the randomness before or after player choice - does it support skill or sabotage action - what should change first ## Working principle Players do not experience randomness as raw probability tables. They experience it as felt fairness, perceived intent, streak memory, and the degree to which their choices still seem to matter.

path: references/audit-checklist.md
content: # Audit Checklist

Use this file as a compact evaluation pass.

## Clarify the system
- What exactly is random?
- What is deterministic?
- How visible are the probabilities?
- How often does the random outcome occur?
- How high-stakes is each roll or draw?

## Expectation risks
- What does a normal player expect to happen over 5, 10, or 20 repetitions?
- Will the player expect short-run balance from a long-run random process?
- Will players believe the system is "due" to produce an outcome?
- Will streaks be highly visible and emotionally memorable?

## Placement risks
- Is the randomness before choice or after commitment?
- Can the player react to the uncertainty using skill?
- Does the randomness change the environment or sabotage the action?

## Fairness-perception risks
- When will the system feel rigged even if it is fair?
- What moments of need make bad outcomes feel malicious?
- Does the game accidentally create the story that it withholds exactly what the player wants?
- Is the short-run emotional experience much worse than the long-run math suggests?

## Agency and competence risks
- Does the player still feel smart when they play well?
- Can skill reduce the pain of bad luck?
- Does the system invalidate good decisions too often?
- Does randomness blur feedback so much that learning becomes muddy?

## Mitigation levers
- reduce output randomness
- move uncertainty earlier
- add pity or streak smoothing
- give a choice among random options
- expose clearer odds
- soften high-stakes streak pain
- reshape reward pools by context
- separate flavor randomness from core skill resolution

## Final verdict prompt
Ask:
- What is the biggest perceived-randomness failure here?
- What is the single highest-leverage fix?
- If no major fix is needed, why is this system perception-safe?


path: references/perception-patterns.md
content: # Perception Patterns

Use this file when you need the core ideas behind how players read randomness.

## 1. Brains look for patterns even in noise

Players naturally search for patterns, intent, and causality.
This is adaptive in life and misleading in random systems.
As a result, players will often believe:
- streaks mean something
- a system is "due" to correct
- the game is reacting to their current need
- unlucky outcomes imply hidden sabotage

## 2. Gambler's-fallacy-style expectations

Independent outcomes do not self-correct in the short run.
Players still often expect them to.

Common player stories:
- "I have missed five times, so the next one should hit"
- "I have not seen this drop in a while, so I should get it soon"
- "The system keeps giving me the one thing I do not need"

Audit implication:
- mathematically fair systems can still feel deeply unfair
- long-run fairness is weak protection against short-run resentment

## 3. Input randomness versus output randomness

### Input randomness
Randomness appears before the player chooses.
Examples:
- cards drawn into hand
- visible shop offers
- procedural room layout revealed before choice
- enemy spawn mix shown early enough to adapt

This usually supports skill better because the player responds to uncertainty.

### Output randomness
Randomness happens after the player chooses and between action and result.
Examples:
- hit chance after choosing an attack
- crit chance deciding the value of a committed action
- random chest result after the player already paid the cost

This is more dangerous because it can sever the link between intention and result.
It is more likely to damage competence and fairness perception.

## 4. Competence and action predictability

Players want uncertain situations.
They do not usually want their deliberate actions to feel untrustworthy.

Good pattern:
- the world is uncertain, but my action behaves as expected

Risky pattern:
- my action itself becomes random or resolves in a way I could not plan around

Audit implication:
- randomness that creates scenarios can be healthy
- randomness that corrupts the resolution of skillful action is more likely to frustrate

## 5. The system-feels-rigged story

When outcomes repeatedly clash with immediate player need, players often infer intent.
Example:
- low health -> no healing drops
- almost enough currency -> no currency drops
- need one upgrade material -> anything but that material

This can happen even with fair independent probabilities.
But the player story becomes:
- the game knows
- the game withholds
- the game is trolling me

Audit implication:
- check not only odds but moments of need
- identify where context amplifies perceived malice

## 6. Mitigation families

Different problems need different fixes.

### Smoothing
Use pity systems, bad-luck protection, or more even distribution when fairness matters more than purity.

### Repositioning randomness
Move randomness earlier so the player reacts to it rather than being blindsided by it.

### Choice injection
Offer several random options and let the player choose one.
This preserves surprise while restoring agency.

### Presentation and telegraphing
Use clearer framing, stronger anticipation, and visible affordances so randomness feels legible rather than arbitrary.

### Context-sensitive weighting
Adjust drop weights or outcomes by context only when the exploit risk is acceptable.

## 7. Main audit question

Do not ask only:
- "Is this mathematically fair?"

Also ask:
- "What will players believe about this randomness?"
- "What frustration story will the system generate?"
- "Does the randomness challenge player skill or erase it?"


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)