Systems Flow

The 6.0 runtime is easier to understand if you stop thinking in terms of isolated ECS types and instead think in terms of flow.

Four main stages

1. Input

Input systems and adapters translate player intent into runtime requests.

Typical responsibilities include:

• cursor or target updates
• manipulation commands
• placement requests

2. Validation

Validation systems inspect the current grid, occupancy, constraints, and mode state.

This stage should answer one question clearly: can the requested operation proceed right now?

3. Execution

Execution systems commit valid placement or manipulation operations.

This is where the runtime updates occupancy, entity state, and long-lived results.

4. Visual reflection

Preview, indicator, or Godot-side systems reflect the updated state back into visuals.

In 6.0, that visual layer is not supposed to own the business rules.

Why this matters for public docs

Older 6.0 drafts blurred architecture talk with GECS-specific details that no longer match the codebase. This flow is the stable public framing that better matches the repository today.

If you are integrating GridPlacement into a game, this sequence is more useful than memorizing every internal type on day one.

Public takeaway

• input and Godot nodes produce requests
• validation decides whether work is allowed
• execution changes the authoritative runtime state
• visuals follow the authoritative state

That is the 6.0 mental model the rest of the public docs should preserve.

Validated By

• the current v6.0 workflow and validation guides
• cs/Core/Tests/WorkflowCoverage/PlacementManipulationEndToEndTests.cs