CALL FOR DISCUSSION: rec.games.mud
Fur - Roy Riggs
>This is an Official Call For Discussion for creating the newsgroup
>rec.games.mud. MUD stands for Multi-User Dungeon, developed at CMU.
I do think there is a need for a new news group here, but you have
confined it to narrowly. There should be a news group for discussing
ALL multi-user games (most likely adventure oriented, but not
exclusive.) Limiting the group to one particular game implementation is
silly. Perhaps rec.games.multi-user would be a better name.
Also, there is no such thing as MUD, TinyMUD was the game developed at
CMU by James Aspnes and others. MUD most commonly stands for Multi User
Dimension(s) so as not to limit the genre.
James Seidman
news.announce.newgroups, and comp.sources.games.bugs (don't ask me why). I
though that it might also be of interest to people here. I'm not sure who
this guy is, or why he's calling for a new group when it looks like he
doesn't even read this one. I make that assumption based on how terribly
misinformed he is about the history of MUDs and his thought that TinyMUD is
the only kind (both of which have been discussed here). Anyway, here's the
message which he posted everywhere but here. Please note to I've set the
Followup-To to both here and news.groups.
In article <95...@medusa.cs.purdue.edu> b...@cs.purdue.edu (Zaphod Beeblebrox) writes:
}This is an Official Call For Discussion for creating the newsgroup
}rec.games.mud. MUD stands for Multi-User Dungeon, developed at CMU.
}There are several of these around the country, most notably at
}Carnegie Mellon (tinyMUD; telnet daisy.learning.cs.cmu.edu 4201), and
}at the University of Oklahoma (tinyHELL; telnet uokmax.ecn.uoknor.edu
}6250).
}
}There currently is an alt.mud, but it suffers from poor distribution.
}Judging by the large number of people that are connected to the MUDs
}at any given time, there should be considerable support for such a
}group. (If you don't believe me, try connecting to one of them
}sometime.)
}
} B.E.E.
} (Finrod on tinyHELL)
}--
} Z. Beeblebrox | I live with two people, I like both of them.
}(alias B. Elmore) | He likes both of me and I like both of him.
}b...@cs.purdue.edu | They're my alter egos and to them I'm wed,
} ..!purdue!bee | 'Cause I'm happy I live in a split-level head. -- Nap. XIV
--
-------------------------------------------------------------------------------
Jim Seidman, Harvey Mudd College, Claremont, CA 91711. (714) 621-8000 x2026
DISCLAIMER: I don't even know if these are opinions, let alone those of
anyone other than me.
P.Kathuria
(Zaphod Beeblebrox) writes:
>This is an Official Call For Discussion for creating the newsgroup
>rec.games.mud. MUD stands for Multi-User Dungeon, developed at CMU.
Although I am in strong favour of a group devoted to multi-user adventure
games, I feel that I should put a few things straight. Even though a
a game was developed at CMU I doubt that it was the first. The first
multi-user dungeon game was developed about 10 years ago at Essex University,
England (Richard Bartle and Roy Trubshaw being the only two names I can
remember of the writers).
Bartle then went onto to form MUSE in 1985, a company which offered the
first commercial game and has taken MUD (multi-user dungeon) as the
registered trademark. The commercial version (MUD-2) is available outside
the UK too. Since then, many games have appeared in the UK, most of them
are paying games. To my knowledge there are at least three different
multi-user games available free in the UK over the academic network (MIST,
aberMUD and VAXMUD) although there is always a multitude of people trying
to write their own games. I mention MUSE because the version of aberMUD
that is available through the IBM PC User Group's Connect service, is known
as aberMUAG (multi-user adventure game); I suspect that the name change is
to not create any legal problems regarding "MUD".
I know that there is a community of muag-ers in the UK; we have an annual
Adventure Convention (where old and new games are taken, and techniques
for writing games are discussed) and a new magazine devoted to comms has
two regular writers on multi-user games/comms (I'm one of them). I also
know that many of the people in the multi-user community don't
necessarily have write access to Usenet, which is why I have taken it
upon myself to write this article.
>There are several of these around the country, most notably at
>Carnegie Mellon (tinyMUD; telnet daisy.learning.cs.cmu.edu 4201), and
>at the University of Oklahoma (tinyHELL; telnet uokmax.ecn.uoknor.edu
>6250).
Hopefully I have made my point that "the country" doesn't have the monopoly
on multi-user games. I think that many in the UK would like a group to
discuss multi-user games (although I know that only a minority will have
the facilities to vote), especially since all the bulletin boards I use
have popular mud folders.
I suggest that the group be called rec.games.muag or rec.games.multi-user
to avoid using "mud". I have seen later articles where rec.games.frp.dungeon
has been suggested as a name and I think that it should be pointed out that
not all multi-user adventure games have dungeons in them or bear any
resemblance to D&D.
Paola Kathuria
[news is dead at zen so I'm using my old university account to read/write
news, please send any replies to pa...@zen.co.uk since I rarely log onto
ukc]
Stephen White
} In article <95...@medusa.cs.purdue.edu> b...@cs.purdue.edu (Zaphod Beeblebrox) writes:
}} This is an Official Call For Discussion for creating the newsgroup
}} rec.games.mud. MUD stands for Multi-User Dungeon, developed at CMU.
}} There currently is an alt.mud, but it suffers from poor distribution.
} Bad idea. Let's not get carried away, here. Sure, lots o people play
} TinyMUD and AberMUD, but a whole official group? In the rec heirarchy?
There's another possible consideration here. MUD games, as you know,
don't generate big packets or even a great number of packets (okay,
maybe when there's a groovy party in the RecRoom, it might get
kinda busy). But do we really want the people who own all the
sites that the Internet connects knowing that some of the bandwidth
of their expensive connections are being used for (gasp) a game?
It's fine when it's a local thing, like Moria (correct me if I'm
wrong; I haven't played it, myself), but when you connect a long way
on [Aber|Tiny]MUD you're involving a number of sites, routers, etc.
along the way. I don't know if we should really advertise the fact
that these MUDs are running at all.
Maybe I'm just being paranoid; you all know I've had a rather
embarassing wrist-slapping incident in this area. Still,
I think we should be a little more cautious before jumping into world-
wide advertising.
My vote: keep MUD in the alt hierarchy for now.
(Hey, what can I say, I'm an alternative kinda guy.)
--
___ Stephen White standard_disclaimer()
______/__ sfw...@watcgl.waterloo.edu
<___ | \ /\ / "If the world was an orange, it would be like,
___> | \/ \/ much too small." - The Young Ones
Mike Charlton
>>}There currently is an alt.mud, but it suffers from poor distribution.
>>} [stuff deleted]
>>}
>>} B.E.E.
>>} (Finrod on tinyHELL)
>>
>Bad idea. Let's not get carried away, here. Sure, lots o people play
>TinyMUD and AberMUD, but a whole official group? In the rec heirarchy?
>I think that's a bit overboard. Sure, Moria has its very own group,
>but many more people play Moria than all the MUDs combined. The MUD
>gorup is in the alt heirarchy because that way sites that don't have
>to deal with traffic of limited interest or alternative appeal don't
>have to deal with it. We are, like it or not, of limited appeal.
>Consider: there are currently ten TinyMUDs. Each one has a maximum of
>60 or so players at a time. 600 people is a rotten base for a group,
>and generally (always) less people than that are on. Sorry, but even
>though I play avidly, I don't think we deserve our own group.
>Bryant Durrell, aka Garrett
Well, if there isn't enough support for a new group (and I agree 600 probably
is too small, if that is the case) then how about someone starting a mailing
list for those of us who don't get the alt.mud group. I would imagine that
if there are so few people, this wouldn't involve much overhead (If someone
with a kind heart is willing to do it...)
Mike
Peter Crowther (CAG ra)
You reckon? :-) I've got TWO running on my machine here (one 'live',
one for development purposes). I bet there are plenty of other tiny
sites around who are not connected to the Internet but have MUD running
for the locals (this one's limited to on-campus; currently 30-40 players
(I think, haven't counted recently)).
I can receive alt.mud; I have no opinion on whether it should be moved
into the rec.* hierarchy at the moment ('I'm alright, Jack'). However,
I consider the '600 users is a rotten base' argument specious.
- Peter
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.)
Peter Crowther, Dept. of Electrical Engineering, University of Manchester,
Manchester M13 9PL, England.
Internet: pcro...@r1.cs.man.ac.uk Janet: pcro...@uk.ac.man.cs.r1
USENET: mcvax!ukc!man.cs!pcrowther Fishing net: Device for catching fish
Ford Prefect
umch...@ccu.umanitoba.ca (Mike Charlton) writes:
>Well, if there isn't enough support for a new group (and I agree 600
>probably is too small, if that is the case) then how about someone
>starting a mailing list for those of us who don't get the alt.mud
>group. I would imagine that if there are so few people, this
>wouldn't involve much overhead (If someone with a kind heart is
>willing to do it...)
600 small? Generally 100 is considered the threshhold for newsgroup
creation. 600 is bloody large! I'd hate to see a 600-name mailing
list (poor uunet...)
I'd really like to see the mainstream group. There's certainly enough
interest (right now TinyHELL is running 1400+ users, I imagine TinyMUD
is similar, and there, last I heard, at least 10 other national-access
MUDs and countless local ones. The TinyBALL that was run this weekend
drew so many users that it temporarily overwhelmed the gateway to the
host it was running on. If even a small fraction of this user base is
interested I think there's enough demand for the group.
Also, there are a lot of people out there working on the MUD source,
and it would be nice to have someplace to discuss this sort of thing
too; rec.games.programmer is a little too general for specific
discussions of the implementation of one game.
--
Help stamp out vi in our lifetime!
Ford Prefect g...@mentor.cc.purdue.edu
(a.k.a. Scott Goehring) ...!purdue!mentor.cc.purdue.edu!gt4
Stephen White
} 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.)
Marcus J. Ranum
---I dropped news.groups out of the distribution. let's not piss *EVERYONE*
off!!---
In article <13...@watcgl.waterloo.edu> sfw...@watcgl.waterloo.edu (Stephen "Ghondahrl" White) writes:
>Each object/room/player would then "link" to a set of
>actions by default. For example, "get" might be expressed as
I had a design (and initial code) for a system that was similar,
except I did not 'link' actions into objects, to save space in the object.
Actions were to be resolved at run-time - there being a 'system' action
table with typical stuff like 'look', 'move' and so on defined in it.
An object could 'post' an action to its container (in the case of a player
object, the room - all objects were to be primary objects) and if the verb
was issued in the room, the object would respond to it. Thus, several things
could happen from a single player action. It was more complicated in that
actions could call eachother. So, for example, exiting a specific door could
tell a room to change its description to 'a dark room' and set the lights
off. I hadn't figured out a good way of preventing a creep from making a
loop, though. (other than to toad them ;-) Verbs could be targeted at a
specific object, by matching names, so that "take cat" would scan only
"cat" for a 'take' program, which it would call, and failing to find one
would check the system table for a 'take' program. Failing that you get
a 'Huh ?' All objects (hey, since they have a symbol table, why not ?)
would be able to have local state variables. Presumably the system 'look'
program might just be:
system->look = {
ifdef($1.description)
echo $1.description;
else
echo "you see nothing special";
}
Programs and symbols are differentiated by the '->' for function
resolution, or '.' for variable name resolution. In addition, I thought
that objects should have an access control mechanism, and ownership, so
that permissions could be defined with exactitude. Objects would also be
able to be flagged as 'setuid', so that they would act as proxies with
the permissions of the owner. Suddenly you have REAL magic::
/* a an example of a staff of polymorph */
new "staff of polymorph";
"staff of polymorph".owner = Wizard;
"staff of polymorph".charges = 2;
"staff of polymorph"->zap = {
ifisthere($1) {
echo "you turned ",$1," into a toad!";
$1.name = "a slimy toad named", $1;
$1.objtype = 0; /* this would be a protected field */
} else {
echo "I see no ",$1," here";
}
"staff of polymorph".charges = "staff of polymorph".charges - 1;
if( "staff of polymorph".charges <= 0) {
echo "the staff crumbles to dust";
delete("staff of polymorph");
}
}
The biggest problems I saw was I watched activity in tiny*. Most
of it is social - most objects 'mere' props. Fancy things would be nice,
but the system I was writing would do symbol table scans constantly. No
a pretty picture. The big advantage, I suppose, would be that once an
engine like mine was working, you could pare it or add to it depending on
the type of use it got. If 90% of the use was social, then you drop all
the fancy commands and magic spells out of the system table, limit the
number of objects that can fit in a room (by writing the limit into the
system 'drop' function) and presto! away you go.
I got a ways through the interpreter, and did the symbol table
code, then realized that I'd have some problems with the performance in
large rooms, and stopped to think of a good way of caching objects. By
the time I was ready to make a complete fresh start, Real Work intervened.
mjr/Jerry_Cornelius
--
The second law of thermodynamics implies that the expression
"good news" is an oxymoron.
Howard S. Nichols Jr.
What harm could a rec.games.mud cause?
Well just judge for yourself.
rec.arts.books! 0
rec.arts.comics! 0
rec.arts.drwho! 0
rec.arts.movies! 0
rec.arts.movies.reviews! 0
rec.arts.poems! 0
rec.arts.sf-lovers! 0
rec.arts.startrek! 0
rec.arts.tv! 0
xrec.arts.tv.soaps! 0
xrec.arts.wobegon! 0
rec.audio! 0
rec.autos! 0
rec.autos.tech! 0
rec.aviation! 0
rec.bicycles! 0
xrec.birds! 0
rec.boats! 0
rec.food.cooking! 0
rec.food.drink! 0
rec.food.recipes! 0
rec.food.veg! 0
rec.games.board! 0
rec.games.bridge! 0
rec.games.chess! 0
rec.games.empire! 0
rec.games.frp! 0
rec.games.go! 0
rec.games.hack: 1-5205
rec.games.misc: 1-7211
rec.games.pbm! 0
rec.games.rogue! 0
rec.games.trivia! 0
rec.games.video: 1-5015
xrec.gardens! 0
rec.guns! 0
rec.ham-radio! 0
rec.ham-radio.packet! 0
rec.humor! 0
rec.humor.d! 0
rec.mag! 0
rec.mag.otherrealms! 0
rec.misc! 0
rec.motorcycles! 0
xrec.music.classical! 0
xrec.music.folk! 0
xrec.music.gaffa! 0
xrec.music.gdead! 0
xrec.music.makers! 0
xrec.music.misc! 0
xrec.music.synth! 0
xrec.nude! 0
xrec.pets! 0
rec.photo! 0
xrec.puzzles! 0
?rec.railroad! 0
rec.scuba! 0
rec.skiing! 0
rec.skydiving! 0
rec.sport.baseball! 0
rec.sport.basketball! 0
rec.sport.football! 0
rec.sport.hockey! 0
rec.sport.misc! 0
rec.travel! 0
rec.video! 0
rec.woodworking! 0
Xrec.equestrian! 0
rec.games.programmer: 1-1573
rec.games.vectrex! 0
rec.mag.fsfnet! 0
rec.arts.int-fiction! 0
rec.music.beatles! 0
rec.humor.funny! 0
rec.humor.spc! 0
rec.arts.anime! 0
rec.music.bluenote! 0
rec.games.moria! 1-3435
rec.autos.sport! 0
rec.folk-dancing! 0
rec.music.cd! 0
xrec.backcountry!
xrec.music.dementia!
rec.ham-radio.swap! 1-22
rec.arts.misc!
rec.models.rc!
rec.games.rpg! 1-27
rec.music.newage!
rec.arts.tv.uk!
rec.gambling!
rec.sport:
rec.food: 1-2
xrec.music.dylan!
rec.org.sca!
rec.radio.shortware!
rec.radio.shortwave!
rec.models.rockets!
bit.listserv.cumrec-l!
rec.sport.soccer!
rec.aquaria!
rec.sport.pro-wrestling: 1-421
rec.audio.high-end!
rec.arts.startrek.info!
Stephen White
} ---I dropped news.groups out of the distribution. let's not piss *EVERYONE*
} off!!---
Sorry, my mistake.
} I hadn't figured out a good way of preventing a creep from making a
} loop, though. (other than to toad them ;-)
[ie., one "TinyMUD II" program referencing another which references the
first one, etc.]
TinyMUCK looks for loops at link-time. That is, as soon as you give
a list of destination (objects, rooms, links, etc.), it recursively
descends the link tree for each new destination, looking for the new
link. If a loop is discovered, the link destination is ignored.
Presumably this could be extended to "TinyMUD II", so that any new
program would check to see that any programs _it_ calls do not
reference the source program.
} The biggest problems I saw was I watched activity in tiny*. Most
} of it is social - most objects 'mere' props. Fancy things would be nice,
} but the system I was writing would do symbol table scans constantly. Not
} a pretty picture. The big advantage, I suppose, would be that once an
} engine like mine was working, you could pare it or add to it depending on
} the type of use it got. If 90% of the use was social, then you drop all
} the fancy commands and magic spells out of the system table, limit the
} number of objects that can fit in a room (by writing the limit into the
} system 'drop' function) and presto! away you go.
I believe part of the reason that most activity in TinyMUD is social
is simply because the puzzle-making capabilities are limited. (Also
'cause MUDders are such a groovy bunch of people!) I see the
capabilities of a hypothetical "TinyMUD II" as allowing the creation
of complex puzzles (perhaps they even deserve the title 'adventures')
from _within the database itself_ (as in TinyMUD), and that people can
connect to it without having to compile/run it on their local machine.
Also, once an adventure is created, you have a willing group of
play testers to try it out and give feedback. As Asp mentioned, there
are a great number of adventure-creation languages available, all of
them virtually unused. "TinyMUD II" would present a fairly powerful
adventure-creation environment with the above-mentioned advantages.
Perhaps adventure room/areas could be flagged as such, so that the
command-searching capabilities could be limited in social areas. I
don't know what the boundaries are in terms of CPU.
Anton Rang
>600 small? Generally 100 is considered the threshhold for newsgroup
>creation.
Nope. 600 is VERY small. The "100" is the threshold for yes/no
votes; I've seen estimates of 1000-1500 or so as the "break-even
point" for when newsgroups are more effective (but don't count on this
being accurate or anything).
>rec.games.programmer is a little too general for specific
>discussions of the implementation of one game.
Not really...it doesn't have that much traffic.
Anton
+---------------------------+------------------+-------------+
| Anton Rang (grad student) | ra...@cs.wisc.edu | UW--Madison |
+---------------------------+------------------+-------------+
Heresiarch
> In article <71...@mentor.cc.purdue.edu> g...@mentor.cc.purdue.edu (Ford Prefect) writes:
>>600 small? Generally 100 is considered the threshhold for newsgroup
>>creation.
>
> Nope. 600 is VERY small. The "100" is the threshold for yes/no
> votes; I've seen estimates of 1000-1500 or so as the "break-even
> point" for when newsgroups are more effective (but don't count on this
[....]
i fail to understand why the mud community wishes to attract more attention.
tinyMUD crashes often enough due to database bloat. what if we suddenly hit
100% propagation? if i remember, tinyMUD is about 25k away from "cataclysm",
where the wizard compresses the database by throwing out lots of unused players
and objects.
i vote no until the programs are advanced enough that they don't crash so
often, our nets stable enough that we can reach the games reliably, and the
games themselves comfortably established on machines with lots of memory and
the blessings of the site administrators.
try again next year.
ashne
_______________________________________________________________________________
Organization: Grand People's Fascist Monarchy of Nebutu (The Sprawling Chaos)
lbu...@eagle.wesleyan.edu_|__all the time you know she's smiling_| Heretics
lbu...@wesleyan.bitnet____|__you'll be on your knees tomorrow.___| need no
ex...@beeblebrox.mit.edu__|__________________________-steely dan_| disclaimers!
Lars Pensj|
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.
la...@myab.se
--
Lars Pensj|
la...@myab.se
Steve Morris
|Demon-Spawn. The Administrator of TinyMich.
|
|What harm could a rec.games.mud cause?
|
|Well just judge for yourself.
|
|rec.food.drink! 0
|rec.food.recipes! 0
|rec.food.veg! 0
If you are trying to imply that rec.food.veg has no traffic than I would
say that all the rest of your number stand to be wrong also. I have
approximately 60 unread postings in rec.food.veg here at U of Delaware
out of 3487 total postings during the history of that group here.
Steven Morris
s...@sun.acs.udel.edu