agentleFS
Come-In-LabsCome-In-Labs/agent-skills/skills/fun-check/SKILL.md

fun-check

Skill2 starsChanged 9 days agoMITView on GitHub

Use when designing, balancing or judging a game, game mode, challenge or any gamified loop and the real question is whether people will enjoy it - "is this fun", "will people come back", "balance it", "make it more playful", "simulate the game", "should we add streaks, badges or a daily bonus", "the sim says fair but a player says they never win". Also when a simulation, a persona review or a retention chart is offered as proof that something is fun.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    In team games, measure the team and the people in it: Add "carry": the share of a team's points made by its most active member.

    line 36
  2. Distinctive:

    Use personas for understanding only: Use cil:ux-review for whether people find the game, understand the rules and read the copy right.

    line 37
  3. Distinctive:

    Compare two versions instead of rating one: Ask "which was more fun, A or B?".

    line 39

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Measuring fun

Core principle

Fun is a feeling, but it has causes you can test. Measure the causes in a simulation, check understanding with personas, measure the feeling through what real people do, and keep only the sim measures that predicted what people did. No single source signs off fun: a balanced sim is a precondition, a persona's "I'd come back" is a hypothesis, a retention chart is engagement.

What causes fun, and how sure we are

Name the evidence tier whenever a claim rests on one of these.

CauseIn a gameEvidence
Competencechallenge matched to skill, clear feedback on how you didexperiment: Keller and Bless 2008 (difficulty matched to the player produced flow, too easy or too hard did not); Peng et al. 2012 (an exergame with competence features switched on and off)
Autonomyreal choices, your own way of playing can winexperiment: Peng et al. 2012; survey: Ryan, Rigby and Przybylski 2006
Relatednessrivals, teammates, people you knowsurvey: Ryan, Rigby and Przybylski 2006
Uncertainty to the endthe result stays open, comebacks happengame measures checked against player rankings: Browne and Maire 2010
Something left to learna better way to play keeps paying offtheory: Koster 2004, Schmidhuber 2010 (fun as learning progress)
Peak and endpeople remember the best moment and the ending, not the averageexperiment: Kahneman et al. 1993
Novelty fadesbadges and streaks lift use for weeks, then lessreview: Hamari, Koivisto and Sarsa 2014

Engagement is not fun. Near misses raise the urge to keep playing while players rate them as unpleasant (Clark et al. 2009). Variable rewards, daily spins and loss-framed streaks raise opens, not enjoyment.

Steps

  1. Write the fun promise and the guardrails before measuring. The promise: who plays, which feeling (mastery, discovery, rivalry, people), at which moments. The guardrails: what the game must never push people to do, such as skip sleep, play while driving, pay, or share where they live. Selling a way out of a loss (a paid streak freeze, a paid retry) is a guardrail failure. Write down each measure's range and the decision a miss triggers, before you look at any result.
  2. Run the sim scorecard (table below) on real behaviour data, with a ladder of bots: a random bot, a greedy beginner who plays the best of what it got, a planner who goes for a goal, a bold player who takes calculated risks, and one restricted bot per honest play style ("only plays safe", "only explores").
    • Bend the replayed behaviour. Nobody in last month's data played the game. When a bot goes for something, it changes the activity within that person's own range (amount, time, place) with a set chance of success. That chance is a guess: write it down and test it with people.
    • Run the bad cases: one very active player, a player who stops, the cheapest exploit.
    • In team games, measure the team and the people in it. Add "carry": the share of a team's points made by its most active member. Most points from one person means the others are watching, not playing.
  3. Use personas for understanding only. Use cil:ux-review for whether people find the game, understand the rules and read the copy right. A persona's feeling ("it never wins") is a hypothesis for step 2 and step 4, never evidence of fun.
  4. Test with people, over the time the game really spans.
    • Compare two versions instead of rating one. Ask "which was more fun, A or B?"; ratings drift and bunch up (Yannakakis and Martínez 2015).
    • Take the decision away once. Each player plays one round where the app decides for them and one where they decide, in random order. When a round lasts a week, split the testers into two groups instead. If behaviour doesn't drop without the decision, the fun is elsewhere (the rival, the activity itself), and a simpler game would do.
    • Ask for a moment, not a score. "Tell me about that game" a few days later. A specific moment ("I called it and made it by two minutes") is a peak; "it was nice" is not.
    • Read the behaviour signals (table below) against a holdout, in week 3, not on day 1.
  5. Calibrate the sim against people. For every scorecard measure, check whether it moved with the human results. Does "open into the last round" predict a rematch? Keep the measures that predicted, retire the rest, adjust the ranges, and write the calibration next to the scorecard.
  6. Report: the scorecard with pass or fail and the feeling each miss stands for, what only people can settle, and one question.

