Architecture overview (6.0)

How GridPlacement 6.0 runtime is structured for setup, placement, manipulation, and UI integration.

Weight: 90

GridPlacement 6.0 is a GECS runtime with explicit boundaries between state, processing, and event delivery.

Components: state and request data only
Systems: process game rules and transitions
Signal buses: emit small typed event payload objects for UI/game glue

Runtime flow

1
2
3
4
5
6
7
PlacementRequestComponent + PlaceableComponent + GridPositionComponent
  ↓
PlacementValidationSystem (physics + rule checks)
  ↓
PlacementPreviewSystem (preview state + collision indicator)
  ↓
PlacementExecutionSystem (command conversion + relationship updates)

Main runtime responsibilities

System	Responsibility
`PlacementValidationSystem`	Validate request viability using physics queries (`intersect_shape`) and optional rule registry callbacks
`PlacementPreviewSystem`	Maintain preview entity lifecycle, visual validity state, and collision indicators
`PlacementExecutionSystem`	Convert successful requests into `PlacementCommandComponent` and apply placement relationships

Manipulation model

Manipulation operations are split by action instead of one monolithic manager:

MovementManipulationSystem
RotationManipulationSystem
PlacementManipulationSystem
RemovalManipulationSystem

The facade ManipulationSystem provides convenience entry points (try_move, try_rotate, etc.).

Event boundary and UI integration

The placement bus (PlacementSignalBus) emits typed payload objects such as:

PlacementSuccessEvent
PlacementFailureEvent
selection / hover / focus / indicator / drag event payload objects

This keeps event contracts explicit while avoiding large mutable shared state objects.

Data ownership highlights

Placement intent lives in PlacementRequestComponent
Placement mode/session state lives in PlacementComponent
Positioning data lives in GridPositionComponent
Visual preview state lives in VisualPreviewComponent