Deploy LPC to Europe — Lars Pensjö 🇸🇪 (Chalmers University Gothenburg 1989), the Language That Invented Online Multiplayer, on EU Infrastructure in 2026

In 1989, the World Wide Web did not yet exist. Tim Berners-Lee would not publish his proposal for hypertext at CERN until the following year. Yet in Gothenburg, Sweden, a computer science student at Chalmers University of Technology named Lars Pensjö 🇸🇪 had already created something that enabled strangers across the internet to inhabit a shared virtual world in real time.

He called it LPMud — Lars Pensjö's Multi-User Dungeon. The language he designed to power it was LPC — Lars Pensjö's C. It was the first programming language purpose-built for internet-accessible multiplayer virtual environments, and it introduced architectural ideas — persistent objects, hot-reloadable code, sandboxed execution, capability-based security — that became central to cloud computing decades later.

Lars Pensjö and the LPMud Architecture

Lars Pensjö 🇸🇪 was a student at Chalmers University of Technology (Chalmers tekniska högskola) in Gothenburg, Sweden — one of Europe's foremost technical universities, founded in 1829, a member of the IDEA League alongside ETH Zürich 🇨🇭, TU Delft 🇳🇱, Imperial College London 🇬🇧, and ParisTech 🇫🇷.

Pensjö was an avid player of MUDs — Multi-User Dungeons — text-based adventure games accessible via Telnet in which players explored virtual rooms, fought monsters, and interacted with each other. The existing MUD implementations of the era (MUD1 by Roy Trubshaw 🇬🇧 and Richard Bartle 🇬🇧 at Essex University, AberMUD by Alan Cox 🇬🇧) had a critical limitation: adding new content required halting the server, modifying C source code, recompiling, and restarting. The game world was static between updates.

Pensjö designed LPMud and its scripting language LPC to solve this problem:

LPMud Architecture (Lars Pensjö 🇸🇪, Chalmers Gothenburg 1989):

  Game Driver (C, compiled)
  │  Network I/O — Telnet connections from players
  │  Scheduler — manages LPC object execution
  │  Interpreter — executes LPC bytecode
  │  Memory manager — handles LPC object lifecycle
  │
  Master Object (LPC)
  │  Controls what other objects can do
  │  Defines security model and capabilities
  │  Loaded at startup, governs all other objects
  │
  Mudlib (LPC objects)
  │  room.c — defines rooms
  │  player.c — defines player characters
  │  monster.c — defines NPCs
  │  weapon.c — defines items
  │  Each object: persistent state + callable methods

→ Hot-loading: new objects deployed WITHOUT server restart
→ Sandboxing: objects cannot call system(), exec(), or file I/O
   without explicit master-object permission
→ Persistence: object state survives across server cycles
→ Capability model: permissions granted per-object by master

The key insight was separation of the game driver from the game content. The driver — compiled C — handled network I/O, scheduling, and the LPC interpreter. Everything else — rooms, players, monsters, items, quests — was LPC code. Adding a new dungeon room meant uploading a new .c file and telling the driver to load it. No compilation. No restart. The world could grow while players were inside it.

The LPC Language

LPC is a C-like language with automatic memory management, designed for object-oriented programming in a persistent, sandboxed environment:

/* Example LPC object: a room (room.c) */
/* LPMud heritage from Lars Pensjö 🇸🇪 Chalmers 1989 */

inherit "/std/room";

void create() {
  set_name("Chalmers Computing Room");
  set_short("A sunlit room with terminals");
  set_long(
    "You are in a computing room at Chalmers University of Technology "
    "in Gothenburg, Sweden. Terminals line the walls. On one screen "
    "you can see the LPMud source code taking shape — Lars Pensjö "
    "is debugging the object persistence system, 1989."
  );

  /* Exits */
  add_exit("north", "/d/campus/corridor");
  add_exit("south", "/d/campus/lab");

  /* Items in the room */
  add_object("/obj/terminal", 3);
  add_object("/obj/coffee_mug", 1);
}

/* Called when a player looks at the room */
string query_long() {
  return ::query_long() + "\n" +
    "A note on the whiteboard reads: " +
    "'LPC 1.0 — persistent objects, hot loading'";
}

LPC's type system combines static typing with runtime flexibility:

/* LPC type system and control flow */

/* Basic types: int, float, string, object, array, mapping */
int    player_count = 0;
string welcome_msg  = "Welcome to EU-hosted LPMud";
mixed  dynamic_val;           /* Can hold any type */

/* Arrays */
string *languages = ({ "LPC", "C", "Swedish" });

