WAIT — Stale — last commit 3y ago

• 4 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• Other licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

BrowserQuest is a real-time multiplayer RPG game built entirely in HTML5/JavaScript, running in the browser with WebSocket-based networking. Players explore a shared world, battle monsters, collect loot, and complete achievements in a synchronous multiplayer environment. It's a technical proof-of-concept demonstrating client-server game architecture with canvas rendering and live player interaction. Monolithic client-server split: client/ contains the frontend (HTML5 canvas game UI, audio in client/audio/sounds/, styles in client/css/, and built assets). bin/build.sh orchestrates builds using r.js (RequireJS optimizer). Server code is inferred to exist outside the listed file structure. Configuration templates in client/config/ define local and build-time settings.

Game developers and JavaScript engineers exploring multiplayer game architecture patterns, especially those building browser-based games or prototyping real-time synchronization mechanics. Contributors are typically Mozilla experimentalists interested in HTML5 gaming capabilities and WebSocket communication at scale.

This is a DEPRECATED experimental project (per repo description). The codebase is static—no recent commits visible in the file listing, and the project serves as a historical reference for HTML5 gaming rather than an active product. It's not production-ready today but remains a valuable learning resource for understanding 2010s-era browser game architecture.

High architectural risk: the project depends on outdated npm packages (underscore, bison, memcache, websocket-server) with no version pinning ('>0' allows breaking changes). The deprecated status means no security updates or modern dependency maintenance. Single-point-of-failure risks from Little Workshop maintainers, and no visible CI/test infrastructure to catch regressions.

Nothing—this is a deprecated, archived experiment. No active development, PRs, or issues are being worked on. The repository is maintained as a historical snapshot of Mozilla's HTML5 gaming exploration circa 2012–2014.

git clone https://github.com/mozilla/BrowserQuest.git
cd BrowserQuest
cp client/config/config_local.json-dist client/config/config_local.json
cp client/config/config_build.json-dist client/config/config_build.json
bash bin/build.sh

Note: You'll need Node.js and npm to install dependencies listed in the package.json (underscore, log, bison, websocket, sanitizer, memcache).

Daily commands:

bash bin/build.sh          # Builds and minifies client assets using r.js
node server.js             # (inferred) Starts WebSocket server listening for clients

Then open http://localhost:[PORT] in a browser. Exact port and server entry point would be in the server-side code not fully listed here.

• server/lib/game.js — Core game server logic managing player state, world updates, and game loop — essential for understanding multiplayer synchronization
• client/js/game.js — Client-side game engine handling rendering, input, and local game state — entry point for browser game logic
• server/lib/worldserver.js — WebSocket server managing client connections, message routing, and world synchronization across all players
• client/js/main.js — Client bootstrap and initialization — sets up the game engine, canvas, and WebSocket connection
• server/server.js — Server entry point configuring HTTP routing, WebSocket server, and game instance initialization
• package.json — Project dependencies and metadata including WebSocket server, sanitizer, and memcache modules critical to multiplayer architecture

• Game Server (game.js) (Node.js, Memcache, Bison) — Central authority for world state, collision detection, combat resolution, loot drops, and game loop timing
  • Failure mode: All players desynchronize; invalid moves or combat outcomes possible if state diverges
• World Server (worldserver.js) (WebSocket (ws module), Bison) — WebSocket connection manager; routes player messages to game server; broadcasts state updates to clients
  • Failure mode: Players disconnect or miss critical state updates; message loss if queue overflows
• Client Game Engine (client/js/game.js) (HTML5 Canvas, RequireJS, Underscore.js) — Renders game world, handles player input, interpolates entity movement, manages local UI state
  • Failure mode: Rendering glitches, input lag, or desync with server state if message handling is delayed
• Player Entity (server/lib/player.js) (Node.js, Memcache persistence) — Encapsulates individual player state: position, health, inventory, equipped items, experience
  • Failure mode: Inventory

Add a new enemy type (mob)

