Vision

Source of truth for product direction. Read before planning any new feature. Authored 2026-06-02. Living document — amend as direction sharpens.

---

1. Vision

HearthHold is a calm, indirect-control medieval city builder for solo desktop players who want the satisfaction of watching a town grow without the stress of micromanagement. The game has no end and no failure state — instead, players advance through an endless ladder of milestones that unlock new visuals, new mechanics, and deeper building progression.

2. Player fantasy

You're a displaced settler who arrives at a quiet clearing with nothing but the clothes on your back. You drop a House. People come. You drop a Farm. People work. The town grows. As your settlement matures, your buildings gain experience, your world transforms with each milestone, and what started as a single house becomes a thriving place that mostly runs itself — while you make the few decisions that shape its character.

3. Target player

• Platform: solo desktop (single-player only, no multiplayer ever)
• Session length: 30 minutes to multiple hours, drop-in friendly
• Genre fluency: familiar with Banished / Manor Lords / Frostpunk but burnt out on punishment
• Mood: wants relaxed pacing, no time pressure, no losing, satisfying numerical progression

4. Pillars

These are the values every feature must uphold. If a feature violates a pillar, redesign or cut it.

Pillar	What it means
Legibility	The player always understands what's happening and why. Numbers tick visibly. Causes name themselves.
Calm	No time pressure. No game-over. No losing.
Tactility	Every action lands with immediate, clear feedback (popups, sounds, visual deltas).
Indirect control	Players assign roles; the city executes. No individual citizen orders, no micromanagement.
Soft-fail	Failures slow you down, never end you. Starvation = slower production, not death.

5. The "aha" moment

The first time a new player assigns a worker to a Farm, sees the +1 Food popup rise above the building, and notices the Food counter tick up — that's the moment "this is a town." Every system in HearthHold reinforces this 30-second feedback cycle.

6. Differentiators

What makes HearthHold not "another indie city builder":

• Roguelite meta-progression on top of city building — buildings gain XP, earn skill points, upgrade, and eventually "Prestige" to a V2 form. Most city builders have no per-building progression.
• Endless milestone ladder — no scenarios, no campaign chapters, no fail-states. One world, milestones forever.
• Calm by design — no starvation deaths, no enemies, no time-limited objectives. Soft-fail throughout.
• Indirect-control purity — citizens are passive walkers, buildings hold all state and interaction. You design the city's logic; the city runs itself.

7. Anti-pillars

What HearthHold intentionally is not:

• ✗ Not a war/conquest game — no combat, no military, no conquest mechanics.
• ✗ Not a multiplayer game — single-player only, forever.
• ✗ Not a hard-fail survival game — soft consequences only (slow production, idle buildings), no citizen death.
• ✗ Not interactive-citizen — citizens are decoration; buildings carry all state.

Distant goals (intentionally deferred, not rejected):

• ~ Giant cities — v1 caps perf at small-to-medium settlements. 5000-building scale is a long-horizon question, not a v1 goal.

8. Building progression system (v2.0 headline)

The signature feature differentiating HearthHold from peer city builders. Briefly:

• Each placed building accumulates XP as it produces resources.
• XP converts to skill points the player spends on upgrades (faster production, more capacity, lower input cost, etc.).
• All upgrades for a building are eventually unlockable — no forced meta. Early decisions shape pacing, not endgame.
• When a building's tree is fully unlocked, it Prestiges to a V2 form — new mesh, new mechanics, fresh upgrade tree.
• V2's progression carries the building toward later milestone unlocks.

Detailed system design lives in a separate doc when v2.0 enters planning (see ROADMAP-V2.md milestone notes).

9. Modding & theming (v4.0 long-horizon)

Long-term enabler — design every system not to block it, but don't build infrastructure until v4.

• All gameplay data lives in .tres Resource files (BuildingDef, GameConfig) — mod-loadable in principle.
• Themes = same buildings, swapped meshes/materials. A "winter theme" or "tropical theme" should be a data-only mod, not a code change.
• Workshop integration is post-v4 and only if the project has traction. The data architecture should permit it; the runtime can ship later.

10. Lock-in risks to watch

These design decisions can quietly box us out of future features. Review at every milestone close:

Risk	Why it matters	Mitigation now
Save/load format	v2.0 building progression adds per-building state — save format must accommodate	Use Resource-based snapshots from v1.5 onward
Building data hardcoded	Modding requires runtime-loadable defs	Already .tres-based; keep loaders unaware of file location
Citizen architecture	If we ever want interactive citizens, abstract counters block that	Keep deferred; reserve scenes/citizens/ folder structurally
Map fixed-size	Procedural needs flexible map sizing	Avoid hardcoding 40×40 outside GameConfig
Game-speed coupling	Engine.time_scale affects everything; can't run UI faster than sim	Document; revisit if multiplayer ever (won't) happens

---

See ROADMAP-V2.md for the milestone-by-milestone slice plan.