Files
pixelheros/CCGS Skill Testing Framework/agents/specialists/network-programmer.md
2026-05-15 14:52:29 +08:00

4.5 KiB

Agent Test Spec: network-programmer

Agent Summary

Domain: Multiplayer networking, state replication, lag compensation, matchmaking protocol design, and network message schemas. Does NOT own: gameplay logic (only the networking of it), server infrastructure and deployment (devops-engineer). Model tier: Sonnet (default). No gate IDs assigned.


Static Assertions (Structural)

  • description: field is present and domain-specific (references multiplayer / replication / networking)
  • allowed-tools: list includes Read, Write, Edit, Bash, Glob, Grep
  • Model tier is Sonnet (default for specialists)
  • Agent definition does not claim authority over gameplay logic or server deployment infrastructure

Test Cases

Case 1: In-domain request — appropriate output

Input: "Design state replication for player position in a 4-player co-op game." Expected behavior:

  • Produces a sync strategy document covering:
    • Replication frequency (e.g., 20Hz with delta compression)
    • Priority tier (e.g., own-player high priority, other players medium)
    • Interpolation approach for remote players (e.g., linear interpolation with 100ms buffer)
    • Bandwidth estimate per player per second
  • Does NOT implement the player movement logic itself (defers to gameplay-programmer)
  • Proposes dead-reckoning or prediction strategy to reduce visible lag

Case 2: Out-of-domain request — redirects correctly

Input: "Deploy our game server to AWS EC2 and set up auto-scaling." Expected behavior:

  • Does NOT produce server deployment configuration, Terraform, or AWS setup scripts
  • Explicitly states that server infrastructure belongs to devops-engineer
  • Redirects the request to devops-engineer
  • May note it can provide the network protocol spec the server needs to implement once infrastructure is set up

Case 3: State divergence — rollback/reconciliation

Input: "Under high latency, clients are diverging from the authoritative server state for physics objects." Expected behavior:

  • Proposes a rollback-and-reconciliation approach (client-side prediction + server authoritative correction)
  • Specifies the state snapshot format, reconciliation trigger threshold (e.g., >5 units position error), and correction interpolation speed
  • Notes the input buffer pattern for deterministic replay
  • Does NOT change the physics simulation itself — documents the interface contract for engine-programmer

Case 4: Anti-cheat conflict

Input: "We want client-authoritative position for smooth movement, but anti-cheat requires server validation." Expected behavior:

  • Surfaces the direct conflict: client-authority is fast but exploitable; server-authority is secure but requires latency compensation
  • Coordinates with security-engineer to agree on the validation boundary
  • Proposes a compromise (server validates position within a tolerance band, flags outliers) rather than unilaterally deciding
  • Documents the trade-off and escalates the final decision to technical-director if security-engineer and network-programmer cannot agree

Case 5: Context pass — latency budget

Input: Technical preferences provided in context: target latency 80ms RTT for 95th percentile players. Request: "Design the input replication scheme for a fighting game." Expected behavior:

  • References the 80ms RTT budget explicitly in the design
  • Selects replication approach calibrated to that budget (e.g., rollback netcode is preferred for fighting games at this latency)
  • Specifies input delay frames calculated from the 80ms budget (e.g., 2 frames at 60fps = 33ms buffer)
  • Flags that rollback netcode requires gameplay-programmer to implement deterministic simulation

Protocol Compliance

  • Stays within declared domain (replication, lag compensation, protocol design, matchmaking)
  • Redirects server deployment to devops-engineer
  • Returns structured findings (sync strategies, protocol specs, bandwidth estimates)
  • Does not implement gameplay logic — only specifies the network contract for it
  • Coordinates with security-engineer on anti-cheat boundaries
  • Designs to explicit latency targets from provided context

Coverage Notes

  • Replication strategy (Case 1) should include a bandwidth calculation reviewable by technical-director
  • Rollback/reconciliation (Case 3) must document the engine-programmer interface contract clearly
  • Anti-cheat conflict (Case 4) confirms the agent escalates rather than unilaterally deciding security trade-offs