[MUD-Dev] Naming and Directories?

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sat Mar 13 11:00:39 New Zealand Daylight Time 1999

[Mark Gritter:]

 >In MUDs I'm familiar with, directories seem to be done in a very ad-hoc 
 >fashion.  Objects may have no name associated with them at all, or a
 >name can be discovered only by exhaustive search.
 >Dikus are a partiularly bad example here.  Doing a "tell" may involve 
 >scanning the entire list of online players.  Objects (I mean driver-level
 >objects including mobs and items) are named only by their location in memory; 
 >object prototypes have essentially meaningless integer IDs.
 >There might be some benefit it doing naming explicitly rather than implicitly.
 >Has anyone had experience with a more structured approach to using directories
 >in a MUD?  

All symbols in AmigaMUD are symbols entered in some table or other. I
haven't used them for some of the things you describe, but I have used
them in different fashions to organize things. There are normally three
global tables in the system: Characters, which maps character names to
player structures; Builtins, which maps all of the server provided
MUD-language builtin functions, and the public table, which is always
accessible to everyone. "Characters" and "Builtins" are names within
it, and it is accessible by calling the "PublicTable" builtin. Builtins
is also always accessible to everyone.

Each player character also has a private table, accessible by calling
the builtin "PrivateTable". Players can create new tables whenever they
want, and can add new symbols of whatever kind they want to any table
they have write-access to (only SysAdmin-level can add to the public
table or the Characters table, and no-one can add to Builtins).

I tend to use the tables much like scopes in programming languages. For
example, some of the more basic symbols needed in the scenario are put
into table "t_base". There are also "t_util", "t_fight", "t_icons",
"t_graphics", "t_build". When an "area" (no formal definition) is
built, I tend to put all of the symbols (room-names, local function
names, special object names, etc.) into that table.

For example, in my "doors room" sub-quest area in my "Proving Grounds",
symbol "o_winch" is used for the winch. It is defined in table
"tp_doorsRoom", which is in turn defined in table "tp_proving", which is
defined in SysAdmin's main private table. I use the convention that a
"tp_XXX" table is private - no-one other than its owner can use it.

This scheme works reasonably well, but has the expected problem of
not knowing where to look for a symbol when you get a large number of
symbols. When I do things like tracebacks on run-time errors, I look
in all "in use" tables for definitions for symbols encountered (e.g. as
function parameter values) during the traceback. This is most useful
when a programmer is testing code and has all the needed table "in use".
However, I had to add a SysAdmin-only builtin that searches all tables
in the system (doing a recursive search) for all names for a given
value. This allows SysAdmin to find out who owns something, or to find
his own stuff that he has forgotten about. It puts a fairly heavy load
on the server, however, which is why only SysAdmin can use it.

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list