[MUD-Dev] Game design highpoints (was Re: Virtual machine design)

claw at kanga.nu claw at kanga.nu
Sun Apr 18 00:43:10 CEST 1999


On Sat, 17 Apr 1999 18:15:04 -0500 
KiZurich  <c718157 at showme.missouri.edu> wrote:

>> -----Original Message-----
>> From: mud-dev-admin at kanga.nu [mailto:mud-dev-admin at kanga.nu]On Behalf Of
>> Felix A. Croes

Writing as list owner for the following sentence only:

  Please redo your attributions to something a little more directly
useful.

No longer writing as list owner:

> I was wondering what the general consensus on "not having to
> reboot" meant to the list.  

I have two complementary views:

  1) The server never resets, not even fractionally.

  2) Any server restart will resume the game world, with perfect
accuracy minus some player port connections, to the world-state
state briefly prior to the preceding shutdown, no matter how
ungraceful the shutdown was (eg power cord yanked).  The scope of
"briefly" is intended to lie within single-digit minutes, and
hopefully within double digit seconds.

Ergo, even if the power is strobing, outside of port mappings for
player connections and a slight slowing of the ratio of game time to
RL time, there is a net zero effect on the game.

> Obviously, if the power goes off to the system the MUD is on, the
> MUD will have to reboot.

And of course there is no UPS.  Why is there no UPS?

> What must be supported on-the-fly for a MUD to be considered
> rebootless?

Feature set wise its primarily runtime morphism.  Once you have that
the rest pretty well follows for free.  Its possible to get runtime
morphism and still retain a rebooting server, but it tends to
require extra effort to retain the reboot requirements.

> Also, for those of us who are slowly cranking on our own code,
> what features are the most important to be able to do while the
> server is running?

This is dependent on what sort of server and game world you intend
to provide.  What are the primary features of your server?  What are
the primary features of your game world(s).  Are you going to
support multiple game worlds?  If so, how much variation will there
be among those game worlds, and to what extent will the server
design encourage and support that variation?

My own goal is a goal-oriented simulationist game which also
supports free user programming in a manner encouraging to
non-programmers.  As such the feature set is heavily slanted to
allowing users at runtime to redefine and in fact delete and create
the entire world and or object heirarchy while the server continues
to run regardless.  After that security models are primary, both to
help guarantee logical correctness (for instance in the event of an
ungraceful shutdown and restart), and to ensure that the game goals
can't be bypassed by simple user programming ("Bubba programs p a
50,000,000hp mega-sword, bops Tiamat over the nose with it and
conquers Carthage").

> For example, adding, modifying etc. rooms in the game world.  Or
> fiddling with item stats (like base damage for generic longswords,
> or whatever).

What type of game are you looking for?  What balance of the four
suits?  What level of immersion?  what is your target audience?

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the mud-dev-archive mailing list