You do not need this page for first setup. Use it when deciding who owns state or policy.
Stable mental model
| Scope | Main surface | Owns |
|---|---|---|
| Shared configuration | GridPlacementBundle / settings/resources |
Reusable plugin configuration, actions, templates, rule/service configuration. |
| Player/controller | PlacementSession |
Mutable selection, targeting, coordinate mode, pending placement/manipulation state. |
| Runtime coordinator | GridPlacementHost |
Session registration, input/interaction routing, and service orchestration. |
| Shared placement world | Placement-world records/registries | Committed object identity, occupancy, mounts/sockets, restore authority. |
| Game domain | Your game | Inventory/economy, construction, ownership/factions, progression, game save schema, AI/pathfinding consequences. |
The key ownership rules
- Sessions own interaction state. Two players should not share one session unless they intentionally share selection/targeting/action state.
- The host routes; it does not become a second copy of placement state.
- Committed occupancy/identity is shared world authority. GRID, SMOOTH, mounts, and restore must not become independent competing truths.
- The game owns game meaning. Feed facts into validation and consume placement results instead of moving faction/economy/construction systems into the addon.
2D and 3D use the same ownership model
The dimensional details differ—TileMapLayer terrain/object paths vs GridMap GRID/SMOOTH/mounts—but the host/session/world ownership split stays the same.
This is intentional: adding a second player or a 3D coordinate mode should not require a second architecture.
When to create a game bridge
A simple game can connect directly to the public placement APIs. Add a typed game-side bridge/authority when your integration starts coordinating substantial game-owned policy such as costs, construction, ownership, or save-domain IDs.
Do not add a bridge merely to rename methods or wrap every plugin call.
See When to Write a Game Bridge.