"The player should feel like a plate-spinner at the circus — the moment one plate is stable, two others start wobbling."

Week 1: History & Design Theory

The Origin

The management genre was born from a single question Will Wright asked in 1989: what if the player was not a character inside the world but the invisible hand shaping it? SimCity gave players a blank grid and a budget, then let them zone residential, commercial, and industrial areas while watching simulated citizens move in, commute, complain, and leave. There was no win condition. The game was the system itself, and the joy came from watching your decisions ripple through interconnected feedback loops.

How the Genre Evolved

SimCity (1989) — Will Wright established the template: a grid-based world, zoning mechanics, budgets, and a simulation that runs on its own while the player nudges it with infrastructure decisions. Traffic jams, fires, and crime emerged not from scripts but from the interplay of systems.

RollerCoaster Tycoon (1999) — Chris Sawyer, working almost entirely in assembly language, narrowed the scope from an entire city to a single theme park and deepened every system. Guests had individual needs — hunger, thirst, nausea, excitement — and would pathfind to rides, food stalls, and bathrooms. The financial model was razor-sharp.

Two Point Hospital (2018) — Two Point Studios modernized the tycoon formula with clarity of information. The breakthrough was in UI design — overlays, graphs, and dashboards that made the simulation legible to the player without dumbing it down.

What Makes It "Great"

A great management game creates a web of systems where every decision has second-order consequences. Hiring more staff costs money, which means raising prices, which lowers satisfaction, which reduces visitors, which reduces income. The player is constantly triangulating between competing pressures, and the game never tells them the "right" answer.

The Essential Mechanic

Balancing interconnected systems where optimizing one often worsens another.

---

Week 2: Build the MVP

What You're Building

A Mini Theme Park Tycoon played on a grid. The player places attractions (rides, food stalls, restrooms) using a budget. Visitors arrive, pathfind to attractions based on their needs, queue up, get served, and eventually leave. The player earns income from ticket sales and pays maintenance costs. If cash drops below zero, the park goes bankrupt.

Core Concepts

1. Simulation Loop

Entities (visitors) have internal needs and behaviors that tick forward each update cycle. Every frame, each visitor evaluates its current state — hungry, bored, needs restroom — and acts on the most pressing need. The simulation loop is the heartbeat of the entire game.

function simulationTick(deltaTime, speedMultiplier):
    scaledDelta = deltaTime * speedMultiplier

    if shouldSpawnVisitor(park.reputation):
        visitor = createVisitor(park.entrance)
        park.visitors.add(visitor)

    for each visitor in park.visitors:
        visitor.hunger += HUNGER_RATE * scaledDelta
        visitor.boredom += BOREDOM_RATE * scaledDelta
        visitor.bladder += BLADDER_RATE * scaledDelta
        updateVisitorBehavior(visitor, scaledDelta)

    park.cash += calculateIncome(scaledDelta)
    park.cash -= calculateExpenses(scaledDelta)

Why it matters: The simulation loop is what makes a management game feel alive. Without it, placing buildings on a grid is just a puzzle. With it, the grid becomes a living system that responds to your design choices.

2. Satisfaction / Demand Modeling

Visitor happiness is a function of multiple weighted inputs. Each visitor tracks individual satisfaction based on how well their needs are met, wait times, and variety. Aggregate satisfaction becomes the park's reputation, which controls visitor inflow.

function calculateVisitorSatisfaction(visitor):
    satisfaction = BASE_SATISFACTION
    if visitor.hunger > HUNGER_THRESHOLD:
        satisfaction -= (visitor.hunger - HUNGER_THRESHOLD) * HUNGER_PENALTY
    if visitor.boredom > BOREDOM_THRESHOLD:
        satisfaction -= (visitor.boredom - BOREDOM_THRESHOLD) * BOREDOM_PENALTY
    satisfaction -= visitor.totalWaitTime * WAIT_PENALTY
    satisfaction += countUniqueRidesVisited(visitor) * VARIETY_BONUS
    return clamp(satisfaction, 0, 100)

Why it matters: Satisfaction modeling is what transforms a placement game into a management game. When the player realizes that cheap food lowers wait times but tanks quality satisfaction — that is the moment they start truly managing.

3. Placement and Zoning

The player places facilities on a grid, each with a zone of influence. Placement determines traffic flow, queue lengths, and whether visitors can find what they need.

function placeFacility(grid, facility, gridX, gridY):
    for dx in range(facility.width):
        for dy in range(facility.height):
            if grid[gridX + dx][gridY + dy].occupied:
                return PLACEMENT_BLOCKED
    // Place and register zone of influence
    for each cell in getCellsInRadius(gridX, gridY, facility.influenceRadius):
        cell.nearbyFacilities.add(facility)
    park.cash -= facility.buildCost

Why it matters: Placement is the player's primary design tool. Good placement reduces visitor walking time and prevents bottlenecks. Bad placement creates frustrated visitors wandering past empty stalls.

4. Financial Model

