Create win/lose outcome logic. An event must resolve with consequences.
When you attack an enemy in a game and see "-47 HP" float above their head, what just happened? A formula ran. Every combat system is math disguised as action. Watch how the pros design these systems:
What Makes a Good Combat System? — GMTK
Mark Brown breaks down what makes combat feel satisfying — from simple number comparisons to complex systems with combos, timing, and strategy. Focus on the core idea: every combat resolves by comparing two numbers.
Discussion after watching: What's the simplest combat system you can think of? (Hint: comparing two numbers — like War, the card game.) What makes combat in your favorite game feel exciting even though it's just math underneath?
Every event needs a resolution — did you win or lose? And what happens as a result? The resolution engine takes inputs (player power, enemy power) and produces consequences (XP gained, XP lost). Without resolution, events are meaningless. Today we make them matter.
You need: Index cards (or small pieces of paper) and a pencil.
Setup:
- Write "PLAYER" on one card. Write a power number: 12.
- Make 5 enemy cards. Write "ENEMY" and a random power between 5 and 20 on each (roll a die, flip cards, or just pick numbers).
- Shuffle the enemy cards face down.
Round 1 — Basic Combat (5 fights):
- Flip one enemy card. Compare: Player Power vs Enemy Power.
- Higher number wins. Write W (win) or L (loss) on the table below.
- Repeat for all 5 enemy cards. Record your win/loss ratio.
Round 2 — Add a Risk Modifier (5 more fights):
- Make 5 new enemy cards (same range: 5-20). Shuffle face down.
- This time, your Player Power = 12 + riskLevel bonus. Set riskLevel = 3, so your power is now 12 + (3 * 2) = 18.
- Fight all 5. Record results.
Record your results:
| Round | Player Power | Wins | Losses | Win Rate |
|---|---|---|---|---|
| No modifier | 12 | |||
| +riskLevel (3) | 18 |
This IS your resolution engine. The code playerPower > enemyPower is literally what you just did — flip two cards, compare numbers. The riskLevel * 2 modifier is the bonus you added in Round 2. You just ran 10 iterations of your combat formula by hand. Now the code will run it in milliseconds.
Battle Resolution:
- Player Power = 10 + (riskLevel * 2)
- Enemy Power = random between 5 and 20
- If Player Power > Enemy Power → Win (+XP based on riskLevel)
- If Enemy Power >= Player Power → Lose (lose all unbanked XP, respawn to Camp)
Build Resolution:
- Build Cost = deduct materials (karma or debt)
- Completion = add payout to karma
- If karma drops below -50 → forced bankruptcy reset
The decision: take on debt for bigger builds, or stay safe with small jobs?
Ami's battle resolution function:
Ida's build resolution function:
You can win and gain XP/karma. You can lose and feel real consequences. State updates correctly after each resolution.
No complex stats. Single variable power only. No inventory. No special abilities.
Not resetting state after loss — unbanked XP must go to zero, zone must reset to safe.
Making wins too easy — if the player always wins, there is no challenge and no tension.
Making losses too harsh — if the player loses everything every time, they quit. Balance matters.
Not testing both outcomes — you must verify both winning and losing paths work correctly.
The paper combat activity connects directly to the code. After they play the card game, point at the resolveEncounter() function and say: "This is exactly what you just did with cards. playerPower > enemyPower is flipping two cards and seeing which number is bigger."
This is applied math. The combat formula is simple but powerful. Ask them to calculate: "With riskLevel 3, what's your power? What's the chance of winning?" Player Power would be 10 + (3 * 2) = 16. Enemy range is 5-20. So the player wins against enemies with power 5-15 (11 out of 16 possibilities = about 69%). Make them reason about probability.
Key question to ask: "If the player always wins, is it fun? If the player always loses, is it fun? Where is the sweet spot?" This connects to the balance discussion from Day 2. The resolution engine is where balance lives.
Watch for the "it's too easy" or "it's too hard" complaint during testing. That's a sign they understand the system and can now tune it. Tuning a number and seeing the result change is real game design.
Tomorrow: We add the decision that makes this a GAME — banking and debt pressure. Right now winning earns XP, but it's never at risk. Tomorrow, you'll have to choose: keep pushing for more, or secure what you have. That tension is everything.