Package responsibilities

Architecture

JVMud is organized around compiler, engine, instance, transport, persistence, and mudlib responsibilities.

Responsibility Map

                 compiler
                     |
                     v
persistence <--> engine <--> mudlib
                     |
                  instance
                     |
                 transport
                     |
                   player

The diagram is a package and ownership map. It keeps JVMud-owned Java concepts separate from authored mudlib content and from player-facing connection mechanics.

Engine And Instance

The engine owns JVMud truth: world rules, canonical state machinery, Places, Entities, Locations, Links, Personas, Sessions, world time, and mudlib boundary events. A running instance owns one live hosted realization: booted mudlibs, loaded LPC objects, active Personas, lifecycle hooks, and mudlib routing.

Outer Responsibilities

Compiler

Turns LPC source into executable JVM code and supplies generated-code runtime support without defining engine ontology.

Mudlib

Supplies authored LPC world content: fiction, object behavior, commands, rules, presentation, and compatibility policy.

Persistence

Owns storage adapters for durable filesystem and database state so engine and instance code do not embed storage formats.

Transport

Owns human connection protocols such as Telnet: sockets, sessions, echo behavior, line I/O, and connection lifecycle.

Rule Of Thumb

If a concept defines what JVMud means by a world, it belongs near the engine. If it exists because a particular mudlib is running, it belongs near the instance. If it speaks a connection protocol, it belongs near transport. If it stores durable state, it belongs near persistence. If it is authored LPC content, it belongs in a mudlib.