[MUD-Dev] HELP WANTED!

[Shane Gough]

Hi Roger,

I'm working on a similar model as you describe, implemented in Java
(J2SE 1.3.1).

> The system I need would have 3 types of elements (locations/rooms,
> objects/items, and characters). Each element could have an
> unlimited number of variables or sub-files assigned to it. For
> example: A variable for a character would be Hit Points; a
> sub-file for a character would be a list of items carried.

I think most MUD's boil down to these three basic items - it's a
fairly straight forward way of abstracting what needs to be done. In
an OO system these would represent the main classes and sub-classes
would take care of any specifics that are required (special rooms
like clan rooms could be implemented as subclasses for example).

You might want to think of adding a fourth class though, something
to encapsulate quests. This would not necessarily be something that
a player would directly interact with but something that keeps track
of their progress through the quest.

In my system I implemented SET and LIST type fields to maintain
collections of things that are held by another object. For example,
a bag object maintains a SET of all things that are currently in the
bag, a room contains a LIST of exits.

Many MUDs that I have seen maintain their databases in set of flat
files (usually text, for ease of editing) and use an engine such a
GDB or BerkeleyDB to manipulate them (or their own implementation
for example).  My system uses a relational database and an O/R
mapping layer in Java to treat the database as an OO database. Quite
probably (at this stage, definitely) slower but that's the area I do
my 'real' work in so it's a good experimental platform for me as
well. It does make it easier to change the schema (and allows schema
extension 'on-the-fly' using in-game code).

> Then, all the elements would interact with each other via
> events. An event would be a short script in a simple in-game
> language that would be able to call, manipulate, and change
> variables in the elements. To give some examples of how events
> would work: Bob is in a room with a portal. Bob types USE
> PORTAL. The command processor gets the USE pointer from the PORTAL
> object. This pointer is a variable that contains the event number
> to call. The processor calls that event. The event script then
> runs, changing Bob's current location to another room (by calling
> and modifying variables).
 
> Event scripts would be short, and simple enough for world biulders
> to create. Events could be used by multiple elements (for example,
> all portals would call the same event script, but feed it a
> different destination), and more complex functions could be
> performed by making a chain of events.

I'm playing with a similar design, using what I call actions, rather
than events although the concepts are very similar. In my case the
command 'GO NORTH' would look for an object in the current room
called 'NORTH' and send the 'GO' action to it. Global commands, such
as just 'NORTH' instead of 'GO NORTH' would be implemented by all
room objects which would basically invoke the most appropriate
action on the appropriate object.

The main actions, such as GO and the like, would be implemented in
the games code itself although the designer could replace them with
an in-game script which would be executed instead. Additional
actions could be added at any time by the designer - once again
using the in-game language.

In my implementation scripts are a set of name->script mappings and
treated as normal string fields internally.

> An important element of the system is that I would want is
> internal world creation. The builders of the game world would be
> able to create new elements by entering commnads from within the
> game.

Definitely - I think this is were MUD's have a *huge* advantage over
other game types. The ease with which a player can modify their
surroundings. Security and trust come in to it a lot - you don't
want to have everyone being able to modify a globally accessable
room for example.

I thought of providing each player with a home - in my scenario an
apartment in an apartment block - which they were free to modify no
matter what level. As players became more comfortable with the
process of modifying the environment and became more part of the
community they would be given permission to work on their own zones
or special rooms for other players to enter. This is fairly standard
from what I've seen - you need to be promoted to a builder to be
able to make modifications and even then it could only be in a
restricted area.

> One of the key elements that I feel is of upmost importance is
> NPC's.  As I have looked around, I have been tremendously
> dissapointed with the level of depth to the computer controlled
> characters in a game. I know when I start speaking about AI,
> programmers across the world think of labor pains, but I feel this
> system would be much simpler.  First, NPC's would be treated by
> the system in the same way as PC's, ie, they would have access to
> all the same commands and abilities as PC's would. In addition,
> NPC's would have memory (likes, dislikes, information based on
> keywords, etc.) The scripts to run the NPC's would be easy to
> implement using the event system described above. An NPC could
> simply be given a chain of events that would interact with the
> elements around the NPC and the NPC's memory to control their
> actions. The initial creation of NPC's would be simple, and they
> could slowly be programmed to be smarter over time by adding more
> event scripts.

I'm not 100% sure an in-game language could provide what is needed
to do this with reasonable enough performance to scale over a large
number of NPC's (even a 100 copies of the same NPC would require a
lot of processing time to analyse the current environment and choose
the appropriate action. Also, MUD's are real time - not turn based,
so this would have to be a continous thing. Every event would have
to be processed by all NPC's in the context of their current state -
this would take up a lot of time. Of course, you would filter events
to ones that directly effect them (that take place in the same room
so to speak) rather than every event but it still adds up to a lot
of time required.

I was thinking along the lines of having a number of 'personalities'
implemented in native code which could be cloned and customised by
adjusting properties of the individual NPC. This could be extended
to allow some specific events processed by in-game scripts but the
bulk of the work done as fast as possible in the actual MUD
engine. Using technologies such a RMI, CORBA, DCOM, RPC etc you
could even have the AI side of NPC's running on a separate server
and treated by the MUD as just another player.

> These are my basic concepts. If there is anything out there close
> to this, please let me know. If not, I would love to have someone
> with the knowledge and hardware code it.

Well - as you can see, I'm working along similar lines and have
quite a bit of the infrastructure in place but no actual MUD up and
running. I'm certainly willing to collaborate with others if anyone
is interested.

Regards,
Shane

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