📖 Navigation
300+ Sections

THE LIVING WORLD

2.5D Persistent Life-Simulation RPG

Master Game Design Document — Performance-First Expo Edition

Target Platform: Android first, iOS second Technology Direction: Expo + React Native + TypeScript Game Presentation: 2.5D / Isometric / Stylized Primary Device: Low-to-mid-range mobile Secondary Platform: PC/Web only if technically practical later Core Fantasy: Live a life inside a world that continues living without you.

1. HIGH-LEVEL VISION

One-sentence pitch

A persistent 2.5D living-world RPG where the player begins as an ordinary person and can build any life they want while thousands of simulated people, businesses, factions and communities continue evolving around them.

The player is not the chosen hero.

The player is not automatically a king.

The player starts as:

Nobody.

They can become:

Or simply live a peaceful life.

2. DESIGN PILLARS

Everything in the game must support these pillars.

Pillar 1 — The World Lives Without You

NPCs have:

They continue doing things whether the player watches them or not.

Pillar 2 — Player Freedom

There should be no single correct way to play.

The player can decide:

"What kind of person do I want to become?"

Pillar 3 — Emergent Stories

The game should create situations rather than simply present scripted quests.

Example:

A farmer loses his harvest.

↓

He cannot pay his debt.

↓

His shop closes.

↓

His family becomes poor.

↓

His son joins a mercenary group.

↓

The son eventually becomes a military officer.

↓

Years later, that officer controls an important city.

The player might have caused the original event.

Pillar 4 — Consequences

Actions should matter.

If the player:

the world remembers.

Pillar 5 — Performance First

Performance is not something added after gameplay.

Performance is a design constraint from day one.

Never design a system and then ask:

"Can the phone handle this?"

Instead ask:

"How can we achieve the same gameplay with less computation?"

3. WHAT THE GAME IS NOT

This project is NOT:

The target is:

A living 2.5D world with deep simulation and selective visual detail.

4. CORE GAME LOOP

The fundamental loop is:

LIVE
 ↓
EXPLORE
 ↓
WORK / TRADE / FIGHT / SOCIALIZE
 ↓
EARN RESOURCES
 ↓
MAKE DECISIONS
 ↓
BUILD RELATIONSHIPS
 ↓
GAIN REPUTATION
 ↓
ACQUIRE PROPERTY
 ↓
CREATE OPPORTUNITIES
 ↓
WORLD REACTS
 ↓
NEW EVENTS
 ↓
NEW GOALS
 ↓
LIVE

There is no mandatory "win".

The player's life is the progression system.

5. STARTING THE GAME

The player creates a character.

Character creation

Minimum launch system:

Background examples:

Farmer

Starts with:

Apprentice

Starts with:

Wanderer

Starts with:

Soldier

Starts with:

Merchant

Starts with:

Street Child

Starts with:

Background changes starting conditions, not destiny.

6. NO CLASS SYSTEM

The player develops skills through actions.

If they repeatedly farm:

Farming increases.

If they repeatedly fight:

Combat increases.

If they trade:

Commerce increases.

If they negotiate:

Diplomacy increases.

Skills should emerge from play.

7. SKILL SYSTEM

Potential skills:

Physical

Combat

Production

Social

Survival

Criminal

8. CHARACTER PROGRESSION

No traditional level treadmill should dominate the game.

Progression comes from:

A farmer with 30 years of experience can be more important than a level-50 fighter.

9. NEEDS SYSTEM

NPCs can have lightweight needs:

But these must NOT be simulated every frame.

Needs are updated through scheduled ticks.

Example:

Hourly:
Energy

Daily:
Food
Money
Work satisfaction
Social status

Weekly:
Housing
Health trends
Relationships

Monthly:
Economic status
Migration pressure
Family changes

10. NPC ARCHITECTURE

NPCs are divided into simulation tiers.

Tier 0 — Abstract Population

Millions theoretically possible.

Stored as aggregate values.

Example:

Town A
Population: 8,421
Farmers: 2,100
Workers: 3,400
Merchants: 420
Soldiers: 600
Children: 1,200
Elderly: 701

No individual AI.

Tier 1 — Simulated NPC

Important NPCs exist as individual data.

Examples:

They have:

Tier 2 — Active NPC

NPC is close enough to the player to require detailed behavior.

They can:

Tier 3 — Rendered NPC

Only NPCs currently visible need rendering.

This is the most expensive tier.

The game should constantly promote/demote NPCs between tiers.

11. NPC LOD

NPC simulation LOD:

PLAYER DISTANCE

0–20m
FULL AI

20–50m
SIMPLIFIED AI

50–150m
SCHEDULE SIMULATION

150m+
AGGREGATE SIMULATION

