Separate Resources, Story Facts and Records
NovelToGame requires resources to be read by actual rules. Hidden promises, testimony and possession also need recorded causes and callbacks. Not every fact needs a progress bar.
| Content | Question |
|---|---|
| Remaining work time | Does it limit today’s available actions? |
| Promise to repair one window first | Which response or action reads that promise? |
| Windows repaired this month | If only historical, can it live in an archive? |
| “Focus” rising on every click | With no rule reading it, why claim gameplay impact? |
This guide asks whether a numeric system needs to exist. Interface organization asks when to display existing information. Hiding an unused stat does not make it useful.
Locate Sources and Rule Checks for Each Stat
Audit the current design or implementation rather than guessing from names.
- What does it measure in terms players understand? Is “trust” a score or a record that someone accepted a promise?
- Which action adds or spends it? Settle once; rereading a screen should not award it again.
- Which gate, action or result reads it? Mark unimplemented uses as plans.
- Where do players see the reason and resulting opportunity? A rising number alone does not explain meaning.
- Which judgment disappears if it is removed? If none changes, consider removing it from the core system.
A source with no use accumulates; spending with no recovery can block a required path. Recovery depends on the project’s task and scope, rather than requiring every resource to regenerate.
Original Example: What a Repair Commission Needs
In this paper game, the player has 4 work hours for the day. Repairing the east window takes 2; the west door takes 3, with no same-day replenishment. Check the balance before starting and deduct only when the chosen job finishes. Resident Tang asks for the window first; the player may promise or explicitly decline.
If Tang hears a promise and the player repairs the door first, she pauses the next optional commission until the player explains and she decides whether to cooperate again. This is the example’s chosen story rule, not a universal affinity penalty. Without a promise, she cannot accuse the player of breaking it.
A separate “professionalism” stat rises by 1 per repair, but no action, character or ending reads it.
- Retain work hours: both jobs cannot fit today. The remaining 2 or 1 hours block the other unfinished job today.
- Record the promise separately: who promised, which job came first and what Tang actually heard cannot be replaced by a total score.
- Remove unused professionalism from the strategy panel: record repaired objects if completion history matters, without inventing level rewards.
This original design is not a running system. Removing the work-hour limit changes task choices; removing unread professionalism changes none of the listed paths.
Check Actions and Saves After Reducing Stats
Use this manual audit brief, not a new native data contract:
Review [stats and rules]. List meaning, sources, spending, rule checks, feedback and path changes after removal. Separate actual rules from plans. Recommend deletion or archival treatment for unread values without inventing uses. Preserve concrete promises, knowledge and possession as facts. Identify affected buttons, results, saves and records for individual decisions.
Removing state or changing semantics may affect old saves. Declare migration or rejection of old versions, then replay the faulty and adjacent paths. Treat label changes separately from rule changes.
Fewer stats do not automatically create depth. The intended result is clearer tasks and retained states that affect actions, which still require checking the candidate and player feedback.
FAQ
Must affinity scores be removed?
No. Keep scores that govern understandable conditions, while preserving concrete promises, permission, knowledge and possession separately. Establish each state’s actual purpose.
Do it with the skill
With source materials, a chosen concept and a product brief, use /game-world-design or $game-world-design in Codex to audit rule checks and necessary systems. Implementation changes also follow game-build state, save and patch boundaries. This worksheet supports design review.
Read the method: Resources, reachability and strategy comparison · Changing situations and deletion tests · State, saves and bounded patches