Skip to main content

Eldiron Architecture

This page gives a high-level view of how Eldiron fits together.

Many other pages document individual systems in detail. This page is the mental model first: what belongs where, how the main systems connect, and why the same game can be presented in 2D, 3D, or text.

Structured Application Feedback​

Creator subsystems can return renderer-independent feedback documents. These documents describe semantic blocks and spans—headings, notices, commands, lists, key/value data, source code, stable IDs, and typed values—rather than embedding UI colors or column spacing into strings.

Views apply their own semantic palette and responsive layout. Interactions carry an event ID and payload instead of a callback, so the same document model can be used safely by Creator docks and, later, plugin-facing surfaces. Plain text is retained as a fallback for logs, copy/paste, and clients without a rich view.

One World​

At the center of Eldiron is a single shared world model:

  • regions
  • sectors
  • linedefs
  • entities
  • items
  • screens

This same authored data can be used by different presentation layers.

Examples:

  • a sector is a walkable area in 2D and 3D
  • the same sector can also be a room in a text-style client
  • a linedef can be geometry, a connection, or both

So Eldiron is not built around separate game modes. It is built around one authored world that can be shown in different ways.

Interaction​

Eldiron separates raw input from gameplay meaning.

The basic flow is:

  1. the player performs an action
  2. the game resolves that into an intent
  3. the world reacts

Examples:

  • keyboard movement in 2D
  • mouse clicks in 3D
  • button widgets on screens
  • terminal commands like attack orc

All of these can feed into the same action and intent system.

That is why the same interaction model can work across:

  • 2D
  • 3D
  • terminal / text-style clients

See Player Input for the input-side details.

Scripts, Rules, and Data​

Eldiron intentionally splits gameplay logic into several layers.

Scripts​

Scripts control behavior and decisions.

Examples:

  • reacting to events
  • choosing when an NPC attacks
  • opening a door
  • picking a target

Scripts are the place for behavior flow.

Rules​

Rules control shared gameplay math and systemic behavior.

Examples:

  • outgoing and incoming damage formulas
  • progression formulas
  • combat messages
  • combat audio

Rules are the place for formulas and reusable game-wide logic.

See Rules.

Authored Metadata​

Authoring metadata controls descriptive and narrative presentation.

Examples:

  • room titles
  • room descriptions
  • connection descriptions
  • per-sector presentation flags

This is edited in the Authoring dock and configured globally through Game / Authoring.

See:

Localization​

Localization is used for shared runtime text that should exist across languages.

Examples:

  • built-in system.* strings
  • combat message templates
  • shared UI text

See Localization.

Presentation Layers​

The same game can be presented in different ways.

2D and 3D​

The graphical clients use the authored map, tiles, avatars, widgets, and camera modes to render the world visually.

Text / Terminal​

The text client uses the same world data, but presents it as:

  • room titles
  • room descriptions
  • exits
  • visible entities and items
  • messages and narration

This is not a separate gameplay system. It is another frontend onto the same world.

Combat and Progression​

The current intended split is:

  • scripts decide when to attack
  • attack() starts combat resolution
  • rules calculate outgoing and incoming damage
  • messages and audio are produced from the resolved result
  • progression handles XP and levels

So:

  • scripts decide
  • rules calculate
  • presentation reports

That keeps behavior flexible without repeating all formulas in every character script.

Creator vs Runtime​

The Creator is the authoring environment.

This is where you:

  • build maps
  • place entities and items
  • write scripts
  • define rules
  • edit locales
  • edit audio FX
  • enter authoring metadata

At runtime, the server and clients consume that authored project data.

Different clients can then present the same project differently:

  • Creator play mode
  • graphical clients
  • terminal client

Creator Actions, Tools, And Automation​

Creator keeps presentation separate from execution. The Actions sidebar, interactive Console commands, Scepter commands, Eldrin editor automation, and a future plugin loader all meet at the same action and tool registries. From there, Creator uses the normal applicability checks, parameter handling, activation lifecycle, undo, dirty state, and project notifications.

An action has three different kinds of identity:

  • a localized display name, which the sidebar can qualify with a group such as Face: or Camera:
  • a stable dotted command ID, such as face.extrude, used by automation and extensions
  • an internal UUID retained by the existing UI and action mechanics

Grouping and theme palette slots are presentation/catalog metadata. They do not replace the older action role, which still controls behavior such as automatic camera application. Changing a group or its color therefore cannot silently change how an action executes.

Tools use the same stable-ID principle, with IDs such as tool.geometry, but remain stateful interaction modes with normal deactivate/activate behavior. Actions remain one-shot contextual operations.

The registries now accept runtime-provided boxed actions and tools, which is the extension boundary needed by plugins. This does not yet constitute a complete plugin product: manifest discovery, loading, permissions, isolation, versioning, and distribution still need to be designed around that boundary.

For automation, the Scepter Lorebook is authoritative for the command protocol, while action.list and tool.list are authoritative for the live registered catalog. The prose documentation is the conceptual guide rather than a duplicated static registry.

If you are not sure where something belongs, this is the short version:

  • world structure: regions, sectors, linedefs, entities, items
  • behavior: scripts
  • formulas and shared systems: rules
  • player-facing descriptive world text: authoring metadata
  • shared translated runtime text: localization
  • how the game is shown: presentation layer / client

That is the bigger picture behind Eldiron’s current architecture.