Exact distances must be benchmarked.

The principle is more important than the exact numbers.

12. NPC DAILY LIFE

Each NPC can have a schedule.

Example:

06:00 Wake
06:30 Breakfast
07:00 Travel to farm
08:00 Work
12:00 Lunch
13:00 Work
17:00 Return
18:00 Market
20:00 Tavern
22:00 Home
23:00 Sleep

But schedules are not hardcoded animations.

They are goals.

If something interrupts the schedule:

NPC adapts.

13. NPC DECISION SYSTEM

NPCs use utility-based decision making.

Example:

Current Situation

Hunger = high
Energy = medium
Money = low
Work time = active
Danger = low

Possible actions:

Eat       score 92
Work      score 71
Sleep     score 20
Socialize score 35
Travel    score 12

Choose highest appropriate action.

This creates believable behavior without expensive AI.

14. RELATIONSHIP SYSTEM

Every important NPC can have relationships.

Types:

Relationships have scores.

Example:

Trust: 72
Respect: 61
Fear: 4
Affection: 80
Debt: 200

15. MEMORY SYSTEM

Important events become memories.

Example:

NPC: Hasan

Memory:
Player saved him from bandits
Year: 12
Importance: 90

Another:

Player stole from him
Year: 14
Importance: 80

NPC reactions can reference memories.

This creates continuity.

16. FAMILY SYSTEM

NPCs can have:

Important families can persist across generations.

Family traits:

17. GENERATIONAL SIMULATION

Characters age.

Children grow.

Adults work.

Elders retire.

Eventually characters die.

New generations replace them.

The world therefore changes over decades.

18. DEATH

Death should matter.

Causes:

Important NPC deaths create events.

Example:

"Master Yusuf died at age 74."

His business may:

19. WORLD TIME

The game uses:

But simulation frequency changes depending on importance.

20. REAL-TIME WORLD

While the player is actively playing:

Visual clock:
Continuous

Movement:
Real-time

Combat:
Real-time

Nearby NPC behavior:
Real-time

Economy:
Event/tick based

Background world:
Scheduled simulation

This provides the feeling of a real-time world without requiring everything to run every frame.

21. OFFLINE / BACKGROUND PROGRESSION

If the player closes the game:

Store:

last_simulation_timestamp

When the player returns:

current_time
-
last_simulation_timestamp
=
elapsed_time

Then run an efficient catch-up simulation.

Example:

Player leaves for 3 days.

On return:

3 days have passed.

The simulation processes:

The player receives:

"While you were away..."

22. IMPORTANT PERFORMANCE RULE

Do NOT simulate 72 hours as:

259,200 frames

Instead:

elapsed = 3 days

process_daily_economy()
process_scheduled_events()
process_travel()
process_businesses()
process_relationship_changes()

Use event skipping wherever possible.

23. WORLD MAP

The world is divided into regions.

Example:

WORLD
 ├── Northern Kingdom
 │    ├── Town A
 │    ├── Town B
 │    └── Village C
 │
 ├── Southern Kingdom
 │    ├── City D
 │    └── Town E
 │
 └── Wilderness

24. WORLD GENERATION

World generation creates:

Use deterministic seeds.

Same seed = same world.

25. TERRAIN

Terrain types:

Launch should begin with fewer biome types.

Expand later.

26. SETTLEMENT GENERATION

Settlement types:

Hamlet

Tiny.

Village

Farming-focused.

Town

Markets and crafts.

City

Large economy.

Capital

Political center.

Settlements grow according to:

27. SETTLEMENT GROWTH

Example:

Village
Population 120
      ↓
Population growth
      ↓
More houses
      ↓
New businesses
      ↓
More trade
      ↓
Town

Growth should be simulation-driven.

28. BUILDINGS

Categories:

Residential

Production

Commerce

Public

Military

29. BUSINESSES

Every business has:

Owner
Workers
Input resources
Output resources
Inventory
Prices
Demand
Profit
Reputation

Example:

BLACKSMITH

Input:
Iron

Output:
Sword

Workers:
3

Inventory:
18 iron
4 swords

Profit:
+72/day

30. ECONOMY

Resources:

Production chains:

Wheat
 ↓
Mill
 ↓
Flour
 ↓
Bakery
 ↓
Bread
 ↓
Market

31. DYNAMIC PRICES

Prices change based on:

Example:

War destroys farms.

↓

Food supply falls.

↓

Food price rises.

↓

Merchants travel to supply city.

↓

Profit increases.

↓

More farmers produce food.

↓

Price gradually stabilizes.

32. TRADE

Merchants can travel between settlements.

Trade routes depend on:

33. CARAVANS

Caravans are visible world entities.

They can:

But background caravans can be simulated abstractly.

