[MUD-Dev] Thoughts on a simplified multiplayer game.

[Bruce Mitchener]

Edward Glowacki wrote:
> On Tue, 2003-05-20 at 19:23, Jason Slaughter wrote:

>> as well as display an attractive graphical map to help in
>> navigation (one of the difficulties I have with text based muds
>> is navigation. Without some sort of spatial representation, I get
>> lost.).

> Zmud has a graphical mapper.  It's not perfect and doesn't work
> well for all muds, but so long as the rooms' text structure and
> exit labels are machine parsable (i.e. not mixed in with a
> paragraph of prose), it usually does a decent job.

You might also look at the UMN MapServer:

    * http://mapserver.gis.umn.edu/

That can be hooked up to PostGIS, an extension to Postgres to better
support GIS-like needs and general spatial database needs:

    * http://postgis.refractions.net/

If you feed your world data into PostGIS, you can both do some
interesting analytical analysis on it, as well as make pretty maps.

I know that in the past, I've found it useful to have a way to
visualize the locations of NPC kills on the world map to find bugs
in NPC AI that led to them getting trapped or being slower to
respond, which led to players brutally carrying out genocidal
campaigns against the poor innocent NPCs.  With a system in place
like that, I'm sure that lots of usages could be found for it,
especially given Jason Slaughter's interest in metrics.

Using GIS stuff has been brought up on the list in the past, but has
pretty much been universally ignored, so maybe the idea sucks in
actual practice:

    * https://www.kanga.nu/archives/MUD-Dev-L/1997Q1/msg00044.php
    * http://www.kanga.nu/archives/MUD-Dev-L/2000Q1/msg00801.php
    * http://www.kanga.nu/archives/MUD-Dev-L/1999Q1/msg00111.php
    * https://www.kanga.nu/archives/MUD-Dev-L/1999Q4/msg00119.php

Phil Lenhardt and I had discussed this some last summer and put
notes about it here:

    * http://agora.cubik.org/wiki/view/Main/GeographicInformationSystems

>> How I intend to simplify the game system: Everything in the game
>> is an "Entity", and an entity has attributes. Any Entity can be
>> asigned any number of "tags", which consist of a "field", and a
>> "value". For example, you could create an entity "Guard", assign
>> him the field "entity_type" and the value of "guard", assign him
>> the field of "hitpoints" and a value of "10". One simple
>> universal data type for every entity in the game...

> Using this system, I can imagine complex things in the game that
> have a large number of fields and values.  Managing such a list of
> attributes could get messy.  If each object has a copy of each
> attribute, you can't easily go back and make changes without doing
> something like a global search-and-replace.

> What you might want is more of an object-oriented style, where
> "Entity" is a base class which all other object types in the game
> inherit.  That way if you wanted to give all swords the ability to
> "slash", you could add a "slash" method to the sword object, and
> it will correctly propagate down to all the appropriate objects.
> Yes it may be a bit more complex to code initially, but it may be
> easier (and more powerful) in the long run.

This sort of stuff was covered in the set of links that I posted in
this message:

    * http://www.kanga.nu/archives/MUD-Dev-L/2003Q2/msg00316.php

>> Everything is simplified into an action/target relationship. Any
>> skill you have, any usable item you have, is an "action", and it
>> can have certain "targets". For example, you may use your kung-fu
>> skills on a guard, or use your first aid on yourself, or use your
>> key on the door. The function for handling this object would
>> essentially be simplified to this: perform_action(performer,
>> action, target), and any action would simply manipulate fields
>> and values on the performer and target, as well as broadcast text
>> to players.

> In order for this to work, an "action" will need to be some sort
> of function, which brings up the question of how to associate
> functions with game objects.  Back to object-oriented...

I'd posted once upon a time about how we do that in The Eternal City
(http://www.eternal-city.com/, a game that we developed and is
hosted by Skotos):

    * http://www.kanga.nu/archives/MUD-Dev-L/2001Q1/msg00415.php

There are other approaches as well ... some that aren't
object-oriented in the usual C++/Java sense, such as using multiple
or predicate method dispatch (done by Common Lisp, some Scheme
object systems, Dylan, Cecil, etc.):

    * http://agora.cubik.org/wiki/view/Main/MethodDispatch
    * http://agora.cubik.org/wiki/view/Main/MultipleDispatch
    * http://agora.cubik.org/wiki/view/Main/PredicateDispatch

The way that Macromedia Director handles attaching behaviors (and
the various ways that it allows you to do so, all with either static
or dynamic composition and aggregation of behaviors) is also
interesting and potentially relevant.  There's a lot of interesting
prior art for this in other UI toolkits as well (Tk,
NextStep/OpenStep/Cocoa, etc).

Cheers,

  - Bruce


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev