Define a system goal
Snapshot
~75 sec
A system goal is a one-sentence statement of the decision an economy exists to support. Without one, every resource, rate, and reward becomes negotiable improvisation instead of a testable design.
You will learn
- Write a system goal as a decision statement, not a feature description.
- Recognize when a goal is too vague to test a resource against.
- Scope one goal to one primary decision before naming any resource.
Target outcome
You can write a one-sentence system goal that a reviewer can test any later resource, rate, or reward against.
Visual walkthrough
Visual walkthrough
~5 min
Four qualities of a testable system goal
Decision-shaped
Names the choice the player makes, not the feature that exists.
Scoped
Covers one decision, not an entire game or session.
Observable
Names a result a reviewer can point to, not a feeling.
Stable
Survives changes to numbers, art, or platform without being rewritten.
Compare a feature-shaped goal with a decision-shaped one
Approach Clarity Testability Scope “Add a crafting system”Names a feature to build, not a decision to support. A reviewer cannot restate a decision from it, only a system name. There is no way to check whether a proposed resource belongs, since nothing was declared as in or out of scope. It implicitly covers every future crafting-related choice, so scope keeps expanding. “Let a player trade saved time for a stronger tool before a session ends”Names the exact tradeoff and the moment it applies. A reviewer can restate the tradeoff in one sentence without guessing. Any proposed resource can be checked against one question: does it serve this trade. It names one decision and one boundary (before the session ends), so new resources cannot silently expand it. One goal, three downstream rules
A goal is written before any resource exists. Read this diagram as upstream first: the goal is what justifies every rule that follows, not the other way around.
Upstream goal
System goal
The one-sentence decision statement written before any resource is named.
Downstream rules
Source rule
A rule proposed to introduce a resource into the model.
Sink rule
A rule proposed to remove a resource in exchange for an outcome.
Signal rule
A rule that decides what a reviewer will look at to check the goal is holding.
- System goalSource rulejustifies
- System goalSink rulejustifies
- System goalSignal ruledefines success for
A goal is written before any resource exists. Read this diagram as upstream first: the goal is what justifies every rule that follows, not the other way around. Reading order
- System goal
The one-sentence decision statement written before any resource is named.
- Source rule
A rule proposed to introduce a resource into the model.
- Sink rule
A rule proposed to remove a resource in exchange for an outcome.
- Signal rule
A rule that decides what a reviewer will look at to check the goal is holding.
Connection explanations
- System goal → Source rule (justifies)
A source rule is only justified if the resource it adds is needed for the goal's decision.
- System goal → Sink rule (justifies)
A sink rule is only justified if removing the resource enacts the decision named in the goal.
- System goal → Signal rule (defines success for)
The goal determines which observable result actually counts as evidence the loop is working.
Test a proposed goal
A designer proposes a goal: “Increase player engagement.” Is this decision-shaped? Why or why not?
Expected reasoning
No. It does not name a decision the player makes or a moment where a resource matters, so no proposed resource can be checked against it. A decision-shaped version might be: “Let a player choose to spend saved time for a one-time advantage before a match starts.” That version can be tested against any resource, rate, or reward proposed later.