34. CRIME

Crime types:

Crime creates:

35. LAW

Each settlement has law enforcement.

Possible policies:

Crime rates react accordingly.

36. REPUTATION

Separate reputations:

Example:

Town Reputation: 82
Military Reputation: 31
Merchant Reputation: 74
Criminal Reputation: 5

37. FACTIONS

Factions have:

Examples:

38. FACTION RELATIONSHIPS

Relations:

+100 Allied
+50 Friendly
0 Neutral
-50 Hostile
-100 At War

Relations change dynamically.

39. POLITICS

Political systems can include:

Player can eventually participate.

40. PLAYER SOCIAL ASCENSION

Possible progression:

Nobody
 ↓
Resident
 ↓
Respected citizen
 ↓
Business owner
 ↓
Landowner
 ↓
Guild member
 ↓
Guild leader
 ↓
Noble
 ↓
Governor
 ↓
Faction leader
 ↓
Ruler

This is optional.

41. PLAYER PROPERTY

The player can own:

42. PLAYER BUSINESS

Business management:

43. FARMING

Player can:

Crops vary by:

44. CRAFTING

Crafting categories:

Craft quality depends on:

45. INVENTORY

Inventory must be optimized.

Avoid thousands of individual React components.

Use stack-based data:

Item ID
Quantity
Quality
Durability

46. EQUIPMENT

Slots:

Equipment affects:

47. COMBAT

Combat is real-time but lightweight.

Target style:

action RPG / tactical 2.5D

Controls:

48. COMBAT AI

Nearby enemies use:

Avoid expensive full AI planners.

49. COMBAT STATES

Idle
 ↓
Detect
 ↓
Approach
 ↓
Attack
 ↓
Recover
 ↓
Evaluate
 ↓
Retreat / Continue

50. GROUP COMBAT

When armies become large:

Do NOT individually simulate every soldier.

Use:

Army Group
Strength
Morale
Supplies
Commander
Unit composition
Position

Detailed combat only occurs near the player.

51. WARS

Wars can exist in the background.

Background war simulation:

Army A strength
Army B strength
Supply
Terrain
Commander
Morale

Produces:

52. PLAYER PARTICIPATION IN WAR

Player can:

53. WEATHER

Weather:

Weather affects:

54. SEASONS

Four seasons.

Spring

Planting.

Summer

Growth.

Autumn

Harvest.

Winter

Low production.

55. DAY/NIGHT

Visual cycle:

Dawn
Morning
Noon
Afternoon
Sunset
Night

NPC schedules respond.

Shops close.

Taverns open.

Guards patrol.

56. ANIMALS

Animals:

Animals should use simplified behavior.

57. EXPLORATION

World contains:

58. PROCEDURAL EVENTS

Event system is central.

Events can be:

59. EVENT CHAINING

Events should trigger other events.

Example:

Drought
 ↓
Poor harvest
 ↓
Food shortage
 ↓
Price increase
 ↓
Poor families struggle
 ↓
Crime increases
 ↓
Guards respond
 ↓
Political unrest

60. QUEST SYSTEM

Avoid a massive handcrafted quest list.

Use templates.

Example:

Actor
Goal
Location
Problem
Obstacle
Reward
Consequence

This allows thousands of combinations.

61. QUEST TYPES

62. DYNAMIC QUESTS

Quest generation uses current world state.

Example:

If a town has:

Food shortage

possible quest:

"Bring grain from the southern farms."

If:

Bandits active

possible quest:

"Protect the caravan."

63. NO QUEST MARKER DEPENDENCY

The world itself should communicate opportunities.

NPC:

"The mill is looking for workers."

Shop:

"Prices are high today."

Guard:

"Bandits attacked the eastern road."

Player can discover things naturally.

64. DIALOGUE

Dialogue should be short and contextual.

NPC dialogue depends on:

65. AI-GENERATED CONTENT

AI can help generate:

But runtime gameplay logic should NOT depend on an online LLM.

The game must remain playable offline.

66. DATA-DRIVEN CONTENT

All content should be externalized.

Example:

/content
    /items
    /weapons
    /buildings
    /npcs
    /quests
    /events
    /factions
    /recipes
    /regions

Use JSON or strongly typed TypeScript data.

67. RENDERING PHILOSOPHY

The renderer should only draw what matters.

WORLD DATA
   ↓
Visibility System
   ↓
Culling
   ↓
LOD
   ↓
Renderer

Never render the entire world.

68. CAMERA

Camera:

Zoom levels:

Close

Character detail.

Medium

Town activity.

Far

World navigation.

69. 2.5D PRESENTATION

Recommended visual structure:

Terrain
 ↓
Ground decorations
 ↓
Buildings
 ↓
Characters
 ↓
