agentleFS
TehseenTechTehseenTech/manus-skills/skills/development-skills/multiplayer-game-builder/SKILL.md

multiplayer-game-builder

Skill0 starsChanged 3 months agoMITView on GitHub

Build multiplayer turn-based games using template-based rapid development, TDD, and real-time Socket.IO integration. Use when creating card games, board games, or any turn-based multiplayer game with real-time synchronization. Apply automatically when the request matches; the user does not need to mention this skill.

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. About 0 are common, 11 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the request matches its description.

    line 15
  2. Distinctive:

    Use this skill when building:

    line 23
  3. Distinctive:

    Test-Driven Development: Write tests first, implement to pass tests, ensure high code quality

    line 32
  4. Distinctive:

    Immutable State: Never mutate game state, always return new objects

    line 33
  5. Very specific:

    Use the find_game_templates.py script to search GitHub:

    line 53
  6. Very specific:

    Use criteria from references/github-template-evaluation.md:

    line 60
  7. Very specific:

    Use templates/implementation-plan-template.md to structure the project.

    line 68
  8. Very specific:

    Follow strict Test-Driven Development.

    line 72
  9. Distinctive:

    Write a failing test

    line 85
  10. Distinctive:

    Run test to verify it fails

    line 86
  11. Distinctive:

    Write minimal code to pass

    line 87
  12. Distinctive:

    Run tests again to verify pass

    line 88
  13. Distinctive:

    Commit with clear message

    line 90
  14. Very specific:

    Broadcasting: Use io.to(gameId).emit() for public state changes

    line 161
  15. Very specific:

    Private Data: Use socket.emit() for player-specific data (hands)

    line 162
  16. Very specific:

    Automatic Actions: Use setTimeout() for delays (e.g., trick collection)

    line 165
  17. Distinctive:

    Update UI in real-time as server broadcasts state changes.

    line 197
  18. Distinctive:

    Always wrap game logic in try/catch and emit errors to specific players.

    line 236
  19. Very specific:

    Use templates/execution-log-template.md to track:

    line 240

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Build multiplayer turn-based games using template-based rapid development, TDD, and real-time Socket.IO integration. Use when creating card games, board games, or any turn-based multiplayer game with real-time synchronization. Apply automatically when the request matches; the user does not need to mention this skill.

This skill should apply automatically when the request matches; the user does not need to mention this skill.

Usage

Use this skill when the request matches its description. The skill is discovered automatically; the user does not need to mention the skill explicitly.

Multiplayer Game Builder

Build multiplayer turn-based games from scratch using a proven workflow that combines template-based rapid development, Test-Driven Development (TDD), and real-time Socket.IO integration.

When to Use This Skill

Use this skill when building:

  • Card games (poker, rummy, bridge, hearts, spades)
  • Board games (chess, checkers, monopoly)
  • Turn-based strategy games
  • Any game requiring real-time multiplayer with game state synchronization

Core Principles

  1. Template-Based Rapid Development: Find and adapt existing open-source templates to save 50%+ development time
  2. Test-Driven Development: Write tests first, implement to pass tests, ensure high code quality
  3. Immutable State: Never mutate game state, always return new objects
  4. Progressive Implementation: Build in phases, test each before moving forward
  5. Comprehensive Documentation: Maintain implementation plans and execution logs

The Development Workflow

Phase 1: Research & Planning (1-2 days)

Research Game Rules

Deeply understand and document the complete rules. Create a rulebook that covers:

  • Deck/board composition
  • Player count and teams
  • Setup and dealing
  • Turn structure
  • Winning conditions
  • Special rules and edge cases

Find Similar Templates

Use the find_game_templates.py script to search GitHub:

python /home/ubuntu/skills/multiplayer-game-builder/scripts/find_game_templates.py "hearts card game"

Evaluate Templates

Use criteria from references/github-template-evaluation.md:

  • Core functionality (auth, lobby, rooms, real-time, database)
  • Technical quality (code quality, tech stack, architecture)
  • Project health (stars, activity, contributors)
  • Ease of use (demo, documentation, setup)

Create Implementation Plan

Use templates/implementation-plan-template.md to structure the project.

Phase 2: Core Game Logic (TDD) (1-2 weeks)

Follow strict Test-Driven Development. See references/tdd-workflow.md for detailed workflow.

Setup Test Infrastructure

Generate boilerplate test files:

python /home/ubuntu/skills/multiplayer-game-builder/scripts/generate_test_suite.py "my-game"

TDD Cycle for Each Module

