host-authoritative-state

Design host-authoritative state ownership, validation, and broadcast patterns for multiplayer games.

66|4|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/SummerEngine/summer --skill host-authoritative-state-summerengine
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: host-authoritative-state
Source: https://github.com/SummerEngine/summer/tree/main/library/skills/host-authoritative-state
Command: npx skills add https://github.com/SummerEngine/summer --skill host-authoritative-state-summerengine

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Multiplayer games ship with desyncs, item duplication, and cheat vulnerabilities when state ownership is undefined. This Skill provides a decision framework and concrete GDScript patterns for deciding which state the host owns, how clients request changes, and how the host validates and broadcasts updates in Summer Engine. ## Core Features & Use Cases - State ownership decision matrix: Apply the question "if a malicious client lies about this, does it break the game?" to every state field, with a canonical table covering health, inventory, position, cosmetics, and more. - Manager pattern with four RPC flavors: Build one autoload Manager per state domain with host-only mutators, validated client request handlers, authority broadcasts, and targeted rpc_id query/response for late-join state replay. - Validation and anti-cheat guidance: Seven prioritized validators (authority, existence, resource, range, line-of-sight, cooldown, magnitude) plus float-epsilon handling and silent-drop policy. - Use Case: When building a 3D action multiplayer game, use this Skill to create HealthManager, InventoryManager, and CooldownManager autoloads so clients send intent RPCs and the host validates range, cooldowns, and line-of-sight before applying damage. ## Quick Start Ask the agent to design the multiplayer state layer for your game by listing every state field and creating one host-authoritative Manager autoload per domain with validation and late-join sync.

Frequently Asked Questions about host-authoritative-state

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide which state the host should own in a multiplayer game?▼

Ask one question per state field: if a malicious client lies about this, does it break the game? If yes, the host owns it and clients send RPC requests the host validates. If no, it is client-owned cosmetic state replicated only for visual sync.

How do I structure host-authoritative state in GDScript?▼

Create one Manager autoload per state domain holding a Dictionary keyed by peer_id. Only _host_apply_* mutators write data, _client_request_* RPC handlers validate then call mutators, and @rpc("authority") broadcasts push state to clients.

How do I sync game state to players who join mid-session?▼

Each Manager exposes a _send_full_state(peer_id) method connected to the peer_joined signal. It replays current state to only the joining peer using rpc_id targeting with reliable transfer, and broadcast handlers must be idempotent.

Should I use MultiplayerSynchronizer for game state replication?▼

MultiplayerSynchronizer is appropriate only for cosmetic state like animation parameters and look direction. It has no validation hook or per-property authority, so game-logic state like health, score, and inventory should go through Manager RPCs instead.

Why do legitimate player actions fail server validation?▼

Float comparisons in range, distance, and cooldown checks fail due to physics-step jitter. Always allow a small epsilon, such as dist > max_range + 0.5, instead of strict equality, so legitimate clients are not silently rejected.

What validations should a client damage request pass on the host?▼

Validate in priority order: authority over the entity, target existence, resources like equipped weapon, range, line-of-sight via host raycast, cooldown readiness, and magnitude caps against weapon max damage. Failed requests are dropped silently without error responses.