Effects
 ↓
UI

Use depth sorting carefully.

70. VISUAL STYLE

Recommended style:

Stylized hand-painted 2.5D medieval world.

Characteristics:

Avoid photorealism.

71. ART PERFORMANCE RULES

Use:

Avoid:

72. PERFORMANCE TARGETS

Initial target:

60 FPS

Preferred frame budget:

16.67 ms

Fallback:

30 FPS

Frame budget:

33.33 ms

The game should remain playable at 30 FPS on weaker devices.

73. PERFORMANCE BUDGET

The actual budget must be measured on hardware.

Initial conceptual budget:

Rendering          ~8 ms
Game simulation    ~3 ms
Input/UI           ~2 ms
Animation          ~1 ms
Other              ~2 ms
------------------------
Target             ~16 ms

These are targets, not guarantees.

74. SIMULATION BUDGET

Never update every entity equally.

Use priority:

PLAYER
 ↓
NEARBY NPCS
 ↓
IMPORTANT NPCS
 ↓
REGION
 ↓
WORLD

75. TICK BUDGET

Example:

FRAME
60 FPS

REALTIME TICK
10–30 updates/sec

NPC SCHEDULE
1–4 updates/sec

ECONOMY
hourly

POPULATION
daily

POLITICS
daily/weekly

GENERATIONAL
monthly/yearly

76. PATHFINDING

Never run expensive global pathfinding for every NPC.

Use:

World route
 ↓
Region route
 ↓
Town route
 ↓
Local navigation

NPCs far away use abstract travel.

Nearby NPCs use actual movement.

77. NPC TRAVEL

Background:

Town A → Town B
Travel time: 9 hours

No physical NPC needed.

When player encounters the caravan:

Spawn detailed caravan representation.

This is one of the biggest performance wins.

78. OBJECT POOLING

Pool:

Avoid constant creation/destruction.

79. WORLD CHUNKING

Divide world into chunks.

Example:

Chunk
 ├── terrain
 ├── buildings
 ├── NPC references
 ├── resources
 └── events

Only active chunks are loaded/rendered.

80. STREAMING

When player approaches another region:

Preload next chunk
 ↓
Unload distant visual chunk

Simulation data can remain lightweight.

81. SAVE SYSTEM

Save:

Do not save every transient visual object.

82. SAVE FORMAT

Prefer compact structured state.

Example:

WorldSeed
CurrentGameTime
PlayerState
SettlementState
FactionState
ImportantNPCState
EconomyState
EventState
HistoryState

83. SAVE FREQUENCY

Autosave at safe checkpoints:

Also use periodic autosave.

Avoid saving huge data every frame.

84. HISTORY SYSTEM

The game records important events.

Example:

YEAR 7
Village of Greenfield founded.

YEAR 12
Great flood destroys farmland.

YEAR 13
Player buys first house.

YEAR 18
Blacksmith guild formed.

YEAR 22
Northern War begins.

The player can open:

WORLD HISTORY

This becomes one of the game's signature features.

85. PLAYER JOURNAL

Automatically record:

86. WORLD MEMORY

The world should remember important player actions.

Example:

Player saves merchant.

Later:

Merchant recognizes player.

Or:

Player steals from merchant.

Later:

Merchant refuses service.

87. DYNAMIC REPUTATION

Reputation propagates through social networks.

Do NOT update every NPC immediately.

Use regional reputation.

Example:

Player reputation in Town A: 80

Nearby contacts:
+ reputation

Distant regions:
slower propagation

88. ECONOMIC SIMULATION LOD

Nearby market:

Detailed:

Distant market:

Aggregate:

Food supply: 74%
Food demand: 92%
Average price: +18%

89. WORLD EVENT PRIORITY

Not every event deserves full simulation.

Priority levels:

Critical

War.

King death.

Major disaster.

Important

Business failure.

Bandit attack.

Political change.

Minor

NPC buys food.

Shop closes.

Small argument.

Minor events can be aggregated.

90. MOBILE UX

The game must be playable with one hand where possible.

Controls:

Avoid requiring tiny buttons.

91. CONTEXTUAL INTERACTION

Player approaches object.

Instead of dozens of buttons:

[ TALK ]

[ WORK ]

[ OPEN ]

[ BUY ]

[ STEAL ]

Only show valid actions.

92. TOUCH MOVEMENT

Preferred:

Tap ground:

character walks there.

Tap NPC:

interact.

Tap enemy:

target.

Drag:

move camera.

Pinch:

zoom.

93. UI PHILOSOPHY

The world should occupy most of the screen.

UI appears contextually.

Avoid permanent HUD clutter.

94. INVENTORY UI

Use:

95. SHOP UI

Shop screen:

SELLER
Gold: 421

