Multiplayer Building & Targeting Service Architecture

Overview

This document tracks the migration to the multiplayer service architecture for GridBuilding, focusing on:

One orchestrating Building/Placement system service for the game.
One Manipulation system service shared across players.
One TargetingShapeCast2D node per user character, each delegating to the shared Core targeting services.

The goal is to support multiple players/characters cleanly while preserving a single authoritative building/manipulation pipeline.

Core services (engine-agnostic)
- Building / placement logic lives in Core services (e.g., placement, manipulation, targeting, mode).
- Services are resolved through the ServiceRegistry and are independent of Godot nodes.
Godot front-end systems (single orchestrators)
- A single Building/PlacementSystem node orchestrates placement requests.
- A single ManipulationSystem node orchestrates manipulation actions (select, rotate, remove, etc.).
- These systems receive requests tagged with which user / character initiated the action.
Per-user TargetingShapeCast2D nodes
- Each controllable character or player has its own TargetingShapeCast2D (or simplified equivalent) node.
- These nodes:
  - Handle engine-level shape casting and input for that one character.
  - Delegate results (grid positions, hits, etc.) to Core targeting services using the user id.

Scales to multiple players without duplicating building/manipulation logic.
Ensures a single authoritative place for placement and manipulation decisions.
Keeps TargetingShapeCast2D focused on engine responsibilities (casts, transforms, input) instead of business rules.
Makes it easier to reason about who is targeting/placing (explicit user id per targeting node).

Ensure there is exactly one Building/PlacementSystem node per gameplay scene (or mode).
Ensure there is exactly one ManipulationSystem node per gameplay scene.
Both systems resolve services through the ServiceRegistry and are agnostic to how many players exist.

For each controllable character / player:
- Instantiate a dedicated TargetingShapeCast2D node.
- Associate it with a user id (via the service layer, not via hard-coded exports for identity).
- Route targeting events and results through the shared Core targeting services, tagged with that user id.

Ensure targeting events are expressed in terms of user id + targeting data.
Building/PlacementSystem and ManipulationSystem consume these events and apply rules in Core services.
Avoid per-player copies of building/manipulation logic; only TargetingShapeCast2D is per-character.

Add tests that cover:
- Multiple TargetingShapeCast2D nodes driving a single shared placement/manipulation pipeline.
- Correct isolation of targeting state per user.
- Conflict scenarios (two users targeting the same tile) resolved by Core services.

Use this table to track implementation status as the multiplayer architecture is rolled out.

Area	Description	Status	Notes
Single Building/Placement orchestrator	Confirm one authoritative placement system node per scene that delegates to Core placement services.	Planned	Replace any remaining per-player building systems.
Single Manipulation orchestrator	Confirm one ManipulationSystem node per scene orchestrating all manipulation via Core services.	Planned	Ensure it is fully ServiceRegistry-based.
Per-user TargetingShapeCast2D	Assign one TargetingShapeCast2D-style node per controllable character/user and tag events with user id.	Planned	Remove any shared targeting node that implicitly assumes a single player.
Multiplayer test coverage	Add tests for multiple users sharing building/manipulation services but using per-user targeting nodes.	Planned	Integrate with existing GridBuilding test projects.

Multiple independent building or manipulation systems per player duplicating logic.
A single TargetingShapeCast2D node that implicitly assumes only one active player.
Embedding business rules in TargetingShapeCast2D instead of delegating to Core services.

Supports the v6 emphasis on Core-first services and Godot as a thin integration layer.
Prepares GridBuilding for richer multiplayer scenarios without architectural rewrites.
Keeps per-player differences localized to targeting/input nodes while keeping core logic shared and testable.