June 1997
- UNSUBSCRIBE Dan Armstrong
- Resets, langs, and quests ashen
- [RP v. Power Gaming v. Pkilling] Jeff Kesselman
- [RP v. Power Gaming v. Pkilling] Caliban Tiresias Darklock
- RP: TIime to define Jeff Kesselman
- RP: TIime to define Caliban Tiresias Darklock
- Reasonable danger [was Alright... IF your gonan do DESIESE...] Matt Chatterley
- Reasonable danger [was Alright... IF your gonan do DESIESE...] Marian Griffith
- Administrative posting coder@ibm.net
- Administrative posting Jeff Kesselman
- Administrative posting coder@ibm.net
- PKilling (was Life) Brandon Gillespie
- A quick apology... Jeff Kesselman
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Jon A. Lambert
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Jon A. Lambert
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Jon A. Lambert
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Adam Wiggins
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Jon A. Lambert
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Adam Wiggins
- The reality of constant combat?? Caliban Tiresias Darklock
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? Adam Wiggins
- The reality of constant combat?? Jeff Kesselman
- The reality of constant combat?? clawrenc@cup.hp.com
- The reality of constant combat?? Ling
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based Nathan Yospe
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Huibai
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based Adam Wiggins
- Room-based vs. coordinate-based Chris Gray
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based Jon A. Lambert
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Nathan Yospe
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Nathan Yospe
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based Brandon J. Rickman
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based Brandon J. Rickman
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Alex Oren
- Room-based vs. coordinate-based Shawn Halpenny
- Room-based vs. coordinate-based Brandon J. Rickman
- Room-based vs. coordinate-based coder@ibm.net
- Room-based vs. coordinate-based Brandon J. Rickman
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Marian Griffith
- Room-based vs. coordinate-based S001GMU@nova.wright.edu
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based S001GMU@nova.wright.edu
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Brandon J. Rickman
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Miroslav Silovic
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based coder@ibm.net
- Room-based vs. coordinate-based Miroslav Silovic
- Room-based vs. coordinate-based Chris Gray
- Room-based vs. coordinate-based clawrenc@cup.hp.com
- Room-based vs. coordinate-based Jeff Kesselman
- Room-based vs. coordinate-based Chris Gray
- Life Jamie Norrish
- Life Ling
- Life ashen
- Life Matt Chatterley
- Life Jeff Kesselman
- Life clawrenc@cup.hp.com
- Life Jeff Kesselman
- Life Marian Griffith
- Life Adam Wiggins
- Life Jeff Kesselman
- Life clawrenc@cup.hp.com
- Life Jeff Kesselman
- Reasonable danger [was Alright... IF your gonan Adam Wiggins
- RP/PG examples Caliban Tiresias Darklock
- RP/PG examples Jeff Kesselman
- RP/PG examples Adam Wiggins
- RP/PG examples Caliban Tiresias Darklock
- RP/PG examples Jeff Kesselman
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Nathan Yospe
On Wed, 4 Jun 1997, Caliban Tiresias Darklock wrote:
:On Wed, 4 Jun 1997 20:02:47 PST8PDT, Adam Wiggins
:<nightfall@inficad.com> wrote:
:>Hmmm, methinks we ought to get our terms straight. I use mud (capped or
:>not) to group Tiny, LP, Diku, and everything else we think of as
:>being online, text-based role-playing games into one giant lump.
:I used to do that. Then I figured out that they were so outrageously
:different that a MUSH and a MUD were entirely different animals.
Bullshit. Had to be said. There is nothing exceptionally special about
tinys. Its a matter of degree. Familiar with LPMOO? You could model a MOO
or MUSH under Physmud++, with about the same amount of work it would take
to model a Diku or an LP. As a matter of fact, there was a Tiny at one
point that modeled a Diku. There is NO justification for this degree of
seperatism. Elitism sucks, and I have never seen anyone who claimed that
Tinys were not muds who didn't suffer from a healthy dose of elitism.
:>If I wish to reference a specific codebase (MUSH, MOO, Diku, MUX, LP,
:>Abber, Ya..) I will do so. You seem to use MUD as anything that is not
:>a Tiny?
:Pretty much. If the foo shits...
Sometimes you really annoy me. There is a huge spectrum out there. Get
familiar with more than a couple of colors before you form your opinions,
would you?
:As examples, I'm going to use TinyMUSH and SMAUG, which are the two
:things I happen to have on my hard drive at the moment. Note that this
:is not meant to be an argument that 'SMAUG is crap' nor that 'Tiny is
:king'. These examples are just that; examples. Period. They are not
:intended as any kind of reflection upon the specific server in question,
:but you want specifics, here they are.
:>> much of any modification to a MUD, you have to drop into the hardcode
:>> and muck around, usually breaking something. When you do go trying to
:>Are you familiar with LPC? I'm fairly certain LP counts as a mud, regardless
:>of your terms.
:No, I'm not familiar with LPC. In order to get familiar with it, I would
:need to have some way of running an LP someplace so I could futz around
:with it. I don't have that kind of resources to invest in something that
:pointless.
Last I checked, DGD LPs were a lot more efficient than MOOs. Not that it
means that much... LPs are best experienced on someone else's machine.
They are that sort of animal.
:>What you seem to be thinking of as muds are worlds with fixed physical
:>characteristics. These are not changable. If you drop something, it
:>will break. Coding around this is a major hack. If you wish to add
:>a material type 'ether' which has no substance, feel free.
:What the hell are you talking about?
He is saying that, in a lot of Dikus, changing hardcoded aspects becomes a
game of hack the pasta. I think. Dikus are not the high point of muds.
They are a nasty accumulation on the sides of the pipe.
:>I grant you that some codebases that attempt this don't do it very
:>well. Diku is now 8 years old, and showing it's age, I'd say.
8 years old, and not designed to change, is the problem. I mean, Tiny and
LP are not young either. Or all that good, I think. But they have at least
been ground-upped a few times.
:>> I created a fountain in the middle of one of my areas. It
:>> doesn't load up into the game when I start the server, though.
:>Totally unrelated to any sort of source-level programming in any
:>codebase I've ever seen.
:It wasn't intended to be source level. However, I could post the code
:necessary to add a new class if you like.
And this is not universal, either. Even before Physmud++, I rewrote Rom
enough for Singularity 1 that just about everything that had configuration
was configurable without restarting the game or changing any code. Races,
classes, areas, rooms, and so forth...
:>Only possible flaw is somewhere in the area
:>definition file - likely they have the fountain in the wrong place, set
:>to load up after a fixed amount of time, or just have an object other
:>than the fountain set for loading.
:Well, gee. Why does this never seem to happen under Tiny? Could it be
:that maybe the interface is cryptic, undocumented, and difficult to
:understand?
Hello? It happens plenty under Tiny. Almost as much as under more advanced
Dikus. Just because you already got over that hump with one, and not the
other... The documentation for both off and on line creation for Roms, at
least, was fairly good. And I wrote an 80 page hypertext document for my
own system for Singularity. Its not at all how you portray it... the
problems with Dikus stem from a lack of complexity, not an overbearing
degree of it, in the creation process.
:>If people can't figure this out,
:>they have no business whatsoever running a mud.
:Oh, piffle. I hear this all the time. "Why are you running a MUD if you
:don't already know all this?" -- well, because NO ONE WILL TELL YOU, for
:one. If you knew how it worked, well, you could cheat, or something.
No. The point is that these are things that most programmers can figure
out in under a minute. The code is hacked and spaghetti, and I REALLY hate
Diku... but I hate codebase bigots just a wee bit more.
:>Most area writers
:>I know have little to know knowledge of programming and manage to write
:>areas just fine; if you can't manage this, there's no way in hell
:>you're going to be able to handle actual source level programming.
:Most Visual Basic developers I know have little to no knowledge of
:programming. Your point?
Uh... your point? Dikus require their admins to be able to program in (non
ANSI) C. The areas are easy to pick up, and failure to pick them up in a
short order of time from an indexed document (which does exist) is about
as clear an indication of not having what it would take to learn C as I
can think of. Where does VB come into this?
:>> I did an oxlpt of the vnums to my qmrfs, and then a cdrflp of
:>> the smrflgn. After I assigned the aflexm, I unset the qrblnt
:>> flag and frmbldorped the horgn. What have I done wrong?
:>I am not familiar with this, so I can't comment.
:>Since it seems to be nonsense (if not, it was some *very* poor
:>acronym choices.. smirk), I'm not sure what solid example it serves.
:Well, okay, try this.
: First I aassigned the area to myself, and aset the hi_obj to the
: right vnum. Then I made the object and did an instaroom, ran a
: savearea, aassigned myself none, and did a foldarea.
:Still looks like nonsense. Maybe I'm too Tinified. Ummmmmmm...
: I @create'd the object and dropped it in the room.
:Gee. Which would you prefer? I kind of like the wizardly aspect of the
:first, you know, but really I kind of like to get to the business at
:hand and finish the job so I can play.
Actually, the stuff you quoted above is all security issues, and is not a
repeated performance kind of thing. Except for the create and drop, it is
done once per area. After that, the OLC system is a lot like your @create
and drop. Oh, you DO have to remember the difference between CREATING and
LOADING... template and instance. No biggie, right? You are quibbling over
symantics, all fluff and no substance.
:>A standard answer to this question would be:
:>Type 'show object fountain' to see how many are currently in existance
:>in the world. If there are none, then you have loaded the wrong object.
:What if there are some? Convenient omission there, I'd say.
Not really. If there are some, and one of them is out of place, maybe you
are loading it in the wrong location. Go kill theerrant one and then do
the following. Its just a sanity check, not a critical procedure, so the
ommision is sensible. (You almost never detail the catch block when
outlining a try/throw/catch enabled function. Mentioning that there is
exception handling present is enough.)
:>Type 'load object fountain', 'at <room> drop fountain', and 'save area
:><area>'. Might want to find out what that extraneous object you managed
:>to add was, too.
:>Is there any codebase that does *not* work like this? (Substitute in
:>@ symbols wherever you like to make the commands more familiar.)
:See the above.
What, so he had to save his changes. I still think you are nitpicking. In
a BIG way. And missing the bigger picture.
:>> (Side note: And you wonder why most MUDs use the same areas.)
:>I'd say it it because creating even a mildly worthwhile area is a time-
:>consuming and arduous task with only the somewhat nebulous reward of
:>'a job well done'.
:Interestingly, I routinely build large MUSH areas and find the process
:quite fun. I never seem to crash the server, and I can have people using
:the area before I'm even finished with it. And if I shutdown before I'm
:done, everything's automatically saved. I have never encountered a
:problem on a MUSH where anything disappeared or was misplaced. Ever. And
:yet it seems to happen routinely on MUDs.
I might add here that while I have seen few GOOD areas on Dikus, and not
many on LPs (though more), on all the Tinys I have played, there have been
NO GOOD AREAS. A decent number of passable ones, but no GOOD ones. I
always attributed this to the @create and go design philosophy. (Sub
collections of rooms for areas where appropriate.)
:>Actually learning how to create an area is trivial;
:>my friend's 12 year old brother figured out the basic format for rooms and
:>had several up and running the first day he tried. He knew nothing about
:>muds, really, so of course they were terrible. But they worked.
:Hmmmm. Let me see...
: #881
: Door to Keep~
: ~
: 0 1073741824 1
: D1
: ~
: ~
: 0 -1 880
: D7
: ~
: ~
: 0 -1 882
: D9
: ~
: ~
: 0 -1 898
: S
:Uhhhh... What? I mean, I think I can figure some of this out. It looks
:like Vnum, Name, uhhhh... something, probably a description, then um...
:gee. I think that middle number there is some, uh, flags, or something.
:D1... hmmmm... I think that might be an exit. Probably going north. D7,
:um, are we counting clockwise or counterclockwise? D9, probably down...
:the strings, I mean those are strings right? Delimited by a ~ character?
:Probably name and desc again... uh, I think those numbers are um, well,
:let me make a wild guess and say that the first one is whether it's
:locked and the second is probably the vnum of the key, and the last one
:is the vnum of where it goes. And that S probably means end of record, I
:think.
:Now then, given that info, let me see... do I want to write an area?
:Hell no. Get this thing away from me.
Off line vs on line. Do you really think you would enjoy designing a MUSH
off line? I don't. Incidentally:
#AREA [
> mindscape { // reference name 'mindscape'
F mindscape.are // saves to file 'mindscape.are'
N The Mindscape~ // named "The Mindscape" in game
A FireBrand // Author == 'FireBrand'
O mindscape2.are // Has occurance generatable alternate
}
]
#HELPS [
> {
K mindscape~ // global information database entry
D Database entry #000 - The Mindscape
A world without form, existing somewhere within the event horizon of
the singularity XBC-3201, the mindscape is under code Omega edict.
~
}
]
#ROOMS [
> central { // reference name 'mindscape:central'
R Cocooned within the heart of the gray mist~, this single occurance of
clear, open air seems strangely cool... <s1>The faint scent of thick,
dry fog wraps itself around you. </s><h4>A gentle hum fills the space
within the mist. </h><v6>Tiny beads of water drift in and out of the
near weightless center of the space, a rainbow trapped within each
gleaming sphere. </v>
~
// default atmosphere = earth normal
T none // no ground
G .25 // quarter strength gravity
// default temperature = room temp
D -1 mist { // an exit set for all directions to 'mindscape:mist'
L The mist is inpenetrably thick.
~
M As you approach the mist, tendrils seem to reach out for you,
enveloping you in cool dampness. A final step, and it closes behind you.
~
L $n disappears into the mist.
~
E <h2>A faint sucking sound reaches your ears. </h>Something seems to
have entered the mists. <v1>A shape resolves itself to your eyes as $n.
</v>
~
}
}
]
#FIELDS [
> mist {
@ 0 0 0
D -1 central{
L A ^b glow illuminates the curling mist.
~
M The mist parts, and sudden light, almost blinding, stuns you.
~
E $n steps out of the mist.
~
}
@ -10 0 0
I rock
@ 10 10 0
I puddle
}
]
#ITEMS [
> rock {
N rock stone~
S $a rock~
L A rock juts out of the mist.
~
D There is nothing particularly extraordinary about this rock, outside
of its location. It looks strangely massive, as if it were too real.
~
C stone
M 10000
S 50 50 50
}
> puddle {
N puddle water~
S $a puddle~
L A puddle of water has pooled in the mist.
~
D It looks like an unusually pure puddle of water.
~
C water
M 100
V 1000
}
]
Looks terrible, doesn't it? Good thing the builders get to use an arrow
driven interface that conceals all this. And, no, this is not the worst.
This example has nearly zero markup.
:>> This is an interface problem. As I've said before, RPers want to get to
:>> the business of playing the game. In order for a MUD admin to get areas
:>Hum...is there anyone that doesn't? This statement is the equivlent of,
:>"Most RPers dislike intense and prolonged physical pain" or "Most RPers
:>type with both hands." :)
:Me, I like being able to use a simple and understandable command that
:does what it says it does. @create creates an object. @dig digs a room.
:@link links this room to another room. None of this annoying
:rcreate/pcreate/ecreate/ocreate crap. @set is @set. Not mset, rset,
:oset, aset, or anything else. Just @set. Bam, done. @set works with
:anything; attribs, flags, multiple objects. It makes sense.
Uh... what's the difference, really? No, I mean, really? Aside from the
obvious design flaws in Diku (the way they define rooms, areas, mobs, and
objects) the differences are all symantic, and not even very large
symantic differences. rcreate == @dig, you see. A Diku builder might well
wonder why you differentiate room creation from object creation with a
word like "dig" of all things? And what the hell is with all of these '@'
symbols? Why not just make them regular commands? </diku builder>
:>> built, he has to gain a pretty intimate familiarity with the internals
:>> of the code, hack the server itself all to hell, and spend hours on end
:>> playing with these unintuitive and mostly undocumented commands to get
:>> his areas up and working. The reset syntax for areas is a total mess and
:>> looks almost like line noise.
:>Still trying to figure out what codebase you're refering to. I've
:>worked with just about every one in existance (and a few that aren't,
:>yet, in existance) and I've never encountered what you're referring
:>to here,
:Hmmmmmm....
:
: E 0 818 0 9
: M 0 813 1 877
: E 0 811 0 16
: G 1 824 1
: G 0 802 0
: M 0 814 1 879
:You know, you're right. That's *perfectly* intuitive. I don't see why I
:never noticed how easy it was before.
What, is that the old style resets? Those were godawful. I released a
patch for Rom, way back when, to massively restructure resets, making them
room based and fully nested. And functionally room based too. I know Its
in use by a few of them, at least. (I released several patches.
Canibalized Sing1 for them. After all, I hacked so many fixes, might as
well let SOMEONE make use of them.)
:>nor do I see what it as to do with "RPers".
:It has nothing to do with RPers. It has to do with why MUDs are better
:suited for powergaming, and MUSHes are better suited to RP.
Get it through your head... there is no black and white here, its all in
your mind.
:>> I think there is a LOT of potential for MUDs as an RP environment. The
:>Me too. For instance, most of the stuff in the MUSH side of the mud family
:>does pretty well, though I think it could be done a lot better. That's
:>part of what bugs me about muds - they only show how much more can
:>really be done with the medium.
:The major drawback to MUSH servers is that they require you to basically
:reimplement EVERYTHING. Even the core game system is absent.
*shrug* Some LPs are like that too. Strangely enough, LPs that implement
from that point tend to be more unique than the MUSHes that do the same.
:>> problem is mainly that huge bunch of stuff you have to learn; it's not
:>> like gaming, it's like computer science. What this ends up meaning is
:>Mudding is complex, agreed. I like this; it's not Doom or Duke Nukem.
:Actually, I can play a MUD using a basic familiarity with four to six
:commands. However, building on one involves crawling through mailing
:lists and newsgroups looking for someone who will quit insulting me long
:enough to tell me something useful. There aren't many docs, after all,
:and the ones there are have gotten pretty far out of date.
*shrug* I took the thing out of the box, played with it, and a few months
later, had one of the most unique Dikus in existance. Then again, there is
an assumption here... a natural talent for programming. You see, the way I
figure it is, if you are asking others, you are stuck with what they have
done. I don't LIKE what they have done. So I do what I want to do, and
would have had to pave my way anyway.
:>Learning how to step into the role of a character in a world which is
:>somewhat similar but mostly very different from our own is a big enough
:>step, but on top of that you most learn to view this world through the
:>somewhat limited window of endless scrolling text. 'Tis no wonder
:>that the community stays as small as it has despite the internet
:>exploding.
:I'd chalk it up more to the number of arrogant dorks who tell you how
:stupid you are when you ask a question. Plenty of people are perfectly
:capable of stepping right into this sort of thing.
Hmmm. Role Playing is easy, right off the bat. Design is hard, right off
the bat. Uh huh. Ever stop to think that the community is not homogeneous?
:>> that the type of person who makes a good RP-centric game designer is not
:>> generally the type of person who makes a good MUD builder, and the
:>> converse also holds. The learning curve is steep. The problem is not so
:>Hmmm, don't know that this is true. I've found that a good builder is a
:>good builder, and a good builder is a hell of a hard thing to find.
:Well, if someone would DOCUMENT THE INTERFACE maybe we could RTFM.
*sigh* There is always the "get it from the code" approach.
:>In my mind it's identical to a good author - they may have their strengths
:>and weaknesses (fiction/non-fiction, sci-fi/fantasy/modern day/western,
:>tragedy/romance/heroic/horror) but generally a good writer is a good writer
:>at whatever they choose to try their hand at.
:That's because they write in one language that has documented and
:accepted rules, instead of forty incompatible half-assed command formats
:that nobody ever wrote down.
Not true. I'm a writer. Writing muds is a simple (oh, so simple)
extension of that. Now, programming a mud to write itself, for the most
part, which is what I am trying to do, is a bit harder... but I'm getting
there. See, most of the design of the mud is done on paper, then
translated. Translation does suffer in some ways, of course. There are few
choices available, there is no way to express the feeling of an open
prairie (why the hell do you think I have designed such a hard core code
consistant base?) or whatever. Linearity suffers when you have to account
for human variables.
:>> much that the commands themselves are bad, but that there's too little
:>> documentation and what there is tends to be incompletely indexed.
:>Oh, yes. An offshoot of being a part-time project of college kids who
:>generally only want to fool around with things that are fun for a while,
:>and then move on. Something like keeping docs up to date isn't really
:>all that much fun.
:Then you shouldn't be writing a MUD.
Nah, just means you shouldn't be releasing your code.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu - RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Ling
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Marian Griffith
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Marian Griffith
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Nathan Yospe
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Nathan Yospe
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD Matt Chatterley
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Jon A. Lambert
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Brandon Cline
- RP=MUSH/PG=MUD coder@ibm.net
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD Adam Wiggins
- RP=MUSH/PG=MUD Jeff Kesselman
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Martin Keegan
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Chris Gray
- RP=MUSH/PG=MUD Nathan Yospe
- RP=MUSH/PG=MUD Caliban Tiresias Darklock
- RP=MUSH/PG=MUD clawrenc@cup.hp.com
- RP=MUSH/PG=MUD Marian Griffith
- RP=MUSH/PG=MUD Nathan Yospe
- RP=MUSH/PG=MUD Matt Chatterley
- Computers can't.... Jeff Kesselman
- Computers can't.... Caliban Tiresias Darklock
- Computers can't.... Jeff Kesselman
- Combat and Roleplay Jeff Kesselman
- Combat and Roleplay clawrenc@cup.hp.com
- Death Jeff Kesselman
- Learning Todd Lair
- Message problems with this list coder@ibm.net
- Greetings Koster, Raph
- Another Introduction... Travis S Casey
- Lorry's document on wizard-hood clawrenc@cup.hp.com
- Lorry's document on wizard-hood Jeff Kesselman
- Lorry's document on wizard-hood clawrenc@cup.hp.com
- Threaded rand() Ling
- I have no words and I must design clawrenc@cup.hp.com
- I have no words and I must design Adam Wiggins
- TSR has been bought. Jeff Kesselman
- DESIGN: The Physics of Magic coder@ibm.net
- over the shoudler view Jeff Kesselman
- Re:[DESIGN] the physcis of magic. Jeff Kesselman
- RIME/Fido nolstalgia Adam Wiggins
- a definition of role-playing Travis S Casey
- [RP] The thoughful player Jeff Kesselman
- web archive for MUD Design List ? Dmitri Kondratiev
- web archive for MUD Design List ? clawrenc@cup.hp.com
- web archive for MUD Design List ? Dmitri Kondratiev
- web archive for MUD Design List ? clawrenc@cup.hp.com
- [WotC TSR buyout] WotC Survey Jeff Kesselman
- The laws of probability coder@ibm.net
- The laws of probability Chris Gray
- The laws of probability coder@ibm.net
- The laws of probability clawrenc@cup.hp.com
- The laws of probability Adam Wiggins
- The laws of probability clawrenc@cup.hp.com
- The laws of probability clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) Chris Gray
- "short" Introductory Message (fwd) Jeff Kesselman
- "short" Introductory Message (fwd) Chris Gray
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) coder@ibm.net
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) Chris Gray
- "short" Introductory Message (fwd) Marian Griffith
- "short" Introductory Message (fwd) Jeff Kesselman
- "short" Introductory Message (fwd) Marian Griffith
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Nathan Yospe
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) Simon Miller
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Matt Chatterley
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) Marian Griffith
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Jeff Kesselman
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Jon A. Lambert
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Martin Keegan
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) clawrenc@cup.hp.com
- "short" Introductory Message (fwd) Simon Miller
- "short" Introductory Message (fwd) Caliban Tiresias Darklock
- "short" Introductory Message (fwd) Jeff Kesselman
- "short" Introductory Message (fwd) Martin Keegan
- Physical Space Representation Mathue Moyer
- Physical Space Representation coder@ibm.net
- "From Kansas to Oz" Chris Gray
- "From Kansas to Oz" clawrenc@cup.hp.com
- "From Kansas to Oz" Jeff Kesselman
- "From Kansas to Oz" clawrenc@cup.hp.com
- "From Kansas to Oz" Jeff Kesselman
- "From Kansas to Oz" clawrenc@cup.hp.com
- "From Kansas to Oz" Miroslav Silovic
- "From Kansas to Oz" clawrenc@cup.hp.com
- "From Kansas to Oz" Jeff Kesselman
- "From Kansas to Oz" coder@ibm.net
- "From Kansas to Oz" Brandon Gillespie
- "From Kansas to Oz" clawrenc@cup.hp.com
- Text output [was "short" Introductory Message (fwd)] Matt Chatterley
- (fwd) RESEARCH: Why do you admin a Mud? clawrenc@cup.hp.com
- Genuinely brief intro Dr. Cat
- Genuinely brief intro Jeff Kesselman
- Genuinely brief intro Chris Gray
- Genuinely brief intro Jeff Kesselman
- Genuinely brief intro Dr. Cat
- Genuinely brief intro Koster, Raph
- Genuinely brief intro Jeff Kesselman
- Genuinely brief intro clawrenc@cup.hp.com
- Genuinely brief intro Jeff Kesselman
- Genuinely brief intro Dr. Cat
- Commercial interests and rules clawrenc@cup.hp.com
- mention from Mud-Dev clawrenc@cup.hp.com
- Intellectual property Caliban Tiresias Darklock
- Intellectual property Jeff Kesselman
- Digest support coder@ibm.net
- List message losses coder@ibm.net
- Testing. coder@ibm.net
- Persistancy Matt Chatterley
- Name/language generation Oliver Jowett
- Name/language generation Brandon Cline
- Name/language generation Chris Gray
- Name/language generation Shawn Halpenny
- Name/language generation Brandon Gillespie
- Name/language generation Martin Keegan
- Name/language generation Jamie Norrish
- Name/language generation Jeff Kesselman
- Git out the boar spear, Martha! Chris Gray
- Git out the boar spear, Martha! Nathan Yospe
- Git out the boar spear, Martha! clawrenc@cup.hp.com
- Git out the boar spear, Martha! Matt Chatterley
- Git out the boar spear, Martha! Adam Wiggins
- Git out the boar spear, Martha! Matt Chatterley
- Git out the boar spear, Martha! clawrenc@cup.hp.com
- Git out the boar spear, Martha! Jon A. Lambert
- Git out the boar spear, Martha! Nathan Yospe
- Git out the boar spear, Martha! clawrenc@cup.hp.com
- Git out the boar spear, Martha! clawrenc@cup.hp.com
- Git out the boar spear, Martha! Matt Chatterley
- Git out the boar spear, Martha! Chris Gray
- Git out the boar spear, Martha! Nathan Yospe
- Git out the boar spear, Martha! Matt Chatterley
- Git out the boar spear, Martha! Matt Chatterley
- Population container Wout Mertens
- Population container Brandon Cline
- Population container Jon A. Lambert
- Population container Chris Gray
- Population container Nathan Yospe
- Population container clawrenc@cup.hp.com
- Population container Wout Mertens
- Population container clawrenc@cup.hp.com
- Population container Wout Mertens
- Population container Chris Gray
- Population container Nathan Yospe
- Population container clawrenc@cup.hp.com
- Dragons... size and history Nathan Yospe
- Dragons (Couldn't resist) Nathan Yospe
- Heroes Nathan Yospe
- Alright... IF your gonan do OWLs... Nathan Yospe
- Black Rabbit & Vworlds-biz mail list Frank Crowell
- Supporting RP+PG Huibai
- Supporting RP+PG Jeff Kesselman
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG Huibai
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG clawrenc@cup.hp.com
- Supporting RP+PG Huibai
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG Marian Griffith
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG Chris Gray
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG Matt Chatterley
- Supporting RP+PG Adam Wiggins
- Supporting RP+PG Miroslav Silovic
- Supporting RP+PG Adam Wiggins
- Supporting RP+PG Jon A. Lambert
- Supporting RP+PG Caliban Tiresias Darklock
- Supporting RP+PG Huibai
- Supporting RP+PG Matt Chatterley
- Integrating PK Matt Chatterley
- Integrating PK Marian Griffith
- Integrating PK Adam Wiggins
- Integrating PK Marian Griffith
- Integrating PK Jeff Kesselman
- Integrating PK clawrenc@cup.hp.com
- Integrating PK Jeff Kesselman
- Integrating PK Matt Chatterley
- Integrating PK Adam Wiggins
- Integrating PK Matt Chatterley
- Integrating PK clawrenc@cup.hp.com
- Integrating PK Alex Oren
- Integrating PK Caliban Tiresias Darklock
- Integrating PK Shawn Halpenny
- Integrating PK Nathan Yospe
- Integrating PK Matt Chatterley
- Integrating PK Matt Chatterley
- Integrating PK Adam Wiggins
- Integrating PK Matt Chatterley
- Integrating PK Jeff Kesselman
- Integrating PK Matt Chatterley
- Integrating PK Jeff Kesselman
- Integrating PK Jon A. Lambert
- Integrating PK Jeff Kesselman
- Integrating PK Matt Chatterley
- Integrating PK Matt Chatterley
- Integrating PK Adam Wiggins
- Integrating PK Adam Wiggins
- Integrating PK clawrenc@cup.hp.com
- Integrating PK Adam Wiggins
- Integrating PK Matt Chatterley
- Integrating PK Martin Keegan
- Integrating PK Matt Chatterley
- common server design Chris Gray
- common server design Caliban Tiresias Darklock
- common server design Chris Gray
- common server design Caliban Tiresias Darklock
- common server design Chris Gray
- common server design Jeff Kesselman
- common server design Jon A. Lambert
- common server design Caliban Tiresias Darklock
- common server design Jeff Kesselman
- common server design Alex Oren
- common server design Jeff Kesselman
- common server design Cynbe ru Taren
- common server design Jon A. Lambert
- common server design Chris Gray
- common server design Caliban Tiresias Darklock
- common server design Chris Gray
- common server design clawrenc@cup.hp.com
- common server design Caliban Tiresias Darklock
- common server design clawrenc@cup.hp.com
- common server design Martin Keegan
- common server design clawrenc@cup.hp.com
- common server design Cynbe ru Taren
- common server design clawrenc@cup.hp.com
- common server design clawrenc@cup.hp.com
- Re: Jeff Kesselman
- The Difference between.. Jeff Kesselman
- The Difference between.. Adam Wiggins
- The Difference between.. Jeff Kesselman
- The Difference between.. clawrenc@cup.hp.com
- The Difference between.. Jeff Kesselman
- (subject missing) mud-dev@null.net
- Neighborhoods (was room-based v coord-based) S001GMU@nova.wright.edu
- Neighborhoods (was room-based v coord-based) Brandon J. Rickman
- Pen-and-paper and Computer-based systems Alex Oren
- User Interface (was: RP=MUSH/PG=MUD) Shawn Halpenny
- Rumours Marian Griffith
- Levels and XP Huibai
- Levels and XP Martin Keegan
- Levels and XP Simon Miller
- Levels and XP Huibai
- Levels and XP Nathan Yospe
- Levels and XP Matt Chatterley
- Meta clawrenc@cup.hp.com
- non pk dealing with conflicts Marian Griffith
- Integrating PK Brandon Cline
- Integrating PK Huibai
- Integrating PK Brandon Cline
- Integrating PK Huibai
- Integrating PK Nathan Yospe
- Integrating PK Cynbe ru Taren
- Integrating PK Chris Gray
- Integrating PK clawrenc@cup.hp.com
- Integrating PK Jon A. Lambert
- noise Alex Oren
- Neighborhood watch clawrenc@cup.hp.com
- Neighborhood watch Nathan Yospe
- Neighborhood watch Chris Gray
- Neighborhood watch Nathan Yospe
- Neighborhood watch Brandon J. Rickman
- Neighborhood watch clawrenc@cup.hp.com
- Neighborhood watch Chris Gray
- Neighborhood watch clawrenc@cup.hp.com
- Mob AI Brandon Cline
- Hardcore server design Alex Oren
- Hardcore server design clawrenc@cup.hp.com
- [NOISE] common server design Martin Keegan
- try it out! Chris Gray
- Population container Wout Mertens
- Population container clawrenc@cup.hp.com
- Population container Raz
- Population container clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Jon A. Lambert
- Level abstractions - Realism vs Game Issues Caliban Tiresias Darklock
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Jon A. Lambert
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Marian Griffith
- Level abstractions - Realism vs Game Issues Jon A. Lambert
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Martin Keegan
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Adam Wiggins
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Nathan Yospe
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Nathan Yospe
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Level abstractions - Realism vs Game Issues Nathan Yospe
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Martin Keegan
- Level abstractions - Realism vs Game Issues Adam Wiggins
- Level abstractions - Realism vs Game Issues Jeff Kesselman
- Level abstractions - Realism vs Game Issues Adam Wiggins
- Level abstractions - Realism vs Game Issues Jon A. Lambert
- Level abstractions - Realism vs Game Issues Nathan Yospe
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues Nathan Yospe
- Level abstractions - Realism vs Game Issues Matt Chatterley
- Level abstractions - Realism vs Game Issues clawrenc@cup.hp.com
- Flexible, Modular Server Design Brandon Cline
- Flexible, Modular Server Design Jeff Kesselman
- Flexible, Modular Server Design Chris Gray
- Another Approach (was: Integrating PK) Brandon Gillespie
- Another Approach (was: Integrating PK) Jon A. Lambert
- Another Approach (was: Integrating PK) Nathan Yospe
- Another Approach (was: Integrating PK) clawrenc@cup.hp.com
- Level abstractions Huibai
- Alright... IF your gonna do Disease... Jon A. Lambert
- thread splitting Alex Oren
- thread splitting coder@ibm.net
- thread splitting coder@ibm.net
- thread splitting Caliban Tiresias Darklock
- Senses & geographical events Wout Mertens
- Senses & geographical events Chris Gray
- Senses & geographical events clawrenc@cup.hp.com
- Additions to sensory planes Wout Mertens
- Nation of shopkeepers Martin Keegan
- Nation of shopkeepers Huibai
- Nation of shopkeepers Jeff Kesselman
- Nation of shopkeepers Adam Wiggins
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Jeff Kesselman
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Marian Griffith
- Nation of shopkeepers Jeff Kesselman
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Marian Griffith
- Nation of shopkeepers clawrenc@cup.hp.com
- Nation of shopkeepers Marian Griffith
- Nation of shopkeepers Brandon Van Every
- Nation of shopkeepers Jon A. Lambert
- Nation of shopkeepers Marian Griffith
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Marian Griffith
- Nation of shopkeepers Jeff Kesselman
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Adam Wiggins
- Nation of shopkeepers clawrenc@cup.hp.com
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Adam Wiggins
- Nation of shopkeepers Adam Wiggins
- Nation of shopkeepers Alex Oren
- Nation of shopkeepers Matt Chatterley
- Nation of shopkeepers Chris Gray