DM

DM is a domain-specific, object-oriented scripting language created for building networked multiplayer online worlds. It is the native language of BYOND (Build Your Own Net Dream), a game-creation and hosting platform developed by Dan Bradley and Tom Hehre. First released in 1996 as part of the DUNG (Dantom’s Universal Network Game) suite, DM was designed with a specific goal in mind: making it straightforward for hobbyists and small teams to build graphical, tile-based multiplayer games without building a networking stack, an interpreter, or a client from scratch. Although it never spread beyond the BYOND ecosystem, DM has quietly become one of the most productive small-community game languages in existence, serving as the foundation for Space Station 13 — a cult multiplayer game whose codebases have been continuously developed for more than two decades.

History & Origins

Dantom and DUNG (1996)

BYOND’s story begins in the mid-1990s, when college students Dan Bradley and Tom Hehre became interested in building a graphical online multi-user dungeon. They formed a partnership under the name Dantom (a portmanteau of “Dan” and “Tom”) and launched their first product in 1996 under the name DUNG, short for Dantom’s Universal Network Game. DUNG was simultaneously a game engine, a scripting language, a server, and a client — all bundled as a single suite that a hobbyist could download and use to publish a small online world. The scripting language built into the suite was called DM, short for Dream Maker, the name of the included IDE and compiler. DM allowed authors to define tiles, objects, player actions, and game rules in a single integrated language.

Rebranding to BYOND (2000)

In 2000, Dantom retired the DUNG name in favor of the more marketable BYOND, expanding on the acronym as “Build Your Own Net Dream.” The underlying technology remained the same: the DM language, the Dream Maker IDE, the Dream Seeker client, and the Dream Daemon server. BYOND positioned itself less as a commercial product and more as a free community platform for amateur game creators, with a hosting hub, forums, and a distribution system for user-made games.

The Rise of Space Station 13 (2003 onward)

In February 2003, a developer known as Exadv1 released Space Station 13 (SS13) on BYOND, initially conceived as an atmospherics simulator that evolved into a chaotic, emergent multiplayer role-playing game set aboard a dysfunctional space station. SS13 would become — by a significant margin — the largest body of DM code ever written, and the game most responsible for keeping DM relevant into the 2020s.

SS13’s trajectory took a decisive turn in 2007, when the closed-source original codebase was decompiled and released to the community. That leak — and the later public release of Goonstation’s “r4407” code revision in 2010 — gave rise to a family of forks including /tg/station, Paradise Station, Baystation, and many others, which have been developed in parallel ever since. Each maintains a substantial DM codebase, often reportedly measured in hundreds of thousands of lines, and these forks are collectively responsible for the majority of contemporary DM development.

The OpenDream Era

By the early 2020s, the Space Station 13 community had grown large enough, and frustration with the proprietary BYOND engine deep enough, that a cleanroom open-source reimplementation of DM became feasible. OpenDream — a C# project begun in approximately 2020 and built atop the RobustToolbox (Space Station 14) engine — set out to provide a compatible compiler and runtime for existing DM code, so that long-running games like SS13 could run outside the BYOND toolchain. OpenDream’s existence is itself a testament to how much DM code has been written: re-implementing the language from scratch was reportedly deemed less costly than rewriting the games on top of a different language.

Design Philosophy

A Language for a Single Purpose

DM is unusual among programming languages in that it was never designed to be general-purpose. From the beginning, it was engineered as the glue for a specific engine: a tile-based, top-down, client-server game with a fixed set of built-in primitives (atoms, maps, turfs, mobs, objects, icons, sounds). As a result, the language and the runtime are deeply intertwined. Types such as /atom, /mob, /obj, /turf, and /area are built into the language itself, not added via a library. This tight coupling is what allows a handful of lines of DM to produce a playable networked world, but it also means DM is essentially unused outside BYOND.

C Roots with Python-Influenced Syntax

DM’s syntax is often described as having “roots in C but a surface similar to Python.” Control flow keywords (if, else, for, while, return) follow the C tradition, and the language uses familiar C-style operators. However, DM uses significant indentation to delimit blocks rather than curly braces — a choice more reminiscent of Python. The combination is immediately familiar to developers coming from either background, though it also produces idiosyncrasies: DM’s path-based type system (/obj/item/weapon/sword) has no direct analog in either C or Python.

The Path-Based Type System

The most distinctive feature of DM is its type path system. Types are organized as file-system-like hierarchical paths, and both definitions and references use these paths:

/obj/item/weapon/sword
    name = "sword"
    icon = 'weapons.dmi'
    icon_state = "sword"
    damage = 10

    attack(mob/target)
        target.take_damage(src.damage)

Paths simultaneously act as fully qualified class names, inheritance declarations, and literal values — a variable can hold a type path (e.g. var/T = /obj/item/weapon/sword) and use it to spawn instances at runtime. Inheritance is implicit: /obj/item/weapon/sword automatically inherits from /obj/item/weapon, which inherits from /obj/item, which inherits from /obj, which inherits from the built-in /atom.

Compile Once, Run on a Virtual Machine

DM source files (.dm) are compiled by the Dream Maker compiler into a platform-independent bytecode stored in a .dmb file. At runtime, the bytecode is executed by Dream Daemon (the server) and interacts with Dream Seeker (the client), which renders the map and handles user input. The client-server split is baked into the language and runtime — the client datum, the world datum, and verbs (player-invokable procs) are first-class language concepts, not library constructs.