/* Mappings (hash tables) */
mapping player_stats = ([
  "strength" : 10,
  "mana"     : 50,
  "gdpr_consent" : 1,    /* GDPR Art. 7 consent tracking */
]);

/* Object references */
object master = find_object("/secure/master");

/* Closures (function objects) */
function callback = (: write("Hello from " + $1 + "\n") :);

/* Control flow */
foreach (string lang : languages) {
  if (lang == "LPC") {
    call_other(master, "log", lang + " object loaded");
  }
}

DGD — Dworkin's Game Driver

The most technically sophisticated LPC implementation is DGD (Dworkin's Game Driver), written by Felix Croes 🇧🇪 (Belgium) beginning in 1990. DGD extended Pensjö's original design with capabilities that remain architecturally significant:

Atomic transactions: DGD supports transactional modification of objects. If an operation fails midway, all changes are rolled back — a property directly analogous to database ACID semantics, implemented in a game engine in 1990.

Snapshot persistence: DGD can dump its entire memory state to disk (a "statedump") and restore it on restart. The virtual world persists across server reboots. This is equivalent to a persistent memory model — the game driver as a distributed in-memory database with crash recovery.

Hot compilation: LPC objects can be recompiled and upgraded while the server runs. Existing instances of an object update to the new definition without restarting. This is live code replacement — a capability most production systems still treat as exotic.

Lightweight threads: DGD's execution model uses cooperative coroutines — each LPC call runs to completion before the scheduler moves to the next. This eliminates data races without locks, a design subsequently echoed in Node.js's event loop (2009) and Go's goroutines (2009).

/* DGD-specific: atomic function (transactional) */
/* Felix Croes 🇧🇪 Belgium, 1990 */

atomic void transfer_gold(object from, object to, int amount) {
  /* If any call_other fails, entire function rolls back */
  if (from->query_gold() < amount) {
    error("Insufficient gold");
  }
  from->add_gold(-amount);
  to->add_gold(amount);
  /* Both operations succeed or neither does */
}

/* DGD: object upgrading while running */
/* Old instances automatically migrate to new code */
void upgraded() {
  /* Called on existing instances when their code is recompiled */
  if (!query_property("migration_v2")) {
    set_property("migration_v2", 1);
    /* Migrate old state to new format */
  }
}

DGD is the runtime used by Skotos Tech (California) for historical roleplaying games, and by several EU-based MUD communities. It remains actively maintained and is available under the AGPL licence.

FluffOS and the Community

FluffOS is the most widely deployed LPC runtime, forked from MudOS (another LPMud derivative) and maintained by an international open-source community. FluffOS powers thousands of active MUD servers globally, including several based in Europe.

FluffOS compiles cleanly on Linux and produces a statically-linkable binary:

FROM debian:bookworm-slim AS builder

RUN apt-get update && apt-get install -y \
    build-essential \
    cmake \
    libssl-dev \
    libpcre3-dev \
    libmysqlclient-dev \
    libpq-dev \
    git \
    && rm -rf /var/lib/apt/lists/*

# Build FluffOS from source
RUN git clone https://github.com/fluffos/fluffos.git /fluffos
WORKDIR /fluffos
RUN cmake -DPACKAGE_DB=OFF . && make -j$(nproc)

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    libssl3 \
    libpcre3 \
    && rm -rf /var/lib/apt/lists/*

COPY --from=builder /fluffos/src/driver /usr/local/bin/lpc-driver
COPY mudlib/ /mud/
COPY config.cfg /mud/

WORKDIR /mud
EXPOSE 6969
CMD ["lpc-driver", "config.cfg"]

For DGD specifically, which has no external dependencies:

FROM debian:bookworm-slim AS builder

RUN apt-get update && apt-get install -y \
    build-essential \
    git \
    && rm -rf /var/lib/apt/lists/*

RUN git clone https://github.com/dworkin/dgd.git /dgd
WORKDIR /dgd/src
RUN make DEFINES="-DUINDEX_TYPE=unsigned -DUINDEX_MAX=UINT_MAX"

FROM debian:bookworm-slim

COPY --from=builder /dgd/bin/dgd /usr/local/bin/dgd
COPY dgd-mudlib/ /mud/
COPY mud.dgd /mud/

WORKDIR /mud
EXPOSE 6047
CMD ["dgd", "mud.dgd"]

LPC's Influence on Modern Architecture

LPC's 1989 design anticipated architectural patterns that became mainstream in the 2010s:

LPC (Lars Pensjö 🇸🇪, Chalmers 1989)
  │
  ├─ Persistent objects surviving restarts
  │   → Erlang/OTP (Ericsson 🇸🇪, 1987 → released 1998)
  │   → Akka actor model (Scala)
  │   → Durable objects (Cloudflare, 2021)
  │
  ├─ Hot code replacement
  │   → Erlang hot upgrades (release_handler)
  │   → Kubernetes rolling deployments
  │   → Next.js hot module replacement
  │
  ├─ Sandboxed execution (master object controls capabilities)
  │   → Java Security Manager (1995)
  │   → Node.js VM module (2011)
  │   → WebAssembly capability model (2019)
  │   → Deno permission system (2020)
  │
  ├─ Cooperative coroutines (no data races)
  │   → JavaScript event loop (Node.js 2009)
  │   → Go goroutines (2009)
  │   → Python asyncio (2014)
  │
  └─ Mudlib separation (driver vs. content)
      → Microservices architecture
      → Kubernetes operator pattern
      → Platform-as-a-Service (the pattern sota.io implements)

The capability-based security model that LPC's master object implements — granting specific permissions to specific objects rather than running everything as root — was theorised by Dennis Ritchie 🇺🇸 and Ken Thompson 🇺🇸 in the 1970s and implemented in production game servers by Pensjö in 1989.

EU Regulatory Angles

GDPR Art. 25 — Data Minimisation by Design: LPC's object model is explicitly stateful: each object holds exactly the state it declares. A player.c object contains only the fields defined by the mudlib programmer. There are no hidden framework states, no ORM shadow tables, no session stores invisible to the developer. GDPR Art. 25 requires data minimisation at design time — LPC's explicit object state model enables a developer to enumerate all PII fields and prove they are the only data stored.

GDPR Art. 17 — Right to Erasure: In DGD's persistent model, deleting a player object removes all associated state atomically. The statedump mechanism means the deletion is durable — no shadow copies in transaction logs. Implementing a compliant GDPR Art. 17 erasure procedure in an LPC-based system requires deleting a single object, which DGD can do transactionally.

NIS2 — Sandboxed Execution: The master object pattern — in which all LPC objects must request capabilities from a single trusted supervisor — implements a mandatory access control model equivalent to SELinux or AppArmor at the application level. LPC objects cannot open network connections, read files, or execute system commands without explicit master-object approval. NIS2 Art. 21 requires appropriate access control for critical services; LPC's architecture enforces it at the language runtime level.

EU AI Act Art. 13 — Transparency: LPC game logic is plaintext .c files interpreted at runtime. There are no compiled binaries obscuring business logic. An LPC-based decision system is auditable by reading its source files — a property directly relevant to EU AI Act Art. 13 requirements for high-risk AI systems to document their decision-making logic.

The Scandinavian Online Computing Cluster

LPMud and LPC emerged from a Nordic university tradition that produced significant contributions to networked computing:

Nordic Internet Computing Heritage (1980s–1990s):

  Chalmers University of Technology 🇸🇪 (Gothenburg)
  │  Lars Pensjö → LPMud/LPC (1989) — first internet multiplayer
  │  IDEA League: ETH Zürich 🇨🇭 / TU Delft 🇳🇱 / Imperial 🇬🇧 / ParisTech 🇫🇷
  │
  KTH Royal Institute of Technology 🇸🇪 (Stockholm)
  │  Internet infrastructure research
  │  Swedish Internet Exchange (Netnod, 1996)
  │
  Uppsala University 🇸🇪
  │  Lysator Academic Computer Society (1973)
  │  Project Runeberg: Nordic digital literature archive
  │  Hosted early Swedish internet nodes
  │
  University of Oslo 🇳🇴
  │  Simula (Dahl + Nygaard, 1967) — first OOP language
  │  Jon Postel collaboration — DNS for .no
  │
  DTU (Technical University of Denmark) 🇩🇰
  │  DIKU (Copenhagen) — early internet research
  │  DIKU MUD (1991) → EverQuest, World of Warcraft lineage
  │
  Ericsson 🇸🇪 (Stockholm)
  │  Erlang (1987) — concurrent fault-tolerant systems
  │  Parallel to LPMud: both solving distributed persistence

→ Sweden joined EU: 1995. All universities above are EU-funded
   through Horizon Europe and national research councils.

Felix Croes 🇧🇪 (Belgium) — author of DGD — represents the EU cross-border open-source collaboration that LPC enabled. A Belgian developer extended a Swedish student's game engine, and the result is still running EU-hosted game servers 35 years later.

Deploy LPC to sota.io

# LPC game server (DGD) on EU infrastructure
# Lars Pensjö 🇸🇪 Chalmers 1989 / Felix Croes 🇧🇪 DGD

FROM debian:bookworm-slim AS builder

RUN apt-get update && apt-get install -y \
    build-essential git \
    && rm -rf /var/lib/apt/lists/*

RUN git clone https://github.com/dworkin/dgd.git /dgd \
    && cd /dgd/src \
    && make

FROM debian:bookworm-slim

COPY --from=builder /dgd/bin/dgd /usr/local/bin/dgd

WORKDIR /app

# DGD mudlib (your LPC objects)
COPY mudlib/ ./mudlib/
COPY kernel/  ./kernel/
COPY mud.dgd  .

EXPOSE 6047
CMD ["dgd", "mud.dgd"]

// mud.dgd — DGD configuration
{
    telnet_port     = ([ "*": 6047 ]);
    binary_port     = ([ ]);
    directory       = "/app";
    modules         = ({ });
    users           = 40;
    editors         = 4;
    ed_tmpfile      = "/tmp/ed";
    swap_file       = "/tmp/swap";
    swap_size       = 4096;
    swap_cache      = 256;
    sector_size     = 512;
    swap_fragment   = 4096;
    static_chunk    = 64512;
    dynamic_chunk   = 32768;
    dump_file       = "/app/snapshots/state.dgd";
    dump_interval   = 3600;    /* Snapshot every hour */
    hotboot         = ({ "/kernel/sys/auto" });
}