ITEMS
Bread       4g
Sword      85g
Cloth      12g

PLAYER GOLD
127g

Prices should reflect simulation.

96. WORLD MAP UI

Map shows:

97. MINIMAP

Only show nearby important features.

Don't render the entire world into the minimap every frame.

Use a simplified representation.

98. AUDIO

Audio should also be performance-conscious.

Use:

Town ambience can be layered:

Base ambience
+
Market sounds
+
Blacksmith
+
Animals
+
Crowd

Do not play hundreds of individual sounds.

99. VISUAL AUDIO REACTION

Examples:

Rain:

Market:

Night:

100. WORLD ATMOSPHERE

The game should feel alive even when the player isn't doing anything.

Examples:

101. THE "BUSY TOWN" TEST

A town should pass this test:

Player enters.

Within 30 seconds they should notice:

The world must not feel like decorative scenery.

102. THE "LEAVE AND RETURN" TEST

Player leaves town for 7 in-game days.

Returns.

At least some meaningful things should have changed.

103. THE "CAUSE AND EFFECT" TEST

If player causes:

Food shortage

the world should eventually respond:

Price increase
 ↓
Merchant opportunity
 ↓
Migration
 ↓
Crime
 ↓
Political response

104. THE "NO PLAYER" TEST

Pause the player.

Allow the simulation to run.

The world should continue evolving.

105. PROCEDURAL CONTENT SYSTEM

Procedural generation creates:

But use deterministic seeds.

106. WORLD SEED

At game creation:

WORLD SEED: 839174

Seed determines:

107. WORLD SHARING

Potential later feature:

Player can share:

World Seed

Other players can generate the same starting world.

108. MULTIPLE GAME MODES

Potential:

Life Mode

Normal sandbox.

Survival Mode

Hard needs.

Ironman

Permanent death.

Sandbox

More resources.

Chronicle

Long generational play.

109. DEATH / CONTINUATION

If player dies:

Optionally continue as:

This creates generational gameplay.

110. LEGACY

Player can leave behind:

After death:

Your legacy remains.

111. LONG-TERM PROGRESSION

Meta progression should be optional and not destroy sandbox freedom.

Potential unlocks:

Avoid pay-to-win if monetized.

112. MONETIZATION DIRECTION

Recommended:

Premium cosmetic model

or:

Free game + optional cosmetics

Potential purchases:

Avoid selling power in a simulation game.

113. NO ONLINE DEPENDENCY

Core game should work offline.

Online services, if added:

The simulation itself remains local.

114. MULTIPLAYER

Do NOT build multiplayer initially.

It massively increases complexity.

First prove:

single-player living world.

Multiplayer could become a separate future project.

115. ENGINEERING ARCHITECTURE

Recommended conceptual architecture:

/src

/core
    GameClock
    EventBus
    Random
    StateManager

/simulation
    WorldSimulation
    NPCSimulation
    EconomySimulation
    PopulationSimulation
    FactionSimulation
    EventSimulation
    TravelSimulation

/world
    WorldGenerator
    ChunkManager
    Terrain
    Settlements

/entities
    Player
    NPC
    Building
    Animal
    Vehicle

/gameplay
    Combat
    Farming
    Crafting
    Trading
    Dialogue
    Quests

/rendering
    WorldRenderer
    SpriteManager
    Camera
    Effects
    Culling
    LOD

/ui
    HUD
    Inventory
    Shop
    Dialogue
    Map
    Character
    Journal

/data
    items
    recipes
    buildings
    factions
    events
    quests

/storage
    SaveManager
    LoadManager
    Serialization

116. REACT NATIVE RESPONSIBILITY

React Native should primarily handle:

Do not make every game entity a React component.

117. GAME LOOP RESPONSIBILITY

The gameplay simulation should exist outside React's render lifecycle.

Conceptually:

Game Loop
    ↓
Simulation Update
    ↓
World State
    ↓
Renderer

React UI subscribes only to the state it needs.

118. STATE MANAGEMENT

Avoid one giant global reactive state causing the entire application to re-render.

Use isolated state domains:

PlayerState
WorldState
UIState
SimulationState
InventoryState

Only update affected subscribers.

119. RENDERING LAYER

For the actual game world, use a rendering technology appropriate for high-frequency drawing rather than thousands of ordinary React Views.

The renderer should support:

The exact renderer should be benchmarked during the prototype.

120. REACT RE-RENDER RULE

Never do:

Every frame
    setState(...)

for the entire game world.

Game loop and UI state must be separated.

121. MEMORY MANAGEMENT

Monitor:

122. ENTITY POOL

Instead of:

create NPC
destroy NPC
create NPC
destroy NPC

use:

NPC pool
 ↓
