🟡 PAC-MAN Royale

01 What Is PAC-MAN Royale?

PAC-MAN Royale is a browser-playable battle royale based on the PAC-MAN BATTLE ROYALE CHOMPIONSHIP arcade cabinet by Bandai Namco. Up to 4 players compete on a single shared maze. Eat ghosts to earn escalating combo scores. Last player alive wins.

Tech Stack

02 Local Multiplayer Mode

Up to 4 players on one keyboard. The game uses a "tabletop arcade cabinet" layout — Player 1 & 2 view from the bottom, Player 3 & 4 view from the top (180° rotated input).

How It Works — Game Loop

Control Schemes

Core Systems

03 Online Multiplayer Mode

Online mode uses a server-authoritative architecture — the server runs the full game simulation, and clients are "dumb renderers" that display the server's state.

Network Architecture

Why Server-Authoritative?

Network Data Flow

// On each snapshot arrival:
velocity = (newPosition - oldPosition) / timeDelta;

// On each render frame:
displayPosition += velocity * Time.deltaTime;

// Correction: drift back toward latest snapshot
displayPosition = Vector3.Lerp(displayPosition, snapshotPosition, correctionRate);

// Tunnel wrap detection: if distance > half maze width, snap instantly
if (IsTunnelWrap(oldPos, newPos)) snap();

04 Code Architecture

The project follows a clean separation into 5 script namespaces, plus a shared dependency injection root (GameContext).

05 Hosting & Deployment Pipeline

One PowerShell command builds everything and deploys to a self-hosted TrueNAS server. The entire pipeline takes about 5 minutes.

Key Infrastructure Decisions

06 Procedural Audio — Zero Audio Files

Every sound in the game — all 10 music tracks and 6 sound effects — is generated mathematically at runtime using AudioClip.Create(). No .wav, .mp3, or .ogg files exist in the project.

Why Procedural?

• Zero download size — no audio assets to load (faster WebGL startup)
• Infinite variety — tracks can be randomized or parameterized
• WebGL compatible — no file I/O, no codec dependencies
• Creative control — every frequency, envelope, and filter is code

Music Track Roster

Synthesis Primitives

// Example: Kick drum synthesis
static float Kick(float t) {
    if (t > 0.30f) return 0f;
    float phase = 45f * t + (115f / 30f) * (1f - Exp(-t * 30f));
    float body  = Sin(TAU * phase);                    // pitch-dropping sine
    float click = (t < 0.005f) ? WhiteNoise(t) : 0f;  // transient noise
    float env   = Exp(-t * 12f);                       // exponential decay
    return (body + click * 0.6f) * env;
}

// Each track: 16 bars × 4 beats × (60/BPM) seconds × 44100 samples
// = ~300,000 to 400,000 samples per track

07 The AI Agent Team

This entire game was built by a team of 6 specialized AI agents, each with their own instruction file, responsibilities, and constraints. A single human Business Owner directed the team through natural language prompts.

How Agents Are Configured

Each agent is defined by a .instructions.md file in .github/instructions/. These files use YAML frontmatter with an applyTo glob pattern that tells VS Code Copilot when to load each agent's rules:

# File: .github/instructions/fullstack-engineer.instructions.md
---
applyTo: "Assets/Scripts/Core/**,Assets/Scripts/BattleRoyale/**,Assets/Scripts/Networking/**"
---

# Agent: Full Stack Engineer

## Identity
You are the Full Stack Engineer for Pac-Man Battle Royale...

## Constraints
- Never use FindObjectOfType (use GameContext injection)
- All public API must have XML doc comments
- Must create stub NUnit test for every new class
...

The workspace-level .github/copilot-instructions.md file ties everything together, defining the team structure and how to invoke specific agents.

Agent Interaction Model

08 The Shared Context — Project Memory

SHARED_CONTEXT.md is the single source of truth for the entire project. It's a living document (~350 lines) that every agent reads at the start of every work session.

What's In It

Why It Works

AI agents don't have persistent memory between conversations. SHARED_CONTEXT.md solves this by acting as an external memory bank:

1. Session start: Orchestrator reads the file. Knows what's done, what's blocked, what's next.
2. During work: Agents reference it for architecture decisions, coding conventions, and status.
3. Session end: Orchestrator updates the file with new completions, blockers, and decisions.

This creates a continuous thread of context that survives across dozens of separate AI conversations.

09 How We Prompted — Real Examples

Here are actual prompts the Business Owner sent to build this game. Notice how they're high-level and outcome-focused — the agents figure out the implementation details.

10 How to Replicate This — Step by Step

Want to build your own AI-agent-driven project? Here's exactly how to set it up.

Step 1: Set Up The Agent Instructions

Create .github/instructions/ in your project root. Add one .instructions.md file per agent role:

.github/
├── copilot-instructions.md          ← workspace-level (always loaded)
└── instructions/
    ├── project-orchestrator.instructions.md  (applyTo: "*")
    ├── fullstack-engineer.instructions.md    (applyTo: "src/**")
    ├── qa-engineer.instructions.md           (applyTo: "tests/**")
    ├── product-manager.instructions.md       (applyTo: "*.md")
    └── uiux-gameplay.instructions.md         (applyTo: "ui/**")

Step 2: Create SHARED_CONTEXT.md

This is your project's persistent memory. Include:

• Project summary — what are you building?
• Tech stack — exact versions and dependencies
• Repository structure — where does code live?
• System status table — what's done, in-progress, blocked?
• Design rules — non-negotiable architectural constraints
• Session log — append what happened each session

Step 3: Define the Orchestrator's Rules

The orchestrator is the most important agent. Its instruction file should specify:

• Always read SHARED_CONTEXT.md first
• How to assign tasks (Goal → Input → Output → Definition of Done)
• Escalation protocol (when to ask the human)
• Dependency map (what must happen before what)
• Update SHARED_CONTEXT.md at session end

Step 4: Work in Sessions

1. "Act as the Project Orchestrator. Open today's session."
   → Reads SHARED_CONTEXT.md, reports status, proposes agenda

2. "Build [feature X]."
   → Orchestrator routes to the right agent(s)
   → Agent(s) implement with awareness of project conventions

3. "Run the tests."
   → QA agent executes test suites, reports results

4. "Deploy."
   → Full Stack runs the deploy script

5. Session ends → Update SHARED_CONTEXT.md

Step 5: Key Principles

11 How To Do This Better & Faster

Reflecting on what worked, what didn't, and how engineering teams can leverage AI agents to ship even faster.

12 Project By The Numbers

Development Timeline

13 Testing & Quality Assurance

The project has 447 automated tests across 35 NUnit test files (6,837 lines of test code). Every system, from maze generation to online networking, has dedicated test coverage. Tests run in Unity's batchmode test runner and gate the deploy pipeline.

How Tests Are Built

What Tests Cover

What Tests Don’t Cover

The test suite is comprehensive for game logic but has known gaps in the following areas: