DROD Scripting

DROD Scripting is the embedded, domain-specific scripting system used to author content for the Deadly Rooms of Death (DROD) puzzle-game series by Caravel Games. It is not a general-purpose programming language; it is a command-based, event-driven, turn-based instruction list authored inside DROD’s level editor and attached to “character” NPCs placed in rooms. Although obscure outside the DROD community, it has been continuously developed since 2005 and is the substrate on which a substantial body of fan-authored puzzle content — official “holds,” Smitemaster’s Selections, and dozens of community campaigns — has been built.

History & Origins

From a Chessboard Prototype to an Open-Source Engine

DROD itself predates its scripting language by nearly a decade. According to interviews with Erik Hermansen, he conceived the original puzzle on a chessboard around 1991, prototyped a Visual Basic for DOS version (initially called “Swordplay”) in the early 1990s, and rewrote the game in C++ for Windows. Webfoot Technologies published the first commercial DROD release in 1996, with Lars Kristian Aasbrenn reportedly composing the original game’s score. Webfoot’s distribution wound down toward the end of the decade, and in 2000 Hermansen — with Webfoot’s permission — released the DROD source code under the Mozilla Public License 1.1, with a SourceForge project registered around that time.

The engine was rebuilt as “Caravel DROD” (version 1.5) in 2002 by a team that came to be known as Caravel Games — Erik Hermansen, Matt Schikore, Mike Rimer, and a rotating cast of volunteer contributors. DROD: Architects’ Edition (engine 1.6) followed in 2003, introducing the in-game level editor and the concept of user-made holds (campaigns), but at that point holds were still purely static puzzle layouts. There was no way for an architect to script behavior; rooms relied entirely on the engine’s built-in monsters, doors, and orbs.

The Birth of DROD Scripting (2005)

Scripting arrived two years later, with DROD: Journey to Rooted Hold (engine 2.0), released on April 1, 2005 (the Linux build reportedly followed shortly after). For the first time, hold authors could attach scripts to placed NPC “characters.” A script was an ordered list of commands — Wait, Move to, Speech, If ... go to, Wait for event, Turn into monster, and so on — selected through dialog widgets in the level editor. The runtime executed those scripts each turn, weaving their effects into the existing turn-based puzzle simulation.

That single addition transformed DROD content authorship. Where a 2003-era hold could only arrange walls, doors, and stock monsters, a 2005-era hold could now stage scripted dialogue, branching narratives, custom puzzle elements built from invisible scripted characters, and full cutscenes. The first official campaign to use scripting heavily was Journey to Rooted Hold itself, but community holds caught up almost immediately — Halph Has a Bad Day, Perfection, Beethro’s Teacher, and other Smitemaster’s Selections released over the following years set the template for what scripted DROD content could be.

Subsequent Evolution

Each major DROD engine release has expanded the scripting system rather than replacing it:

• DROD 3.0 — The City Beneath (2007) added user-defined variables, alongside additional commands, events, and the _-prefixed family of predefined game-state variables.
• DROD RPG — Tendry’s Tale (2008) is a parallel branch of the engine that extended the scripting language with RPG primitives: hit points, attack and defense values, equipment switching, keyed doors, gold, items, and runtime Build commands that let scripts place or remove tiles and entities.
• DROD 4.0 — Gunthro and the Epic Blunder (2012) and DROD 5.0 — The Second Sky (2014) further expanded the command set, monsters, and presentation features (custom images, cinematic controls, voice acting hooks). Engine 5.x remains the current baseline.

The DROD codebase, including the scripting interpreter, lives in the open-source CaravelGames/drod repository on GitHub, where it continues to receive maintenance and community contributions.

Design Philosophy

A Language Welded to a Game

DROD Scripting is one of the more extreme examples of a language whose design is inseparable from its host runtime. It exists to drive a turn-based, tile-based puzzle game with a fixed catalog of built-in concepts — rooms, turns, orbs, monsters, doors, characters, holds — and almost every command in the language references those concepts directly. There is no general arithmetic-expression syntax; there are no first-class functions; there is no module system. What there is, instead, is a curated set of verbs that map cleanly onto things a DROD puzzle designer needs to do.

This is by design. DROD architects are not, in general, professional programmers. They are puzzle designers. The scripting system was engineered so that the bar to entry is “open the editor, place a character, click ‘Add Command,’ choose from a dropdown” — not “learn a syntax.”

Authoring Is GUI-Driven

DROD scripts are not edited as plain-text source files. The DROD level editor presents a script as an ordered list of commands, with each command’s arguments configured via dialog widgets — target square, direction, speech text, event type, variable name, and so on. The script is stored inside the hold’s binary data file, not as a separate .dm or .script file. This makes DROD Scripting unusual among scripting languages: the canonical representation is structured data inside an editor, not text.

Turn-Based, Character-Scoped Execution

Scripts are owned by characters — NPC entities placed in rooms. Each character has its own ordered command list and its own instruction pointer. The runtime advances each character’s pointer turn by turn, resuming where it last paused. Holds can also define global scripts that run across the whole campaign, but the dominant pattern is per-room, per-character logic.

The execution model is closer in spirit to early adventure-game scripting (or to assembly with named labels and gotos) than to a high-level scripting language like Lua or Python. There are no function calls, no scopes, no closures — just a list of commands, labels, and conditional jumps.

How DROD Scripting Works

Anatomy of a Script

A script is a flat, ordered list of commands. The interpreter maintains an instruction pointer for each character. It runs the script once before the player’s first turn, then resumes from the saved pointer at the start of each subsequent turn until it encounters an action command (such as Move to or Strike orb at), at which point that character’s turn ends.

Commands fall into a few broad categories:

