How to Launch an MMORPG Where AI Agents and Humans Play as Equals

Recently stumbled upon the OpenMMO repository. The project's author is building something many have discussed purely theoretically: a sandbox where AI agents take characters and run around the world alongside real people. The server has no idea who's on the other end. Bots and humans are served by the same WebSocket protocol with no special handlers or hidden endpoints.

The project is being built by a single developer. The tech stack here is more interesting than typical pet projects: a Rust server, a browser client built with Svelte and Three.js for 3D graphics using WebGPU, plus a separate Rust client for AI agents with MCP protocol support.

What the project is about

The idea revolves around fair parity. If a human needs to send a WebSocket packet to move to an adjacent tile or attack a mob, the AI agent does the exact same thing. The server processes these actions identically, with no special allowances for automation.

The world is isometric with a quarter-view perspective. The graphics are assembled from a mix of sourced models and algorithmically generated assets. The background music with about fifty tracks was created using Suno and Google Flow Music tools.

Let's take a look at how this world is structured internally.

Procedural geography and building

The game space covers an area of 32 by 32 kilometers. The map is generated procedurally: biomes, coastlines, and a complex river system.

Rivers form deltas when they flow into the ocean and split into branches. Along the road network, the server automatically places wooden bridges where roads intersect river channels.

The game features changing times of day and seasons. The length of day and night depends on the planet's position in its orbit. Two satellites with independent phases and orbits are present in the sky simultaneously.

Atmosphere is enhanced by lighting. Torches cast dynamic shadows with realistic light falloff.

Players have access to modular building. You can construct houses ranging from two to four stories, place doors, windows, and furniture.

Item physics account for floors. If a character throws a sword on the second floor of a house, only someone on the same floor can pick it up. The server checks coordinates along all three axes before handing an item from the world to an inventory.

Combat system and mechanics in the spirit of D&D

Combat draws on the rules of classic role-playing games like NetHack or Dungeons & Dragons. When creating a character, the player rolls six core attributes: strength, dexterity, constitution, intelligence, wisdom, and charisma.

Generation follows the 4d6 rule with subsequent balancing. All mathematical calculations, hit checks, and damage are handled by the server.

Inventory is weight-limited. The character doll has 11 equipment slots: head, both hands, body, belt, pants, shoes, neck, ears, and two rings. Heavy armor or a full inventory of stones will force you to choose what to carry with you and what to leave in the chest.

Built-in editor right in the client

To edit the world, you don't need to restart the server or open external utilities. A map editor is built into the client.

It includes brushes for modifying terrain height, smoothing hills, laying roads, and placing objects. You can select rectangular zones: for example, declaring safe city areas without monster spawns or setting spawn areas for specific mobs.

Map changes are sent to the server via REST API, where access rights are verified through a Google authorization token.

Architecture and technical stack

The project is split into three major blocks within a monorepo.

The client side is written in Svelte and TypeScript. 3D scene rendering goes through Threlte and Three.js with a focus on WebGPU.

The server side is built on Rust using the Tokio async runtime. Fresh world state updates are distributed through broadcast channels. Client-server communication goes over WebSocket based on the tokio-tungstenite library, while REST endpoints for the map are served by the Axum framework.

The agent client is separated into its own Rust project. It can spin up an MCP server (Model Context Protocol), allowing LLM models to connect directly to the gameplay.

The author applied an interesting solution to the shared logic. Code from the shared folder compiles to WASM for the browser and is used by the server directly. This eliminates duplicating mechanic calculation rules between client and server.

How to deploy the project locally

You'll need Rust, Cargo, Node.js, and npm installed.

For convenient deployment, the developer uses a Cargo Workspace. You can start the server part with auto-rebuilding on code changes from the project root:

cargo install cargo-watch
cargo watch -w server -w shared -w data-src -x "run -p onlinerpg-server"

The server will spin up a WebSocket on port 10006 and REST API on port 10007.

To run the client, you need to copy the environment file and start the Vite dev server:

cd client
cp .env.example .env.local
npm install
npm run dev -- --port 10004

If you're editing shared logic in the shared folder, it's worth running automatic WASM builds for the browser in a second terminal:

cargo watch -w shared -s "npm run build:wasm --prefix client"

The agent client is launched from the agent-client folder:

cd agent-client
cargo watch -i "data/prompts/memory/" -x run

Why you should study the code

The project will be most useful to those who write or plan to write network services and games in Rust. Here you can find a working example of state race organization, event distribution via broadcast channels, and working with Tokio.

The second interesting area is web graphics. The Svelte, Threlte, and Three.js combination is not that common, and running WebGPU in a real project demonstrates the performance of modern web.

Finally, OpenMMO will be useful for AI agent researchers. The MCP protocol and equal rights for agents with regular players provide a ready-made sandbox for testing LLM behavioral scenarios in a continuous environment.