For each game logic module (deck, bidding, playing, scoring):

  1. Write a failing test
  2. Run test to verify it fails
  3. Write minimal code to pass
  4. Run tests again to verify pass
  5. Refactor if needed
  6. Commit with clear message

Example: Deck Creation

// test/deck.test.js
it("should create a deck of 52 cards", () => {
  const deck = createDeck();
  assert.strictEqual(deck.length, 52);
});

// game-logic/deck.js
function createDeck() {
  // Implementation here
}

Validate Game State

During development, validate game state structure:

python /home/ubuntu/skills/multiplayer-game-builder/scripts/validate_game_state.py "game_state.json"

Key Modules to Implement

  • Deck/Board: Card/piece generation, shuffling
  • Dealing: Distribute cards/pieces to players
  • Game Actions: Bidding, playing, moving
  • Validation: Turn order, legal moves, rule enforcement
  • Trick/Round Collection: Determine winners
  • Scoring: Calculate and track scores
  • Game Orchestration: Coordinate all modules

Phase 3: Real-Time Multiplayer (1 week)

Integrate game logic with Socket.IO. See references/socketio-patterns.md for patterns.

Setup Socket Handlers

Start with templates/socket-handler-template.js:

const games = {}; // In-memory game store

module.exports = function(io, socket) {
  socket.on("create_game", (data, ack) => {
    const gameId = generateId();
    games[gameId] = createGame();
    ack({ gameId });
  });
  
  socket.on("join_game", (data, ack) => {
    // Join logic
  });
  
  socket.on("play_card", (data) => {
    try {
      const game = games[data.gameId];
      const updatedGame = playCard(game, data.card, data.player);
      games[data.gameId] = updatedGame;
      io.to(data.gameId).emit("card_played", updatedGame);
    } catch (error) {
      socket.emit("error", { message: error.message });
    }
  });
};

Key Patterns

  • Broadcasting: Use io.to(gameId).emit() for public state changes
  • Private Data: Use socket.emit() for player-specific data (hands)
  • Turn Validation: Enforce turn-based play on server
  • Error Handling: Wrap all logic in try/catch
  • Automatic Actions: Use setTimeout() for delays (e.g., trick collection)

Phase 4: User Interface (1 week)

Build client-side interface that connects to Socket.IO.

UI Components

  • Game board/table
  • Player hands
  • Action controls (buttons for bidding, playing)
  • Current game state display
  • Score tracking

Client-Side Socket Integration

const socket = io();

socket.emit("join_game", { gameId, userId });

socket.on("card_played", (data) => {
  renderGameState(data);
});

$("#play-card-btn").click(() => {
  socket.emit("play_card", { gameId, card, player });
});

State Rendering

Update UI in real-time as server broadcasts state changes.

Phase 5: Polish & Production (1-2 weeks)

Game-Over Condition

Implement logic to end game and declare winner.

Persistence (Optional)

Integrate database (PostgreSQL, Redis) to save game state.

UI/UX Polish

  • Card images instead of text
  • Animations (card playing, trick collection)
  • Sound effects
  • Mobile responsive design

Deployment

Deploy to production server with proper monitoring.

Best Practices

Immutable State Management

See references/game-state-management.md for patterns:

// Bad: Mutation
game.currentPlayer = nextPlayer;

// Good: Immutable
return { ...game, currentPlayer: nextPlayer };

Error Handling

Always wrap game logic in try/catch and emit errors to specific players.

Logging

Use templates/execution-log-template.md to track:

  • Tasks completed
  • Architectural decisions
  • Code snippets for critical components
  • Lessons learned
  • Test results

Common Game Patterns

See references/common-game-patterns.md for reusable patterns:

  • Turn-based play
  • Bidding systems
  • Trick-taking
  • Scoring systems
  • Round management

Resources

Scripts (scripts/):

  • find_game_templates.py: Search GitHub for similar games
  • generate_test_suite.py: Create boilerplate test files
  • validate_game_state.py: Validate game state structure

Templates (templates/):

  • implementation-plan-template.md: Project planning structure
  • execution-log-template.md: Track implementation progress
  • game-logic-template.js: Starter code for game modules
  • socket-handler-template.js: Socket.IO boilerplate
  • test-suite-template.js: Test structure

References (references/):

  • tdd-workflow.md: Detailed TDD process
  • socketio-patterns.md: Real-time multiplayer patterns
  • game-state-management.md: State management best practices
  • github-template-evaluation.md: Template selection criteria
  • common-game-patterns.md: Reusable game mechanics

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.