activate
 ↓
use
 ↓
deactivate
 ↓
reuse

123. TEXTURE STRATEGY

Use:

Avoid loading every asset at startup.

124. ASSET STREAMING

Load assets based on:

Current region
+
Nearby regions
+
Current activity

125. LOADING STRATEGY

Initial app launch should load only:

Everything else loads progressively.

126. PERFORMANCE TEST LEVELS

Level 1

50 NPCs.

Level 2

100 NPCs.

Level 3

250 NPCs.

Level 4

500 NPCs.

Level 5

1,000 simulated nearby entities.

Then benchmark.

Never assume the maximum.

127. STRESS TEST SCENARIOS

Market Stress

300 NPCs.

Combat Stress

100 combatants.

Rain Stress

NPCs + particles + weather.

Town Stress

500 active entities.

Economy Stress

10,000 simulated businesses.

World Stress

100 settlements.

128. PERFORMANCE METRICS

Record:

129. PERFORMANCE BUDGET PHILOSOPHY

Every expensive system gets a budget.

Example:

Rendering
Simulation
Pathfinding
Animation
Particles
UI
Audio

If one exceeds budget:

optimize before adding features.

130. AUTOMATED STRESS TESTER

Build an internal developer mode.

Commands:

Spawn 100 NPCs
Spawn 500 NPCs
Spawn 1000 NPCs
Start rain
Start battle
Generate town
Generate economy
Advance 1 year
Advance 100 years

Then measure performance.

131. SIMULATION PROFILER

Developer screen:

NPC Simulation     1.4ms
Economy             0.5ms
Pathfinding        0.8ms
Rendering           6.2ms
Particles           0.7ms
UI                  0.4ms
Other               1.2ms

This becomes essential.

132. QUALITY LEVELS

Low

Medium

Default.

High

133. DEVICE TIERS

Tier A

High-end phones.

Tier B

Mid-range phones.

Tier C

Low-end phones.

Game automatically chooses quality.

134. BATTERY MODE

Optional:

Performance

Maximum visual activity.

Balanced

Normal.

Battery Saver

Reduced simulation/rendering frequency.

135. NETWORK / BACKEND

No backend required for core gameplay.

Potential later backend:

136. SECURITY

Never trust client-side purchases if monetization is introduced.

But the core game remains local-first.

137. ACCESSIBILITY

Support:

138. CAMERA ACCESSIBILITY

Allow:

139. AUDIO ACCESSIBILITY

Separate:

140. CONTENT SCALE

Initial release does NOT need thousands of handcrafted assets.

Target launch:

3–5 biomes
5 settlement types
20–30 buildings
50–100 items
20–40 NPC professions
10–15 factions
100+ event templates
50+ quest templates

Procedural combinations create variety.

141. FUTURE CONTENT

Later add:

142. SIGNATURE SYSTEM #1

THE WORLD NEVER WAITS

Player leaves.

World continues.

This should be marketed heavily.

143. SIGNATURE SYSTEM #2

GENERATIONS

People grow old.

Children become adults.

Families rise and fall.

The world changes.

144. SIGNATURE SYSTEM #3

HISTORY

The game records the player's world.

Players can browse their civilization's history.

145. SIGNATURE SYSTEM #4

LIFE CHOICE

No forced hero path.

Become whoever you want.

146. SIGNATURE SYSTEM #5

EMERGENT STORIES

The most memorable stories should be generated by systems.

147. EXAMPLE PLAYER STORY

Year 1:

Player is a farmer.

Year 2:

Buys a horse.

Year 4:

Starts selling wheat.

Year 6:

Opens bakery.

Year 8:

Marries a local merchant.

Year 11:

Has first child.

Year 15:

Buys second property.

Year 18:

Bandits attack town.

Player hires guards.

Year 21:

Becomes wealthy.

Year 25:

Joins merchant guild.

Year 31:

Becomes guild leader.

Year 40:

Funds city expansion.

Year 48:

A war begins.

Player supplies the army.

Year 52:

Becomes noble.

Year 60:

Player dies.

Their child inherits:

The story continues.

148. ANOTHER PLAYER STORY

Player starts poor.

Becomes thief.

Joins gang.

Gang gets caught.

Player escapes.

Moves to another city.

Becomes merchant.

Uses smuggling contacts.

Becomes wealthy.

Buys tavern.

Uses tavern as criminal headquarters.

Eventually controls the city's black market.

None of this needs to be a predefined campaign.

149. ANOTHER PLAYER STORY

Player becomes soldier.

Fights bandits.

Joins army.

Becomes officer.

Saves a noble.

Receives land.

Builds estate.

Marries into noble family.

Becomes political figure.

Eventually becomes governor.

Again:

The player created the story.

