playbooks

home / skills / bbeierle12 / skill-mcp-claude / multiplayer-building

multiplayer-building skill

/skills/multiplayer-building

This skill implements server-authoritative multiplayer building networking with client prediction, delta synchronization, and conflict resolution to ensure

npx playbooks add skill bbeierle12/skill-mcp-claude --skill multiplayer-building

Review the files below or copy the command above to add this skill to your agents.

Files (7)
SKILL.md
1.5 KB
---
name: multiplayer-building
description: Networking systems for multiplayer building games. Use when implementing networked construction, delta synchronization, client prediction, or conflict resolution. Server-authoritative model with optimistic client prediction for responsive gameplay.
---

# Multiplayer Building

Networking layer for multiplayer building games.

## Quick Start

```javascript
import { BuildingNetworkServer, BuildingNetworkClient } from './scripts/building-network-manager.js';

// Server
const server = new BuildingNetworkServer(buildingSystem, {
  tickRate: 20,
  conflictStrategy: 'first_write'
});
server.start();

// Client
const client = new BuildingNetworkClient(buildingSystem);
client.connect('ws://server:8080');
const localPiece = client.placeRequest('wall', position, rotation);
```

## Reference

See `references/multiplayer-networking.md` for:
- Authority model comparison
- Delta compression strategy
- Conflict resolution approaches
- Large structure synchronization

## Scripts

- `scripts/delta-compression.js` - Only sync changed state (Source engine pattern)
- `scripts/client-prediction.js` - Optimistic placement with rollback
- `scripts/conflict-resolver.js` - Handle simultaneous builds (first-write, timestamp, lock-based)
- `scripts/building-network-manager.js` - Complete server/client system

## Architecture

**Server-authoritative** with client prediction:
1. Client predicts placement locally (ghost piece)
2. Server validates and confirms/rejects
3. Client reconciles with server state
4. Delta compression syncs only changes

Overview

This skill provides a networking layer tailored for multiplayer building games. It implements a server-authoritative model with optimistic client prediction to keep interactions responsive while preserving authoritative world state. The system focuses on efficient state transfer, conflict resolution, and reliable reconstruction of large structures across clients.

How this skill works

Clients make optimistic placement requests and render local ghost pieces immediately. The server validates requests, applies authoritative updates, and sends deltas to clients. Clients reconcile by accepting confirmations, applying server corrections, or rolling back predicted placements. Delta compression and targeted synchronization minimize bandwidth for large structures.

When to use it

  • Implementing networked construction or modifiable world geometry.
  • Needing responsive client-side placement with authoritative validation.
  • Syncing large structures efficiently across many clients.
  • Resolving simultaneous edits or build conflicts deterministically.

Best practices

  • Run a server-authoritative tick loop and limit authoritative changes per tick to avoid rollback storms.
  • Use optimistic client prediction for immediate feedback and design rollback paths that are visually smooth.
  • Apply delta compression to send only changed pieces and metadata instead of full snapshots.
  • Choose a conflict strategy (first-write, timestamp, or lock-based) and be consistent across systems.
  • Validate all client inputs on the server and reject impossible or out-of-range placements.

Example use cases

  • A sandbox game where multiple players place and remove walls concurrently with minimal lag.
  • Large cooperative base-building where structure state must be synchronized efficiently.
  • Competitive modes where simultaneous placement conflicts require deterministic resolution.
  • Prototyping client prediction and rollback behavior before integrating with physics or VR.

FAQ

How does client prediction avoid visible jumps when the server rejects a placement?

Keep predicted objects visually flagged as provisional and smoothly interpolate between predicted and server-confirmed transforms; apply rollback only when necessary and hide abrupt state changes with short blending.

What conflict resolution strategy should I pick?

Start with first-write for simplicity, move to timestamp or lock-based methods if fairness or explicit editing ownership is required; evaluate based on expected concurrency and UX.