Key Concepts

What we mean by MUD

A MUD is an interactive, multiplayer, text-centric game set in a persistent, temporal, player-present world.

This is JVMud's design commitment. Each part matters: there is a game to play, a shared world to inhabit, and a particular place within it from which each player acts and perceives.

The eight pillars

Game

The world exists to be played. Rules, challenges, goals, discovery, and progression give actions meaning. JVMud supplies the machinery for running the game; the mudlib authors its rules and fiction. Combat systems, character classes, and victory conditions belong to that authored layer.

Text

Players perceive and manipulate the world through text. Descriptions, dialogue, and commands are part of the game itself. JVMud separates connections and text delivery from the mudlib's presentation, so the game controls what its world says. Structured client messages can accompany that text.

Interactive

Players can affect the world (through their Personas), and the world can affect players. A command can move an Entity, change an object, or provoke a response. JVMud routes input into mudlib behavior and provides world operations and perception delivery. The mudlib decides what an action means and whether it succeeds.

Multiplayer

Multiple players inhabit the same world simultaneously. Their actions meet in shared state. Within each running mudlib, JVMud serializes player input, callbacks, administration, and ticks on an execution queue, giving changes an ordered execution context. Separate mudlibs have independent runtime state.

World

The game has a concrete virtual domain. JVMud models it with Places, traversable Links, and Entities. A situated Entity has one immediate Location: a Place or another Entity. That supports a sword in a bag carried by a character, as well as movement between rooms. The engine maintains spatial and containment rules; the mudlib gives those structures their meaning.

Persistence

The world and its state endure independently of any one player's connection. World continuity and durable storage are related but distinct: a world can continue after a player leaves, while selected state is saved and restored across restarts. JVMud supplies storage adapters; the mudlib determines what game state to preserve. Persistence does not require every live value to survive forever, and it can coexist with reboots and resets.

Temporality

The world changes through time. A storm can arrive, a torch can burn down, or a creature can act while a player waits. Each JVMud-hosted mudlib has its own clock and scheduled work. Recurring ticks and delayed callbacks provide timing; the mudlib supplies the events and their consequences. Active time is a different concern from saving state.

Presence

A player experiences the game from within its world through a located Persona. Location shapes what can be perceived and which interactions are nearby, making exploration, concealment, and surprise possible.

JVMud distinguishes the Player, the Session carrying the connection, and the Persona providing an in-world perspective. A durable account is another mudlib-defined concept. Keeping these roles distinct lets a game decide what happens when someone disconnects, reconnects, or controls a different character.

An LPMud engine by design

JVMud specifically targets LPC-authored games in the LPMud tradition. The mudlib is the source and content that define a game: its objects, commands, rules, and presentation. JVMud compiles LPC to JVM bytecode and loads it as live objects.

Live development is a key innovation of LPMud: separating the driver from LPC-authored game behavior lets authors rewrite, recompile, and reload that behavior while the game continues. In classic DikuMUD-derived servers such as stock CircleMUD, changing behavior written into the C server requires recompiling and restarting that server. LPC places much of the game's behavior in a separately loadable mudlib.

JVMud carries that live-development tradition forward. Reloading code and migrating existing object state are separate operations; the lifecycle and compatibility contracts determine the behavior available to a particular mudlib.

JVMud is specific about its language and game model while remaining independent of any one legacy LP dialect. It gives compatibility an explicit home in profile configuration, lifecycle mappings, aliases, and dedicated mudlib shims. A legacy init method can be selected for an interaction-scope event; a simulated efun becomes a mudlib-global function, or mfun, supplied by a configured object.

This keeps the distinction between a conventional room object and a Place, or a legacy player object and the Player/Session/Persona roles. Compatibility preserves useful mudlib conventions without making each convention a universal engine rule. The Glossary explains those correspondences in detail.

Separation of concerns

Each part of JVMud owns a specific responsibility. These boundaries make it possible to reason about the code, adapt existing mudlibs, and change one facility without spreading its assumptions throughout the system.

Execution

The application owns startup, public endpoints, administrator authority, and worker supervision. It can run with zero mudlibs. Each mudlib runs in its own worker JVM; its instance assembles the runtime, boots authored content, and orders execution. The world model owns Places, Entities, movement, and time. A World is part of a mudlib, and a mudlib's lifetime is distinct from the application's.

Separate workers provide process fault isolation. They retain the host account's operating-system permissions, so that isolation is not an OS security sandbox.

Language

The language subsystem compiles and executes LPC and exposes engine operations through efuns. The mudlib defines what the game does with those operations. The compiler need not know the rules of a particular guild, and transport need not know how a combat command succeeds.

Communication

Communication handles sockets, Telnet, protocol messages, text output, and administration interfaces. Player input is delivered to the instance for mudlib interpretation. Keeping transport separate from game rules allows connection handling and world behavior to evolve independently.

Storage

Storage owns durable representations and filesystem or database adapters. Execution uses those services without taking ownership of their formats. A network Session, a live Entity, and a saved profile have different lifetimes, even when a legacy mudlib represents them through one LPC object.

These responsibilities are reflected in the Java packages language, execution, communication, and storage. The manual's architecture chapter follows them into the implementation.

The design in play

Consider a player typing north. Transport receives a line of text. The instance queues it, and the mudlib interprets it as a request to travel. Game policy decides whether the route is available; world operations update the Persona's Location through a Link. The mudlib describes the destination and responds to relevant perception events.

A delayed event may then change that Place, and a later save may preserve selected state. Command interpretation, movement, time, perception, and storage cooperate, with each retaining a clear responsibility.

The code is the product

Reading, learning from, extending, and contributing to JVMud's source are primary ways of using it. Clear names, deliberate boundaries, documentation, and consistent implementation are product qualities. Correct behavior and understandable code belong together.

Continue with the manual's full philosophy, the lifecycle reference, or the Java API.