sfwhite@watcgl.waterloo.edu (Stephen White) (02/07/90)
In article <637@m1.cs.man.ac.uk> pjc@r1.UUCP (Peter Crowther (CAG ra)) writes: } wizard on UglyMUG (derived from TinyMUD 1.4.1 Beta - I've added deletion } of objects, newlines in descriptions. I'm about to add containers and a } *very* general compound command mechanism.) I'm interested in your deletion algorithm. Does it allow for deletion of players? I've decided to cut short my work on the next generation of TinyMUD's (ie., with imbedded programming language, etc. as Asp & I had discussed). If I don't I'll be in danger of flunking out: not a good scene. What I'll do instead is toss my ideas out for the MidGaard folks. What Asp mentioned about a simplified programming language (with if/then/else constructs and bounded loops) helped me to come up with some ideas for an idealized MUD. What I've been trying to come up with is a very simple language which would allow all commands (including the existing get/drop, etc.) to be expressed in a simple form, using a very small set of built-in functions. Each object/room/player would then "link" to a set of actions by default. For example, "get" might be expressed as get $1 if (locof($1) != locof($player)) then tellplayer("I don't see that here."); else move($1, $player) This action would be written only once, as the default "get" for an object. An object would "link" to this program, and the player could then over-ride the default by writing their own program and linking to it instead. locof(thing), move(thing, dest), tellplayer(message) and tellothers(message) might be the only required functions--any ideas here? Perhaps the ability of a program to re-@desc or re-@name an object should be allowed, or to compare strings (this would cut down on object-swaps and string-duplication) Note that I'm using a C-like syntax ... it's just what I know best, perhaps something LISP-like would be better. Also, the concept of "key" has been removed; it has to be added in by the player. In fact, the only required fields might be: name, description, owner, flags, location, contents, and a new one, "programs". Asp suggested that all types of objects would be derived from a superclass which defines the functions which may be performed on it. This "program" might be stored as an object, like everything else, except that it could be "linked to" by any player. The only problem I see with this scenario is access. If you link to a program created by another player, the program will now be moving around things created by the first player, not the creator of the program. Perhaps programs should have a "LINK_OK"-type flag, to indicate that others may use them. The "programmer" would be responsible for not making publicly accessible programs which did things he didn't want them to (ie., move around important objects). Crude containers might be implemented as follows: put $1 in $2 if locof($1 != player) tellplayer("You don't have that!") else move($1, $2) tellplayer("You put $1 in $2.") (The existing "contents" field could be used, but the "get" action would have to be modified to check the contents of each object in the player's inventory and room objects' contents for items to extract, if such functionality was desired). This program would only be linked to by whichever objects were to be containers. I should mention that although I was initially distrustful of the idea of programs in MUD's (being wary of bad programs crashing the entire MUD), I have since been convinced that it is the only way to go. TinyMUCK is a clever way to tack on some new features into the structure of TinyMUD, but it doesn't allow the full flexibility of a programming language. (And, as anyone who has used it will tell you, TinyMUCK is definitely lacking in the ease-of-use area.) -- ___ Stephen White standard_disclaimer() ______/__ sfwhite@watcgl.waterloo.edu <___ | \ /\ / "If the world was an orange, it would be like, ___> | \/ \/ much too small." - The Young Ones
lars@myab.se (Lars Pensj|) (02/08/90)
There are some discussions about how a multi user dungeon really should be
done. I have made one, and it works, although there are of course lot of
bugs yet.
My game can be seen as a cross between Abermud and tinyMUD. It is up and
running for public access, but as I don't consider it complete yet, I am
not ready to go public with the address. Any one interested to try can
mail me a request.
My game is called LPmud.
IDEA BEHIND THIS GAME.
I played Abermud a lot, and wanted to do something better (who don't).
1. A wizard can extend the game.
2. The game can be extended on fly, without rebooting the mud.
3. There are no difference between objects. Rooms, players and things
are just objects.
4. All objects are specified in interpreted C. The specifications are
compiled (loaded) first time they are referenced.
5. There are no player parser. All commands are defined by the objects.
For example, the knife defines the command 'wield', and the
leather jacket defines 'wear'. An object defines a command by
associating it with a local function, defined in the object. When
the user types that command, the corresponding function will be called.
If the user types 'wear jacket', then "jacket" will be sent as an
argument to the wear function in the jacket object. If the user
types 'wear plate', the jacket wear function will detect that
"plate" != "jacket", and return false. Then, another 'wear' command
is tried, untill success. When the user drops the jacket, all commands
are removed that was associated with that object.
6. The rooms are just objects that defines some commands like 'look',
'east', 'north' and such things. When the user then types 'north',
the room function will do something to the player.
7. An object may define a function "heart_beat". It will be called every
two seconds. This can be used for automoving monsters, torches burning
down, time delayed traps and healing players ...
8. The most complex object is the player object. It defines commands like
"get", "smile" and "kill".
9. When a player becomes wizard, he will get a small portable castle.
He can drop this anywhere, and it will grow and become a full scale
castle. He can then rename it and extend it. It is okey to rename it
to "entrance to hell" or anything.
10. The language that defines objects are similar to C. It is interpreted.
11. There is a builtin ed-compatible editor for wizards creating objects.
There is also 'ls' and 'cat'.
12. There are no global reset. Every object can define a local
reset() which will be called some time. This is especially useful for
rooms that wants to restore a treasure or relock doors etc.
Comments about the result:
A wizard is very powerful, and can really do anything. That means he has
a great resposibility.
I choose the language C, because why invent a new language that is hard
to learn ?
Performance:
There are yet no problem with reponse to player actions. It is really MUCH
better than Abermud file communications.
There might be a problem with the size of the program when all object
definitions arer loaded. An object takes on average 2000 bytes. All object
definitions are first run through the C preprocessor, and then loaded.
They are only loaded on demand, though.
The machine, a IBM PC-RT has only 4 Mbytes. When someone starts X-window,
the game can get slow.
As I am doing this myself, what is really lacking is the size of the
adventure. Currently there are only 60+ rooms, and slowly expanding.
The game uses a port on an internet address, and thus any number of players
can play (at least more than number of pty's).
If you are intrested in helping with designing more adventures, please
tell me.
As an example of how general this game is:
A player is saved when he quit by just storing all global variables
from the player object in file named from his player name.
There is an elevator that can move a player between levels. It just
has a variable "level" and "dest_level" and "time_until_arrival", and
so on.
A monster can catch all "talk" and be programmed to activate in any way.
There is a Post Office, where players can send and read mail to other players.
There is a shop where you can sell and buy things. Most things have values.
The above examples all uses only the standard predefined language.
Conact me if you have any questions or ideas.
lars@myab.se
--
Lars Pensj|
lars@myab.se