1. Create a new mob class extending server/lib/mob.js with AI behavior and stats (server/lib/mob.js)
2. Register the mob spawner in the world map configuration (server/lib/maps.js)
3. Add sprite assets for the new mob (idle, walk, death animations) (client/img/1/)
4. Define mob metadata (health, damage, loot drops) in server configuration (server/data/mobs.json)

Add a new item or equipment

1. Define item properties (type, stats, rarity) in server item data (server/data/items.json)
2. Create icon sprite asset for the item (client/img/1/item-*.png)
3. Add item spawning logic to server loot system (server/lib/loot.js)
4. Update client item renderer to display new item icon in inventory (client/js/ui/inventory.js)

Add a new sound effect or music

1. Place dual-format audio files (MP3 and OGG) in sound directory (client/audio/sounds/)
2. Register sound in client audio manager with event trigger (client/js/audio.js)
3. Trigger sound playback from game event handler (client/js/game.js)

Add a new NPC or quest giver

1. Create NPC entity with dialogue data and quest triggers (server/lib/npc.js)
2. Add NPC sprite assets for different regions (client/img/1/)
3. Define quest logic and reward conditions (server/lib/quest.js)
4. Update client dialogue UI to render NPC conversations (client/js/ui/dialogue.js)

• HTML5 Canvas — Enables efficient 2D rendering of game world and entities without plugins; cross-browser compatible
• WebSocket — Provides low-latency bidirectional communication essential for real-time multiplayer synchronization
• Bison binary serialization — Reduces network payload size and parsing overhead for frequent game state updates
• Node.js + Express — JavaScript runtime allowing shared code patterns across client/server; event-driven I/O suitable for WebSocket handling
• Memcache — Fast in-memory cache for player session state reducing database queries during active gameplay

• Client-side rendering with server authority

  • Why: Reduces server computation but increases network traffic for state synchronization
  • Consequence: Higher bandwidth requirements but better scalability to many concurrent players; some client-side prediction complexity needed

• Binary serialization (Bison) over JSON

  • Why: Minimizes network payload for frequent updates
  • Consequence: Harder to debug; requires synchronization of protocol version between client and server

• Memcache for session storage, not persistent database

  • Why: Minimizes latency for active player state lookups
  • Consequence: Player data lost on cache eviction; requires background persistence mechanism for durability

• Persistent world state across server restarts (ephemeral session-only)
• Large-scale MMO (designed for local region/limited concurrent players)
• Cross-platform mobile support (HTML5 desktop-focused)
• User account system with long-term progression (proof-of-concept multiplayer)

Critical gotchas: (1) Config files must be copied from -dist templates and customized—the build will fail silently if missing. (2) Both MP3 and OGG audio formats are required for browser compatibility; one format alone will fail in some browsers. (3) The build process uses RequireJS (r.js), an older module bundler—no modern ES6 module support or tree-shaking. (4) Server code is not included in the file listing; you'll need to locate it separately (likely in a server/ directory at the root). (5) Memcache must be running for session persistence; no fallback to in-memory storage is configured.

• WebSocket bidirectional communication — BrowserQuest relies on persistent WebSocket connections for real-time player state synchronization; understanding frame-based vs. event-based messaging is essential to grasp how the game stays in sync across clients
• Tile-based world representation — The game world is divided into grid tiles for efficient collision detection, pathfinding, and entity spatial partitioning; this is fundamental to understanding how the server manages world state and sends deltas to clients
• Binary protocol encoding (Bison) — BrowserQuest uses Bison to serialize game messages into compact binary format for bandwidth efficiency; understanding this reduces message size vs. JSON and is critical for multiplayer optimization
• Canvas 2D rendering pipeline — The client renders the entire game world to a 2D canvas context with layering (terrain, entities, UI); inefficient rendering causes frame drops in multiplayer—the engine must batch draw calls and manage dirty regions
• RequireJS AMD module system — Client code is organized as AMD modules loaded by RequireJS, then bundled by r.js; understanding this asynchronous module pattern is necessary to navigate and modify the codebase, though it's now superseded by ES6 modules
• Memcache for session/state caching — Server likely uses Memcache to store transient player state and sessions; this distributed cache pattern allows horizontal scaling and is worth understanding if extending the backend
• Client-side entity interpolation — In multiplayer games, server sends position updates at intervals (e.g., 100ms), but the client must render smoothly between updates via interpolation; this prevents jittery movement and is implicit in the rendering loop

