LPC

LPC — short for Lars Pensjö C — is an object-oriented programming language derived from C, created in 1989 by Swedish programmer Lars Pensjö to power LPMud, his family of text-based multi-user dungeons. LPC was designed with an unusual goal: to let ordinary players, not just systems programmers, build the game world. By embedding a safe, interpreted, C-like language inside a running game server, Pensjö made it possible for volunteer “wizards” to add rooms, weapons, monsters, and entire quests to a live virtual world without ever crashing it. The result was one of the most influential domain-specific languages in the history of online gaming, and the architecture it pioneered — a virtual machine “driver” hosting a framework “mudlib” — still defines how LPMud-style games are built today.

History and Origins

LPC was born from a gameplay problem. In the late 1980s, Lars Pensjö — then a student at Chalmers University of Technology in Gothenburg, Sweden — was an avid player of early multi-user dungeons such as TinyMUD and AberMUD. He wanted to create a world that combined the open-ended flexibility of TinyMUD with the adventure-game style of AberMUD, but he did not want sole responsibility for designing and maintaining all of its content. As he later put it, “I didn’t think I would be able to design a good adventure. By allowing wizards coding rights, I thought others could help me with this.”

His solution was to invent a new programming language that people with minimal coding experience could use to extend the game. That language was LPC, and the game engine that ran it was LPMud. Pensjö launched Genesis in April 1989 as the first LPMud and the first implementation of LPC, a world in which trusted players could write their own objects in the new language.

A critical early design decision came at the suggestion of fellow programmer Lennart Augustsson, who persuaded Pensjö to build a virtual machine to interpret LPC code rather than compiling and running it natively. This VM — known as the driver — managed execution and provided operating-system-like services, and crucially it could protect the server from runaway player code such as infinite loops or unbounded recursion. That insulation is what made open, community-driven world-building safe enough to be practical.

Design Philosophy

LPC reflects a few clear and pragmatic priorities, all flowing from its purpose as a world-building language for shared, always-on games:

• Approachable, C-like syntax. LPC borrows C’s curly-brace syntax, control structures, and general feel so that anyone who had seen C could become productive quickly, while hiding the dangerous parts (manual memory management, raw pointers) behind a managed runtime.
• Safety in a multi-user, untrusted environment. Because player-written code runs inside a live, persistent server shared by many users, the driver sandboxes execution, enforces resource limits, and gracefully handles errors so one buggy object cannot take the whole game down.
• Separation of engine and content. LPMud splits cleanly into the driver (the LPC interpreter/VM, written in C or C++) and the mudlib (the game framework, written in LPC itself). A single driver can host many different mudlibs, and game designers work almost entirely in LPC.
• Objects as the unit of the world. Everything in the game — a room, a sword, a dragon, a player — is naturally modeled as an LPC object, making the object model central rather than incidental.

Key Features

LPC blends procedural C-style programming with an object model tuned for game worlds. Its most distinctive features include:

• Blueprints and clones. LPC uses a prototype/blueprint object model rather than classic classes. A source file defines a blueprint object — analogous to a class — and the driver can produce many clones of it. A single sword file becomes hundreds of individual sword objects in the world, each with its own state.
• Built-in high-level data types. Beyond C’s primitives, LPC provides first-class arrays, mappings (associative arrays/dictionaries), and a dynamic mixed type that can hold any value. Mappings can be multi-dimensional and combined with operators, making them a workhorse for game data.
• Efuns and simul-efuns. External functions (efuns) are primitives provided directly by the driver and impossible to write in LPC itself. A simulated efun (simul_efun or sefun) is written in LPC and registered so that it appears alongside the built-in efuns in every object’s namespace, letting each game extend the standard library.
• The master object and applies. Each game has a special master object, the first object the driver loads, which configures the runtime — telling the driver where the simul_efun object lives, what to preload, and how to handle security. The driver communicates with LPC objects through applies: well-known function names the driver calls at specific moments (such as when an object is created or a command is issued).
• Closures and lambdas. LPC supports closures that reference executable code — other functions, efuns, or, in drivers like LDMud, code compiled at runtime as lambda functions — enabling a degree of functional and metaprogramming flexibility unusual for a C derivative of its era.
• Inheritance. Objects can inherit from other LPC files, letting the mudlib build hierarchies (for example, a base “living thing” inherited by both players and monsters).

A small flavor of LPC, modeling a simple room:

1
2
3
4
5
6
7

inherit "/std/room";

void create() {
    set_short("a quiet clearing");
    set_long("Sunlight filters through the trees into a small clearing.\n");
    add_exit("north", "/world/forest/path");
}

Drivers and Mudlibs

Because LPC has no single official implementation, its history is really the history of its drivers — the competing C/C++ virtual machines that interpret LPC — and the mudlibs built on top of them. The major branches include:

This proliferation means “LPC” varies somewhat between drivers — closures, type-checking strictness, and available efuns differ — but the core object/blueprint model and C-like syntax are common across them.

Evolution

LPC’s evolution has tracked its drivers. The original Pensjö line established the language and the driver/mudlib architecture. MudOS (1992) pushed it forward with networking and compilation features and spawned framework-oriented mudlibs such as TMI, which reframed the mudlib as a set of examples to extend rather than a finished game. The Amylaar driver and its successor LDMud focused on cleaning up and stabilizing the gamedriver, eventually accumulating enough original work to stand as a distinct implementation. Most recently, FluffOS has carried the MudOS lineage into the modern era, adding UTF-8 string handling, encrypted and WebSocket connections, and database integration, with releases continuing into 2025.

LPC also escaped its origins entirely. In 1994, programmers at Lysator in Linköping wrote a clean, GPL-licensed reimplementation of the LPC virtual machine called µLPC (micro LPC), extracting the language from the MUD context to use as a general rapid-prototyping tool. In 1996 it was renamed Pike, which went on to become a general-purpose dynamic programming language — LPC’s most prominent descendant.

Current Relevance

LPC remains a living language within its niche. The MUD community, while far smaller than in the 1990s, is still active, and long-running games such as Genesis, Discworld MUD, BatMUD, and Lost Souls continue to be developed in LPC by volunteer coders. The two principal drivers — FluffOS and LDMud — are both maintained, with FluffOS in particular seeing regular releases and modern feature work. New mudlib development and new games still happen, and LPC continues to serve precisely the audience Pensjö designed it for: people who want to build rich, persistent, multi-user text worlds without writing a game engine from scratch.

Why It Matters

LPC’s significance reaches well beyond the games it was written for. It was an early and remarkably successful example of an embedded scripting language with a sandboxed virtual machine — letting untrusted users safely extend a live, shared application — years before such architectures became commonplace in web servers, browsers, and game engines. Its clean split between a fast systems-language driver and a high-level mudlib prefigured the engine/scripting divide that modern game development takes for granted. And through Pike, LPC’s runtime ideas found a second life in general-purpose computing. For a language created by a student to share the work of building an adventure game, LPC left a deep and lasting mark on how interactive, programmable virtual worlds are made.