Show HN: NeoMud – A multiplayer dungeon game with AI agents that QA and playtest

2 points

3 months ago

  I've been building a modern take on a MUD (multiplayer text RPG) with Claude Code over the past few weeks. Kotlin server, Android client, React-based world editor. The usual hobby project stuff.

  The interesting part is the agent pipeline that grew around it:

  - A /game-designer agent reads all the world data files, models the combat math, and produces balance proposals with specific JSON changes
  - A /playtest agent connects to the running game server over WebSocket, creates a character, explores, fights NPCs, loots items, and files GitHub issues for bugs it encounters
  - A /worldmaker agent drives the world editor in a real browser via Playwright — clicks through zone editing, NPC configuration, item creation, and files issues when things break
  - A /bugfixer agent picks up those issues and submits fixes

  Each agent has persistent memory across sessions, so the game designer remembers its previous balance audits and the playtester remembers what areas it's already explored.

  The game itself is a modern take on '90s MUDs like MajorMUD — tick-based combat, NPC behaviors (wander, patrol, pursuit), spells, skills, stealth, loot tables, vendors, trainers. 4 zones, 25 rooms, 17 NPCs. Everything is data-driven JSON — the world editor exports .nmd bundles (ZIP archives) that the server loads at startup, similar to DOOM's WAD files.

  The world editor has a visual zone map where you place rooms on a shared coordinate grid, click to connect exits, and configure NPC patrol routes by clicking rooms on the map. All zones share one global coordinate space so rooms can't overlap across zones.

  ~45k lines of code, 830 tests across server/shared/maker, 460 AI-generated assets (images and audio). The agents have filed about 40 GitHub issues so far, most of which are legitimate.

  It's a hobby project — combat balance is rough, there's no quest system yet, and it needs real multiplayer stress testing. But the feedback loop of building features and then having agents test them in the actual running application has been a surprisingly effective workflow.

2 comments

I've been building a modern take on a MUD (multiplayer text RPG) with Claude Code over the past few weeks. Kotlin server, Android client, React-based world editor. The usual hobby project stuff. The interesting part is the agent pipeline that grew around it: - A /game-designer agent reads all the world data files, models the combat math, and produces balance proposals with specific JSON changes - A /playtest agent connects to the running game server over WebSocket, creates a character, explores, fights NPCs, loots items, and files GitHub issues for bugs it encounters - A /worldmaker agent drives the world editor in a real browser via Playwright — clicks through zone editing, NPC configuration, item creation, and files issues when things break - A /bugfixer agent picks up those issues and submits fixes Each agent has persistent memory across sessions, so the game designer remembers its previous balance audits and the playtester remembers what areas it's already explored. The game itself is a modern take on '90s MUDs like MajorMUD — tick-based combat, NPC behaviors (wander, patrol, pursuit), spells, skills, stealth, loot tables, vendors, trainers. 4 zones, 25 rooms, 17 NPCs. Everything is data-driven JSON — the world editor exports .nmd bundles (ZIP archives) that the server loads at startup, similar to DOOM's WAD files. The world editor has a visual zone map where you place rooms on a shared coordinate grid, click to connect exits, and configure NPC patrol routes by clicking rooms on the map. All zones share one global coordinate space so rooms can't overlap across zones. ~45k lines of code, 830 tests across server/shared/maker, 460 AI-generated assets (images and audio). The agents have filed about 40 GitHub issues so far, most of which are legitimate. It's a hobby project — combat balance is rough, there's no quest system yet, and it needs real multiplayer stress testing. But the feedback loop of building features and then having agents test them in the actual running application has been a surprisingly effective workflow.