[MUD-Dev] RP=MUSH/PG=MUD

Nathan Yospe yospe at hawaii.edu
Fri Jun 27 18:27:50 CEST 1997


On Fri, 27 Jun 1997 clawrenc at cup.hp.com wrote:

:In <Pine.GSO.3.95q.970621211819.4326B-100000 at uhunix2>, on 06/22/97 
:   at 11:07 AM, Nathan Yospe <yospe at hawaii.edu> said:
:
:>On Sat, 21 Jun 1997, Caliban Tiresias Darklock wrote:
:
:>:On Fri, 20 Jun 1997 19:13:08 PST8PDT, "Jon A. Lambert"
:>:<jlsysinc at ix.netcom.com> wrote:

:>:Direct editing of a text file loaded directly by the MUD is a bad idea.
:>:People make too many mistakes. The actual MUD configuration file should
:>:be machine written if possible, to avoid problems. I do see some great
:>:advantages to having the configuration human-readable and human-editable
:>:if necessary, but I think it's a problem to require the builder to edit
:>:this file directly every time.

:>Agreed. Make it editable, readable, and sensical... but DON'T make it
:>normal to do it that way.

:Given a client which automagically D/L's the file in the background
:and allows structured editing of the file locally, prior to automatic
:uploading of the finished version (cf Emacs and Ange-FTP), I see
:little difference.

Structured editing is another matter altogether. The thing that gives me
the heebies is direct editing of the data file.

:>:	For each checkbox,
:>:		Is the exit checked?
:>:			Yes: Is there an exit there?
:>:				Yes: Leave it alone.
:>:				No: Make an exit.
:>:			No: Is there an exit there?
:>:				Yes: Destroy the exit.
:>:				No: Continue.
:
:>:However, this could be just as easily done with a command like
:
:>:	setexits <<n|s|e|w|u|d|ne|nw|se|sw>[=name]>[...]

:Counter: I've changed my exits model enough that anything of this
:nature would have been difficult to stick to, and would be difficult
:to map to now.  Currently I support two disperate exit models:  exits
:as objects in the current room, and exits as verbs bound to the
:current room (variation: occassionally exits as verbs bound to the
:player character object).  The next problem of course is that I
:stylisitically encourage contextual exits ("door", "bar", "street"
:etc), as vs the compass directions (and pleasantly tend to place the
:compass directions as leading to things you don't want to go towards).
:
:This is not to say its impossible, just that the model needs extensive
:adapting.

Likewise. My model has four primary object types that make up the world.
(everything else being support, and all internal objects being derived
from one of the above.) I have the Physical (Items), the Controller
(Character - there is a big difference between a character and the
Physical body), the Location (Rooms, Fields, Regions), and Boundaries.
(Bulking Containers are not actually part of the world, from this point
of view.) Boundaries are not so much exits as 2D bounds to Locations...
but they fill the same role as an exit. When an exit is created, it can be
accessed by a player spacially or contextually, IE "go forward, turn
right, go, go toward the big oak door, aproach the door, open the
door, go through door, close door, lock door, run" or toward couple verbs
("enter bar" coupled to a boundary on the outside of a bar) or coupled
triggers ("bar", which makes "<motion verb> bar" active.) This is easy
enough to build in context, as a lot is handled by defaults, but nearly
impossible to adapt out of standard models.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu




More information about the mud-dev-archive mailing list