150. THE WORLD SHOULD PRODUCE SURPRISES

The game should occasionally produce:

But avoid random chaos.

Events should emerge from world state.

151. EVENT CAUSALITY

Prefer:

Low food
 ↓
High prices
 ↓
Poor people
 ↓
Crime

over:

Random crime happened

Both can exist, but causal events feel more believable.

152. PLAYER INTERVENTION

The player should be able to interrupt systems.

Example:

Food shortage.

Player can:

Different outcomes follow.

153. EMERGENT ECONOMIC STRATEGIES

Player could intentionally:

But prevent easy infinite money exploits through simulation balancing.

154. WORLD BALANCE

The world should resist runaway domination.

If player becomes too powerful:

The goal is not to stop the player.

The goal is to create new problems.

155. LIVING FACTIONS

Factions have internal politics.

A faction can:

156. DYNAMIC TOWNS

Towns should have personalities based on economy.

Examples:

Farming Town

Food abundant.

Mining Town

Metal abundant.

Trade Town

High wealth.

Military Town

High soldiers.

Religious Town

High religious influence.

157. REGIONAL IDENTITIES

Different regions should feel distinct through:

158. CULTURE SYSTEM

Culture influences:

Culture should be mostly data-driven.

159. FESTIVALS

Periodic events:

During festivals:

160. TAVERNS

Taverns become social hubs.

Player can:

161. RUMOR SYSTEM

Rumors propagate through NPC networks.

Example:

"Bandits are attacking northern caravans."

Rumor may be:

This gives information value to socializing.

162. INFORMATION ECONOMY

Players can learn about:

through:

163. LETTER / MESSAGE SYSTEM

Important NPCs can send:

This provides asynchronous world storytelling.

164. MAILBOX

Player home can have a mailbox.

Messages appear based on world activity.

165. HOUSING

Player house can contain:

Housing can become a progression system.

166. DECORATION

Cosmetic furniture:

No heavy gameplay dependency.

167. MOUNT SYSTEM

Later:

Mounts increase travel speed.

168. VEHICLE SYSTEM

Later:

Use abstract movement when off-screen.

169. EXPLORATION DISCOVERY

Player can discover:

170. WORLD EVENTS

Major events can reshape regions.

Examples:

Great Fire

Destroys buildings.

Drought

Reduces crops.

War

Changes borders.

Plague

Reduces population.

Gold Discovery

Creates mining town.

171. DISASTER SIMULATION

Disasters should be rare and consequential.

They should not randomly destroy player progress constantly.

172. RECOVERY

World should recover.

Example:

Fire:

Fire
 ↓
Destroyed buildings
 ↓
Temporary unemployment
 ↓
Construction demand
 ↓
Builders earn money
 ↓
Town recovers

173. PLAYER BUILDING

Initial version:

Player can place/manage selected structures.

Avoid full city-builder complexity at launch.

Later:

174. ROAD SYSTEM

Road quality affects:

Road upgrades can become meaningful.

175. WORLD CONNECTIVITY

Regions connect through:

This creates natural economic geography.

176. LOADING STRATEGY

Never load entire world visuals.

Load:

Player chunk
+
Neighbor chunks

Keep distant world as data.

177. MEMORY TARGET

Memory budget must be established through real-device profiling.

No arbitrary promise should be made before prototype testing.

The rule:

Memory usage must remain stable during long sessions.

178. LONG SESSION TEST

Run game continuously for:

30 minutes

1 hour

2 hours

Look for:

179. SIMULATION CORRECTNESS

Stress tests must verify:

180. ECONOMY SAFETY

Every economic transaction should be atomic:

Validate
 ↓
Remove input
 ↓
Add output
 ↓
Record transaction

Never allow partial transactions.

181. EVENT SAFETY

Events require:

Prevent duplicate processing.

182. SIMULATION DETERMINISM

Use seeded random systems.

Important simulation should be reproducible.

This makes:

much easier.

183. DEBUG MODE

Developer overlay:

FPS
Frame Time
Memory
NPC Count
Visible NPCs
Simulation Entities
Draw Calls
Texture Memory
Chunk
Game Time
Simulation Queue

184. DEBUG CONTROLS

Developer commands:

+1 hour
+1 day
+1 month
+1 year

Spawn NPC
Kill NPC
Add gold
Start war
Start rain
Create famine
Generate town

185. TEST AUTOMATION

Automated simulations:

Generate world
Simulate 1 year
Check economy
Check population
Check events
Check save
Load
Compare state

186. SAVE/LOAD VALIDATION

After save/load:

World state must remain logically identical.

Transient rendering state can be regenerated.

187. DEVELOPMENT PHASE 0 — TECHNICAL PROOF

Build:

