Add zones and building doc
This commit is contained in:
parent
01d5848178
commit
da809bea31
GPG key ID:
22B5C6D66A38B06C
1 changed files with 596 additions and 0 deletions
596
docs/how/zones-and-building.rst
Normal file
596
docs/how/zones-and-building.rst
Normal file
|
|
@ -0,0 +1,596 @@
|
|||
zones and building — from grids to worlds
|
||||
=========================================
|
||||
|
||||
a design doc. captures the vision for how players and builders create,
|
||||
connect, and inhabit spaces in the MUD. born from a riffing session, fed
|
||||
by research into how other engines handle this. living document — update
|
||||
as decisions get made and things get built.
|
||||
|
||||
see also: ``things-and-building.rst`` (item/verb system),
|
||||
``architecture-plan.txt`` (engine/content boundary),
|
||||
``prompt-system.txt`` (modal prompts).
|
||||
|
||||
|
||||
the core idea — everything is a zone
|
||||
--------------------------------------
|
||||
|
||||
a zone is a rectangular grid of tiles. it has dimensions, a palette, and
|
||||
tile data. that's it. everything is a zone.
|
||||
|
||||
- the procedural overworld? a zone with a generator (perlin noise)
|
||||
- a hand-built treehouse? a zone with tile data from a file
|
||||
- a single room (office, closet)? a small zone
|
||||
- a dungeon? a zone with procedural guts
|
||||
- the flower you spawn in? a tiny zone
|
||||
|
||||
the differences between zones are properties, not types:
|
||||
|
||||
**wrapping**
|
||||
does the zone loop? options: toroidal (wraps both axes, like a sphere
|
||||
— walk far enough and you're back), cylindrical (wraps one axis),
|
||||
bounded (hard edges, you hit a wall or void).
|
||||
|
||||
**generator**
|
||||
how tiles get filled. ``none`` means blank canvas (you paint it).
|
||||
``perlin`` means procedural terrain from a seed. ``file`` means tile
|
||||
data loaded from a TOML. generators and hand-placed tiles can coexist
|
||||
— generate a base, then paint over specific areas.
|
||||
|
||||
**dimensions**
|
||||
5x5, 100x50, 1000x1000. whatever the space needs.
|
||||
|
||||
**palette**
|
||||
what each symbol means. char + name + color + properties (passable,
|
||||
movement cost, opacity, etc). every zone has a palette. zones can
|
||||
share palettes or define their own.
|
||||
|
||||
|
||||
zone data format
|
||||
-----------------
|
||||
|
||||
the web editor already saves something close to this. extend it with
|
||||
zone metadata and portal definitions.
|
||||
|
||||
::
|
||||
|
||||
[zone]
|
||||
name = "treehouse"
|
||||
description = "a treehouse nestled in the canopy of an ancient oak"
|
||||
wrapping = "bounded"
|
||||
spawn = [10, 7]
|
||||
|
||||
[map]
|
||||
width = 20
|
||||
height = 15
|
||||
data = """
|
||||
..oooo..TTT.........
|
||||
..o..o..TTT.........
|
||||
..o..o..TTT.........
|
||||
..oooo....T.........
|
||||
..........T.........
|
||||
........+.T.........
|
||||
..........T.........
|
||||
..........TTTTT.....
|
||||
................~~~~
|
||||
................~~~~
|
||||
....................
|
||||
....................
|
||||
....................
|
||||
....................
|
||||
....................
|
||||
"""
|
||||
|
||||
[palette]
|
||||
entries = """
|
||||
o|wall|#8b4513|solid
|
||||
.|floor|#d2b48c|passable
|
||||
T|leaves|#0a5f0a|passable
|
||||
~|water|#2244aa|solid
|
||||
+|door|#c8a456|passable
|
||||
"""
|
||||
|
||||
[[portals]]
|
||||
x = 10
|
||||
y = 14
|
||||
target = "zone:forest_path:20,5"
|
||||
label = "a rope bridge stretches into the canopy"
|
||||
|
||||
[[portals]]
|
||||
x = 10
|
||||
y = 0
|
||||
target = "overworld:450,300"
|
||||
label = "a ladder descends to the ground far below"
|
||||
|
||||
zones live in ``content/zones/``. loaded at startup like mobs and
|
||||
commands. hot-reloadable via ``reload``.
|
||||
|
||||
|
||||
player location model
|
||||
----------------------
|
||||
|
||||
today a player is ``(x, y)`` on the overworld. with zones, a player is
|
||||
either on the overworld OR in a zone.
|
||||
|
||||
conceptually: ``(zone_name, x, y)`` where ``zone_name`` is ``None`` for
|
||||
the overworld. the viewport, movement, look — all the same mechanics,
|
||||
just reading from a different grid.
|
||||
|
||||
portals are tiles with a target. step on one, you transition. your
|
||||
location changes from ``(treehouse, 10, 14)`` to
|
||||
``(forest_path, 20, 5)``. the viewport redraws with the new zone's
|
||||
tiles and palette.
|
||||
|
||||
open question: do portals auto-trigger (step on tile = transition) or
|
||||
require explicit action (``enter``, ``use door``)? could depend on the
|
||||
portal — a path auto-triggers, a locked door requires a key and
|
||||
``open door`` + ``enter``. the portal definition could specify this::
|
||||
|
||||
[[portals]]
|
||||
x = 5
|
||||
y = 3
|
||||
target = "zone:basement:5,0"
|
||||
trigger = "auto" # step on it and you go
|
||||
label = "stairs descend into darkness"
|
||||
|
||||
[[portals]]
|
||||
x = 12
|
||||
y = 7
|
||||
target = "zone:vault:0,0"
|
||||
trigger = "manual" # requires 'enter' command
|
||||
label = "a heavy iron door"
|
||||
requires = "iron_key" # item check (future)
|
||||
|
||||
|
||||
the flower spawn
|
||||
-----------------
|
||||
|
||||
new player experience. you wake up inside a sealed flower.
|
||||
|
||||
the flower is a tiny zone, maybe 7x7. petals surround you. the
|
||||
description mentions perfume, texture on your hands, dim light filtering
|
||||
through. you can look around but every direction is sealed — petal walls.
|
||||
|
||||
any force command (push, kick, punch, pull) opens the flower. the petal
|
||||
tiles change (solid → passable, or the zone swaps entirely), you "fall"
|
||||
— a text transition, maybe a brief animation of symbols scrolling — and
|
||||
land in the treehouse zone.
|
||||
|
||||
the treehouse is the real starting area. hand-built, 20x15 or whatever
|
||||
feels right. has a few things to interact with, maybe a note or a simple
|
||||
puzzle. eventually you find the way down (a portal) and land on the
|
||||
overworld. infinite procedural landscape in every direction.
|
||||
|
||||
tutorial funnel: tiny space → medium space → infinite space.
|
||||
|
||||
::
|
||||
|
||||
flower (7x7, sealed)
|
||||
↓ player breaks out
|
||||
treehouse (20x15, hand-built)
|
||||
↓ portal (ladder, rope, etc)
|
||||
overworld (1000x1000, procedural)
|
||||
↓ portals to other zones
|
||||
dungeons, houses, other players' creations...
|
||||
|
||||
|
||||
creating zones — three workflows
|
||||
----------------------------------
|
||||
|
||||
all three produce the same format. interchangeable.
|
||||
|
||||
workflow A: web editor
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
open the map editor in a browser. paint tiles, define palette, set
|
||||
dimensions. save as TOML. drop the file in ``content/zones/``. reload
|
||||
in the MUD (or restart). the zone exists.
|
||||
|
||||
the web editor is not special — it's just faster for large-scale work.
|
||||
photoshop vs MS paint. good for: laying out a big area, precise pixel
|
||||
work, working offline, iterating visually.
|
||||
|
||||
workflow B: in-game commands
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
@new-zone jareds-house 100 50
|
||||
|
||||
creates a blank bounded zone. you're placed in the center. the viewport
|
||||
shows void/empty tiles. now you build.
|
||||
|
||||
::
|
||||
|
||||
@new-zone the-wilds 500 500 --wrap
|
||||
|
||||
creates a toroidal zone. walk far enough and you loop.
|
||||
|
||||
::
|
||||
|
||||
@new-zone dungeon-3 40 40 --gen perlin
|
||||
|
||||
creates a zone with procedural terrain. paint over specific parts.
|
||||
|
||||
workflow C: paint mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
this is the one that buzzes. push into paint mode like editor mode or IF
|
||||
mode. your ``@`` becomes a cursor. movement works freely — no passability
|
||||
checks, you float over everything.
|
||||
|
||||
two states within paint mode:
|
||||
|
||||
**survey** (default)
|
||||
move around, look at things, nothing changes. scouting.
|
||||
|
||||
**painting**
|
||||
every tile you leave behind gets stamped with your brush. walk east
|
||||
5 tiles, leave 5 walls behind you.
|
||||
|
||||
toggle with ``p``. status line shows state::
|
||||
|
||||
[paint: . floor] survey
|
||||
[paint: o wall] PAINTING
|
||||
|
||||
change brush: type the symbol character. type ``o`` and your brush is
|
||||
now wall. type ``.`` for floor. type ``~`` for water. single-char input
|
||||
sets the brush — no ambiguity because you're in a special mode where
|
||||
normal commands don't apply.
|
||||
|
||||
or explicit: ``b o`` for brush=wall. both work.
|
||||
|
||||
you could even render as the brush symbol instead of ``@`` when painting.
|
||||
you see an ``o`` moving around leaving ``o``'s behind it.
|
||||
|
||||
entering and exiting::
|
||||
|
||||
@paint enter paint mode (survey by default)
|
||||
p toggle painting on/off
|
||||
o set brush to 'o' (wall)
|
||||
n/s/e/w/ne/etc move (and paint if painting)
|
||||
@paint exit paint mode (or :q, or @done)
|
||||
|
||||
workflow D: @dig (expanding the canvas)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
not room-linking like traditional MUDs. you're extending the zone's tile
|
||||
grid itself.
|
||||
|
||||
::
|
||||
|
||||
@dig 5 e zone grows 5 tiles east (new tiles are void)
|
||||
@dig 10 s zone grows 10 tiles south
|
||||
@dig n grow 1 tile north (default)
|
||||
|
||||
new space is void/empty. paint it into existence.
|
||||
|
||||
this means zones aren't fixed-size — they grow as you build. start with
|
||||
a 1x1 zone and @dig your way to a mansion.
|
||||
|
||||
|
||||
materials and palettes
|
||||
-----------------------
|
||||
|
||||
every symbol needs at minimum: char, name, color. that's the palette.
|
||||
|
||||
::
|
||||
|
||||
[palette]
|
||||
entries = """
|
||||
.|floor|#d2b48c|passable
|
||||
o|wall|#8b4513|solid
|
||||
~|water|#2244aa|solid
|
||||
+|door|#c8a456|passable
|
||||
#|window|#87ceeb|solid
|
||||
^|mountain|#666666|solid
|
||||
T|tree|#0a5f0a|passable
|
||||
:|gravel|#9a9996|passable
|
||||
=|brick|#a51d2d|solid
|
||||
"""
|
||||
|
||||
each zone has a palette. could be inline or reference a shared one::
|
||||
|
||||
[zone]
|
||||
palette = "default" # use content/palettes/default.toml
|
||||
|
||||
a shared palette means consistent symbols across zones. a custom palette
|
||||
means a zone can redefine what ``~`` looks like (lava instead of water).
|
||||
|
||||
future properties per material: movement cost (forest is slower), opacity
|
||||
(walls block line of sight), damage (lava hurts), wetness (water makes
|
||||
you wet). for now, just passable/solid is enough.
|
||||
|
||||
|
||||
portals connect zones
|
||||
----------------------
|
||||
|
||||
a portal is a tile with a target. defined in the zone TOML or placed
|
||||
in-game.
|
||||
|
||||
in-game portal creation::
|
||||
|
||||
@portal here → jareds-house:5,3
|
||||
|
||||
"this tile, right where I'm standing, is a portal to jareds-house at
|
||||
coordinates 5,3."
|
||||
|
||||
portals are bidirectional by default? or one-way? probably one-way by
|
||||
default (you set up both ends), with a convenience flag for
|
||||
bidirectional::
|
||||
|
||||
@portal here ↔ jareds-house:5,3 # creates both sides
|
||||
|
||||
what stepping on a portal looks like: the viewport dissolves (or snaps)
|
||||
to the new zone. you get a brief transition message. your prompt updates
|
||||
if the zone has different ambient info.
|
||||
|
||||
|
||||
connecting to the overworld
|
||||
----------------------------
|
||||
|
||||
the overworld is just another zone — the big one. portals from the
|
||||
overworld into smaller zones work the same way. a tile at (450, 300) on
|
||||
the overworld has a portal to ``treehouse:10,0``. the treehouse has a
|
||||
portal back to ``overworld:450,300``.
|
||||
|
||||
buildings, dungeons, caves, interiors — all zones with portals from
|
||||
the overworld. the overworld tile might show a special symbol (a door
|
||||
icon, a cave mouth) to hint that something's there.
|
||||
|
||||
|
||||
procedural as a tool, not the default
|
||||
---------------------------------------
|
||||
|
||||
the procedural perlin world is useful but it's a tool. good for:
|
||||
|
||||
- wilderness areas (forests, plains, mountains)
|
||||
- dungeon generation (random layouts with a seed)
|
||||
- filler terrain between hand-built areas
|
||||
- prototyping (generate a base, paint over it)
|
||||
|
||||
the main game world should be hand-built. the starting experience, key
|
||||
locations, cities, landmarks — all authored by humans. procedural fills
|
||||
in the gaps, provides variety, makes the world feel larger than what was
|
||||
hand-crafted.
|
||||
|
||||
a zone can mix both: generate perlin terrain, then overlay hand-placed
|
||||
features (roads, buildings, rivers) on top. the generator runs first,
|
||||
then the overlay applies.
|
||||
|
||||
|
||||
layers (future)
|
||||
----------------
|
||||
|
||||
jared mentioned up/down and layers. a zone could have a z-axis — floor 1
|
||||
is the ground, floor 2 is the second story, floor -1 is the basement.
|
||||
same x,y grid, different z level. portals (stairs, ladders, holes)
|
||||
connect layers vertically.
|
||||
|
||||
not needed for v1 but the data model should not prevent it. a zone's
|
||||
tile data could eventually be::
|
||||
|
||||
[map]
|
||||
width = 20
|
||||
height = 15
|
||||
layers = 3
|
||||
data.0 = """...""" # ground floor
|
||||
data.1 = """...""" # second floor
|
||||
data.-1 = """...""" # basement
|
||||
|
||||
or layers could just be separate zones with portals. simpler, same
|
||||
result. decide later.
|
||||
|
||||
|
||||
what we learned from other engines
|
||||
-----------------------------------
|
||||
|
||||
research into how DikuMUD, LPC, MOO, Evennia, and others handle
|
||||
building. key takeaways and things to avoid.
|
||||
|
||||
what works
|
||||
~~~~~~~~~~~
|
||||
|
||||
**MOO's immediacy.** in LambdaMOO, @dig creates a room and you're done.
|
||||
no save step, no compilation, no restart. changes are instant. builders
|
||||
stay in flow. we want this — @new-zone, @paint, and your changes are
|
||||
live.
|
||||
|
||||
**evennia's XYZGrid.** optional coordinate system drawn as ASCII maps in
|
||||
python files. rooms at grid intersections, links along paths. transition
|
||||
nodes connect separate maps. proves grid-based worlds work in a
|
||||
room-based engine. their wilderness contrib is smart: players get their
|
||||
own room instance at a coordinate, share when co-located.
|
||||
|
||||
**diku OLC menus.** redit/oedit/medit push you into an edit mode with
|
||||
numbered options. simple, discoverable, no memorization. the nested
|
||||
mode pattern (game → editor → description editor) maps well to our mode
|
||||
stack.
|
||||
|
||||
**LPC file-based content.** builders write .c files, ``update`` compiles
|
||||
them live. version controllable, diffable, shareable. our TOML approach
|
||||
has the same benefits without requiring a programming language.
|
||||
|
||||
**ranvier's hybrid coordinates.** optional (x,y,z) per room, local to
|
||||
each area. explicit exits override inferred ones. areas can mix
|
||||
coordinate and non-coordinate rooms. flexible and clean.
|
||||
|
||||
**dead souls QCS.** wizard-driven creation (``addnpc``, ``addroom``)
|
||||
generates LPC files via interactive prompts. lowers the barrier —
|
||||
builders answer questions instead of writing code.
|
||||
|
||||
what people hate
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
**menu-driven OLC is clunky.** everyone acknowledges OLC is better than
|
||||
manual file editing, but it's still tedious. numbered menus, nested
|
||||
sub-menus, explicit save commands. modern builders expect something
|
||||
faster. our paint mode is a direct response to this.
|
||||
|
||||
**descriptions nobody reads.** "most players don't read the descriptions
|
||||
after seeing them the first time, and probably only skim them the first
|
||||
time anyway." high effort, low return. our tile-based visual approach
|
||||
sidesteps this — you SEE the room, you don't read a paragraph about it.
|
||||
descriptions can supplement the visual, not replace it.
|
||||
|
||||
**too much coding required.** evennia requires python for anything beyond
|
||||
basic building. MUSHcode has a brutal learning curve. MOO programming is
|
||||
its own language. builders want to create content, not learn to program.
|
||||
our approach: TOML data files for definitions, paint mode for visuals,
|
||||
minimal programming needed for basic building.
|
||||
|
||||
**collaborative building is an afterthought.** evennia's default setup
|
||||
doesn't support collaborative building well. MOO's permission system
|
||||
creates unexpected barriers. we should design for collaboration from the
|
||||
start — multiple builders in a zone, clear ownership, easy sharing.
|
||||
|
||||
**framework lock-in.** evennia's ObjectDB forces assumptions that don't
|
||||
fit all games. our zone model is simple data (TOML files, tile grids) —
|
||||
no complex object hierarchy to fight against.
|
||||
|
||||
**no good copy-paste or templating.** every room built from scratch.
|
||||
repetitive work. our web editor handles this naturally (select, copy,
|
||||
paste). in-game: could support @copy-region or stamp/template tools.
|
||||
|
||||
**saving and losing work.** diku OLC requires explicit saves; crash
|
||||
before saving = lost work. MOO's auto-persistence is better. our zones
|
||||
should auto-save on edit (or at least on leaving paint mode).
|
||||
|
||||
**recruiting builders is hard.** the harder the tools, the fewer
|
||||
builders you get. "building can be an enjoyable activity, but it's got
|
||||
its downsides. which probably explains why MUD creators have a difficult
|
||||
time recruiting dedicated builders." paint mode should make building
|
||||
feel like play, not work.
|
||||
|
||||
patterns from zone connectivity
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**evennia XYZGrid transition nodes.** metadata-only nodes that hold
|
||||
target coordinates on another map. never spawn as rooms. clean
|
||||
abstraction for zone-to-zone links. similar to our portal concept.
|
||||
|
||||
**diku inter-zone exits.** reference format: ``room_name@zone_name``.
|
||||
globally unique vnums (virtual numbers). our equivalent:
|
||||
``zone_name:x,y``.
|
||||
|
||||
**evennia wilderness fixed locations.** certain wilderness coordinates
|
||||
are "fixed rooms" — reach those coords, transition into a real room.
|
||||
this is how building entrances work in their wilderness system. maps
|
||||
directly to our portal-on-overworld-tile concept.
|
||||
|
||||
**alex kallend's wilderness (1999).** generate descriptions
|
||||
deterministically from coordinates. same coords always produce same
|
||||
room. memory-efficient. this is basically what our perlin generator
|
||||
does.
|
||||
|
||||
**ranvier cross-area linking.** reference format: ``areaname:roomid``.
|
||||
works between coordinate and non-coordinate rooms. our format:
|
||||
``zone:name:x,y`` or ``overworld:x,y``.
|
||||
|
||||
.. note::
|
||||
|
||||
open research: dig deeper into other MUD codebases for building
|
||||
patterns. specifically:
|
||||
|
||||
- evennia's prototype/spawn system for templating objects across zones
|
||||
- how discworld (LPC) handles its massive hand-built world
|
||||
- AresMUSH's web-based building tools (they moved building to the browser)
|
||||
- graphicMUD's tile-based building (closest to our model — they use
|
||||
sixel graphics on a tile grid)
|
||||
- how any engine handles "undo" for building mistakes
|
||||
- permission models that actually work for collaborative building
|
||||
without being bureaucratic
|
||||
|
||||
|
||||
build order
|
||||
------------
|
||||
|
||||
rough priority. each step is usable on its own.
|
||||
|
||||
1. **zone data model + registry.** load TOML zone files from
|
||||
``content/zones/``. zone has dimensions, tile grid, palette, portals,
|
||||
metadata. registry maps zone names to loaded zones.
|
||||
|
||||
2. **player-in-zone tracking.** extend player location from ``(x, y)``
|
||||
to ``(zone, x, y)``. zone=None means overworld. persist to sqlite.
|
||||
|
||||
3. **viewport reads from zone.** ``look`` checks which zone the player
|
||||
is in and reads tiles from that zone's grid instead of the overworld.
|
||||
movement checks that zone's passability rules. same rendering
|
||||
pipeline, different data source.
|
||||
|
||||
4. **@new-zone + @goto.** create blank zones from in-game. ``@goto
|
||||
treehouse`` teleports you into a zone. ``@goto overworld`` returns
|
||||
you. builder/admin commands.
|
||||
|
||||
5. **paint mode.** push onto mode stack. cursor movement without
|
||||
passability. brush selection. paint toggle. status line integration.
|
||||
|
||||
6. **file import/export.** load zone from TOML file (web editor output).
|
||||
save zone state back to TOML. the web editor and in-game building
|
||||
produce the same files.
|
||||
|
||||
7. **portals.** portal definitions in zone TOML. portal tiles trigger
|
||||
zone transitions. ``@portal`` command for in-game portal creation.
|
||||
|
||||
8. **@dig.** expand zone dimensions from in-game. grow the canvas in any
|
||||
direction.
|
||||
|
||||
9. **procedural generator as zone option.** ``--gen perlin`` on zone
|
||||
creation. generate base terrain, allow painting over it.
|
||||
|
||||
10. **the flower spawn.** hand-build the flower and treehouse zones. wire
|
||||
the new-player experience to start in the flower instead of the
|
||||
overworld center.
|
||||
|
||||
|
||||
open questions
|
||||
---------------
|
||||
|
||||
- should the overworld be a zone, or is it a special case? making it a
|
||||
zone simplifies the code (everything goes through the same path) but
|
||||
the overworld has unique properties (huge, procedural, wrapping).
|
||||
probably: overworld IS a zone, just a large wrapping one with a
|
||||
generator.
|
||||
|
||||
- zone ownership and permissions. who can edit a zone? the creator?
|
||||
anyone with builder role? co-ownership? defer this until the permission
|
||||
model from things-and-building.rst is designed.
|
||||
|
||||
- how big can a zone be before performance matters? a 1000x1000 zone is
|
||||
1MB of chars. loading, saving, and transmitting that is fine. but do
|
||||
we want to support zones larger than that? probably not initially.
|
||||
|
||||
- persistence model. are zones purely file-based (edit file, reload) or
|
||||
do runtime changes (paint mode edits) persist automatically? leaning
|
||||
toward: paint mode edits modify in-memory state AND write back to the
|
||||
TOML file. the file is always the source of truth, and it stays
|
||||
current.
|
||||
|
||||
- what symbol is void/empty? tiles that haven't been painted yet. could
|
||||
be space (invisible), could be a dim dot, could be configurable. needs
|
||||
to be visually distinct from any palette symbol.
|
||||
|
||||
- should portals be visible on the map? a special symbol, a color, a
|
||||
blinking character? or do they look like their underlying tile (a door
|
||||
looks like a door, not like a portal)?
|
||||
|
||||
- layers vs separate zones for vertical space. layers are elegant but
|
||||
add complexity. separate zones with portals (stairs) are simpler and
|
||||
get the same result. start with separate zones.
|
||||
|
||||
|
||||
relation to things-and-building.rst
|
||||
-------------------------------------
|
||||
|
||||
that doc covers the item/verb system (phase 1-2) and room system
|
||||
(phase 3). zones and building here are the spatial foundation that
|
||||
the item system lives on top of.
|
||||
|
||||
zones provide the WHERE. things provide the WHAT. a zone has tiles
|
||||
(terrain, walls, floor). things sit on tiles (items, furniture, NPCs).
|
||||
portals are a zone-level concept. doors with locks are a thing-level
|
||||
concept (the door is a @thing with an @verb for ``open`` that checks for
|
||||
a key).
|
||||
|
||||
build zones first (this doc), then populate them with things
|
||||
(things-and-building.rst).
|
||||
Loading…
Reference in a new issue