[MUD-Dev] Introduction Systems

[Travis Casey]

Adam Martin wrote:
> ----- Original Message -----
> From: "Travis Casey" <efindel at earthlink.net>
> To: "Ben Chambers" <mud-dev at kanga.nu>
> Sent: Monday, March 12, 2001 9:45 PM
> Subject: Re: [MUD-Dev] Introduction Systems
 
>> You could, say, use a 24-bit number for character ID (giving about
>> 16.7 million character IDs), and an 8-bit number for the index into
>> the list of that character's aliases (allowing a character to have
>> up to 256 aliases, which is more than anyone's likely to actually
>> want).

> I agree entirely, but just wanted to raise the question of what
> *would* you do if 8-bits ended up not being enough? I appreciate
> that you weren't attempting to be precise, but I'd like to highlight
> the general problem whereby too many designers shoot themselves in
> both feet by neglecting to define how they are going to handle the
> extremely-improbable when it does finally come home to roost.
 
> I bring it up because I would have really appreciated being warned
> not to make the mistake some years ago.

No problem.  You plan ahead, of course.  :-)

First, modularize the alias-handling code as much as possible.  The
basic functions you're going to need to expose are:

  -- translation from alias to player id (PID, from here), for a given
  player.  This can take a text string (the alias as the player sees
  it), and return a PID.  The PID length should be chosen to be much
  greater than any foreseeable need, so its size should never need to
  be changed. If you really want to plan for the future, though, you
  might want to create a "PID" type.  That way, you can change the
  size of PIDs in the future simply by redefining and recompiling.

  If you allow multiple players to have the same alias, you'll need to
  have it be able to return a list of PIDs.  The program requesting
  the translation will then have to determine which of the PIDs makes
  sense in the context, which might involve asking the user questions.

  -- translation from PID to alias, for a given player.  This takes a
  PID and returns a text string.  If you allow a player to know
  multiple aliases for another player, it may need to return a list of
  text strings, or you may need a way for players to determine which
  alias for a character they want to see.

  -- register an alias for a player.  This takes a PID and a text
  string, and adds the alias to the player's alias database.  It may
  also need to ask the player if the new alias should be set as the
  default for that player.

  -- change one player's default alias for another player.  This takes
  a PID and an alias, and sets that alias to be the default alias for
  that player.  Whether it should add the alias if it doesn't already
  exist, or return an error instead, is an implementation decision
  that needs to be made.

  -- remove an alias mapping from a player's list.  Can take either a
  PID-alias pair, or just a PID.  In the latter case, it will remove
  all aliases for that PID.

  -- return all PIDs that match a given alias, without respect to
  players.  (I.e., search for all the players using a given alias).

  Functions for reading and writing the alias file(s) don't need to be
  exposed to most other programs and modules.  General maintenance
  (e.g., removing aliases for characters who no longer exist) can be
  done with the above functions.  The only thing I can think of
  off-hand that should require direct access to the files is changing
  them to a new format...  which I'm about to cover.  :-)

The alias files should have a version code embedded in them.  This
makes transitions from one alias file format to another easier.  When
a new format is created, either a one-time program can be written to
walk through all the existing alias files and translate them, or the
function for loading a player's alias file can be altered to check its
version and do the necessary translation.  Or both -- run the program
to change all of them over at a low priority, with code in it to
prevent it from changing a file that's in use.

Personally, since I have no ambitions of running a commercial mud, I'd
just do the translation on loading, and keep it in place for the
length of time it takes until a player file gets automatically wiped
for non-use.  This will ensure that all files will be either updated
or deleted.

There's probably a hole in this somewhere, since I've only spent about
ten minutes or so thinking about it.  To actually use this in a mud,
of course, you'd want to spend longer on it, and have more than one
person look at it

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_)
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev