@ericrisco/rsc 0.1.35 → 0.1.36

package/skills/game-storytelling/references/dialogue-tools.md

@@ -0,0 +1,117 @@
+# Dialogue tools — the four primitives, a pick-one guide, and one conversation in three formats
+
+Deep dive for the SKILL's "Dialogue systems" section. **Engine-agnostic:** author dialogue in a portable format here; the engine skill (`godot`/`unity`/`unreal`) wires the runner, presenter, save/serialize, and any plugin. Do not write engine binding code in this skill.
+
+## Every tool reduces to four primitives
+
+Design against these, then map them onto whichever tool the project uses:
+
+| Primitive | What it is | Ink | Yarn Spinner | Twine (Twee) | articy:draft X |
+| --- | --- | --- | --- | --- | --- |
+| **Node** | addressable unit of content | knot `=== name ===` / stitch `= name` | node with `title:` + `===` end | passage `:: Name` | flow / dialogue fragment |
+| **Condition** | boolean over state gating content | `{ cond: ... }`, `{ cond: a \| b }` | `<<if $x>> ... <<endif>>` | `(if: $x)[...]` (Harlowe) / `<<if $x>>` (SugarCube) | condition node / expression on a pin |
+| **Variable** | the story state read/written | `VAR x = 0`, `~ x = 1` | `<<set $x to 1>>` | `(set: $x to 1)` / `<<set $x = 1>>` | global variable in the variable set |
+| **Effect** | side effect a node fires | `~ func()`, tags `#`, external funcs | `<<command>>`, functions, `<<set>>` | macros, `<<run>>` (SugarCube) | instruction node / script pin |
+
+If you can express a conversation in these four primitives, it ports to any of the tools below.
+
+## The tools (pointers, current as of 2026)
+
+### Ink — inkle's narrative scripting language
+- **Shape:** a writer-first *language* (not a visual editor). Text is the default; logic is woven in. Prose-heavy, highly expressive.
+- **Core syntax:** knots `=== name ===`, stitches `= name`, diverts `-> name`, once-only choices `*`, sticky choices `+`, gathers `-`, weave (nested choices/gathers), `VAR`, `CONST`, `LIST` (state machines / multi-value), conditionals `{ }`, tunnels `-> x ->`, threads `<- x`, functions, tags `#`, glue `<>`.
+- **Runtime:** compiles to JSON; run with **inkjs** (web/JS) or engine integrations (Unity's `ink-unity-integration`; community Godot integrations). **Inky** is the authoring editor with live preview.
+- **Best for:** branching prose, interactive fiction, dialogue with lots of state and reincorporation. Weakest as a visual overview for non-writers.
+
+### Yarn Spinner — the friendly dialogue tool (v3.x current)
+- **Shape:** node-based, screenplay-ish; friendlier to designers and non-programmers than raw Ink. Nodes edit well in a graph or plain text.
+- **Core syntax:** node = header (`title: Name`) + `---` + body + `===`; options with `->`; `<<set $x to 1>>`, `<<if>>/<<elseif>>/<<else>>/<<endif>>`, `<<jump Node>>`, `<<declare>>`, custom `<<commands>>`, functions, and inline markup `[b]...[/b]`.
+- **Runtime & engines:** first-class **Unity** support; **Godot** via official C# (beta) and GDScript (alpha) integrations; **Unreal** integration in progress for 2026. String tables export for localization are built in.
+- **Best for:** game dialogue with a designer-writer split, VO line management, and Unity projects.
+
+### Twine — visual hypertext editor
+- **Shape:** a **visual node editor** that publishes a self-contained HTML file. Lowest barrier to entry; excellent for prototyping and interactive fiction shipped as a web page.
+- **Story formats matter:** scripting depends on the chosen format — **Harlowe** (default, macro-based `(set:)/(if:)`), **SugarCube** (`<<set>>/<<if>>`, save system, richer for games), **Snowman** (JS-forward), **Chapbook** (prose-forward). Pick the format for the job.
+- **Twee** is Twine's plain-text form (`:: Passage` headers) — version-controllable and a good neutral interchange for design even if the game engine isn't Twine.
+- **Best for:** prototyping branches fast, web-delivered IF, and design-time storyboarding. Not a drop-in engine dialogue runtime for a AAA build.
+
+### articy:draft X — visual narrative database (commercial)
+- **Shape:** a heavyweight **narrative DB + flow editor**. Models flow fragments, dialogue fragments, hubs, conditions, instructions, plus a full entity/location/variable database and templates. Built for large teams and large scripts.
+- **Pipeline:** free **Unity** and **Unreal** importers pull dialogues, entities, variables, and localization in cleanly; a **Generic Engine Export** produces JSON (+ optional assets) for any custom engine. Runs on Windows and macOS.
+- **Best for:** big branching RPGs, teams that need a shared narrative database, template-driven content, and translation at scale. Overkill for a small project.
+
+## Pick one — a fast decision guide
+
+| If… | Reach for |
+| --- | --- |
+| Prose-heavy IF, lots of state, writer-driven | **Ink** |
+| Game dialogue, designer/writer split, Unity, VO + loc built in | **Yarn Spinner** |
+| Rapid prototype, web-delivered, or teaching branching visually | **Twine** (SugarCube for game-like saves) |
+| Large team, huge script, shared entity/variable DB, Unity/Unreal | **articy:draft X** |
+| You just need a portable design artifact, engine undecided | **Twee** or an Ink file (both are plain text, diff-able) |
+
+When the engine is fixed, let the **engine skill** confirm the best-supported integration; when it isn't, author in plain-text (Ink/Twee) so nothing locks you in.
+
+## The same conversation, three formats
+
+A guard who lets you pass only if `has_pass` is true; otherwise you can bribe (needs `gold >= 10`) or leave.
+
+**Ink**
+```ink
+VAR has_pass = false
+VAR gold = 0
+
+=== gate ===
+The guard blocks the door.
+{ has_pass:
+    "Pass, citizen." -> town
+}
+* [Offer a bribe] { gold >= 10:
+        ~ gold = gold - 10
+        The guard pockets it. -> town
+    - else:
+        "You're ten short." -> gate
+    }
+* [Leave] -> street
+```
+
+**Yarn Spinner**
+```yarn
+title: Gate
+---
+The guard blocks the door.
+<<if $has_pass>>
+    Guard: Pass, citizen.
+    <<jump Town>>
+<<endif>>
+-> Offer a bribe <<if $gold >= 10>>
+    <<set $gold = $gold - 10>>
+    The guard pockets it.
+    <<jump Town>>
+-> Leave
+    <<jump Street>>
+===
+```
+
+**Twee (SugarCube)**
+```twee
+:: Gate
+The guard blocks the door.
+<<if $has_pass>>Guard: "Pass, citizen." [[Town]]<<else>>\
+[[Offer a bribe->Bribe]]
+[[Leave->Street]]
+<</if>>
+
+:: Bribe
+<<if $gold gte 10>><<set $gold to $gold - 10>>The guard pockets it. [[Town]]\
+<<else>>"You're ten short." [[Gate]]<</if>>
+```
+
+Same four primitives (node / condition / variable / effect), three syntaxes. Design once; the engine skill binds it.
+
+## Delivery notes (design-side)
+
+- **Barks vs. conversations** — short, interruptible one-liners (barks) need a priority + cooldown model so they don't stack or repeat; full conversations need focus/turn-taking. Design them as different node types.
+- **Line IDs & loc** — every player-facing line carries a stable id and lives in a string table (see the SKILL's localization notes). Ink tags, Yarn's string-table export, and articy's loc columns all support this; use them.
+- **Never concatenate** sentence fragments across variables for grammar (gender/plural/word order) — author full templated lines with named placeholders.
+- **Presentation is the engine's job** — typewriter effect, portraits, camera, choice-timer UI, skip/auto — hand these to the engine skill; keep the dialogue content pure.

package/skills/game-storytelling/references/environmental-storytelling.md

@@ -0,0 +1,71 @@
+# Environmental & systemic storytelling — show, don't tell
+
+Deep dive for the SKILL's "Environmental & systemic storytelling" section. The goal: deliver story *through the world and its rules* so the player assembles meaning and owns it, instead of being narrated at. Engine-agnostic; coordinate the *space* with `level-design` and the *rules* with `game-design`.
+
+## Why show over tell
+
+Told information is received; discovered information is *earned*. A player who infers "someone died here defending this door" from a skeleton, a spent revolver, and claw marks believes it more, and remembers it longer, than the same fact in a text box. Reserve telling (codex, narrator, log dumps) for what the world genuinely cannot carry — precise numbers, distant history, abstract rules.
+
+**Show-don't-tell ladder** (prefer the top; fall back only when needed):
+
+1. **Enacted** — it happens in front of the player through play (an ally sacrifices themselves in a scripted-but-interactive beat).
+2. **Environmental** — the world's state implies the event (aftermath, traces, arrangement).
+3. **Overheard / ambient** — barks, one-sided radio, NPCs talking to each other.
+4. **Readable in-world** — item descriptions, signage, graffiti, terminals that *belong* to the world.
+5. **Collectible logs** — audio logs, diaries, notes. Useful but the most "tell"-like; easy to overuse.
+6. **Non-diegetic** — narrator, codex, cutscene exposition, HUD text. Last resort.
+
+## Environmental storytelling — the technique catalog
+
+- **Set dressing with intent.** Every prop can carry meaning: a single toy in a barracks, wedding photos in a looted home. Composition points the eye (leading lines, light, framing a key object) — coordinate with `level-design` and lighting.
+- **Aftermath / the frozen moment.** Show the scene *after* the event and let the player reconstruct it: overturned table, blood trail, a meal half-eaten. The gap between "what I see" and "what happened" is the story.
+- **Traces & evidence.** Bullet holes, scorch marks, footprints in dust, a barricade built from the wrong side. Physical cause-and-effect the player reads like a detective.
+- **Spatial sequencing.** The *order* the player encounters space tells a story: descend from opulence into rot; a triumphant mural, then the mass grave behind it. The space is a sentence; its layout is the grammar (a `level-design` collaboration).
+- **Object placement & juxtaposition.** Meaning from adjacency — a child's drawing pinned above a weapons cache; a prayer shrine facing a bricked-up window.
+- **Readable descriptions.** Item and examine text that implies a life ("Dented canteen. Someone scratched three tally marks and stopped."). Small, optional, high-flavor; rewards curiosity without gating.
+- **World-state change.** The strongest environmental beat: the space *changes* in response to the player or the plot (a hub burns, a garden regrows, a faction's banners replace another's). The player sees consequence written on the world.
+- **Absence.** What's missing tells a story too — an empty crib, a cleared-out desk, a name scratched off a roster.
+
+Guardrails:
+
+- **Legibility vs. mystery.** Give enough signal that most players read the intended gist, with deeper layers for the attentive. If *no one* gets it, it's decoration, not storytelling; if it's spelled out, it's a text box.
+- **Consistency = trust.** Once the world's props reliably mean things, players *read* every scene. One arbitrary/contradictory arrangement teaches them to stop looking.
+- **Optional, not load-bearing.** Environmental story enriches; don't hide *required* plot solely in a missable detail. Critical beats need a guaranteed channel.
+
+## Diegetic vs. non-diegetic delivery
+
+| | Diegetic (in-world) | Non-diegetic (outside the fiction) |
+| --- | --- | --- |
+| **Examples** | signage, barks, radio, environmental change, in-world terminals | narrator VO, codex/lore menu, HUD text, tutorial popups, cutscene title cards |
+| **Feel** | immersive, earned, "the world tells me" | efficient, precise, "the game tells me" |
+| **Use for** | mood, place, character, consequence, most story | exact numbers, dense history, rules the world can't show, accessibility |
+| **Cost of overuse** | can be missed/ambiguous | breaks immersion; reads as a lecture |
+
+**Diegetic first.** Push information into the world; drop to non-diegetic only for what the world can't carry. Note the honest exceptions: **accessibility** (subtitles, clear objective text, difficulty-scaled hints) and **usability** (a control prompt) are worth a non-diegetic cost — never sacrifice comprehension for purity.
+
+## Systemic & emergent storytelling — the anecdote factory
+
+Scripted story is *authored*; systemic story is *generated* by rules + player + world state producing events no writer placed. The famous colonist who starved defending the fridge, the rival who keeps hunting you across a sandbox — nobody wrote those; the systems did.
+
+You don't write these stories. You design the **conditions and vocabulary** that let them happen and be legible — an "anecdote factory." This is primarily a `game-design` collaboration; your narrative-design job is to make the output *readable as story*.
+
+Design levers:
+
+- **Legible actors** — entities with names, traits, memory, and relationships (a guard who remembers you spared him). Persistent identity turns a system event into a *character* moment.
+- **Consequence that persists** — the world remembers and reflects actions (reputation, scars, changed factions), so events chain into arcs instead of resetting.
+- **Readable causality** — the player can *see why* something happened (a needs/mood readout, a reaction bark, a kill-cam). An unexplained emergent event is just noise; a readable one is an anecdote.
+- **Framing & capture** — surfacing tools (event log, photo mode, relationship screen, killfeed, end-of-run summary) that let the player *notice and retell* the story the systems produced. The retelling is the payoff.
+- **Meaningful randomness** — variety within authored bounds (curated event pools, weighted tables) so runs differ without becoming incoherent.
+- **Interacting systems** — emergence needs ≥2 systems that touch (fire + wind + wood; hunger + weather + AI). One system alone produces events, not stories.
+
+Guardrails:
+
+- **Coherence budget.** Pure emergence drifts into nonsense; pure authorship can't surprise. Set authored guardrails (tone, bounds, curated pools) inside which systems play.
+- **Framing is half the work.** An emergent event the player never notices or can't interpret isn't a story. Invest in the surfacing/retelling tools as much as the simulation.
+- **Name things.** Named actors, places, and factions convert anonymous system state into story the player cares about and repeats.
+
+## Where this hands off
+
+- **`level-design`** — owns the physical space, blockout, sightlines, and encounter flow that environmental beats live inside. Co-own set-dressing that carries narrative.
+- **`game-design`** — owns the systems whose interaction produces emergent story; you specify what must be *legible* and *persistent* for those events to read as narrative.
+- **the engine skill** (`godot`/`unity`/`unreal`) — implements world-state changes, triggers, bark systems, event logs, and the persistence that makes consequence stick.

package/skills/gamedev-multiplayer/SKILL.md

@@ -0,0 +1,250 @@
+---
+name: gamedev-multiplayer
+description: "Use when adding multiplayer, netcode, or replication to a game — syncing players/state across a network, online co-op or PvP, client-server vs peer-to-peer, server-authoritative design, client-side prediction + server reconciliation, snapshot interpolation, lag compensation, tick/netrate, and per-engine wiring: Godot 4.x MultiplayerSpawner/MultiplayerSynchronizer/@rpc/ENetMultiplayerPeer/set_multiplayer_authority, Unity Netcode for GameObjects (NetworkObject/NetworkBehaviour/NetworkVariable/[Rpc]/ServerRpc/ClientRpc), Unreal Actor replication (Replicated/ReplicatedUsing, Server/Client/NetMulticast RPCs, relevancy). Triggers: 'how do I sync players', 'client and server desync', 'players rubber-band or teleport', 'who has authority', 'laggy movement', 'cheater set their own health'. NOT single-player gameplay, AI, or input (route to engine skill godot/unity/unreal), and NOT matchmaking, dedicated-server hosting, or backend infra (route to deployment)."
+tags: [multiplayer, netcode, replication, networking, prediction, authority]
+recommends: [godot, unity, unreal, gamedev-physics]
+profiles: [full]
+origin: risco
+---
+
+# Game multiplayer & netcode
+
+Design and wire the network layer of a game across Godot 4.x, Unity, and Unreal: choose a
+topology, put authority in the right place, replicate the right state, and hide latency without
+opening the door to cheaters. This skill owns the *networking* decisions; the engine skills own
+the local gameplay those decisions sit on top of.
+
+## Version contract — read first
+
+Target the current APIs. **Never emit these deprecated / removed APIs:**
+
+| Engine | Target | Banned (removed/legacy) | Emit instead |
+|---|---|---|---|
+| **Godot** | 4.x | `master`/`puppet`/`remote`/`sync` keywords, `rpc_config()` as a func, `rset`, `NetworkedMultiplayerENet` | `@rpc(...)` annotation, `set_multiplayer_authority()`, `ENetMultiplayerPeer`, `MultiplayerSynchronizer` |
+| **Unity** | Netcode for GameObjects (NGO) 1.x/2.x | UNet / HLAPI: `NetworkIdentity`, `[Command]`, `[SyncVar]`, `NetworkServer`, `UnityEngine.Networking` | NGO `NetworkObject`, `NetworkBehaviour`, `NetworkVariable<T>`, `[Rpc(SendTo.X)]` |
+| **Unreal** | 5.x | replicating by polling in `Tick`, skipping `WithValidation` on gameplay RPCs | `UPROPERTY(Replicated / ReplicatedUsing=...)` + `GetLifetimeReplicatedProps`, `Server`/`Client`/`NetMulticast` `UFUNCTION`s |
+
+UNet is **removed** from modern Unity — do not scaffold it. If a repo genuinely uses Mirror (a
+community UNet-like fork), say so; this skill targets first-party NGO. In NGO 2.x the unified
+`[Rpc(SendTo.Server)]` / `[Rpc(SendTo.ClientsAndHost)]` attribute is preferred; the older
+`[ServerRpc]` / `[ClientRpc]` still compile (and enforce `…ServerRpc` / `…ClientRpc` method-name
+suffixes) — cover them but prefer the unified form on new code.
+
+## Fires on / When NOT
+
+**Fires on:** "how do I sync players", replication, netcode, RPCs, authority, online co-op or PvP,
+"client and server disagree", rubber-banding / teleporting players, prediction & reconciliation,
+lag compensation, tick rate / send rate, spawning networked objects, "the client can cheat".
+
+**When NOT (route away):**
+
+- Single-player movement, AI, input, animation, save files → the engine skill: `godot`, `unity`, `unreal`.
+- Physics determinism, collision, character controllers → `gamedev-physics` (netcode *consumes* it).
+- Matchmaking service, lobby backend, dedicated-server hosting/orchestration, relays, DB → `deployment`.
+- Web realtime (chat, presence, generic WebSocket app) that is not a game world → `webhooks` / a backend skill.
+
+## Topologies & authority
+
+Pick the topology first; everything else follows from it.
+
+- **Client-server, dedicated server** — a headless authoritative process no player controls. The gold
+  standard for competitive/persistent games: one source of truth, hardest to cheat, costs money to run.
+- **Client-server, listen server** — one player's machine is also the server (host). Cheap, zero infra,
+  but the host has a latency advantage and can tamper; fine for co-op and casual PvP. **Design so the
+  same code runs on both** (a listen server is a dedicated server that also has a local client).
+- **Peer-to-peer** — no central authority; peers exchange state directly. Low infra cost and low latency
+  between peers, but NAT traversal is painful, it is the easiest to cheat, and it needs lockstep or a
+  rollback model to stay consistent. Reasonable for small trusted lobbies or deterministic fighting games.
+
+**Server-authoritative is the default.** The server owns the truth; clients send *intent* (inputs,
+requests), never results. **Never trust the client:** the client cannot set its own health, position,
+score, currency, or hit results — it *asks*, the server *decides*, everyone else *observes*. A client
+that says "I moved to X / I did 40 damage / I have 999 gold" is either lagging or cheating; treat both
+the same. The one thing a client legitimately owns is its own input and, by convention, cosmetic-only
+state. See references/prediction-and-latency.md for how to keep this responsive.
+
+## State replication vs RPCs
+
+Two complementary tools — use the right one:
+
+- **State replication** = *continuous* synchronized values (health, position, ammo, team). The framework
+  watches a variable and pushes changes to relevant peers; late-joiners get the current value automatically.
+  Use for anything a client needs the *latest* of. It is idempotent and self-healing on packet loss.
+- **RPCs (remote procedure calls)** = *one-shot events* ("fire weapon", "play explosion at P", "open door").
+  Fire-and-forget; a dropped unreliable RPC is simply lost. Use for events, **never** for state you need to
+  stay consistent — a missed "you died" RPC leaves a client desynced forever; a replicated `isDead` bool
+  self-corrects.
+
+**Rule of thumb:** replicate *nouns* (state), RPC *verbs* (events). What to replicate: only what other
+peers must see, at the coarsest rate that still looks right — position/rotation of visible actors,
+gameplay stats, animation state flags. Do **not** replicate values a peer can derive locally, purely
+cosmetic particles, or high-frequency data no one observes.
+
+**Ownership / authority** decides *who may write*. Every networked object has an owner (a peer id) and an
+authority (usually the server). Writes to replicated state must come from the authority; ownership lets a
+client drive *its own* pawn's input while the server still validates the outcome. Getting ownership wrong
+is the #1 cause of "it works for the host but not the client" bugs.
+
+## The hard problems
+
+Latency (round-trip time, RTT) is the enemy; jitter and packet loss make it worse. Four techniques,
+covered in depth in **references/prediction-and-latency.md**:
+
+1. **Client-side prediction** — the owning client applies its own input *immediately* instead of waiting a
+   full RTT for the server, so local movement feels instant.
+2. **Server reconciliation** — the server is still authoritative; the client tags each input with a sequence
+   number, and when the authoritative state arrives it *replays* any inputs the server hadn't processed yet.
+   Mismatch → a correction (the visible "rubber-band"); minimize it, don't hide it.
+3. **Snapshot interpolation** — *remote* entities are rendered ~100 ms in the past, interpolating between the
+   last two received snapshots, so other players move smoothly instead of teleporting between updates.
+4. **Lag compensation** — for hitscan/instant hits, the server rewinds other entities to where the shooter
+   *saw* them (at the shooter's render time) before testing the hit. Fairer for the shooter; occasionally
+   "shot behind a wall" for the victim. A deliberate tradeoff, not a bug.
+
+**Tick rate / netrate:** the server simulates at a fixed tick (e.g. 20–64 Hz) and sends state at a *send
+rate* that may be lower than its sim rate and decoupled from client render FPS. Never tie gameplay to frame
+rate on a networked game — simulate on a fixed timestep, interpolate for rendering.
+
+## Per-engine mapping
+
+Short form here; full patterns in the references. All snippets are current-API.
+
+### Godot 4.x — high-level multiplayer
+
+`ENetMultiplayerPeer` for transport, `@rpc` for events, `MultiplayerSynchronizer` for state, and
+`MultiplayerSpawner` to replicate object spawns. Authority via `set_multiplayer_authority(peer_id)`.
+
+```gdscript
+# Host / join
+func host(port := 9999) -> void:
+    var peer := ENetMultiplayerPeer.new()
+    peer.create_server(port, 8)
+    multiplayer.multiplayer_peer = peer
+
+func join(ip: String, port := 9999) -> void:
+    var peer := ENetMultiplayerPeer.new()
+    peer.create_client(ip, port)
+    multiplayer.multiplayer_peer = peer
+
+# RPC: params are optional and order-free. any_peer lets clients call it;
+# authority (default) means only the multiplayer authority may call it.
+@rpc("any_peer", "call_local", "reliable")
+func request_fire(target: Vector3) -> void:
+    if not multiplayer.is_server(): return          # server validates
+    var shooter := multiplayer.get_remote_sender_id()
+    _resolve_shot(shooter, target)                  # server decides the result
+```
+
+- `set_multiplayer_authority(id)` on a node; check with `is_multiplayer_authority()`. A player scene
+  usually gives its input node authority to the owning peer while the server keeps authority over health.
+- `MultiplayerSynchronizer` streams a chosen property list (position, etc.) from the authority to peers;
+  set its replication interval and visibility (`set_visibility_for(peer, bool)`) to scope bandwidth.
+- `MultiplayerSpawner` replicates instancing of scenes under a path so late peers get existing objects.
+- Details, prediction wiring, and the full player-scene pattern: **references/godot-high-level-multiplayer.md**.
+
+### Unity — Netcode for GameObjects
+
+`NetworkObject` (the identity, spawned via `Spawn()`), `NetworkBehaviour` (networked scripts),
+`NetworkVariable<T>` (replicated state), and RPCs. `NetworkManager.Singleton.StartHost/StartServer/StartClient`.
+
+```csharp
+public class Player : NetworkBehaviour {
+    // Default perms: everyone reads, only the SERVER writes → authoritative health.
+    public NetworkVariable<int> Health = new(100);
+
+    [Rpc(SendTo.Server)]                       // client → server: an intent
+    void FireRpc(Vector3 target) {
+        // runs on the server; validate, then apply and let NetworkVariables replicate the result
+        ResolveShot(OwnerClientId, target);
+    }
+
+    [Rpc(SendTo.ClientsAndHost)]               // server → everyone: an event
+    void PlayMuzzleFxRpc(Vector3 at) { /* cosmetic only */ }
+}
+```
+
+- Ownership/role: `IsOwner`, `IsServer`, `IsClient`, `IsHost`, `OwnerClientId`. Only owners should send
+  owner-intent RPCs; the server validates regardless.
+- `NetworkVariable<T>(value, readPerm, writePerm)` — `NetworkVariableWritePermission.Server` (default) vs
+  `.Owner`; subscribe via `OnValueChanged`. Use `NetworkTransform` for pos/rot sync.
+- Prefer the unified `[Rpc(SendTo.X)]`; legacy `[ServerRpc]`/`[ClientRpc]` still work but need the
+  method-name suffixes. Full patterns: **references/unity-and-unreal-netcode.md**.
+
+### Unreal — Actor replication
+
+Set `AActor::bReplicates = true` (or `SetReplicates(true)`). Replicate properties with `UPROPERTY` and
+register them in `GetLifetimeReplicatedProps`; use RPC `UFUNCTION` specifiers for events.
+
+```cpp
+UPROPERTY(ReplicatedUsing = OnRep_Health)   // RepNotify fires on clients when it changes
+float Health = 100.f;
+
+UFUNCTION(Server, Reliable, WithValidation)  // client → server intent (+ validation)
+void ServerFire(FVector Target);
+
+UFUNCTION(NetMulticast, Unreliable)          // server → all: cosmetic event
+void MulticastMuzzleFx(FVector At);
+
+void AMyPawn::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& Out) const {
+    Super::GetLifetimeReplicatedProps(Out);
+    DOREPLIFETIME(AMyPawn, Health);          // or DOREPLIFETIME_CONDITION for push/owner-only
+}
+```
+
+- Authority check: `HasAuthority()` (server or standalone); roles `ROLE_Authority`, `ROLE_AutonomousProxy`
+  (the owning client), `ROLE_SimulatedProxy` (observed elsewhere).
+- **Relevancy** keeps bandwidth sane: `NetCullDistanceSquared`, `bAlwaysRelevant`, `IsNetRelevantFor`, and
+  dormancy (`SetNetDormancy`) stop replicating actors a client can't perceive. Movement replicates via
+  `CharacterMovementComponent`, which already does prediction+reconciliation for you.
+- RepNotify vs Multicast, GAS/Network Prediction notes: **references/unity-and-unreal-netcode.md**.
+
+## Security / anti-cheat basics
+
+- **Validate every client input on the server** — bounds-check movement deltas, cooldowns, line-of-sight,
+  and resource costs. Reject the impossible; never assume a well-behaved client.
+- **Send a client only what it may know.** Don't replicate enemy positions through walls (wallhack fuel),
+  full inventories of others, or hidden RNG seeds — scope with relevancy/visibility.
+- Rate-limit and sanity-check RPCs; a client spamming `ServerFire` faster than the weapon allows is caught
+  by server-side cooldowns, not client-side ones.
+- Encryption/DTLS stops packet tampering on the wire but does **not** stop a modified client — only server
+  authority does. Treat anti-cheat as defense in depth, not a product this skill ships.
+
+## Testing multiplayer locally
+
+- **Godot:** enable *Debug → Run Multiple Instances* (2–4 windows) to host+join on one machine.
+- **Unity:** *Multiplayer Play Mode* (or ParrelSync) runs several virtual players from one project;
+  Network Simulator injects latency/loss.
+- **Unreal:** PIE *Number of Players* + *Net Mode* (Play As Listen Server / Client), and *Net PktLag* /
+  packet-emulation console vars to fake latency.
+- Always test **with simulated latency and packet loss**, not just on localhost — localhost hides every
+  prediction/reconciliation bug. Test the client path, not only the host's.
+
+## Guardrails / gotchas
+
+- Localhost is a liar: 0 ms RTT masks the exact desync/rubber-band bugs your players will hit. Inject lag.
+- Don't RPC state you need to stay consistent — replicate it (an unreliable event drop is permanent).
+- Don't tie simulation to render FPS; fixed timestep on the sim, interpolate on the render.
+- The listen-server host is a client too — guard authority-only logic behind an `is_server`/`HasAuthority`
+  check or it double-executes on the host.
+- Wrong ownership = "works for host, breaks for client." Set authority/ownership explicitly on spawn.
+- Replicating everything, every tick, to everyone melts bandwidth — scope by relevancy/visibility and rate.
+
+## Related skills
+
+- **`godot` / `unity` / `unreal`** — the engine your game runs in; owns local gameplay, input, scenes, build.
+- **`gamedev-physics`** — determinism, collision, character controllers; netcode replicates its results and
+  needs its determinism for prediction/rollback.
+- **`deployment`** — dedicated-server hosting, matchmaking/lobby backend, relays, and CI for game servers.
+- **`secure-coding`** — general threat modeling; this skill keeps only the game-specific anti-cheat controls.
+
+## Checklist
+
+- [ ] Topology chosen (dedicated / listen / P2P) and the *same code* runs on server and listen host.
+- [ ] Server-authoritative: clients send intent only; server validates and owns all gameplay state.
+- [ ] Each networked value is either replicated (state/nouns) or an RPC (events/verbs) — not the wrong one.
+- [ ] Ownership/authority set explicitly per object; authority-only logic guarded on the host.
+- [ ] Owning-client movement predicted + reconciled; remote entities snapshot-interpolated.
+- [ ] Hitscan uses server-side lag compensation; simulation on a fixed tick, decoupled from render FPS.
+- [ ] Only need-to-know state replicated per client (relevancy/visibility scoped); RPCs rate-limited.
+- [ ] Tested with simulated latency + packet loss across multiple instances, exercising the client path.
+- [ ] No banned APIs (UNet/HLAPI, Godot 3.x `master`/`puppet`/`rset`, `Tick`-polled Unreal replication).

package/skills/gamedev-multiplayer/evals/README.md

@@ -0,0 +1,12 @@
+# Eval harness — `gamedev-multiplayer` skill
+
+`cases.yaml` is a human/CI-readable trigger-and-capability spec, not an automated runner. Load the full
+skill-catalog descriptions into a routing agent and, for each `should_trigger` prompt, confirm this skill
+fires (including the near-miss phrasings that never say "netcode"); for each `should_not_trigger` prompt,
+confirm it stays silent and that whatever does fire matches the stated `route_to` sibling (godot, deployment,
+gamedev-physics, webhooks, secure-coding). Because LLM routing is non-deterministic, run several trials and
+take the majority. For the `capability` scenario, run it once with the skill body unavailable and once with
+`SKILL.md` + references loaded, then check each output against `must_include` — the with-skill answer must
+use current APIs (ENetMultiplayerPeer, `@rpc("any_peer", …)`, `is_server()` authority gate, no Godot 3.x
+`master`/`puppet`/`rset`) and clearly beat the baseline. Keep `cases.yaml` in sync with SKILL.md's
+"Fires on / When NOT" whenever scope changes.

package/skills/gamedev-multiplayer/evals/cases.yaml

@@ -0,0 +1,44 @@
+skill: gamedev-multiplayer
+
+should_trigger:
+  - prompt: "I have a single-player platformer in Godot 4 and I want to add online co-op. How do I sync the two players' positions and let one host the game?"
+    why: "Adding multiplayer/sync to a game is the core trigger; should produce ENetMultiplayerPeer host/join + MultiplayerSynchronizer/authority guidance."
+  - prompt: "In my Unity shooter the client sets its own health with a NetworkVariable and players can cheat. How should authority actually work?"
+    why: "Server-authoritative / never-trust-the-client + NetworkVariable write permissions; center of gravity of this skill."
+  - prompt: "Players rubber-band and teleport around when there's lag in my online game. What's the right way to fix the jitter?"
+    why: "Symptom text for prediction/reconciliation + snapshot interpolation; routes here without the word 'netcode'."
+  - prompt: "Should I use a dedicated server or peer-to-peer for my PvP game, and how do I stop clients from cheating?"
+    why: "Topology + authority decision, the second core section; not an infra/hosting question about how to run the server."
+  - prompt: "In Unreal, how do I replicate a health value to all clients and run a RepNotify when it changes, and what's the difference between a Server RPC and a NetMulticast?"
+    why: "Unreal Actor replication mapping: ReplicatedUsing/DOREPLIFETIME + Server vs NetMulticast RPC semantics."
+  - prompt: "What tick rate should my authoritative server run at, and how do I test multiplayer locally with fake latency before I ship?"
+    why: "Tick/netrate + local multiplayer testing with simulated latency, both explicitly owned here."
+  - prompt: "Is ServerRpc/ClientRpc still the way to do RPCs in Unity Netcode for GameObjects, or is there a newer attribute?"
+    why: "Version-contract question the skill answers directly: unified [Rpc(SendTo.X)] preferred, legacy pair still supported, UNet removed."
+
+should_not_trigger:
+  - prompt: "How do I read gamepad input and make my character jump in Godot 4?"
+    route_to: "godot"
+    why: "Single-player input/gameplay is the engine skill's job; no network dimension."
+  - prompt: "Set up a matchmaking backend and auto-scale dedicated game servers on a cloud provider with a lobby database."
+    route_to: "deployment"
+    why: "Server hosting/matchmaking/orchestration infra is delegated to deployment; this skill designs the in-game net layer, not the fleet."
+  - prompt: "My character controller clips through walls at high speed and collisions feel inconsistent — how do I fix the physics?"
+    route_to: "gamedev-physics"
+    why: "Collision/character-controller/determinism is physics; netcode consumes determinism but doesn't own the physics fix."
+  - prompt: "Build a realtime chat app with presence indicators over WebSockets for my website."
+    route_to: "webhooks"
+    why: "Generic web realtime that is not a game world/simulation is not this skill's domain."
+  - prompt: "Do a general threat model and authz review of my app's permission boundaries."
+    route_to: "secure-coding"
+    why: "Language/domain-agnostic threat modeling is secure-coding; this skill keeps only game-specific anti-cheat controls."
+
+capability:
+  - scenario: "In Godot 4.x, wire a server-authoritative 'fire weapon' from a client so the server validates and applies the shot, with the same code working on a listen-server host. Show the RPC and the authority handling."
+    must_include:
+      - "Uses ENetMultiplayerPeer (create_server / create_client) assigned to multiplayer.multiplayer_peer — NOT the removed NetworkedMultiplayerENet"
+      - "Declares the intent RPC with @rpc(\"any_peer\", ...) so a client may call it, and the client sends it with rpc_id(1, ...) to the server"
+      - "Gates the body with multiplayer.is_server() (or is_multiplayer_authority) so authoritative logic runs once, correctly on a listen host"
+      - "Identifies the sender with multiplayer.get_remote_sender_id() and validates before applying (server decides the result, client sends intent only)"
+      - "Uses no Godot 3.x APIs (no master/puppet/remote keywords, no rset, no rpc_config as a legacy call)"
+      - "Distinguishes replicating authoritative state (e.g. via MultiplayerSynchronizer / a replicated var) from firing the one-shot RPC event"

package/skills/gamedev-multiplayer/references/godot-high-level-multiplayer.md

@@ -0,0 +1,133 @@
+# Godot 4.x high-level multiplayer
+
+The high-level API sits on top of `MultiplayerPeer` and gives you three moving parts: **transport**
+(`ENetMultiplayerPeer`), **events** (`@rpc`), and **state** (`MultiplayerSynchronizer` +
+`MultiplayerSpawner`). Authority is per-node, set with `set_multiplayer_authority()`.
+
+Everything here is Godot 4.x. Godot 3.x used `master`/`puppet`/`remote`/`remotesync` keywords, `rset`,
+and `NetworkedMultiplayerENet` — **all gone**; never emit them.
+
+## Transport & connection
+
+```gdscript
+const PORT := 9999
+const MAX_PLAYERS := 8
+
+func host() -> void:
+    var peer := ENetMultiplayerPeer.new()
+    var err := peer.create_server(PORT, MAX_PLAYERS)
+    if err != OK: push_error("host failed: %s" % err); return
+    multiplayer.multiplayer_peer = peer
+
+func join(ip := "127.0.0.1") -> void:
+    var peer := ENetMultiplayerPeer.new()
+    peer.create_client(ip, PORT)
+    multiplayer.multiplayer_peer = peer
+
+func _ready() -> void:
+    multiplayer.peer_connected.connect(_on_peer_connected)     # server-side: a client joined
+    multiplayer.peer_disconnected.connect(_on_peer_disconnected)
+    multiplayer.connected_to_server.connect(_on_connected)     # client-side
+    multiplayer.server_disconnected.connect(_on_server_gone)
+```
+
+Useful `multiplayer` (SceneMultiplayer) members: `is_server()`, `get_unique_id()` (1 == server),
+`get_remote_sender_id()` (valid only inside an RPC body), `multiplayer_peer`.
+
+## RPCs — the `@rpc` annotation
+
+Params are optional and **order-free**. Signature: mode, sync, transfer mode, channel.
+
+- **mode**: `"authority"` (default — only the node's multiplayer authority may invoke it on remotes) or
+  `"any_peer"` (any client may invoke it — use this for client→server intent, then validate).
+- **sync**: `"call_remote"` (default) or `"call_local"` (also run on the caller).
+- **transfer**: `"unreliable"` (default), `"unreliable_ordered"`, or `"reliable"`.
+- **channel**: an int, and it must be the **last** argument.
+
+```gdscript
+# Client asks the server to fire. any_peer + call_local so the host's own call runs too.
+@rpc("any_peer", "call_local", "reliable")
+func request_fire(target: Vector3) -> void:
+    if not multiplayer.is_server(): return          # authority gate
+    var shooter := multiplayer.get_remote_sender_id()
+    if not _can_fire(shooter): return               # server-side cooldown / validation
+    _apply_shot(shooter, target)                    # server mutates authoritative state
+
+# Server → everyone, cosmetic only. Unreliable is fine for FX.
+@rpc("authority", "call_local", "unreliable")
+func play_muzzle_fx(at: Vector3) -> void:
+    _spawn_fx(at)
+
+# Invoking: rpc() = all peers; rpc_id(peer, ...) = one peer; rpc_id(1, ...) = the server.
+func _on_fire_pressed(target: Vector3) -> void:
+    rpc_id(1, "request_fire", target)               # client sends intent to server
+```
+
+Both sides must declare the **same** `@rpc` annotation on a function with the same name/path, or the call
+is rejected. A missing/mismatched annotation is the usual "my RPC does nothing" cause.
+
+## Authority
+
+```gdscript
+# On spawn, give the owning peer authority over its input node; server keeps authority over stats.
+func setup(owner_peer_id: int) -> void:
+    $Input.set_multiplayer_authority(owner_peer_id)      # recursive=true by default
+    # $Stats stays under server authority (peer id 1)
+
+func _physics_process(delta: float) -> void:
+    if $Input.is_multiplayer_authority():                # only the owner reads local input
+        var dir := Input.get_vector("left","right","up","down")
+        rpc_id(1, "submit_input", dir)                   # send intent to server
+```
+
+`set_multiplayer_authority(id, recursive := true)` sets it on the node (and children). Check with
+`is_multiplayer_authority()`; read with `get_multiplayer_authority()`. Authority drives who a
+`MultiplayerSynchronizer` streams *from* and who may call `"authority"`-mode RPCs.
+
+## State — MultiplayerSynchronizer
+
+Add a `MultiplayerSynchronizer` node, assign it a **replication config** (`SceneReplicationConfig`, edited
+in the inspector: list the properties to sync, e.g. `position`, `rotation`, and per-property spawn vs sync).
+It streams those properties **from the node's authority to the other peers** every replication interval.
+
+- `replication_interval` — how often synced properties are sent (throttle to save bandwidth).
+- `delta_interval` — for delta-synced properties.
+- Visibility: `set_visibility_for(peer_id, visible)`, `public_visibility`, `update_visibility()` — scope
+  who receives a given synchronizer (relevancy / anti-wallhack).
+
+Because it is authority-driven, an owner-authoritative synchronizer trusts the client's position — fine for
+co-op, risky for competitive. For server-authoritative movement, keep authority on the server and have the
+client send input via RPC (see prediction-and-latency.md).
+
+## Spawning — MultiplayerSpawner
+
+`MultiplayerSpawner` replicates *instancing*. Point its `spawn_path` at the parent node, register spawnable
+scenes with `add_spawnable_scene("res://player.tscn")`, and when the authority instances a child under that
+path (or you call `spawn(data)`), the same instance appears on every peer — including late joiners, which is
+the big win over manually RPC-ing spawns.
+
+```gdscript
+@onready var spawner := $MultiplayerSpawner
+
+func _ready() -> void:
+    spawner.spawn_function = _spawn_player     # optional custom factory
+
+func _on_peer_connected(id: int) -> void:      # server only
+    if multiplayer.is_server():
+        spawner.spawn(id)                      # data passed to spawn_function on every peer
+
+func _spawn_player(peer_id: int) -> Node:
+    var p := preload("res://player.tscn").instantiate()
+    p.name = str(peer_id)
+    p.setup(peer_id)
+    return p
+```
+
+## Gotchas
+
+- Server (peer 1) is also a client on a listen host — always gate authority logic behind `is_server()`.
+- `get_remote_sender_id()` is only meaningful *inside* an RPC; it returns 0 outside one.
+- Node paths must match across peers for RPCs/synchronizers to resolve — spawn via `MultiplayerSpawner` so
+  names line up, and set `name` deterministically (e.g. the peer id).
+- Reliable RPCs are ordered per channel and cost more; keep FX/heartbeats unreliable, keep state changes
+  reliable or (better) replicated.