WorldForge Development Timeline
WorldForge is an open-world RTS/RPG settlement simulation. Build and manage a frontier settlement, then directly lead individuals or small parties through exploration, danger, diplomacy, and crisis. Villagers live autonomously, and the results of your decisions persist in the settlement and the wider world.
Development roadmap
Early phases build the engine, camera, controls, assets, and save systems. Later phases add the world map, autonomous villagers, settlement jobs and logistics, direct party control, encounters, relationships, memory, and lasting consequences.
Phase 0A
Complete
Build the executable spine first: SDL3 boot, window/input abstraction, fixed-step simulation scheduling, and a clean separation between platform events and game commands.
The game boots, runs its simulation clock, handles input, and shuts down cleanly.
Phase 0B
Complete
Configure EnTT as the ECS storage layer, then define Worldforge's stable IDs, plain components, system ownership, scheduling, and sim/render boundaries on top of it.
Game entities now have stable identities and consistent simulation state.
Phase 0C
Complete
Build the flat 2:1 isometric presentation boundary and only the procedural scene plumbing needed to prove camera movement, reversible picking, stable scene submission, and selection feedback before external asset IO exists.
The isometric view, camera, scene rendering, and mouse and marquee selection are working.
Phase 0D
Complete
Establish deterministic asset discovery, decoding, manifests, lifetime, and the separation between immutable source data and mutable runtime state before Phase 1 adds world streaming.
Configuration, scenarios, authored scenes, images, and fonts load through the manifest with explicit validation, diagnostics, and cleanup.
Phase 0E
Complete
Build the reusable observability and proof framework around the Phase 0 state that actually exists; later phases extend it as they introduce world, actor, economy, and event schemas.
The integrated Phase 0 review passed. Fixed ticks execute the ordered ECS systems, reset refreshes asset and presentation state, developer inspection remains modular, and replay reports the first divergent step.
Phase 0 Addendum
Complete
Formalize the existing direct-launch application lifecycle before Phase 1 adds world and session loading responsibilities.
The shared lifecycle contract, direct-launch composition, real and injected failure containment, leaving cleanup, detached inspection, and complete sanitizer matrix are proven.
Phase 1
Complete
Build the persistent spatial substrate: chunks for embodied state, regions for compressed state, routes for travel, and explicit heat transitions that preserve causal continuity.
Spatial identity, synchronous chunk residency, route travel, compressed region state, observer knowledge, heat transitions, persistence, replay, failure containment, and measured workload budgets are proven.
Phase 2
Complete
Place individual people on the Phase 1 world substrate with explainable needs, shallow plans, interruption rules, and identity-preserving compressed updates.
Canonical actor state, mutation-free IAUS focus selection, focus-to-plan execution, heat-tier scheduling, interruption and route cancellation, hysteresis, bounded replanning, repeat travel, warm/cool continuity, actor save/load, and deterministic actor-decision replay are proven.
Phase 3
Complete
Once actors can think, give them a real settlement loop: jobs, hauling, stockpiles, one food chain, and one construction or upgrade chain.
Demand, actor-neutral jobs, deterministic multi-Actor claims, reservations, conserved resource transfers, IAUS job preference, finite food supply and successor chains, shortage and blocked-route alerts, Actor-owned job plans, World-owned routes, grid construction, multi-instance authored economy data, cancellation, persistence, replay, detached inspection, throughput evidence, narrow scheduler queries, and a bounded 20,000-Actor population proof are complete.
Phase 4
Complete
Layer player-authored action on top of autonomous life only after the autonomous world already produces meaningful states to intervene in.
Shared control authority, additive selection, durable Site movement and bounded attack orders, small-Party lead/follow/assist behavior, bounded Intersection reasoners, wildlife and traveler-dispute outcomes, scouting knowledge updates, persistence, replay, detached inspection, visible-proxy scale, and release reconciliation are proven.
Phase 5
Complete
Make episodes matter by persisting them through memory records, social propagation, and practical downstream effects.
Typed Memory with provenance and decay, bounded propagation, Reputation, Relationship, Household strain, learned tendency feedback, scheduled IAUS input, causal ledgers, separate detached inspection, persistence, replay, and sparse 20,000-Actor scale are proven.
Phase 6
Complete
Finish by making the slice understandable, debuggable, and replayable rather than merely functional.
Player-facing session flow, commands and causal lenses, detached decision inspection, complete owner persistence and replay, bounded heat-tier and render work, a locked scenario, Actor-specific command outcomes, and an integrated 20,000-person benchmark are proven.
Phase 7
Complete
Expand the proven food and construction paths into a settlement the player can deliberately grow without bypassing labor, logistics, households, or world geography.
Deterministic local movement, complete Building lifecycle, housing, road and watchtower effects, stable Settlement identity and membership, maintenance through normal labor and materials, player settlement commands, persistence, typed command replay, and representative scale are proven.
Phase 8
Complete
Expand the world substrate into a changing place that must be explored and reported rather than an omniscient static route graph.
Source-aware Observer Knowledge, scouting and report return, World calendar and environment, bounded regional ecology, finite renewable resources, environmental and discovery incidents, stale player reads, generated-baseline separation, deterministic persistence, and representative world breadth are proven.
Phase 9
Complete
Expand the proven material flow into production and exchange while preserving spatial ownership, reservations, conservation, and route risk.
Data-defined multi-step production, one useful tool consumer, party provisioning, physical trade obligations, bounded regional summaries, exact conservation, cancellation, deadlines, persistence, replay, cross-owner validation, and detached bottleneck diagnostics are proven.
Phase 10
Complete
Expand persistent villagers into changing lives while keeping cognition bounded and each social or biological fact under one owner.
Attributable Actor progression, relationship stages, transactional Household formation and care, illness, treatment, life stages, death, bounded lineage, detached biography, stable persistence, and representative population budgets are proven.
Phase 11
Complete
Expand the incident pipeline into authored and systemic story structures that read and write the same world as labor, travel, relationships, and trade.
Validated authored incident and event policy, focused resolution, durable multi-step rescue and institutional request lifecycles, real domain consequences, bounded prompt presentation, persistence, replay, and causal explanation are proven.
Phase 12
Complete
Expand the proven encounter and command path into deeper conflict and rival powers without turning warfare into a disconnected ruleset.
Equipment-sensitive combat, wounds, retreat, treatment, Party formations, settlement defense, bounded faction strategy, negotiation, raids, retained aftermath, and remote-conflict compression are proven through existing owners.
Phase 13
Complete
Turn the proven and expanded systems into a coherent production game with sufficient content, presentation, accessibility, performance, migration, and distribution quality.
Validated production content breadth, sprite and ground presentation, accessible player guidance, save recovery, supported migrations, representative release budgets, reproducible Linux packaging, and live extracted-package interaction are proven.
Game Development
Phase 14-22 turn the proven systems into a connected, inhabited game. They are approved plans but remain closed until each gate is explicitly activated.
Phase 14
Complete
Add a versioned Lua development platform that can inspect and command the engine, reproduce or replace the standard interface through stable composition contracts, reload safely, and publish a separate wiki-style reference for every exposed API.
Phase 15
Complete
Turn the bounded presentation area into a small connected world where embodied Actors can cross chunk boundaries without teleporting or losing their orders.
Phase 16
Complete
Compose the completed engine systems into one small settlement that visibly works, struggles, and responds to player direction.
Phase 17
Complete
Make settlement inhabitants live through understandable daily rhythms, health changes, relationships, households, aging, and family continuity.
Phase 18
Complete
Turn travel beyond the settlement into a prepared, risky, and consequential field loop shaped by knowledge, weather, ecology, and return.
Phase 19
Complete
Let settlements choose distinct development paths through construction, production, wealth, trade, specialization, capability, prosperity, decline, and recovery.
Phase 20
Current gate
Let settlements form rules, leadership, institutions, and diplomatic relationships that arise from people and materially affect daily life.
Phase 21
Planned
Turn systemic lives, expeditions, settlements, and institutions into playable personal stories whose participants and aftermath remain part of the world.
Phase 22
Planned
Expand proven combat and diplomacy into supplied rival factions, settlement defense, remote conflict, and persistent world pressure without turning Worldforge into an army-first RTS.
Phase 23
Planned
Scale approved gameplay through governed content authoring, safe extension points, final presentation, audio, accessibility, distribution, and long-term compatibility.