Gameplay

Ceres Gameplay is a lightweight Actor-based scaffold for projects that need shared world lifecycles, scene composition, and gameplay services without adopting a large application framework. It is implemented by the Ceres.Gameplay assembly and builds on Ceres Core, Graph, and Flow.

Gameplay provides reusable contracts and runtime services. Projects still own their game-specific state, spawning rules, save model, networking, and presentation architecture.

Module map

Area	Purpose
World and Actors	GameWorld, Actors, Components, Controllers, versioned handles, world subsystems, and actor snapshots
Actor Flow	Actor lifecycle events, embedded or shared graphs, remote graph selection, and Gameplay nodes
Level	DataTable-authored levels, Addressables scene loading, progress, events, and additive scene ownership
AI and Spatial Queries	Job-backed spatial queries built on world actor snapshots
Animation	Script-driven PlayableGraph layers, blending, sequences, and notifications
Audio and FX	Pooled playback from direct assets or Addressables addresses
Graphics	Reactive render settings and data-driven volume profiles
Capture	Camera and screen capture with platform gallery integration
Mod	Mod discovery, validation, configuration, and Addressables content mounting

These modules are independent entry points over the same world and Core services. Use only the parts required by the project.

Dependency direction

Gameplay is the highest framework layer: Ceres → Ceres.Graph → Ceres.Flow → Ceres.Gameplay.

Core services do not depend on Gameplay. Gameplay can expose its C# APIs to Flow, use Core resources and DataTables, and share Graph runtime infrastructure.

Start here

• Start with World and Actors when defining the runtime ownership model.
• Add Actor Flow only to actors that need visually authored behavior.
• Use Level when a gameplay level spans one or more Addressables scenes.
• Read Ceres Architecture and Concepts for the boundary between Core, Graph, Flow, and Gameplay.