No gameplay yet.

Goal:

Prove rendering architecture.

188. PHASE 1 — BUSTLING TOWN

Create:

Goal:

Does the town feel alive?

189. PHASE 2 — SIMULATION

Add:

Goal:

Prove simulation scale.

190. PHASE 3 — PLAYER LIFE

Add:

Goal:

Make the game fun.

191. PHASE 4 — WORLD

Add:

Goal:

Create a living world.

192. PHASE 5 — CONSEQUENCES

Add:

Goal:

Create emergent stories.

193. PHASE 6 — GENERATIONS

Add:

Goal:

Make the world persistent across generations.

194. PHASE 7 — WAR

Add:

Goal:

Expand from personal life to regional events.

195. PHASE 8 — POLITICS

Add:

Goal:

Allow social ascension.

196. PHASE 9 — CONTENT

Add:

197. PHASE 10 — OPTIMIZATION

Only after the systems are proven:

Then stress test again.

198. DEVELOPMENT RULE

Every major feature must answer:

  1. Does it improve the core fantasy?
  2. Can it run within the performance budget?
  3. Can it be simulated efficiently?
  4. Does it create emergent gameplay?
  5. Is it worth its complexity?

If not:

Do not add it.

199. MVP

The MVP should NOT contain everything.

MVP:

1 town
1 surrounding region
Player
50–100 active NPCs
500–1,000 simulated residents
10 professions
10 buildings
20 items
Basic economy
Basic shops
Day/night
Weather
NPC schedules
Relationships
Basic events
Saving/loading
Performance profiler

If this is fun:

Continue.

If this is not fun:

Fix the core before expanding.

200. MVP SUCCESS CRITERIA

The prototype succeeds if:

Performance

It maintains a stable frame rate on target low/mid devices.

Simulation

NPCs appear to have meaningful lives.

Persistence

The town changes when the player leaves.

Interaction

Player actions cause visible consequences.

Fun

The player voluntarily keeps playing without needing a quest checklist.

201. THE GOLDEN TEST

Give the player no quest.

Put them in the town.

Say:

"You are free."

Then observe.

If they naturally start asking:

"Can I buy this shop?"

"Who owns this farm?"

"Why is bread so expensive?"

"Where did that merchant go?"

"Can I marry her?"

"Can I join the guards?"

"Can I become a noble?"

"What happened while I was gone?"

then the game is working.

202. FINAL GAME IDENTITY

The game should ultimately feel like:

A world, not a level.

A life, not a quest list.

A simulation, not a spreadsheet.

A story generator, not a scripted campaign.

The player should be able to stop after 50 hours and say:

"My world was different."

203. FINAL TECHNICAL PRINCIPLE

The game should use:

React Native
        ↓
UI / Application Layer

Specialized 2D/2.5D Renderer
        ↓
Visual World

Simulation Core
        ↓
Living World

Data-Driven Content
        ↓
Huge Content Scale

LOD + Culling + Aggregation
        ↓
Mobile Performance

The renderer does not need to know about every person in the world.

The simulation does not need to render every person.

The UI does not need to know about every simulation update.

This separation is what makes the concept viable.

204. THE ULTIMATE DESIGN GOAL

The player should be able to walk through a town and think:

"These people were going to do these things even if I wasn't here."

Then leave.

Return later.

And think:

"Something happened."

Then investigate.

Eventually discover:

"I accidentally caused this."

That is the game's magic.

205. FINAL PRODUCT VISION

A player starts with nothing.

They choose a life.

They meet people.

They make friends.

They make enemies.

They work.

They earn.

They lose.

They build.

They travel.

They fight.

They trade.

They fall in love.

They create a family.

They build a business.

They gain influence.

The world changes.

Years pass.

People die.

Children grow.

Kingdoms rise.

Kingdoms fall.

And eventually:

the player's life becomes part of the world's history.

206. MASTER PERFORMANCE RULE

NEVER SCALE BY RENDERING MORE.

Scale by:

Aggregating.

Culling.

Level of Detail.

Event simulation.

Instancing.

Pooling.

Chunking.

Streaming.

Background simulation.

Deterministic time advancement.

The world can become enormous without the screen becoming enormous.

207. MASTER DEVELOPMENT RULE

DO NOT BUILD THE BIG GAME FIRST.

Build:

One beautiful, extremely alive town.

Then prove:

100 NPCs
 ↓
250 NPCs
 ↓
500 NPCs
 ↓
1,000 simulated
 ↓
5,000 simulated
 ↓
10,000 simulated

while profiling on actual phones.

Only increase the world when the previous level is stable.

208. FINAL TARGET

The finished game should give the player this feeling:

"I don't know what is going to happen today."

And that should be the reason they open the game tomorrow.