Sources and sinks

377. Lesson identity

Module

1.9 — Basic economy

Lesson

Sources and sinks

Academic type

Systems

Schema type

text

Order

1

Estimated time

20–30 minutes, including practice

This lesson treats economy as a gameplay loop rather than as a shop interface.

378. Learning objective

After this lesson, you can map one resource source and one resource sink for a tiny game economy, including what causes each transaction and how the resource balance changes.

379. Why this matters

A shop is only one presentation of an economy. The economy itself is the movement of a resource into and out of the player's available balance. If you can identify the source and the sink first, you can judge whether a reward is meaningful and whether a cost creates a real decision. This gives you a systems description that can guide later UI and code decisions.

380. Prior knowledge

You should be able to describe a player action and its immediate result using the Stage 1 loop: ACT → RESPOND → CHANGE → AGAIN. Module 1.8, Tutorial interaction, provided practice with valid player states and continued interaction. No shop UI or code implementation is required for this lesson.

381. Core concept

A source adds a resource to the player's available balance. A sink removes that resource through a cost, purchase, loss, or other expenditure.

A source is not simply “where the player gets something.” It must identify a transaction or event that increases the balance. A sink is not simply “something the player wants.” It must identify a transaction or event that decreases the balance.

A minimal economy needs both sides:

source: completed action or event → + resource
sink:   chosen cost or expenditure   → - resource

The source and sink should be described in terms of player behavior. “Coins exist in the game” is not a source. “Completing a delivery adds 3 coins” is a source. “The shop exists” is not a sink. “Buying a repair removes 2 coins” is a sink.

382. Mental model

Use the balance ledger:

Then test the loop with ACT → RESPOND → CHANGE → AGAIN:

1. ACT: The player completes a delivery.
2. RESPOND: The game acknowledges the completed delivery.
3. CHANGE: The player's balance increases by 3 coins.
4. AGAIN: The player decides whether to spend, save, or pursue another action that uses the economy.

The same model applies when the sink occurs: the player acts, the game confirms the expenditure, the balance changes, and the new balance affects the next choice.

383. Concrete example

Consider a tiny expedition game with one resource: rations.

• Source: Returning from an expedition adds 4 rations if the player found supplies.
• Sink: Starting an expedition removes 2 rations.
• Current balance: 6 rations.

One cycle looks like this:

ACT:      Start an expedition
RESPOND:  The game confirms that the expedition begins
CHANGE:   6 rations → 4 rations
AGAIN:    Return from the expedition or decide whether another expedition is affordable

If the return adds 4 rations, the balance becomes 8. The economy now has a visible relationship between activity and cost. The expedition is not economically free, and the reward is not just decoration: it changes how many future expeditions are possible.

Notice what this example does not specify. It does not need a shop screen, item icons, or currency animation. Those are presentation choices. The source-and-sink map is the system underneath them.

384. Common mistake

A common mistake is to list rewards without naming a sink. For example, “the player earns coins for deliveries” describes a source but not an economy. Without a sink, coins accumulate without affecting decisions. The opposite mistake is to define an attractive purchase without defining how the player can fund it. A usable map must state at least one addition, one removal, and the event that triggers each.

385. Guided practice

Create a one-resource economy for a tiny game loop. Do not design a shop screen.

1. Choose one resource: coins, rations, fuel, keys, or another concrete resource.
2. Write one source using this format: When the player [action/event], the balance increases by [amount].
3. Write one sink using this format: When the player [choice/action], the balance decreases by [amount].
4. Start with a balance of 5 units and calculate the balance after one source and one sink.
5. Decide which action the player takes next and explain how the resulting balance affects that choice.

Your map must include one meaningful decision. For example, the player may spend the resource now or preserve it for a later action. If your source and sink do not change a decision, revise one amount or trigger.

386. Validation / evidence

Your evidence is a five-line balance ledger containing:

• the resource name;
• one clearly triggered source;
• one clearly triggered sink;
• the balance before and after both transactions;
• one next decision affected by the final balance.

A valid map passes these checks:

• the source increases the balance;
• the sink decreases the balance;
• both transactions have an identifiable trigger;
• the final balance can be calculated without guessing;
• the balance changes what the player can do next.

387. Key takeaways

• A source adds a resource; a sink removes it.
• An economy is the relationship between resource flows and player decisions, not merely a shop interface.
• Every source and sink needs a trigger and an amount.
• ACT → RESPOND → CHANGE → AGAIN can be used to trace how an economic transaction affects the next choice.

388. Next lesson

Next: 1.9 L2 — Shown price is not the rule. It will extend this source-and-sink map into a display-versus-simulation decision.

389. Knowledge check