# sota.yaml
service:
  name: lpc-mud-server
  runtime: docker
  region: eu-central-1
  port: 6047

storage:
  type: persistent
  path: /app/snapshots
  size: 1Gi

database:
  type: postgres
  version: "17"
  size: small

env:
  LPC_REGION: EU
  GDPR_DATA_RESIDENCY: DE
  DGD_DUMP_INTERVAL: "3600"

# Deploy LPC/DGD to EU infrastructure
sota deploy --region eu-central-1

# With persistent storage for DGD snapshots
sota deploy --region eu-central-1 --with-storage --with-postgres

# Check deployment status
sota status
sota logs --tail 100

DGD's single-binary deployment — no JVM, no Node modules, no Python packages — means a container image under 20MB. The persistent snapshot mechanism means game state survives container restarts, aligned with sota.io's persistent storage volumes. EU data residency (German data centres) satisfies GDPR Art. 46 data transfer restrictions for any user-identifiable player data stored in LPC objects.

See Also

• Deploy Erlang to Europe — Ericsson 🇸🇪 (Stockholm, 1987). Erlang and LPC were developed in Sweden at almost the same time (1987/1989), both solving persistent concurrent state. Erlang's actor model and LPC's object persistence model are architectural cousins — one in telecom, one in gaming.
• Deploy Simula to Europe — Ole-Johan Dahl 🇳🇴 + Kristen Nygaard 🇳🇴 (Oslo, 1967). LPC's object model descends directly from Simula's class/object distinction. Pensjö's persistent LPC objects are Simula objects with network presence and automatic persistence.
• Deploy Occam to Europe — Tony Hoare 🇬🇧 (Oxford, CSP). LPC's cooperative coroutine model — no shared state, message-based interaction — implements the same principles as CSP and Occam, arrived at independently from a game engineering perspective.
• Deploy GNU Guile/Scheme to Europe — Guile's embedded scripting model (Scheme as extension language for C programs) parallels LPC's role: a safe, sandboxed language embedded in a compiled driver to allow hot-loading of application logic.
• All languages on sota.io

