2.0 KiB
2.0 KiB
| description | alwaysApply |
|---|---|
| Server-authoritative simulation; client sends intents; transport-only networking; no client-trusted outcomes. | true |
Architecture — authority & client boundaries (Neon Sprawl)
Canonical background: docs/architecture/tech_stack.md. This rule is the non-negotiable slice for day-to-day implementation.
Where truth lives
- Authoritative game state and rules live on the C# / ASP.NET Core server (zones, combat resolution, inventory, economy, progression, anything audit-worthy).
- The Godot client is responsible for input, presentation, camera, UI, and local feel (e.g. interpolation, cosmetic prediction only if explicitly designed)—not for deciding final outcomes of gameplay systems.
Network shape
- WebSocket or TCP is transport only. Do not put authoritative simulation in Godot’s high-level multiplayer templates or patterns that imply peers co-own game state.
- Prefer a clear boundary: client emits intents (e.g.
MoveIntent,UseAbilityIntent); server validates, simulates, persists as needed, and responds with state deltas or snapshots. Names are examples—follow whatever contracts exist in-repo.
What the client must not “decide”
- Do not treat the client as source of truth for loot, trades, crafting results, currency, or anti-cheat-sensitive behavior. Those paths belong on the server with validation and, where required, database transactions (see tech stack doc).
Exceptions
- Prototype-only, client-local behavior is allowed when a Jira story or plan explicitly scopes it (e.g. no server yet, “client-only milestone”) and docs/README call out that it is temporary until authoritative sync exists. Do not silently expand client-only shortcuts into permanent architecture.
When unsure
- Default to server validates + owns outcome; add a short note in the story plan or PR if you introduce a deliberate exception.