Architecture Overview

This section explains the technical shape of the tool at a level that is useful to advanced users, integrators, and maintainers.

You do not need to fully understand this section to get started, but it becomes useful once you want to reason about service ownership, optional modules, or why some editor tooling depends on shared setup.

The important idea

The current architecture is module-based.

It is built around:

• a shared bootstrap
• explicit module registrars
• a shared service registry
• clear ownership of cross-module services

Main module groups

Shared

Shared provides the common contracts and utilities used by feature modules.

It is a dependency layer, not a full gameplay feature module.

CivilAI

CivilAI is the simulation-focused module.

It owns the behavior-driven town simulation, world time, and item catalog when installed.

Dialogue

Dialogue is the conversation-focused module.

It owns dialogue-facing systems such as conversations, responses, mood, and dialogue content authoring.

Valid installation combinations

The architecture is intended to support:

1. Shared + CivilAI
2. Shared + Dialogue
3. Shared + CivilAI + Dialogue

Why this matters to users

This design affects setup in practical ways.

• the scene uses a bootstrap object instead of older one-off setup assumptions
• services can come from different modules depending on what is installed
• editor tooling may depend on shared services being available

Design direction

The architecture borrows from ideas common to Domain Driven Design:

• keep concepts named consistently
• keep responsibilities separated
• interact through clear service boundaries
• keep optional systems loosely coupled

The rest of this section explains the main structure types and how they relate to one another.