The same wait/test commands can be used two ways: as standalone instructions that pause the script until the condition is satisfied, or as the condition argument to If ... go to, in which case they evaluate immediately and either branch or fall through.

Events

The Wait for event command listens for a fixed catalog of game events. Examples include: all monsters killed, all tarstuff removed, bomb exploded, broken wall destroyed, roach egg hatched, evil eye woke, fuse burning, Halph entered room, monster stabbed, player activates orb, all trapdoors removed, player teeters on pit edge, Slayer entered room, serpent smashed, tar baby formed, tunnel, and wubba stabbed. Each of these maps to a moment in DROD’s puzzle simulation that an architect might want to react to.

Variables (DROD 3.0+)

Beginning with engine 3.0, scripts can declare named user-defined variables in addition to a family of predefined _-prefixed game-state variables. Variables, together with If ... go to, are how scripts express counting puzzles, multi-stage state machines, conditional unlocks, and similar logic. Variable expressions are still relatively constrained compared to a general scripting language — there is no rich expression grammar, but architects can compose simple comparisons and updates.

Coordinating Multiple Characters

Sophisticated DROD puzzles routinely place several invisible characters in a single room, each running its own script and coordinating with the others through events, variables, and Wait for ... conditions. This is the dominant pattern for building “custom” puzzle elements that go beyond what the engine ships with. Per-turn execution order is well-defined: in each turn the player and non-character monsters move first, then character scripts run (in placement order), then tar/mud growth, then fuses and bombs, then mimic/decoy placement.

Safeguards

Because architects can write loops with labels and Go to, the runtime includes an infinite-loop guard: if a single character cycles through more commands in one turn than its script contains, execution terminates and the incident is reportedly logged to an error file. This protects the puzzle simulation from a runaway script breaking the game loop.

Hold, Level, Room, Character

DROD content is organized hierarchically:

• Hold — a complete, shareable campaign. Holds are the unit of distribution; players download them via CaravelNet or the forum and play through them in the same engine that runs the official campaigns.
• Level — a named group of rooms within a hold.
• Room — a fixed grid of static elements (walls, doors, pits, orbs) and dynamic actors (monsters, characters, items).
• Character — a placed NPC entity that owns a script. Characters are the only carriers of scripts; they may be invisible, take any monster or character appearance, transform mid-script, branch on events, and act as room-level state machines.

A “scripted puzzle,” in DROD parlance, is therefore typically a room populated with one or more invisible characters whose scripts implement custom logic that the engine doesn’t natively offer.

DROD RPG and the Scripting Language

DROD RPG: Tendry’s Tale (2008), led by Mike Rimer, is a parallel branch of the DROD engine that grafts RPG mechanics onto the original puzzle framework — and the scripting language went along for the ride. RPG holds gain access to:

• Stats and resources as scriptable values: hit points, attack, defense, gold, keys, items.
• Equipment switching: scripts can change the player’s weapon or accessory, replacing classic DROD’s fixed sword.
• Keyed doors: the puzzle gates of classic DROD become coloured keyed doors driven through scripts.
• Build commands: scripts can place or remove tiles and entities at runtime, enabling shops, dynamic terrain, and reactive level layouts.
• Each Use and Question blocks for player-facing interactions.

The classic and RPG branches both live in the Caravel Games GitHub repository and continue to evolve in parallel.

The Editor and Distribution

DROD ships with a built-in graphical editor that handles room layout, monster placement, and scripting in a single integrated environment. Authoring a script involves selecting a character, opening its script panel, and adding commands from menus and dropdowns. Each command’s arguments — coordinates, directions, speech text, variable bindings, event types — are configured through dialog widgets. Speech commands include support for portraits, mood, and (in commercial releases) recorded voice acting hooks.

Holds are saved as binary files that bundle the room layouts, characters, and their scripts together. CaravelNet, the online service integrated into the games, provides hold sharing, leaderboards, hint integration, and achievements. The Caravel forum (forum.caravelgames.com) is the central community hub for hold sharing, beta testing, scripting help, and the long-running People’s Choice Hold Awards.

Current Relevance

DROD Scripting is still actively used. The current baseline engine, DROD: The Second Sky (5.x, 2014), continues to receive updates; DROD RPG 2 and additional Second Sky maintenance releases are in development as of the mid-2020s. The Caravel forum’s annual Hold of the Year awards have continued without interruption, and the GitHub repository sees ongoing commit activity.

Outside of DROD, the language has had no measurable adoption — and is not designed to. The official games run on Windows, macOS, and Linux, with distribution through Steam, GOG.com, and Caravel’s own site.

Why It Matters

DROD Scripting is a study in how far a deliberately tiny, deliberately game-specific language can go when paired with a dedicated community.

1. A language as part of a game. DROD Scripting is an example of a “language” that exists almost entirely as structured data inside an editor, with no canonical text representation. It demonstrates that a “language” can be defined by its command catalog and execution model rather than by its grammar.

2. Scripting as content authoring. DROD’s design treats scripting as a content-authoring tool — closer to a level editor than a programming environment — but with enough power that architects routinely build full custom puzzle systems on top of it. The line between “scripting” and “designing” effectively disappears.

3. Longevity through community. Like a few other small-community scripting systems (BYOND’s DM, the Source engine’s VScript, classic LucasArts SCUMM-style systems), DROD Scripting has survived for two decades not through commercial adoption but through a community of architects who keep producing new holds. The People’s Choice Hold Awards have run year after year, and the open-source engine ensures that holds authored in 2005 still run in 2026.

DROD Scripting will almost certainly never escape the DROD ecosystem. But within it, it is the medium through which one of the longest-running independent puzzle communities expresses itself — and a reminder that programming languages can be successful at very small scales, when fitted precisely to the work they are meant to do.