I'm new to MUDs and IF.
As far as IF: I am interested in understanding the IF community's
connection with the MUD community and wondering why a MUD code
base doesn't get used for IF creation. (See Hitchiker's Guide on a
MOO ref below.) I would basically like to be able to create
multi-player IF "game". Seems like a reasonable goal...
And as far as MUDs: not into the "gaming" aspect of it so much as
I am interested in the possibilities for using the paradigm as
either 1) a tool for education, or 2) a tool for creating interactive
fiction, like the old infocom games.
(Well... ideally, educational interactive (non?)fiction, but...)
Trying to find a site that attempts to go a step further than the
"MUD hierarchy trees" and actually compare/contrast the different
Questions that come to mind include...
Are certain MUD code bases just...
1. ... easier? (coding/building/using-wise) Answer: LambdaMOO?
2. ... more powerful? (complexity of interactions) Answer: Merc1?
3. ... different? (different types of interactions)
4. What are levels? "210 levels!" "I got to level 9."
5. Could one actually implement a Inform/Infocom system
using a MUD code base? Would it be difficult? Why don't
people write IF using a MUD codebase?
6. Is "timing" a part of some/all MUDs? For example,
in this primitive MOO, timing does not exist. There is
no sense that time is passing or that past actions I took
(such as opening a window) has actually taken place.
Hitchiker's Guide to the Galaxy:
when you've logged on as a guest and type
@go #347 you end up at the beginning of the Infocom game...
about to be bulldozed.
7. Any Inform Z-machine ports to CGI allowing the serving of IF
thru HTML over the web?
In a comparison of code bases, I would be curious to see:
1. one base "world" coded in each.
2. a list of typical functionalities possible
Are these reasonable questions? I have poked around the web and
MUDs/MOOs for many, many hours trying to get up to speed and
looking for answers.
Any direct replies/posts or web resources you can recommend would be great.
Thanks in advance for the help and advice,
: As far as IF: I am interested in understanding the IF community's
: connection with the MUD community and wondering why a MUD code
: base doesn't get used for IF creation. (See Hitchiker's Guide on a
: MOO ref below.) I would basically like to be able to create
: multi-player IF "game". Seems like a reasonable goal...
In my experience, most MUD languages, even puzzle-oriented ones,
aren't as powerful as Inform or TADS. They don't have the benefit
of those languages' libraries; as a result, different regions of
the same MUD can behave very differently when it comes to even
the simplest of commands. It can give these environments a "patchwork"
feel that, for me, ruins the suspension of disbelief.
This isn't to say that there _couldn't_ be one. I just haven't
seen one, and I'm no MUD expert, even when it comes to my own.
: 6. Is "timing" a part of some/all MUDs? For example,
: in this primitive MOO, timing does not exist. There is
: no sense that time is passing or that past actions I took
: (such as opening a window) has actually taken place.
It can be. MUDs that gauge the passing of time open up opportunities
for collaborative puzzle-solving; a concept obviously absent from
single-user IF. Unfortunately, the one puzzle-oriented MUD I'm
familiar with strictly _forbid_ collaboration. I'll never quite
understand why, since the single-user puzzles were mediocre at
On ifMUD, which is really more of a MOO, there have been a few
attempts to construct two-person, timing-based puzzles. Unfortunately,
it's not the best programming environment. You might want to swing
by and check it out, though: http://fovea.retina.net:4001/
"I think there's some good stuff on the web. Unfortunately, there are
no links to it." - The House of Erotic Massage (spring edition)
Visit ifMUD: We'll pay shipping http://fovea.retina.net:4001/
Anyone who's spent any time on ifMUD can attest that "Timing!" is
indeed a huge part of it.
Adam Cadre, Anaheim, CA
: 4. What are levels? "210 levels!" "I got to level 9."
Levels are used in combat-oriented muds, which are often based on a RPG
system such as Dungeons and Dragons. Players kill NPC "monsters" (or,
sometimes, each other) and gain experience points, and sometimes money or
equipment. Whenever the character gets enough exp. and coin, he/she can
advance a level. The higher the level, the more powerful the character
is. So, basically, it's a way to simulate the fact that a character would
get better at fighting, casting spells, etc. the more practice they had.
Muds vary widely as to how many levels there are as well as how difficult
it is to attain them. One mud I played had 20 levels, and it took me
*months* to get up to level 10 (which I promptly lost by dying twice).
Another mud I tested and passed up required only 30-45 minutes to achieve
level 10. (That wasn't nearly as much fun.)
Joanna M. DeLaune
"If there should be crying that nobody hears, or hands that spill empty,
eyes that spell fear, then let me be chosen to fill those hands and dry
I guess I just find the r.g.m.* FAQ frustrating. It's very
helpful (thank's Jennifer and everyone!) with the descriptions of
the various varieties and instances of MUDs, but it's hard to get
a sense of the ease-of-use / power-of-implementation factors
(mentioned in my original post) which one can use for comparing
MUD code bases. Maybe I am asking for a flamewar, but I think
there are SOME answers which I haven't found.
For now? How to figure this out? Guess.
I am looking for an environment (environments?) that work for
producing 2 types of MUDs:
1. User driven:
One that can be a medium for freewheeling collaborative
problem-solving and analysis (and general communication)
surrounding a core group of web documents.
2. A bit more "system driven" (like IF - interactive fiction):
One that can produce IF/puzzle solving to be used by a single user or
group and one which could work for producing a question/answer
based ITS (intelligent tutoring system) with topics, hints,
prerequisite, user modeling, etc. for use with more traditional
educational topics -- Sciences & Math, literature & history...
As far as I can tell, LambdaMOO would be the way to go.
Only in case 2 would you be having to "produce lots of content to
say ahead of users" and even then, it would be closer to an
"interactive textbook" than to a "virtual world" that one would
hang out in for hours on end, so "keeping pace" would hopefully
not be a huge issue once the content of the text was produced.
the ifMUD, already mentioned. <g>
>7. Any Inform Z-machine ports to CGI allowing the serving of IF
>thru HTML over the web?
Not that I'm aware of, although there is a Zmachine in a Java applet by M
Russotto.. do a search for 'zplet' in your favorite search engine.
and that's just the way it is...
> Are certain MUD code bases just...
> 1. ... easier? (coding/building/using-wise) Answer: LambdaMOO?
Yes and no. For instance, LPmud's code base is straight forward for C
or C++ people, whereas LambdaMOO takes concepts from Forth, which
could be alien to some people. Some code bases are just plain crap
> 2. ... more powerful? (complexity of interactions) Answer: Merc1?
Both. The goals of IF systems and MUD systems are very different. Of
course, the goals of one MUD system from another are vastly different
too. (not hard to imagine, few MUDs even remotely resemble the game
that invented the term)
For instance, most IF systems have powerful parsers, but most MUDs
have only rudimentary parsers. LPmud had the best parser I've seen,
but it doesn't come close to what TADS or Inform can do without even
trying. Most chat-MUDs don't even bother with parsing.
> 3. ... different? (different types of interactions)
Yes. MUDs are essentially real-time, while IF usually is not.
Thus you interact with the games in very different ways.
You can't just walk away from a MUD to have dinner without taking
precautions that you don't get robbed or stomped on.
> 4. What are levels? "210 levels!" "I got to level 9."
Some gaming oriented MUDs have levels. These are basically how
powerful the character is. It's a stupid holdover from D&D, but
it's so simple to implement that most MUDs do it. There *are* some
gaming MUDs that don't use levels, and stick to skills and attributes
(though even then, that may get compiled down into a single number,
mostly so that players can boast to lesser players).
Chat-MUDs don't care.
> 5. Could one actually implement a Inform/Infocom system
> using a MUD code base? Would it be difficult? Why don't
> people write IF using a MUD codebase?
It would be difficult. Parsing is the biggest drawback. It's just a
lot of work compared to a good IF system. But theoretically, there's
nothing preventing it (in a good programmable MUD that is).
A MUD code base is essentially set up to be a MUD. To use the code
base and build on top of it means you're going to have a lot of stuff
that never gets used but is still taking up space. But building a MUD
code base from scratch in something like LPmud can be tedious (I've
done it, I know).
But IF systems are better suited to IF, so why go to a MUD to write
IF? The biggest reason would be to have a multi-player IF game (which
is essentially a MUD when you think about it :-). If you don't need
multi-player, why bother?
> 6. Is "timing" a part of some/all MUDs? For example,
> in this primitive MOO, timing does not exist. There is
> no sense that time is passing or that past actions I took
> (such as opening a window) has actually taken place.
Yes, many MUDs have timers. They tend to be real-time timers, but
that's not necessary. It doesn't matter for non-real-time timers,
because you can just increment a counter on every command or such.
Some MUDs have lots of things change over time. Nighttime may come on
a periodic basis, or the store will run out of times, or every week
the orcs may invade the town. This tends to confuse newbies, who
don't understand why the pub is a pile of smoldering ash when it was
just fine a little while ago :-)
I had considered doing a more TADS/Inform like MUD system once, one
that would let you do standalone single player games and full blown
MUD's in the same system. But it's been gathering dust for far too
long, and I've long burned out as far as MUDs.
But hey, you can find it from the other URL too.
For history, Cold was basically a rewrite of MOO--from the ground up--to
many of the problems MOO has (a few of which have since been fixed).
language also changed in the process but hey.
To send me email, remove the 'x' from my domain naActually:
How do you program events/objects to happen to just ONE person and no one else,
when warranted? And, on that score, if one player solves "the" puzzle of the
game, does that mean that no one else can? What if solving this puzzle required
2-3 unique components in the hands of a player and that player suddenly stops
playing the MUD?
It's that kind of logic that presents the biggest barrier.
(Implementor at work)
Erik Haugsjaa wrote:
> Greetings people,
> I'm new to MUDs and IF.
> As far as IF: I am interested in understanding the IF community's
> connection with the MUD community and wondering why a MUD code
> base doesn't get used for IF creation. (See Hitchiker's Guide on a
> MOO ref below.) I would basically like to be able to create
> multi-player IF "game". Seems like a reasonable goal...
(Post kept for those who are only catching the follow-up.)
Darin Johnson <da...@usa.net.removethis> wrote:
: "Howard A. Sherman" <ran...@excaliber.net> writes:
: > How do you program events/objects to happen to just ONE person and no
: > one else,
: > when warranted?
: Well, the problem is that you can't do the same kinds of things, but
: nothing prevents you from taking new tacks on things.
: - let some events happen to everyone. If you cause a building to fall
: into the sea, maybe it'll be gone for everyone (for a few hours maybe).
: - Think less about unique objects needed for puzzles, or ensure that
: they can't be sold in stores or left lying around (some newbie
: MUD programmers forget this).
: - Think about the problems when designing the adventure. This will
: naturally lead one to using different styles of puzzles. Ie, you
: will have difficulty translating Zork to a MUD as is, without a lot
: of work. Make sure that walking into a room that someone just left
: doesn't spell out the solution to a puzzle.
: - Make sure items can reset themselves. Allow multiple copies of
: items. This way, no one can quit the game and make the puzzle
: unsolvable for everyone else. This is mostly automatic in some
: MUDs (gaming muds), but others (chat-type muds) tend to have only
: unique objects). Make sure that unique items are either not
: required to major puzzles or that they can't be retained when one
: leaves the game.
: - only allow one player into your puzzle area at a time, and have all
: puzzle items retrieved and replaced when the player leaves.
: (alternatively, have the game make multiple copies of the rooms as
: they're entered, sort of like unix fork(), so that players won't run
: into each other; but this can be very disconcerting to players
: trying to figure out why they can't see each other)
: The biggest problem in a practical view, is you can't save games. Ie,
: you can leave and perhaps have all your inventory saved, but the world
: will change while you are gone. On most systems, more often than not
: you end up having to do a full quest/adventure in one sitting.
: A *pure* IF system would be hard in most MUDs. But theoretically, you
: could have a central area where people can see each other, but within
: each adventure they would be isolated. Most puzzles/adventures in
: MUDs are adjuncts - added interest (ie, you normally role play, but
: run into adventures or quests while doing so).
: Darin Johnson
Well... this would kind of defeat the purpose. How aboout setting up a base
camp town, and then have seperate guilds who send out parties of 2 or 3 to
jointly figure out a puzzle? (Earn money and awards for your guild by solving
puzzles etc.) Granted, it would no longer be pure Zork (or whatever you're
basing it on), but in this case it won't be anyway.
I've been thinking about a MUD lately called LiveMUD... like real life. A very
complex parser that lets you chose a historical period, location, and career.
(i.e., living in 1645 would offer much different employment then 2020). The
only two problems are that the timeline would be messed up severely, and that
it requires more computing power than we can get as of yet. (Course, by now
you think I'm a kook... and that I should probably be posting this suggestion
to a mud group...)
TAW2 on WWChat
ICQ UIN: 10836917
> Granted, it would no longer be pure Zork (or whatever you're
> basing it on), but in this case it won't be anyway.
Yes, that was my point. Adventures will have to be designed based
upon the environment they will be in. When I said "pure IF" I really
meant "interactive text adventure games as we know them".
A game world that changes based upon how far along you've played the
game is very difficult to achieve in MUDs, since you can't control
when and where the players will actually be playing. Ie, you can come
back next week and discover that all the rules have changed in the
meantime. That sort of thing doesn't happen in paper fiction, and
doesn't happen in typical IF (you don't restore a game then discover
that the curse has already overwhelmed your Aunt's mansion).
If you are referring to the historical mud, each general period would require a
different server... and they unfortunately would not be able to affect each
other due to the limitations you pointed out.
"I fought in the Great Spam Wars of the late 20th century."*
TAW2 on WWChat
ICQ UIN: 10836917
*apologies to whoever it was I took that from in alt.games.duke3d...
(One odd example - in some muds, dropping your internet connection
will often leave a motionless unmoving player. In ours, these were
made unattackable, and we didn't just remove them, since often
internet connections were dropped with no control of the player, and
they usually came back on soon. However, quite a few players took to
doing this on purpose, so that they could keep all their items.
We had a timeout that would automatically log them out after a certain
time, but I decided to be more original. Instead, I had them tossed
into what passed for the underworld in the mythos. Complete with
other players seeing the body being stolen away and all. Getting out
of that underworld took a tiny amount of thought, it wasn't a
difficult puzzle. But with all the background detail, there were a
lot of inadvertent red herrings.
When we first turned this feature on, the trapped players were at
first upset - even though we had rules about not dropping connections
for that long. They'd start to whine for hints and what not, and were
disconcerted the first time it happened to them. To them, they had
"saved the game", and now when they did a "restore" the whole world
and the way it worked seemed to have changed on them.)
>A *pure* IF system would be hard in most MUDs. But theoretically, you
>could have a central area where people can see each other, but within
>each adventure they would be isolated. Most puzzles/adventures in
>MUDs are adjuncts - added interest (ie, you normally role play, but
>run into adventures or quests while doing so).
>When I said "pure IF" I really
>meant "interactive text adventure games as we know them".
Thanks for the explanation. Otherwise I was going to rant about your narrow
definition of IF. What I don't understand is, if you have a
MUD, which does some things so much better than single-player adventures,
why would you want to use it to implement something it does so much worse?
The great thing about MUDs is they're multiplayer.
Two important consequences:
1. They've gone beyond puzzles. Playing on a good (IMHO) MUSH is about
roleplaying, not about solving puzzles. Or rather, the puzzles you solve
have no known solutions before you solve them; "solving" them means working
out the conflicts or obstacles with the other characters.
2. You're not just playing a story, you're telling a story.
This puts a whole new spin on how you view the text you're writing on a
roleplay MUSH. You take pleasure in writing good prose, and in producing
good dramatic effects for your fellow players. This will not happen in
single player IF. To accomplish this, a computer wouldn't just have to
be smart enough to tell you a story -- it would have to be smart enough
that you would enjoy telling it a story.
Shouldn't this thread move to rec.arts.int-fiction?
That's not a valid question. Sorry. What I ought to say is:
Are you aware that MUDs have great capabilities for a certain kind of
interactive fiction that single-user IF will never achieve?
Nonsense. Every good puzzle should have three solutions, two that the
creator figured out in advance and the one that the players will actually
come up with!
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... Set phasors to debug!
> The great thing about MUDs is they're multiplayer.
> Two important consequences:
> 1. They've gone beyond puzzles. Playing on a good (IMHO) MUSH is about
> roleplaying, not about solving puzzles. Or rather, the puzzles you solve
> have no known solutions before you solve them; "solving" them means working
> out the conflicts or obstacles with the other characters.
Well, MUSH is so limited, programming wise, that you almost *have* to
rely upon roleplaying. If you're looking for this type of MUD, I'd
think a MOO would be better.
But many gaming mud's (LP, Aber, the original MUD I and II that
started it all, etc) do have puzzles that do have known solutions.
Ie, they're more of a simulation.
> 2. You're not just playing a story, you're telling a story.
> This puts a whole new spin on how you view the text you're writing on a
> roleplay MUSH. You take pleasure in writing good prose, and in producing
> good dramatic effects for your fellow players.
This is the big difference between gaming muds and social muds. In a
gaming mud, you are a player. This is more like pen-and-paper RPG's,
where you have a gamemaster create a world and scenarios, and the
players then use those. This is more like a novel. In social muds, a
*shared* cooperation is important. There is no gamemaster per se, and
the players are all usually allowed to build and create for
themselves, and social collaboration is practically required. This is
not much like a novel at all.
(though the two classes overlap each other a lot)
A traditional IF game is much closer in feel to a gaming mud than to a
social mud, both in terms of playing and creating. So I sort of
assumed this was the style of muds people were talking about here.
> Nonsense. Every good puzzle should have three solutions, two that the
> creator figured out in advance and the one that the players will actually
> come up with!
True :-) One advantage a MUD has for creating over typical IF, is that
you get to watch the players as they try to solve it; and this is more
than just seeing a log of the game. And you get to discover all the
wierd and wacky ways players will try to solve your puzzle, as well as
the wierd and wacky ways the players will actually bypass your
obstacles that you had never considered (often by using items from
elsewhere on a mud).
> You get to watch the players AND CHANGE THE GAME
> as they try to solve your "puzzle".
You can, but it's not advisable. What happens is that other players
will complain. Ie, you can not be on 24 hours a day customizing the
puzzle for everyone. And players tend to get annoyed when someone
doesn't have to go through the same agony they did. (ie, sort of like
players who just say "hello sailor" to solve a classic Zork puzzle)
On the other hand, I have changed the game while players were trying
to solve it - ie, trying to add a whole new section before a friend of
mine solved it. A race sort of, between him and me. I lost :-)
> When you have a multiplayer game, you don't need ANY game mechanics at all,
> other than the ability to send messages to each other. The game master can
> decide what happens, and send out that message.
But the problem here is that the GM can't be on 24 hours a day, but
there will always be players online. This is where the programming is
critical, so that you can add lots of interesting stuff without
relying upon a human behind the curtains. This is sort of what
disappointed me about many social muds that emphasized role playing,
in that I had to make a regular appearance and log in at roughly the
same times, else I end up with no one I know on (I'm not that social,
so I don't usually care to go introduce myself all over again).
> People on this group are always thinking of automated interactive fiction;
> I'm just trying to remind them that there are great things that can be done
> with computer-facilitated (but not automated) interactive fiction.
Well, it's like a novel. Do you want to read the story, or do you
want to make it up as you go? Both have their uses, but I think most
"players" like reading a story (or having it presented to them), as
opposed to being in a place with a lot of cool props. (at least if
Therefore, IMHO, if a background and scenario is just presented, and
the players have to improvise, then I wouldn't call it IF. Although
it's a broad term, in my associations "fiction" means novels, stories,
and so forth