Income and expenses flow continuously. Rides generate ticket revenue per visitor served, food stalls earn per sale, and the park pays maintenance costs per facility per tick. Cash flow is displayed in real time, and if cash hits zero, the game ends.

function calculateIncome(scaledDelta):
    income = 0
    for each facility in park.facilities:
        if facility.type == RIDE:
            income += facility.visitorsServedThisTick * facility.ticketPrice
        else if facility.type == FOOD_STALL:
            income += facility.salesThisTick * facility.itemPrice
    income += park.newVisitorsThisTick * park.entryFee
    return income

Why it matters: The financial model is the constraint that makes placement meaningful. Without money, placing buildings is free and the game is trivial. With a budget, every ride is an investment that must pay for itself.

5. Time Acceleration

The player can toggle simulation speed between 1x, 2x, and 4x by multiplying the delta time. The key challenge is ensuring nothing breaks at higher speeds.

SPEED_OPTIONS = [1.0, 2.0, 4.0]

function gameLoop(deltaTime):
    scaledDelta = min(deltaTime * multiplier, MAX_TICK_DELTA)
    if scaledDelta > TICK_THRESHOLD:
        subTicks = ceil(scaledDelta / TICK_THRESHOLD)
        for i in range(subTicks):
            simulationTick(scaledDelta / subTicks)
    else:
        simulationTick(scaledDelta)

Why it matters: Management games involve waiting. Time acceleration lets the player skip the boring parts while maintaining the simulation's integrity.

6. UI for Complex Systems

A management game lives or dies by its information architecture. The player must see park-wide stats at a glance, drill down into individual facility performance, and spot problems before they cascade.

function renderDashboard(park):
    drawText("Cash: $" + formatNumber(park.cash))
    drawText("Visitors: " + park.visitors.length)
    drawText("Reputation: " + round(park.reputation) + "%")
    cashFlow = getCashFlowPerMinute()
    color = cashFlow >= 0 ? GREEN : RED
    drawText(formatCashFlow(cashFlow) + "/min", color)

Why it matters: The simulation can be deep and accurate, but if the player cannot read it, they cannot play it. UI is not a cosmetic layer — it is the player's primary interface with the simulation.

7. Emergent Behavior from Simple Rules

Each visitor follows simple individual rules — find the nearest facility that satisfies my most pressing need, walk there, queue, get served, repeat. But when hundreds of visitors follow these rules simultaneously, patterns emerge: traffic jams near popular rides, dead zones, rush-hour surges at food stalls.

function updateVisitorBehavior(visitor, scaledDelta):
    switch visitor.state:
        case DECIDING:
            need = getMostPressingNeed(visitor)
            facility = findNearestFacility(visitor, need.type)
            if facility: visitor.state = WALKING
            else: visitor.state = LEAVING
        case WALKING:
            moveToward(visitor, visitor.target.position)
            if arrived: visitor.state = QUEUING
        case QUEUING:
            visitor.waitTime += scaledDelta
            if visitor.waitTime > MAX_WAIT:
                visitor.state = DECIDING  // give up
        case LEAVING:
            moveToward(visitor, park.exit)

Why it matters: Emergent behavior is the magic of management games. When a player notices that visitors leaving the roller coaster always flood the nearby food stall, they did not read that in a tutorial — they observed it in the simulation.

---

Stretch Goals

• Loan system — Borrow money at interest to fund expansion.
• Staff entities — Hire janitors and mechanics that must be routed to facilities.
• Random events — Rainstorms lower outdoor ride satisfaction, VIP visitors with high expectations.
• Heatmap overlay — Show real-time traffic patterns across the park.

MVP Spec

Component	Minimum Viable Version
Grid	16x16 tile map
Facilities	3 types: Ride, Food Stall, Restroom
Visitors	Spawn at entrance, pathfind to needs, queue, get served, leave
Satisfaction	Per-visitor score based on needs met, wait times, variety
Financial Model	Entry fee + per-use charges, maintenance costs, bankruptcy = game over
Time Controls	1x / 2x / 4x speed toggle
UI	Top bar (cash, visitors, reputation), facility panel on click

Deliverable

A playable management simulation where the player places three facility types on a grid, watches visitors autonomously navigate to satisfy their needs, manages cash flow, and can accelerate time. The game must demonstrate emergent visitor behavior, a functional financial model, and a clear dashboard.

---

Discussion Questions

1. The Information Problem: RollerCoaster Tycoon lets you click on any guest to see their thoughts. Two Point Hospital uses overlays. Which approach better serves the player, and at what scale does one break down?
2. Depth vs. Readability: Adding more interconnected systems makes the simulation richer but harder to understand. Where is the line between "deep" and "opaque"?
3. Emergent Behavior as a Design Tool: What if simple rules produce degenerate strategies (e.g., one of each facility at the entrance)? How do you design rules that produce interesting emergent behavior?
4. The Tycoon Difficulty Curve: How do you design difficulty scaling that stays challenging without feeling punitive?