Skip to content

Splintertree

Splintertree is an educational open-source MMO server emulator for the Classic era. The Rust workspace explores how a fully microservice-based, modding-first server emulator can be designed and built from scratch, drawing on the rich open-source emulation heritage that came before it.

Educational project

Splintertree ships no Blizzard data, does not operate any public realms, and does not recommend running public realms with it.

Repository name

The GitHub repository is still called rustcraft — that name predates the project rebrand to Splintertree. The Rust workspace crates already use the splintertree-* prefix, and new documentation refers to the engine as Splintertree throughout.

What the project explores

The codebase is built around a handful of design questions worth studying in their own right:

  • Microservice-first emulation. Can a Classic-era server be cleanly split across sixteen Rust crates communicating over NATS, with one process per (map_id, instance_id)? See Architecture › Overview.
  • Multi-tenant primitives from day one. What does the configuration look like for a single deployment that could host multiple realms — with cross-realm matchmaking, transfers, and connected realms — without the data plane needing rewrites later? See Architecture › Clustering & multi-realm.
  • Modding as the content layer. Can the engine stay completely content-neutral, with rulesets, balance, and custom features shipping as hot-loadable .rcmod bundles? See the Modding section.
  • Scripting at two altitudes. An embedded Python runtime for full programs and an AzerothCore-compatible Smart AI rule table for declarative event/action behaviour, side by side in the same worker. See Scripting.

What is not on the table

  • No game data. The repository ships no client files, DBC tables, MPQs, NPC text, quest text, or item content. Anyone reading the code is reading the engine — bringing it up does not produce a playable game.
  • No operated service. The Splintertree project does not run servers, does not maintain a realmlist, and does not provide player support. There is no "official" realm and there will not be one.
  • No production-readiness claim. The cluster topology and the modding pipeline are interesting on their own; that does not make Splintertree a turnkey product. Public hosting carries legal, security, and operational responsibilities far beyond what this educational project addresses.

How to read the codebase

If you want to dig in:

  1. Start with Architecture › Overview to map the crates onto the request flow.
  2. Read one reference mod end-to-end — mods/faction_tax/ is a compact tour of scripts, addons, and tunables.
  3. Skim splintertree-world/scripts/python/examples/ for runnable Python script demonstrations.
  4. Run mkdocs serve on this site locally to keep the docs open alongside the source.

Why split engine and content?

Even though no realms are operated, the engine / content split is load-bearing for the architecture:

  • The engine stays content-neutral. Performance, clustering, and tooling do not get tangled with gameplay debates.
  • Mod authors get a stable target. The Python API, the YAML content shape, and the Smart AI DSL are decoupled from any specific ruleset.
  • Educational reuse stays clean. Anyone forking the engine for their own learning project starts from the same neutral baseline.

For the engine itself, head back to Architecture.