Fun is not a launch gate. Block a launch only when a guardrail fails or the scorecard shows a broken game (choices are fake, volume decides, one piece wins everything). Otherwise ship it as a test: part of the users, a holdout, no streaks or spins, and the kill criteria from step 1. The fun verdict comes from week 3.

Sim scorecard

A "round" is whatever unit scores: a round, a day, a week. A "piece" is whatever players pick: a card, an option, a strategy, a map zone, a quest. In a solo game the goal is the rival: "win" means making it, the bot ladder compares going for it with not trying (if ordinary behaviour already makes most goals, the goal is fake), and "volume doesn't decide" compares the time to a reward for a three-times-a-week player and a daily one. Skip rows that don't exist in the game, such as collecting. Starting ranges come from one game and must be recalibrated in step 5.

MeasureHowStart rangeFeeling it stands for
Choices are realbest bot against randomfar above 50%decisions are not fake; random is no stand-in for a weak human
Learning laddereach rung against the one below: planner over greedy, bold over plannereach step 55 to 80%something left to learn, beginners not crushed
Every style can wineach restricted-style bot against the free bot45 to 55%my way of playing counts
Volume doesn't decidethe player with fewer sessions wins45 to 55%it is about play, not hours
Decision weightshare of plays where the best and the worst legal choice end the round differently40% or moremy decision counts; below it, autoplay would feel the same
Open to the endundecided going into the last round45% or moreuncertainty
Comebacksthe side behind after the first round wins20% or morenever out of it
Peak at the endgames ending with a comeback, a deciding round won by a small margin, or a bold play that came off50% or morewhat people remember
No dominant pieceshare of rounds won by the most common card or option2.5 times its fair share at most (25% with 10 or more)variety, nothing solved
Collecting gives choicefull collection against a starter set58% at mostno pay or grind to win
Lengthmedian time a game takeswhat the promise needsfits the rhythm of life

A fair average can hide a missing peak: when a style wins half its games but never gets the big moment, the dominant-piece and peak measures show it, not the win rate.

Behaviour signals

SignalWhat it means
The losing side starts the next gamethe strongest single sign of fun
Next game started without a push or mailwanted, not reminded
Delegation rate: decisions left to autoplay or defaultshigh means the choice is not fun
Behaviour changed for the game (schedule, habit, effort)the game reached their life
Visits between sessions without a promptthey think about it
Which version people pick when asked A or Bpreference, not politeness
Guardrails: lost sleep, overuse, spending, complaintsthe cost of the engagement

Common mistakes

MistakeInstead
"The sim is balanced, so it's fun"Balance is a precondition; the sim measures causes, people measure the feeling
A persona says it would come backA hypothesis; test it with the behaviour signals
Retention from another feature as proofIt describes that feature's engagement; this game gets its own holdout
Asking people to rate fun from 1 to 5Ask A or B, and ask for a moment
Reading day 1Read week 3, against a holdout; novelty fades
Adding streaks, spins or daily bonuses to lift retentionLaunch without them and test later against a holdout; never variable rewards tied to money
Fixing a "never wins" complaint by tuning the win rateCheck peaks and the dominant piece first; give the style a big moment, not more average points
Tuning every check to the middleThe ranges guard the floor; the promise decides the shape

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.