Why sota.io for LPC Deployments

sota.io is the EU-native PaaS for developers who need European infrastructure — not as an afterthought, but as a technical requirement.

LPC's design philosophy — explicit state, sandboxed execution, hot-reloadable code, persistent objects — maps naturally onto modern cloud patterns. DGD's snapshot mechanism and transactional object model are ahead of their time. Deploying DGD on sota.io's EU infrastructure gives you persistent storage volumes for statedumps, managed PostgreSQL for structured data, and German data centres for GDPR compliance — all without configuring Kubernetes or managing servers.

Lars Pensjö designed LPC in 1989 at Chalmers University in Gothenburg so that a virtual world could grow without ever going offline. That same property — continuous availability, live update, persistent state — is what modern cloud infrastructure attempts to provide. sota.io brings the language that invented it to EU infrastructure.

# Deploy LPC/DGD to EU — the language that
# invented online multiplayer in 1989.
sota deploy --region eu-central-1

LPC was designed by Lars Pensjö 🇸🇪 at Chalmers University of Technology in Gothenburg, Sweden in 1989. DGD (Dworkin's Game Driver) was written by Felix Croes 🇧🇪 (Belgium) beginning in 1990. FluffOS is maintained by an international open-source community. Chalmers University of Technology is a member of the IDEA League of European technical universities.