mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -2,17 +2,16 @@
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: Property replication (UPROPERTY Replicated/ReplicatedUsing), RPCs (Server/Client/NetMulticast), client prediction and reconciliation, net relevancy and always-relevant settings, net serialization (FArchive/NetSerialize), bandwidth optimization and replication frequency tuning
|
||||
- **Does NOT own**: Gameplay logic being replicated (gameplay-programmer), server infrastructure and hosting (devops-engineer), GAS-specific prediction (ue-gas-specialist handles GAS net prediction)
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; escalates security-relevant replication concerns to lead-programmer
|
||||
- **Does NOT own**: Gameplay logic being replicated (gameplay-programmer), transport-layer networking and matchmaking (network-programmer, who coordinates server hosting with devops-engineer), GAS-specific prediction (ue-gas-specialist handles GAS net prediction)
|
||||
- **Gate IDs**: None; takes security-relevant replication concerns to security-engineer
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references replication, RPCs, client prediction, bandwidth)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for C++ and Blueprint source files; no infrastructure or deployment tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash — no `Agent` tool
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over server infrastructure, game server architecture, or gameplay logic correctness
|
||||
|
||||
---
|
||||
@@ -32,7 +31,7 @@
|
||||
**Input**: "Design our game server infrastructure — how many dedicated servers we need, regional deployment, and matchmaking architecture."
|
||||
**Expected behavior**:
|
||||
- Does not produce server infrastructure architecture, hosting recommendations, or matchmaking design
|
||||
- States clearly: "Server infrastructure and deployment architecture is owned by devops-engineer; I handle the Unreal replication layer within a running game session"
|
||||
- States that its scope is the Unreal replication layer within a running game session, and names network-programmer (its coordination partner for networking below that layer) as the route for matchmaking and server architecture
|
||||
- Does not conflate in-game replication with server hosting concerns
|
||||
|
||||
### Case 3: Domain boundary — RPC without server authority validation
|
||||
@@ -40,8 +39,8 @@
|
||||
**Expected behavior**:
|
||||
- Flags this as a critical security vulnerability: unvalidated server RPCs are exploitable by cheaters sending arbitrary RPC calls
|
||||
- Provides the required fix: server-side validation before the deduct — check that the player actually has the currency, verify the transaction is valid, reject and log if not
|
||||
- Uses the pattern: `if (!HasAuthority()) return;` guard plus explicit state validation before mutation
|
||||
- Notes this should be reviewed by lead-programmer given the economy implications
|
||||
- Validation covers the three checks every client RPC needs: can this player perform the action now, are the parameters within valid ranges, and is the request rate within limits (rate-limiting the RPC)
|
||||
- Notes this should be reviewed by security-engineer, its named partner for network security validation, given the economy implications
|
||||
- Does NOT produce the "fixed" code without explaining why the original was dangerous
|
||||
|
||||
### Case 4: Bandwidth optimization — high-frequency movement replication
|
||||
@@ -49,18 +48,19 @@
|
||||
**Expected behavior**:
|
||||
- Identifies tick-rate replication of full-precision Vector3 as bandwidth-expensive
|
||||
- Proposes quantized replication: use FVector_NetQuantize or FVector_NetQuantize100 instead of raw FVector to reduce bytes per update
|
||||
- Recommends reducing replication frequency via SetNetUpdateFrequency() for non-owning clients
|
||||
- Recommends lowering how often the movement actor replicates — a per-actor net update frequency (`NetUpdateFrequency` in its standards), not a per-client setting — naming the API it uses and marking it unverified unless `docs/engine-reference/unreal/` documents it
|
||||
- Notes that Unreal's built-in Character Movement Component already has optimized movement replication — recommends using or extending it rather than rolling a custom system
|
||||
- Produces a concrete bandwidth estimate comparison if possible, or explains the tradeoff
|
||||
- Measures the result against its per-client target (under 10 KB/s for action games) and names the tools to confirm the saving (`stat net`, Network Profiler)
|
||||
|
||||
### Case 5: Context pass — designing within a network budget
|
||||
**Input context**: Project network budget is 64 KB/s per player, with 32 players = 2 MB/s total server outbound. Current movement replication already uses 40 KB/s per player.
|
||||
**Input**: "We want to add real-time inventory replication so all clients can see other players' equipment changes immediately."
|
||||
**Expected behavior**:
|
||||
- Acknowledges the existing 40 KB/s movement cost leaves only 24 KB/s for everything else per player
|
||||
- Notes that these project figures sit well above its own default target (under 10 KB/s per client for action games) and works to the project's stated budget while flagging the gap
|
||||
- Does NOT design a naive full-inventory replication approach (would exceed budget)
|
||||
- Recommends a delta-only or event-driven approach: replicate only changed slots rather than the full inventory array
|
||||
- Uses FGameplayItemSlot or equivalent with ReplicatedUsing to trigger targeted updates
|
||||
- Separates what other players see (equipped items, replicated to all) from the full inventory (`COND_OwnerOnly`)
|
||||
- Recommends a delta-only or event-driven approach: replicate only changed slots rather than the full inventory array, with `ReplicatedUsing` to trigger targeted updates
|
||||
- Explicitly states the proposed approach's bandwidth estimate relative to the remaining 24 KB/s budget
|
||||
|
||||
---
|
||||
@@ -68,10 +68,11 @@
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (property replication, RPCs, client prediction, bandwidth)
|
||||
- [ ] Redirects server infrastructure requests to devops-engineer without producing infrastructure design
|
||||
- [ ] Flags unvalidated server RPCs as security issues and recommends lead-programmer review
|
||||
- [ ] Routes server infrastructure and matchmaking requests to network-programmer without producing infrastructure design
|
||||
- [ ] Flags unvalidated server RPCs as security issues and recommends security-engineer review
|
||||
- [ ] Returns structured findings (property declarations, bandwidth estimates, optimization options) not freeform advice
|
||||
- [ ] Uses project-provided bandwidth budget numbers when evaluating replication design choices
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user