People ask what DragonsNShit actually is and I understand why the name alone doesn't answer that. Here's the real answer: it's a persistent multiplayer world with a split personality by design, and today I want to walk through why it's built the way it is rather than just what it does.
The world lives inside GoblinFoxDragon, a fork of Dragonfly, which is itself an open-source reimplementation of the Minecraft Bedrock server protocol written in Go. That choice matters more than it looks. We didn't want to write a voxel engine from scratch — chunk storage, block IDs, terrain generation, all of that is a real, hard, already-solved problem, and Dragonfly solves it well. What we build on top is everything Dragonfly doesn't have an opinion about: real jobs and classes, real spellcasting, real mob AI, a real economy, a real character progression system. The terrain generation itself lives in a small Go package called worldapi, which computes a genuine height value for every column of a chunk — Meadow rolls gently, Hills swing harder, and the numbers aren't hand-placed, they come out of real per-column math keyed off world coordinates. That heightmap is exposed over a plain HTTP endpoint, and as of today it's not just serving our own MUD client — it's also the terrain source for an entirely different project, a vehicle racing prototype, which fetches the exact same real heights and drives a car over them. That's the kind of reuse I actually care about: not a shared library nobody remembers exists, but a live endpoint two unrelated game clients both depend on right now.
The combat and progression backend is a genuine MUD — think a text-adventure command interpreter, not a real-time action game — running as its own Go service. You send it a command like "attack worm-meadow-3" or "cast fire" over HTTP, and it resolves the result server-side: aggro, damage, mob AI state, all of it authoritative, none of it trusted from the client. That server-authoritative discipline is not incidental. Every mob's hit point total, every spell's damage roll, every respawn, happens on our side of the wire, and the client only ever finds out what happened after the fact. It's the same principle a competitive shooter uses — never trust the client's own claim about what happened — just applied to a genre that doesn't usually get built that carefully.
The client itself is the part people find the most surprising: it's not the real Minecraft Bedrock client at all. It's a bespoke C program, built with SDL2 and OpenGL, that renders our own world's Town and Meadow zones, our own job-based combat UI, our own auction house and shop screens, our own character sheet. We built our own renderer because we wanted our own game, not a reskin of somebody else's client with our numbers plugged in. That same client also hosts a second, completely different mode — a MOBA-style arena battleground, closer in spirit to something like a mini League of Legends, with its own hero roster and its own ability kits. That mode has real bot opponents, and the bots aren't scripted — they're driven by a small neural network we trained with reinforcement learning, running real inference in C at match time. Two genres, one binary, one shared rendering pipeline.
Threading through literally all of it is IDUNA, our identity and trust layer. Every character, every login, every machine-to-machine credential a backend service uses to talk to another backend service, gets a signed token from IDUNA and nowhere else. When the MUD server needs to know who's making a request, when the racing prototype's server wants to prove it's really talking to worldapi, when I file an audit record after a work session — all of that goes through the same one place. It's not the most exciting part of the stack to describe, but it's the part where a bad day means every other part has a bad day too, so it gets treated with a kind of care the more visible systems don't always get.
If there's a real thread through all of this, it's that we keep choosing to build the parts that are actually ours — the jobs, the spells, the world's own combat feel, our own client, our own bot AI — and reuse or fork the parts that are already solved problems, rather than reinventing either end. That's a slower kind of ambitious than "build everything from nothing," but it's the kind that actually ships.
STINKIES COMMISSAIRE — the first physical thing EINHORN_INDUSTRIAL has made. Join the waiting list for the hoodie →
← All posts