Skip to main content

Core

This page owns the Core as the live concept for the MC's fixed personal anchor. The file path keeps older "core-base" wording, but canon treats the system as the Core.

What The Core Is​

  • The Core is the MC's fixed personal anchor at the starting Nexus/Wardheart. (See lore exposure: lh-game1-world-hooks.md — Starting Nexus row, Nexus manifestation row)
  • It is established in Act 0 and remains the stationary counterpart to the travelling Camp.
  • It is the MC's anchor for recovery, storage, ward work, and protected household support.
  • It is not the Settlement and it is not a player-facing Realm birth trigger.

What Establishing The Core Does Not Do​

  • founding the Core does not create the Settlement
  • founding the Core does not create a player-facing Realm
  • founding the Core does not replace the later Outpost-tier Settlement layer
  • founding the Core does not turn personal-anchor infrastructure into settlement administration

What The Core Must Support​

  • Act 0 survival recovery, storage, and anchor stabilization
  • Act 1 support for the first protected named people living under the Core's protection
  • named-character assignments tied to ward work, stores, recovery, teaching, and household support
  • expedition logistics, resupply, and return points for work that leaves with the Camp
  • personal-anchor infrastructure that still matters after the first Outpost and later settlement growth exist

Named Character Use At The Core​

  • Core-side assignments give named characters explicit anchor-facing work rather than turning them into fixed profession slots.
  • Core is one assignment context in the broader model, and it should stay legible alongside Camp, Site, Mission, settlement-facing, party or expedition, training or teaching, and later management or governance roles.
  • Once settlement-scale labor exists, pops still fill ordinary jobs while named characters provide differentiated oversight, unlocks, clue interpretation, training, and event hooks.
  • Core assignments should produce grounded outcomes such as better recovery, safer routines, improved work quality, new clue handling, or teaching support.

Core Infrastructure Boundary​

  • Core-side buildings and upgrades belong to the personal-anchor layer.
  • They should improve recovery, shelter, storage, warding, logistics, and household support tied to the Nexus/Wardheart anchor.
  • They do not own settlement administration, district governance, or population-scale economic management.
  • Settlement-scale land administration belongs to the Settlement layer that starts with the first Outpost.

Design Rules​

  • The Core should feel tied to the special properties of the starting anchor, not like a generic build-anywhere campfire.
  • The Core remains important after Act 2 and Act 3 because the later Settlement layer grows on top of, not in place of, the MC's anchor.
  • Core progression should strengthen the MC's personal base of operations without collapsing Core, Camp, and Settlement into one surface.

Runtime Status​

This section records the live doc-vs-runtime split for the Core. It is the durable drift guard for this page. The Core has a real runtime slice already, but the slice is narrower than the full contract above, and several pieces of legacy terminology still ship in runtime id strings rather than in prose. The purpose of this section is to keep that gap legible across waves rather than let it rot quietly between code and design.

Shipped​

Host runtime fields, methods, and command surfaces that already exist for the Core:

  • GameWorld.CoreLocationId, GameWorld.HasCore, GameWorld.TryEstablishCore(...), and GameWorld.IsCoreLocation(...) in Host/GameWorld.cs.
  • GameRuntime.EstablishCore(...) in Host/GameRuntime.cs.
  • GameSession.EstablishCore(...) and GameSession.CreateCoreEstablishedJournalEntry(...) in Server/Services/GameSession.cs.
  • GameCommandService.EstablishCore(...) in Server/Services/GameCommandService.cs.
  • The operation id GameOperations.EstablishCore = "core.establish" and the typed EstablishCoreCommandArgs in Server/Services/GameOperations.cs.
  • CoreSnapshot plus the Core property on the snapshot envelope in Server/Services/GameSnapshot.cs, populated by Server/Services/GameSnapshotBuilder.cs and routed by Server/Services/GameOperationRouter.cs.

Client surfaces that consume the shipped Core slice:

  • CoreSnapshot in Client/src/api/types.ts (line 475) and the core field on the snapshot envelope types at Client/src/api/types.ts lines 847 and 878.
  • The establishCore() action in Client/src/store/gameStore.ts.
  • The SignalR invocation for Core establishment in Client/src/api/signalr.ts (line 131).

Shipped — partial / prototype​

These pieces exist in the runtime but only as a narrower stand-in for the full contract above.

  • The Core Screen (../ux/gd-core-screen.md) renders basic Core state, but building management and Core-side upgrades are not yet wired to runtime data. The screen is a stub for the full personal-anchor infrastructure surface described in "What The Core Must Support" and "Core Infrastructure Boundary" above.
  • The Journal entry written when the Core is established (GameSession.CreateCoreEstablishedJournalEntry(...)) uses hard-coded string literals ("Core Established" and "Core established. Hold this anchor and keep scouting the frontier."). It is not yet a structured Journal hook driven by Journal entry classes, links, or annotations as described in ../ux/gd-journal.md.

Deferred​

These pieces are not in the runtime yet and are explicit follow-through, not silent gaps.

  • A named-character assignment surface at the Core. The contract above describes Core-side assignments tied to ward work, stores, recovery, teaching, and household support, but no runtime surface owns these assignments yet.
  • Ward-work mechanics. Stabilizing, maintaining, and acting through the Nexus/Wardheart anchor remains design-only.
  • Core progression beyond the Core Screen stub: buildings, upgrades, recovery routines, storage growth, warding upgrades, logistics expansion, and household support are all deferred.
  • Structured Journal hooks at Core establishment. The current hard-coded string literals are deferred drift; the canonical fix is to issue the Core-established beat as a Journal entry of an explicit class with links, tags, and optional narration-safe prose per ../ux/gd-journal.md.
  • Legacy id-string cleanup in ../../Content/locations/features/dormant_nexus.secs (lines 56–60) and the mirroring ../../Generated/Locations/FeaturePlacement/FeatureContentProfiles.cs (lines 48, 51). Those files still ship the runtime id strings "CoreBase", "found-core-base", and "NexusCore". These are runtime ids, not prose, and they predate the live Core canon. This wave does not edit those files; it flags them here as deferred terminology drift requiring a future code wave so the gap stays visible instead of rotting.