Create structured scaling with exactly 3 tiers.

Progression = increasing stakes in controlled steps. Not infinite scaling — defined tiers. Each tier increases both risk and reward. Three tiers keep Version 1 manageable.

Ami — Danger Tiers

Tier 1 (Low Threat): riskLevel < 2. Base enemy power 5–10. XP reward ×1.

Tier 2 (Medium Threat): riskLevel 2–4. Enemy power 10–15. XP reward ×2.

Tier 3 (High Threat): riskLevel > 4. Enemy power 15–25. XP reward ×3.

if (riskLevel < 2) { tier = 1; } else if (riskLevel < 4) { tier = 2; } else { tier = 3; }
Ida — Development Tiers

Tier 1 (Small Homes): karma 0–99. Low build cost, low payout.

Tier 2 (Medium Builds): karma 100–299. Medium cost/payout. Medium debt risk.

Tier 3 (Major Projects): karma 300+. High cost, high payout, high debt risk.

  • Implement getCurrentTier() function
  • Adjust enemy power ranges per tier (Ami)
  • Adjust job payout ranges per tier (Ida)
  • Display current tier in console
  • Test: tier changes as progress increases
  • Verify tier affects difficulty and reward
  • Checkpoint

    Tier changes visibly as progress increases. Higher tiers feel harder and more rewarding.

    Exactly 3 tiers in Version 1. No sub-tiers. No dynamic difficulty adjustment.

    Tiers too close together — they don't feel different. Make the jump between tiers noticeable.

    Not scaling both difficulty AND reward — if Tier 3 is harder but doesn't pay more, it feels punishing, not rewarding.

    Making Tier 3 impossible — high difficulty should be challenging, not unfair. Playtest each tier.

    Ask: "Why 3 tiers instead of infinite scaling?" Answer: constraints create design decisions. Infinite scaling is lazy — you never have to decide when things change. Three tiers force you to define exactly when and how.