• gamelab/kiwi.js — HTML5 2D game framework with similar canvas-based rendering architecture and entity management patterns
• Automattic/Scribe — Another Mozilla experiment in real-time collaborative editing via WebSocket, demonstrating similar client-server sync patterns
• phaser-io/phaser — Modern evolution of HTML5 game framework with superior physics, animation, and input handling—BrowserQuest's spiritual successor
• playcanvas/engine — Contemporary WebGL-based game engine that replaced Canvas-only approaches; shows how game architecture evolved post-BrowserQuest
• mozilla/pdf.js — Parallel Mozilla experiment in pushing browser capabilities (PDF rendering) with similar architectural goals and era of development

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add audio format fallback detection and loading tests

The client has 24 audio files (12 pairs of .mp3/.ogg formats) but there's no visible test suite for audio loading logic. A new contributor could create tests for the audio system to ensure proper fallback behavior between MP3 and OGG formats across browsers, preventing silent failures in production.

• [ ] Create client/test directory with audio loading test suite
• [ ] Add tests for audio format detection and fallback logic in client/audio handling
• [ ] Verify MP3/OGG format selection based on browser capabilities
• [ ] Document audio format fallback strategy in client/README.md

Add configuration validation and documentation for config_build.json and config_local.json

The repo has config template files (config_build.json-dist, config_local.json-dist) in client/config/ but no documentation of required fields, types, or validation logic. A contributor could add a schema validator and document the configuration structure to help new developers properly configure the game.

• [ ] Create client/config/CONFIG_SCHEMA.md documenting all required/optional fields
• [ ] Add a config validator script in bin/ to validate against schema
• [ ] Update client/README.md with configuration setup instructions and examples
• [ ] Add sample values to config_build.json-dist and config_local.json-dist

Create asset pipeline documentation and build output tests

The bin/build.sh and bin/r.js suggest a RequireJS-based build process, but there's no documentation of how client assets (images in client/img/1/, fonts in client/fonts/, CSS in client/css/) are bundled. A contributor could document the build process and add tests to verify asset bundling correctness.

• [ ] Document build.sh and r.js usage in bin/README.md with asset processing steps
• [ ] Create tests in bin/test to verify CSS, font, and image assets are properly bundled
• [ ] Add verification that client/img/1/ sprites are correctly referenced in generated client code
• [ ] Create a build troubleshooting guide referencing specific font/image paths

• Add unit tests for client game entity logic—currently no test files visible in client/js/. Start with testing entity movement and collision detection using Mocha or Jest.
• Document the WebSocket protocol and message types used between client and server in a PROTOCOL.md file. Reverse-engineer from Bison message definitions to provide a reference for new contributors.
• Convert RequireJS build process to a modern bundler (esbuild, Vite, or Webpack) to eliminate bin/r.js dependency and enable ES6 module syntax, better tree-shaking, and dev server hot-reload.