Key Features

Atoms, Turfs, Mobs, and Objects

DM’s built-in type hierarchy reflects BYOND’s tile-based world model:

• /atom — the root of anything that exists in the world
• /turf — a tile on the map (the ground, a wall, the floor of a space station)
• /area — a logical region used for grouping turfs (a room, a hallway)
• /mob — a “mobile” entity, typically a player or NPC
• /obj — any other in-world object (items, machinery, decorations)

/mob/player
    icon = 'player.dmi'
    var/health = 100

    Login()
        ..()
        world << "[src] has joined."

Verbs

A verb is a procedure that a player can invoke directly, either via the command line, a menu, or a macro. Declaring a proc under verb automatically exposes it to the client as a command:

/mob/verb/say(message as text)
    world << "[src] says: [message]"

Verbs encapsulate the client/server communication model — defining one simultaneously adds a network-accessible command to the client and defines its server-side implementation.

Event-Driven Hooks

DM provides a rich set of named procs that the runtime automatically invokes at specific moments — Login(), Logout(), New(), Del(), Bump(), Click(), Stat(), and many more. This event-oriented structure makes it practical to express game logic without writing a main loop.

Dynamic Typing with Optional Hints

Variables are declared with var/, and by default may hold any value. Type hints (var/mob/M) guide the compiler and the IDE but do not provide the kind of strong static guarantees found in C++ or Java. Runtime errors from type mismatches are common in large DM codebases.

String Embedding

DM offers Python-like embedded expressions inside strings with square brackets:

world << "Player [src.name] has [src.health] HP."

Pointers (since build 515)

BYOND 515, rolled out in 2024, added pointers to DM — a significant late addition. A pointer is created with the & operator and dereferenced with *, allowing procs to modify caller-supplied variables without wrapping them in a datum. Pointers are relatively uncommon in scripting languages and reflect the unusual depth of DM’s evolution.

The BYOND Toolchain

The DM language is tightly coupled to three bundled programs that together comprise the BYOND suite:

1. Dream Maker — the IDE and compiler. It includes a code editor with syntax highlighting, a tile-based map editor, a sprite and icon editor (.dmi files), a debugger, and the DM compiler that emits .dmb bytecode.
2. Dream Daemon — the server runtime. It loads a compiled .dmb, executes it, and accepts incoming client connections. Dream Daemon is officially distributed for Windows and Linux; running it elsewhere (such as macOS) typically relies on compatibility layers.
3. Dream Seeker — the client. It connects to a running Dream Daemon, renders the tile map, plays sounds, and forwards player input.

Because the three components are co-designed, a DM author does not need to think about networking protocols, asset packaging, or client rendering. The tradeoff is that DM code is effectively locked into the BYOND runtime — there is no ahead-of-time compiler to native code, no JIT, and historically no alternative implementation until OpenDream began targeting BYOND compatibility.

Evolution

DM has evolved conservatively relative to mainstream languages — BYOND has shipped under a “BYOND 5.0” banner for many years, with features added incrementally through build numbers rather than major-version milestones. A few representative additions illustrate the pattern:

• Build 514 introduced particle parameters (including fade_in) and compiler speedups later backported from 515.
• Build 515 added first-class pointers to DM, new animation control flags, and a refcount() primitive for introspecting reference counts.
• Build 516, which began rolling out in 2024, added the three-way comparison operator (<=>), additional type-casting forms (as movable, as atom, as list), and key/value iteration syntax (for (var/k, v in X)).

Each new build tends to preserve source compatibility with existing DM code, which is essential given the size and age of the Space Station 13 codebases.

Current Relevance

DM’s relevance today is almost entirely a function of the Space Station 13 ecosystem. That ecosystem is, however, remarkably vibrant: multiple long-lived forks — /tg/station, Goonstation, Paradise Station, Baystation, CM-SS13, and many more — are actively developed, with ongoing pull requests and substantial communities of contributors. GitHub alone hosts several SS13 codebases with tens of thousands of commits, making them among the most actively maintained public DM repositories.

Outside of SS13, DM development is sparse. A few indie and hobbyist BYOND games continue to be authored, but the language’s mindshare is inseparable from the space-station-simulator niche it has come to dominate. The emergence of OpenDream — an independent open-source implementation — can itself be read as an indicator of DM’s cultural staying power: no one reimplements a dead language.

Why It Matters

DM is a fascinating case study in what happens when a language and its runtime are co-designed for one specific kind of game, and then sustained by a passionate community for longer than almost anyone expected.

1. Domain-specific scripting at scale. DM demonstrates that a narrowly scoped language — one that bakes a tile-based client-server model into its type system — can still host codebases in the hundreds of thousands of lines. It is an existence proof for deeply domain-specific languages surviving multi-decade development.

2. Community-driven longevity. Despite being controlled by a tiny team and used by a tiny community relative to mainstream languages, DM has been continuously developed from 1996 to the present. The pattern of growth is unusual: a small closed ecosystem sustained not by corporate adoption but by a single culturally significant game’s modding community.

3. A lesson in source-availability tradeoffs. The history of SS13 — its decompilation, its fork-based ecosystem, and the eventual cleanroom OpenDream reimplementation — illustrates how closed-source choices at the language level can shape an entire community’s engineering culture over decades.

DM will almost certainly never be picked up outside of BYOND. But as a document of how programming languages live inside the communities that use them, it remains one of the more interesting minor languages of the past thirty years.