|
|
|
|
@ -1,400 +0,0 @@
|
|
|
|
|
roadmap — order of operations
|
|
|
|
|
=============================
|
|
|
|
|
|
|
|
|
|
the master plan. what to build and in what order.
|
|
|
|
|
|
|
|
|
|
current state: the engine works. command system, game loop, mode stack,
|
|
|
|
|
combat (state machine + TOML moves), persistence (SQLite), editor mode,
|
|
|
|
|
IF/z-machine (dfrotz + embedded interpreter), terrain generation, content
|
|
|
|
|
loading — all built. what's unbuilt is the object model and everything it
|
|
|
|
|
enables: zones, things, inventory, containers, portals, verbs, multi-zone
|
|
|
|
|
worlds, rich NPCs, player building, and eventually the DSL.
|
|
|
|
|
|
|
|
|
|
the architecture-plan.txt priority list (items 1-8) is essentially done.
|
|
|
|
|
this plan picks up from there.
|
|
|
|
|
|
|
|
|
|
each phase builds on the one before it. the MUD stays functional
|
|
|
|
|
throughout — no phase leaves things broken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 1: object foundation
|
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
|
|
the base class everything inherits from. pure additive — nothing breaks,
|
|
|
|
|
existing tests keep passing.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- Object base class: name, location (Object | None), x (int | None),
|
|
|
|
|
y (int | None)
|
|
|
|
|
- contents property — reverse lookup: everything whose location is self
|
|
|
|
|
- can_accept(obj) method — default: False
|
|
|
|
|
- Entity inherits from Object instead of being a standalone dataclass
|
|
|
|
|
- Player, Mob unchanged externally — they still work exactly as now
|
|
|
|
|
|
|
|
|
|
the location field exists but isn't wired up yet. Entity still has x, y
|
|
|
|
|
from before, they just come through Object now. no behavioral change.
|
|
|
|
|
|
|
|
|
|
depends on: nothing
|
|
|
|
|
enables: everything below
|
|
|
|
|
refs: object-model.rst (hierarchy, containment mechanics)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 2: zones + overworld migration
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
the big migration. the overworld becomes a Zone object. players live
|
|
|
|
|
inside it. movement, rendering, persistence, mob spawning all update.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- Zone class: width, height, toroidal flag, terrain data, generator
|
|
|
|
|
- Zone.can_accept() returns True (zones accept everything)
|
|
|
|
|
- Zone.contents_at(x, y) for spatial queries
|
|
|
|
|
- convert current World terrain generator into Zone initialization — the
|
|
|
|
|
procedural overworld becomes a Zone instance loaded at startup
|
|
|
|
|
- Entity.location = zone (players and mobs live in the overworld zone)
|
|
|
|
|
- movement system goes through zone: wrapping, passability checks come
|
|
|
|
|
from player.location (the zone), not a global world reference
|
|
|
|
|
- viewport rendering reads terrain from player.location
|
|
|
|
|
- persistence adds zone name to save/load schema
|
|
|
|
|
- mob spawning sets location=zone
|
|
|
|
|
- remove world injection into command modules — commands access
|
|
|
|
|
player.location instead of module-level globals
|
|
|
|
|
- send_nearby_message uses zone.contents_at() instead of iterating the
|
|
|
|
|
global players dict
|
|
|
|
|
|
|
|
|
|
the global ``_world`` singleton goes away. ``players`` dict can stay for
|
|
|
|
|
session management but spatial queries go through zones.
|
|
|
|
|
|
|
|
|
|
migration strategy:
|
|
|
|
|
|
|
|
|
|
- keep World class temporarily as Zone's terrain generator
|
|
|
|
|
- migrate one system at a time (movement → rendering → persistence →
|
|
|
|
|
broadcasting) with tests green at every step
|
|
|
|
|
- object-model.rst "how existing code maps in" section traces each path
|
|
|
|
|
|
|
|
|
|
depends on: phase 1
|
|
|
|
|
enables: multi-zone, portals, interior spaces
|
|
|
|
|
refs: object-model.rst (Zone section, migration paths),
|
|
|
|
|
zones-and-building.rst (zone properties, wrapping, generators)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 3: things + inventory
|
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
|
|
items exist. you can carry them. the world has stuff in it.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- Thing class: description, portable flag (from Object)
|
|
|
|
|
- Entity.can_accept() allows portable Things (inventory)
|
|
|
|
|
- pick up / drop commands
|
|
|
|
|
- inventory command (list Things whose location is the player)
|
|
|
|
|
- items on the ground: Thing at location=zone, x=5, y=10
|
|
|
|
|
- look shows nearby items at your coordinates
|
|
|
|
|
- thing templates in TOML (content/things/) loaded at startup
|
|
|
|
|
- thing spawning: template → instance with location=zone
|
|
|
|
|
- viewport shows ground items (new symbol or marker)
|
|
|
|
|
- persistence: player inventory persists to SQLite; ground items respawn
|
|
|
|
|
from templates on restart
|
|
|
|
|
|
|
|
|
|
depends on: phase 2 (things need zones to exist in)
|
|
|
|
|
enables: equipment, crafting ingredients, quest items, loot
|
|
|
|
|
refs: object-model.rst (Thing section), things-and-building.rst (decorator
|
|
|
|
|
pattern, content format)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 4: containers + portals
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
|
|
nesting and zone transitions. both depend on Thing existing.
|
|
|
|
|
|
|
|
|
|
containers:
|
|
|
|
|
|
|
|
|
|
- Container class: capacity, closed (bool), locked (bool)
|
|
|
|
|
- Container.can_accept() checks capacity + open state
|
|
|
|
|
- put / get commands (move Thing into/out of Container)
|
|
|
|
|
- open / close commands
|
|
|
|
|
- lock / unlock (requires key item — first real item interaction)
|
|
|
|
|
- nested inventory display (backpack contains: ...)
|
|
|
|
|
|
|
|
|
|
portals:
|
|
|
|
|
|
|
|
|
|
- Portal class: target_zone, target_x, target_y, portable=False
|
|
|
|
|
- zone transition: step on portal → location changes to target zone,
|
|
|
|
|
position changes to target coords
|
|
|
|
|
- enter / go command for explicit portal use
|
|
|
|
|
- build at least one interior zone (tavern or test room) with hand-built
|
|
|
|
|
tile data from TOML
|
|
|
|
|
- two-way portals (portal in each zone pointing at the other)
|
|
|
|
|
- look shows portal presence, portal descriptions
|
|
|
|
|
|
|
|
|
|
depends on: phase 3 (portals and containers are Things)
|
|
|
|
|
enables: multi-zone world, interior spaces, locked doors, bags, keys
|
|
|
|
|
refs: object-model.rst (Container, Portal sections),
|
|
|
|
|
zones-and-building.rst (zone data format, hand-built zones)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 5: verbs + interaction
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
the layer that makes the world feel alive. drink from a fountain, pet a
|
|
|
|
|
mob, read a sign. anything can have verbs.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- @verb decorator on Object — any object in the world can have verbs
|
|
|
|
|
- @thing decorator for spawnable templates with verbs pre-attached
|
|
|
|
|
- verb resolution: "drink fountain" → find fountain at player's
|
|
|
|
|
coordinates → call its drink verb handler
|
|
|
|
|
- verb dispatch integrates with command system — verbs checked as
|
|
|
|
|
fallback after global commands fail to match
|
|
|
|
|
- content format: verbs defined in TOML alongside thing definitions,
|
|
|
|
|
or in python via the decorator
|
|
|
|
|
- default verbs: look at / examine (work on everything with a
|
|
|
|
|
description)
|
|
|
|
|
|
|
|
|
|
depends on: phase 4 (need objects with verbs to interact with)
|
|
|
|
|
enables: rich interaction, builder content, puzzle creation
|
|
|
|
|
refs: things-and-building.rst (@thing/@verb decorator system, full
|
|
|
|
|
PepsiCan example)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 6: multi-zone content + building
|
|
|
|
|
--------------------------------------
|
|
|
|
|
|
|
|
|
|
the world has places. builders can create more.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- zone loading from TOML files (hand-built zones with tile grids)
|
|
|
|
|
- hub / phone-switch zone with portals to different areas
|
|
|
|
|
- tutorial zone for new players
|
|
|
|
|
- tavern / social zone (interior, bounded, not toroidal)
|
|
|
|
|
- paint mode: admin tool for editing zone terrain tile-by-tile
|
|
|
|
|
- zone TOML export (runtime state → version-controlled files)
|
|
|
|
|
- spawn points per zone (where you appear on entry)
|
|
|
|
|
- zone-specific ambient messages
|
|
|
|
|
- per-zone mob spawning rules (what mobs live here, density, respawn)
|
|
|
|
|
|
|
|
|
|
depends on: phase 4 (portals connect zones)
|
|
|
|
|
enables: a world with actual geography, builder workflow
|
|
|
|
|
refs: zones-and-building.rst (zone format, paint mode, building tools,
|
|
|
|
|
portal network design)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 7: GMCP + rich client support
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
|
|
|
|
structured data for graphical MUD clients (Mudlet, Blightmud, etc.).
|
|
|
|
|
independent of the object model — can be done earlier if desired.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- GMCP option negotiation in telnet handshake (telnetlib3 supports this)
|
|
|
|
|
- Char.Vitals package: pl, stamina, max_stamina
|
|
|
|
|
- Char.Status package: flying, resting, mode, combat state
|
|
|
|
|
- Room.Info package: zone name, x, y, terrain type
|
|
|
|
|
- MSDP for real-time variable updates (client-side HP bars, gauges)
|
|
|
|
|
- map data for clients that support structured map rendering
|
|
|
|
|
|
|
|
|
|
telnetlib3 already handles the protocol layer. this phase is defining the
|
|
|
|
|
data packages and wiring them to game state changes.
|
|
|
|
|
|
|
|
|
|
depends on: nothing (can start anytime)
|
|
|
|
|
enables: rich MUD client experience alongside raw telnet
|
|
|
|
|
refs: DREAMBOOK.md (things to explore: GMCP, MSDP)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 8: NPC evolution
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
mobs become characters, not just combat targets.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- dialogue trees: TOML-defined, triggered by "talk to" or "ask" commands
|
|
|
|
|
- non-combat behaviors: patrol, wander, idle, shopkeeper, guard
|
|
|
|
|
- behavior trees or state machines defined in TOML
|
|
|
|
|
- mob reactions to verbs ("pet" the cat, "ask" the bartender about X)
|
|
|
|
|
- spawn/respawn system using location=None as template state (die →
|
|
|
|
|
location=None, timer → respawn at zone with fresh stats)
|
|
|
|
|
- mob schedules (bartender appears in tavern during the day, gone at
|
|
|
|
|
night)
|
|
|
|
|
- shopkeeper mobs (buy/sell interface using inventory system)
|
|
|
|
|
|
|
|
|
|
depends on: phase 5 (verbs for interaction), phase 6 (zones for mobs
|
|
|
|
|
to inhabit)
|
|
|
|
|
enables: living world, quests, commerce
|
|
|
|
|
refs: architecture-plan.txt (entity model section),
|
|
|
|
|
object-model.rst (location=None for templates/despawned)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 9: world systems
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
time, weather, seasons. the world breathes.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- game time cycle: ticks → hours → days → seasons
|
|
|
|
|
- time of day affects descriptions ("the tavern is dim in the evening
|
|
|
|
|
light" vs "sunlight streams through the windows")
|
|
|
|
|
- weather system: rain, wind, storms (per zone or global)
|
|
|
|
|
- weather affects gameplay: rain slows movement, storms block flying,
|
|
|
|
|
cold water is worse in winter
|
|
|
|
|
- seasonal terrain variation: snow in winter, flowers in spring, color
|
|
|
|
|
palette shifts
|
|
|
|
|
- ambient messages tied to time/weather ("a cold wind picks up")
|
|
|
|
|
|
|
|
|
|
depends on: phase 6 (zones with descriptions to vary)
|
|
|
|
|
enables: atmosphere, seasonal events, weather-dependent gameplay
|
|
|
|
|
refs: DREAMBOOK.md (seasons, weather, time of day)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 10: player creation + housing
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
|
|
|
|
players shape the world. the MOO dream.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- player-owned zones (personal rooms, houses, pocket dimensions)
|
|
|
|
|
- building commands: create zone, set dimensions, paint terrain, place
|
|
|
|
|
things
|
|
|
|
|
- in-world editing via editor mode (descriptions, verb scripts)
|
|
|
|
|
- player-created content stored in SQLite
|
|
|
|
|
- admin review + export to files (sqlite → TOML for version control)
|
|
|
|
|
- permissions: who can build, who can edit what, visitor access controls
|
|
|
|
|
- crafting system: combine things → new thing, recipes in TOML
|
|
|
|
|
- IF creation tools: use the IF primitives to build small adventures
|
|
|
|
|
from inside the MUD
|
|
|
|
|
|
|
|
|
|
depends on: phase 6 (zones), phase 5 (verbs), persistence
|
|
|
|
|
enables: the MOO vision — player-built, player-programmed world
|
|
|
|
|
refs: DREAMBOOK.md (user-created content, presence and community),
|
|
|
|
|
architecture-plan.txt (player-created content in sqlite,
|
|
|
|
|
engine/content boundary)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 11: the DSL
|
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
replace python callables with a scripting language writable from inside
|
|
|
|
|
the MUD. this is the hardest design challenge in the project.
|
|
|
|
|
|
|
|
|
|
build:
|
|
|
|
|
|
|
|
|
|
- language design: informed by what phases 1-10 needed to express
|
|
|
|
|
- interpreter/runtime: sandboxed, no file/network access
|
|
|
|
|
- content definitions gain ``body: dsl:script_name`` option alongside
|
|
|
|
|
``body: python:module.function``
|
|
|
|
|
- DSL scripts editable in-world via editor mode
|
|
|
|
|
- help system teaches the DSL from inside the MUD
|
|
|
|
|
- standard library: common verbs, triggers, conditions
|
|
|
|
|
- migration path: existing python handlers get DSL equivalents over time
|
|
|
|
|
|
|
|
|
|
defer specifics until phases 1-10 reveal exactly what the DSL needs to
|
|
|
|
|
express. the ecosystem research (dsls.md) catalogs prior art: MOO's
|
|
|
|
|
language, LPC, MUSH softcode.
|
|
|
|
|
|
|
|
|
|
depends on: everything above being stable
|
|
|
|
|
enables: non-programmers creating game content from a telnet session
|
|
|
|
|
refs: architecture-plan.txt (DSL section, content definition format),
|
|
|
|
|
docs/research/dsls.md (prior art)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
phase 12: horizons
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
things from the dreambook's "explore later" list. order is flexible —
|
|
|
|
|
tackle based on interest and what the world needs.
|
|
|
|
|
|
|
|
|
|
- web client: xterm.js terminal emulator pointed at telnet port. honor
|
|
|
|
|
the protocol even in the browser
|
|
|
|
|
- MCCP compression for bandwidth-heavy sessions
|
|
|
|
|
- inter-MUD communication (IMC2, I3)
|
|
|
|
|
- AI-driven NPCs: LLM-backed conversation, personality, memory
|
|
|
|
|
- alternate screen buffer: split views (map panel + text panel)
|
|
|
|
|
- sound via MSP or links
|
|
|
|
|
- procedural dungeon generation: zones with random layout per visit
|
|
|
|
|
- quest system: objectives, tracking, rewards, quest-giver NPCs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dependency graph
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
phase 1: object foundation
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 2: zones + migration
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 3: things + inventory
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 4: containers + portals
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 5: verbs + interaction
|
|
|
|
|
│ phase 7: GMCP (independent)
|
|
|
|
|
▼
|
|
|
|
|
phase 6: multi-zone content
|
|
|
|
|
│
|
|
|
|
|
├────────────────┐
|
|
|
|
|
▼ ▼
|
|
|
|
|
phase 8: NPCs phase 9: world systems
|
|
|
|
|
│ │
|
|
|
|
|
└───────┬────────┘
|
|
|
|
|
▼
|
|
|
|
|
phase 10: player creation
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 11: DSL
|
|
|
|
|
│
|
|
|
|
|
▼
|
|
|
|
|
phase 12: horizons
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
notes
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
|
|
**the phase 2 migration is the riskiest step.** it touches movement,
|
|
|
|
|
rendering, persistence, mob spawning, and message broadcasting. the
|
|
|
|
|
strategy is incremental: migrate one subsystem at a time, keep tests
|
|
|
|
|
green, keep the MUD playable. the object-model.rst doc has a detailed
|
|
|
|
|
"how existing code maps in" section for this.
|
|
|
|
|
|
|
|
|
|
**phase 7 (GMCP) floats.** it doesn't depend on the object model and
|
|
|
|
|
can be done whenever energy or interest is there. it's slotted at 7
|
|
|
|
|
because the data it reports (zone name, position, combat state) gets
|
|
|
|
|
richer as the object model matures, but basic vitals work anytime.
|
|
|
|
|
|
|
|
|
|
**phases 8-10 have some flexibility.** world systems (weather, time)
|
|
|
|
|
could come before NPC evolution. player creation could come before
|
|
|
|
|
either. the dependency shown is the tightest path — if housing needs
|
|
|
|
|
NPCs (shopkeepers, guards), then 8 before 10. if not, reorder freely.
|
|
|
|
|
|
|
|
|
|
**the DSL (phase 11) is intentionally last.** the architecture-plan.txt
|
|
|
|
|
says "defer it until we know exactly what it needs to express." phases
|
|
|
|
|
1-10 discover that organically.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
related docs
|
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
- ``DREAMBOOK.md`` — vision, philosophy, wild ideas
|
|
|
|
|
- ``docs/how/architecture-plan.txt`` — engine/content boundary, original
|
|
|
|
|
priority list (items 1-8 now complete)
|
|
|
|
|
- ``docs/how/object-model.rst`` — class hierarchy, containment, verbs,
|
|
|
|
|
migration paths
|
|
|
|
|
- ``docs/how/zones-and-building.rst`` — zone format, building tools,
|
|
|
|
|
paint mode, portal network
|
|
|
|
|
- ``docs/how/things-and-building.rst`` — @thing/@verb decorator system
|
|
|
|
|
- ``docs/how/combat.rst`` — combat system (built, referenced by phase 8)
|
|
|
|
|
- ``docs/how/commands.txt`` — command system (built, extended by new
|
|
|
|
|
phases)
|
|
|
|
|
- ``docs/research/dsls.md`` — scripting language catalog (phase 11)
|