• Critical · Overly Permissive Dependency Versions — package.json - all dependencies. All dependencies use '>0' version specifiers, which allows installation of any version including major versions with breaking changes and security vulnerabilities. This makes the project vulnerable to supply chain attacks and introduces unpredictable security risks. Fix: Pin dependencies to specific versions (e.g., '1.2.3') or use reasonable ranges (e.g., '^1.2.3' or '~1.2.3'). Implement dependency scanning tools like npm audit, Snyk, or OWASP Dependency-Check.
• High · Insecure WebSocket Dependency — package.json - websocket, websocket-server dependencies. The 'websocket' and 'websocket-server' packages are outdated generic names with no version constraint. These are critical for real-time communication and may contain known vulnerabilities. The project is from 2012-era and likely uses deprecated versions. Fix: Update to modern WebSocket libraries like 'ws' with pinned versions. Verify no known CVEs exist for the specific versions used. Consider using Socket.io for additional security features.
• High · Unvalidated Input Sanitization — package.json - sanitizer dependency, client-side code patterns. The project includes 'sanitizer' dependency with no version constraint. If this is relying on sanitization for XSS prevention without proper validation, client-side sanitization alone is insufficient. No evidence of server-side validation patterns in the file structure. Fix: Implement server-side input validation and output encoding. Use context-aware escaping for HTML, JavaScript, and URL contexts. Never rely solely on client-side sanitization.
• High · Deprecated and Unmaintained Project — README.md - project status. The repository is explicitly marked as DEPRECATED. This means it receives no security updates, bug fixes, or maintenance. Any vulnerabilities discovered will never be patched. The project likely contains known vulnerabilities from its era. Fix: Do not use this project in production environments. If modernization is required, fork and conduct a comprehensive security audit, update all dependencies, and implement modern security practices.
• High · Missing CORS and CSP Configuration — Server configuration files (not fully visible). No evidence of Content Security Policy (CSP) headers, CORS configuration, or security headers in the file structure. A multiplayer game with WebSocket communication is particularly vulnerable to CSRF and XSS attacks without these protections. Fix: Implement comprehensive security headers including Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and appropriate CORS policies. Use secure WebSocket (WSS) with TLS.
• High · No Authentication/Authorization Framework Visible — package.json - missing security dependencies. The dependency list lacks modern authentication libraries. For a multiplayer game, the absence of secure session management, JWT, or OAuth suggests weak or missing authentication mechanisms vulnerable to account takeover. Fix: Implement robust authentication using industry-standard libraries (passport.js, jsonwebtoken, or similar). Use secure session tokens with proper expiration and storage.
• Medium · Memcache Usage Without Encryption — package.json - memcache dependency. The project uses memcache (unencrypted in-memory cache) with no version constraint. If used for session storage or sensitive data, this is a privacy risk as data is transmitted and stored unencrypted. Fix: Use Redis with encryption in transit, or implement application-level encryption for sensitive cached data. Ensure cache servers are not exposed to untrusted networks.
• Medium · Configuration Files in Repository — client/config/ directory. Config files like 'client/config/config_build.json-dist' and 'config_local.json-dist' are tracked. Distribution configs may contain examples with hardcoded values or sensitive information patterns. Fix: Keep .dist files minimal with safe defaults. Never commit actual configuration files with secrets. Use environment variables for sensitive configuration. Add to .gitignore: *.json (except .dist files).
• Medium · Underscore.js Without Version Constraint — undefined. The 'underscore' Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mozilla/BrowserQuest shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mozilla/BrowserQuest repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mozilla/BrowserQuest.

What it runs against: a local clone of mozilla/BrowserQuest — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mozilla/BrowserQuest | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1062 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mozilla/BrowserQuest. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mozilla/BrowserQuest.git
#   cd BrowserQuest
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mozilla/BrowserQuest and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mozilla/BrowserQuest(\\.git)?\\b" \\
  && ok "origin remote is mozilla/BrowserQuest" \\
  || miss "origin remote is not mozilla/BrowserQuest (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "server/lib/game.js" \\
  && ok "server/lib/game.js" \\
  || miss "missing critical file: server/lib/game.js"
test -f "client/js/game.js" \\
  && ok "client/js/game.js" \\
  || miss "missing critical file: client/js/game.js"
test -f "server/lib/worldserver.js" \\
  && ok "server/lib/worldserver.js" \\
  || miss "missing critical file: server/lib/worldserver.js"
test -f "client/js/main.js" \\
  && ok "client/js/main.js" \\
  || miss "missing critical file: client/js/main.js"
test -f "server/server.js" \\
  && ok "server/server.js" \\
  || miss "missing critical file: server/server.js"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1062 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1032d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mozilla/BrowserQuest"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.