Connecting MUDs
Strange Journey
My MUD is a big place, but its universe is not big enough for me.
When I walk around its castles, I can feel the walls that bind me to
the one machine. I want to be able to walk off the edge of the map
and explore Darker Realms, or Defiance, or any of the hundreds of
other MUDs *out there*. I want to retain the same character from MUD
to MUD instead of having twenty copies of Sjourney all at various
levels of ability.
Imagine for a moment that technical issues could be resolved. The way
I see it, each MUD could be a country unto itself with its own
culture, but connected to the others so that one could walk across a
bridge, go through customs, and be in another place. I'd like to see
alliances, embassies with their diplomat-wizards, economies, cultural
exchanges, wars, a United MUDs. In other words, take our isolated
virtual communities and make of them a world, the most variagated,
interesting, and powerful subculture on the Net. Consider it an
evolutionary step.
Although all our code is MUD specific, we do share certain attributes
which could be abstracted. We'd need an exchange rate for XPs, SPs,
HPs, coinage, etc. No equipment would be transferred from one MUD to
another until translation was worked out. And, of course, a million
other details.
Perhaps when a player telnets (invisibly) to another MUD, a packet in
a MUD standard format is passed to the remote MUD which then would
create a character in its own code format based on those statistics,
and would write back changes when the character moved on, quit or goes
net dead for too long. Just an idea.
If anyone is already pursuing this or is interested in designing
something, please drop me a line.
Sjourney
--
sjou...@netcom.com
Travis S Casey
>
>My MUD is a big place, but its universe is not big enough for me.
>When I walk around its castles, I can feel the walls that bind me to
>the one machine. I want to be able to walk off the edge of the map
>and explore Darker Realms, or Defiance, or any of the hundreds of
>other MUDs *out there*. I want to retain the same character from MUD
>to MUD instead of having twenty copies of Sjourney all at various
>levels of ability.
Hmm... personally, I prefer to create a different character on
each MUD that I play on. How do other people feel about this?
>Imagine for a moment that technical issues could be resolved. The way
>I see it, each MUD could be a country unto itself with its own
>culture, but connected to the others so that one could walk across a
>bridge, go through customs, and be in another place. I'd like to see
>alliances, embassies with their diplomat-wizards, economies, cultural
>exchanges, wars, a United MUDs. In other words, take our isolated
>virtual communities and make of them a world, the most variagated,
>interesting, and powerful subculture on the Net. Consider it an
>evolutionary step.
Even if the technical issues can be resolved, there are also
other issues. For example, many admins may not *want* to have
such connections. For another, people might want to have multiple
"mud-nets"; there might be one for science-fiction based muds, one
for fantasy-based muds, etc.
>Although all our code is MUD specific, we do share certain attributes
>which could be abstracted. We'd need an exchange rate for XPs, SPs,
>HPs, coinage, etc. No equipment would be transferred from one MUD to
>another until translation was worked out. And, of course, a million
>other details.
Umm... most of us share those attributes. :-) I'm currently working
on a MUD which will have neither XPs nor SPs.
>Perhaps when a player telnets (invisibly) to another MUD, a packet in
>a MUD standard format is passed to the remote MUD which then would
>create a character in its own code format based on those statistics,
>and would write back changes when the character moved on, quit or goes
>net dead for too long. Just an idea.
Ig. This could get really confusing really fast. Players often
don't know who to contact with problems on the MUDs they're already
playing on... if someone wanders off to another mud and gets killed
by, say, a hill giant when they can easily take the hill giants on
their "native" MUD, chances are the native MUD's admins are the
ones who are going to take the heat...
>If anyone is already pursuing this or is interested in designing
>something, please drop me a line.
I've seen discussions of this idea before... technically,
it's a pretty hard problem to start with, especially when you
start dealing with MUDs that have made major mudlib mods.
You'd probably need to integrate the "world transport"
features with the mudlib, which would mean that only muds
with that lib would be able to use it, at least until other
mudlibs started working out some compatability thing.
Still, I see too much variation among muds and too much
confusion for the players for this.
Consider just weaponry, for example. On mud X, a chainsaw might
be assigned a weapon class of 15 or so, while on mud Y, it's
only a 10. Throw in the fact that mud X might have hill giants
that are only half as nasty as those on Y, and players going
from X to Y or vice-versa and trying to use a chainsaw on a
hill giant are not going to get what they expect.
Personally, I'm not willing to give up the freedom to do
whatever I want with my mud just so that people can transfer
the stuff they gained on another mud here, or vice-versa.
In addition, I think that too many muds are too similar
already; for example, you can find the same old OrcQuest
on dozens of muds, just like you can find tons of muds
with Star Trek areas, stuff inspired by Piers Anthony,
etc.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' confirmed cat person, sometime UNIX guru
'---''(_/--' `-'\_) No one agrees with me. Not even me.
Strange Journey
: Even if the technical issues can be resolved, there are also
: other issues. For example, many admins may not *want* to have
: such connections.
They wouldn't have to have them. No MUD police making people link up
or shut down. But for those interested in connected MUDs, why not?
: For another, people might want to have multiple "mud-nets"; there
: might be one for science-fiction based muds, one for fantasy-based
: muds, etc.
That's a cool idea. When do we start?
: >Although all our code is MUD specific, we do share certain attributes
: >which could be abstracted.
: Umm... most of us share those attributes. :-) I'm currently working
: on a MUD which will have neither XPs nor SPs.
Yes. You see I'm showing my LP bias (whoops). I'm guilty of
overstating my case. Granted there are some MUDs that just wouldn't
fit the mold enough, and they are interesting and important places.
But that they can't participate without excising what makes them
unique doesn't imply that we should abandon the idea or that they
should perform the excision. There is room enough on the net.
: ... if someone wanders off to another mud and gets killed
: by, say, a hill giant when they can easily take the hill giants on
: their "native" MUD, chances are the native MUD's admins are the
: ones who are going to take the heat...
: players going from X to Y or vice-versa and trying to use a chainsaw
: on a hill giant are not going to get what they expect.
Not getting what one expects...that sounds appealing to me, not
negative. Be careful when travelling in a foreign country. The
difference, the possible danger, is what makes travel so interesting.
Foreign lands are foreign and while MUD players might not be mature
enough now, I see no reason not to expect more from them. Help them
along with clear demarcation points and "At your own risk" signs if we
think they need it. They'll pick up on it soon enough, like learning
the visual language of movies.
: Personally, I'm not willing to give up the freedom to do
: whatever I want with my mud just so that people can transfer
: the stuff they gained on another mud here, or vice-versa.
That's why I proposed a system--perhaps with no technical basis--that
would not allow items to be transferred, only statistics. One that
created a character in each MUD's own peculiar, eccentric,
personalized code so that what tied the games together, the "world
transport" part of the driver, is the only thing that need be similar
on each MUD, and invisible to the players.
: In addition, I think that too many muds are too similar
: already; for example, you can find the same old OrcQuest
: on dozens of muds
That's true, and connecting them would really show that up, perhaps
even leading wizards to create something new to differentiate
themselves for players who free to roam from world to world and not
stay cloistered on any one MUD. One might say that every damn country
has its share of McDonalds, but only France has the Eiffel Tower, the
Arc de Triomphe and the Louvre. We go to see what's different and
stands out and overlook the necessary banalities.
Travis S Casey
>Travis S Casey (ca...@ioctl.cs.fsu.edu) wrote:
>
>They wouldn't have to have them. No MUD police making people link up
>or shut down. But for those interested in connected MUDs, why not?
My point is, what if you can't get a large number of muds
interested in this? People tend to create muds because they
have a particular idea of what a mud should be that they want
to share with others; allowing other muds that may not share
that idea to be "linked" to your mud dilutes that.
If you could only get, say, 5 muds that are willing to take a shot
at it, would you still want to do it? The people you really need
to convince to try this are the mud admins out there; players tend
to love the idea, just because it means they would only have to
build up one character.
>: For another, people might want to have multiple "mud-nets"; there
>: might be one for science-fiction based muds, one for fantasy-based
>: muds, etc.
>
>That's a cool idea. When do we start?
Whenever we can convince enough good mudlib coders that (a) this
is a good idea and (b) this is a feasible idea.
>: Umm... most of us share those attributes. :-) I'm currently working
>: on a MUD which will have neither XPs nor SPs.
>
>Yes. You see I'm showing my LP bias (whoops). I'm guilty of
>overstating my case. Granted there are some MUDs that just wouldn't
>fit the mold enough, and they are interesting and important places.
>But that they can't participate without excising what makes them
>unique doesn't imply that we should abandon the idea or that they
>should perform the excision. There is room enough on the net.
Actually, you're showing your general knowledge gained by
playing many muds built off of the same mudlibs, often
with little or no modification. :-)
The mud I'm working on *is* a LP mud, just one with a new
mudlib that we're building. That's the biggest problem with
creating a mud teleport thing... that you can't assume
*anything*. Two LPmuds can be completely different--indeed,
one could look more like a Diku or a MUSH than a "standard"
LP. Of course, the same applies to all the other mud types,
although some are harder to modify extensively than others.
>Not getting what one expects...that sounds appealing to me, not
>negative. Be careful when travelling in a foreign country. The
>difference, the possible danger, is what makes travel so interesting.
>Foreign lands are foreign and while MUD players might not be mature
>enough now, I see no reason not to expect more from them. Help them
>along with clear demarcation points and "At your own risk" signs if we
>think they need it. They'll pick up on it soon enough, like learning
>the visual language of movies.
The biggest problem that I see is immature players using this
kind of setup to allow them to advance faster. Items may not
transfer from one mud to another, but if XP and characteristic
gains do, then a player who is "native" to one mud can wander
off to a mud where it's easier to go up and rise more quickly.
This creates problems for muds that want their players to
advance more slowly.
>: Personally, I'm not willing to give up the freedom to do
>: whatever I want with my mud just so that people can transfer
>: the stuff they gained on another mud here, or vice-versa.
>
>That's why I proposed a system--perhaps with no technical basis--that
>would not allow items to be transferred, only statistics. One that
>created a character in each MUD's own peculiar, eccentric,
>personalized code so that what tied the games together, the "world
>transport" part of the driver, is the only thing that need be similar
>on each MUD, and invisible to the players.
This still creates problems... if statistic increases on a
"foreign" mud can be transferred to the "native" mud, then it
opens up problems with keeping players from advancing too fast.
If they can't be transferred back, players are likely to
complain about it.
I don't know how many mudders out there are old-time pencil-and-
paper RPGers like me, but those who are are probably familiar
with "open worlds" vs. "closed worlds." An "open world" is
like what you're describing--a game in which people are allowed
to bring in characters from other games. A "closed world"
corresponds to the current setup, where characters can't
be moved from one game to another, but you can create a new
character in each world.
The biggest problem that open worlds have is what I'd call
"collectors"; people who go from world to world getting
neat items, gaining tons of XP in easy games, getting their
stats raised to ridiculous levels, etc. One solution that
some games use is to allow "clones"; that is, a character
who has the same name, race, stats, personality, etc. as
your other character, but is "native" to this world, so you
don't get to keep items, experience, etc. However, this
really isn't any different from making a new character with
the same name, except that you can keep your old attribute
scores.
Even that method runs into problems if the character relies
on something that isn't found in the new world, like being
a race that doesn't exist there.
Using some of these ideas, here's what I see as a sort of
psuedo-code protocol for moving from one mud to another:
(Note: Mud 1 is the Mud the character is native to; Mud 2
is the Mud he/she is moving to).
Mud 1 contacts Mud 2 and requests entry for the character.
The information sent is the name of Mud 1 and the character
name, real name, and IP address logged in from of the character.
At this point, Mud 2 can either deny the request or allow
the process to continue. Reasons for denial could include:
Mud 2 doesn't want people to be able to come in from Mud 1;
Mud 2 doesn't allow either the character name or the real
name to log in; Mud 2 doesn't allow logins from the character's
IP address.
If this stage is passed, Mud 1 transmits a set of "standard"
stat information to Mud 2, including strength, constitution,
etc. This information is treated as advisory by Mud 2.
Mud 2 uses various formulas to compute the needed attributes
for a character on Mud 2.
Mud 2 sends back a text message, telling the player what
his/her stats will be on Mud 2. (Basically the output of Mud
2's "score" and "st" commands or equivalents). The player may
either accept these stats or choose to not transfer to Mud 2.
Mud 2 can also send back a "no conversion possible" message,
which would end the transfer attempt. (An example of this
might be that people from Mud 1 are allowed on, *if* their
race is one that exists on Mud 2.)
If the player chooses to transfer to Mud 2, his character on
Mud 1 is put into storage and he is linked to his character on
Mud 2.
The first and last parts are the easy part. It's the
computing of attribute values for Mud 2 by Mud 2 that gets
complicated, since different muds have different attributes,
different ranges that the attributes cover, different classes,
etc. This part would probably require that either (1) all
muds that use this system agree to use a standard setup
for characteristics and not modify it, or (2) a "converter"
to convert characters from Mud X be created for each mud that
a specific mud wants to allow to transfer characters to it.
Either way, admins aren't going to like it. In (1), their
freedom to build the mud the way they want is restricted.
In (2), a considerable amount of effort is needed to construct
these converters, effort that then can't be used to improve
the mud in other ways.
Going back could work one of two ways: (1) the player
is simply "snapped back" into his/her character on Mud 1
as if he/she had been disconnected while on Mud 2, with no
transfer of stat gains from Mud 2. (2) Mud 2 could send
back a new set of stats for the character (in the intermud
format), which Mud 1 could then convert to give new stats
for the character. Note that this requires Mud 1 to have
a "converter" set up for Mud 2 stats.
Ways to make this easier:
Stats could be sent on a relative basis instead of an
absolute one. That is, the intermud format could specify
that a stat be ranked from 0 to 100, where 0 is the worst
possible on the mud and 100 is the best possible. Using
such relative stats would make conversion much easier
for stats.
Different mudlibs could come with basic converter
units "built in"; that way the admins could simply modify
an existing converter instead of building one from
scratch.
Lastly, as much as possible, these mudlib features should
be controllable with #defines, etc.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' confirmed cat person
Mark Clements
One way of doing it might be to create a MUD client which stores
player information in much the same way as the WIN.INI file that Windows
uses. e.g. a heading in square brackets indicating the MUD name, which can
be added to.
There would be a general section at the top which includes things like
name, password, etc. and then under each MUDs section would be listed stats
relevant to that MUD.
+++++++++++++++++++++++++++++++++++Example:
[General]
name=Dennis;
password=dh12nb4 **
ip_address=156.24.312.42
LastMud=Mudname1|192.64.36.115/6666
[Mudname1|192.64.36.115/6666]
LastEntered=12/04/95
Race="orc"={
strength=+4
wisdom=-2
}
Strength=17
Wisom=20
LockPick=12
Level=4
[Mudname2|192.92.35.10/2000]
LastEntered=30/03/95
Cunning=45
PlayerKiller=No
+++++++++++++++++++++++++++++++++++(etc.)
** Encrypted password - would need a standard InterMUD encryption protocol.
+++++++++++++++++++++++++++++++++++
When a player moves from one mud (A) to another (B), this file is
transfered from A to B, which checks the [General] section
to decide whether access should be granted, notifying A of the outcome.
If no access is granted, then A notifies the player, and B destroys
the file on it's system. (Or possibly updates a file, if relevant).
If access is granted, system A sets LastMud to the name|ip_address of
B, and does the things necessary to transfer the connection.
(I will not go into transferral of items in this post)
MUD B also sets LastMud to it's own name|address combination.
It then checks to see if it already has a section in the file, if so
it creates a character based on the information held there. It then
searches the other MUDs' sections in order they've last been visited (most
recent ones first) to try and fill in any stats it doesn't have listed.
Thus, if MudName2 in the above example made use of the strength stat, it
would look through the other sections and find it under MudName1.
These may (probably) need to be expressed as a percentage of the maximum,
but things like levels (which sometimes are unlimited) it would need
to be expressed differently. This needs some thought.
If the MUD has not been accessed before, it may print special help files
or notices, or at least direct the player to them, and urge that they
be read. It will then create any variables not found in other
sections and set them to their default values, and save them in the player
file under it's own section.
If the player logs into a MUD, where LastMud isn't equal to itself, it
will call that MUD which will either return the player file (and set it's
LastMud variable to the relevant MUD) or it's value in LastMud if it
has been moved. This way the MUD you log into will search the other MUDs
to locate the most recent version of your character. If there is a problem
locating it, you may be given the option to use the stored player file,
but this may create problems later on.
You would only be allowed to imp on one MUD, although you may be able
to choose from those you have entered. You would have to meet the
criteria imposed for that MUD, so some may be easier to gain wizardhood on
than others. The MUD may refuse a player wizardhood, especially in order
to balance the wizards between the MUDs.
Special things which have no obvious effect from their value, but have
an effect on the game (e.g. 'race' above) could have a little sub-section
dealing effects - possibly in C like code e.g.
if(weapon="club"){ DamageDone=+4; }
for an orc, as they have extra club-weilding ability. These will only be
used if the specific instance is not available on the current MUD. Values
such as the ones in the example may be sufficient however.
Objects could be dealt with (alright I lied earlier) by having
an [inventory] section which lists the object code of the items, and
a little information, such as name and desc. so it can access their
original MUD if necessary, but this will only be when they are
to be used. Both the incoming MUD and outgoing MUD can screen
against certain objects being transfered.
Stats that aren't supported by the MUD will simply not be used, however
a method similar to the race description above may be used to define
spells and special abilities, if they are made transferable.
Also things such as shouts and channels would be local, although there
would be a special interMUD channel (if it doesn't cause too much slowdown)
and InterMUD tells would be allowed (they are already present on some MUDs.
As would be interMUD finger, who, and similar commands.
This is just a suggestion, (lump of suggestions) - there is a long
way to go still.
(I wonder how plausible this all is?)
Continue this thread!!
--
___ ,';_,-,__
Writing is just backwards reading. /~_ ,',' |O|,:,\,
Reading is just clever seeing. / /,',' /--|_|-;:;|
Seeing is believing. ( )',_) ) ):;)
To write, you must believe... >\,(__ / /:;;|
:...Mark...//~ /:;:;:\
Tim Hollebeek
Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>InterMUD connection:
>
>One way of doing it might be to create a MUD client which stores
>player information in much the same way as the WIN.INI file that Windows
>uses. e.g. a heading in square brackets indicating the MUD name, which can
>be added to.
A format for storing the data is the trivial part ...
>name=Dennis;
>password=dh12nb4 **
>ip_address=156.24.312.42
>LastMud=Mudname1|192.64.36.115/6666
>
>[Mudname1|192.64.36.115/6666]
>LastEntered=12/04/95
>Race="orc"={
> strength=+4
> wisdom=-2
> }
>Strength=17
>Wisom=20
>LockPick=12
>Level=4
This assumes all muds are so boring that they all have the same
stats/skills/etc.
>It then checks to see if it already has a section in the file, if so
>it creates a character based on the information held there. It then
>searches the other MUDs' sections in order they've last been visited (most
>recent ones first) to try and fill in any stats it doesn't have listed.
>Thus, if MudName2 in the above example made use of the strength stat, it
>would look through the other sections and find it under MudName1.
>These may (probably) need to be expressed as a percentage of the maximum,
>but things like levels (which sometimes are unlimited) it would need
>to be expressed differently. This needs some thought.
Ok. I start up BeekIsReallyGreatMUD. I quickly advance in levels and
stats through the GiveMeGobsOfStats command until I have all my stats
maxed and I'm level 1 zillion. Then I transfer my character to your
mud ...
Obviously, I'm exagerating, but this could happen if even if you
restrict the muds you'll accept characters from. People will have an
incentive to play the easiest mud in the group. Of course, that's no
problem. I'm sure the admins can easily resist the temptation to make
their mud easier so as to attract more players *wink*. Pretty soon,
all the muds will be involved in an arms race ...
If you don't think this will happen, consider the fact that it happens
on many muds wrt individual areas.
>Special things which have no obvious effect from their value, but have
>an effect on the game (e.g. 'race' above) could have a little sub-section
>dealing effects - possibly in C like code e.g.
> if(weapon="club"){ DamageDone=+4; }
>for an orc, as they have extra club-weilding ability. These will only be
>used if the specific instance is not available on the current MUD. Values
>such as the ones in the example may be sufficient however.
Sufficient? Only if your mud is a really lame hack and slash with no
originality. Have you suggested this to Diku's? :)
>Objects could be dealt with (alright I lied earlier) by having
>an [inventory] section which lists the object code of the items, and
>a little information, such as name and desc. so it can access their
>original MUD if necessary, but this will only be when they are
>to be used. Both the incoming MUD and outgoing MUD can screen
>against certain objects being transfered.
This would be a balance headache at best, ignoring the fact that the
muds would have to be very similar for the code to transfer decently ...
>(I wonder how plausible this all is?)
>
>Continue this thread!!
Nah, let it die :) This should be in the FAQ along with 'can emacs be
implemented?'
--
---
Tim Hollebeek 'There will be a better sig when I have time'
root
<Some ream o' stats here>
> This assumes all muds are so boring that they all have the same
> stats/skills/etc.
I would hope they're not, but skills unused in another mud would be
ignored. Not much use for a swimming skill in a world with no open water!
The idea would be generic values that the individual muds could interpret
on a per-basis.
> Ok. I start up BeekIsReallyGreatMUD. I quickly advance in levels and
> stats through the GiveMeGobsOfStats command until I have all my stats
> maxed and I'm level 1 zillion. Then I transfer my character to your
> mud ...
> Obviously, I'm exagerating, but this could happen if even if you
> restrict the muds you'll accept characters from. People will have an
> incentive to play the easiest mud in the group. Of course, that's no
> problem. I'm sure the admins can easily resist the temptation to make
> their mud easier so as to attract more players *wink*. Pretty soon,
> all the muds will be involved in an arms race ...
There's no reason why a 'fudge factor' couldn't be introduced... if it's
really easy for a player to reach that mud's max level, just fudge the
stats coming from that mud to a lower amount. ie: A mud that has a max
of 30 mortal player levels would fudge down the numbers coming from a mud
with only 20 levels, and vice versa. -shrug- The 'mighty mortal' power
race could easily enough be contained by that or by refusing connections
from that mud.
> Sufficient? Only if your mud is a really lame hack and slash with no
> originality. Have you suggested this to Diku's? :)
Muds can be based on death and violence and still be original, ya know. ;)
> This would be a balance headache at best, ignoring the fact that the
> muds would have to be very similar for the code to transfer decently ...
This is true... there would have to be some balance issues solved. I know
that for the mud I code on (Ancient Anguish) the balance process is
partially automated. One of the nice things would be that, once the
system was installed, an object that would transfer to one mud would be
able to fairly easily transfer to all muds. The onus would be on coder
to make things balance-compatible to a pre-determined standard.
> >(I wonder how plausible this all is?)
> >
> >Continue this thread!!
> Nah, let it die :) This should be in the FAQ along with 'can emacs be
> implemented?'
I dunno about that... the underlying idea of hooking together muds has
basic problems of the type that a lot of major companies deal with every
day... INTERCONNECTIVITY. Good experience for when 'real world'
situations arise (for all you college geeks out there <grin>). 'sides...
even if it doesn't come about, it'd be a helluva mental exercise. Maybe
someone should create an RFC for it.
-Hatamoto @ Ancient Anguish-
--
----------------------------------------------------------------------
mailto:ri...@direct.ca <Rick Franchuk@Internet Direct, Vancouver, BC>
"Hypocrisy is the lubrication for all political intercourse."
David Bennett
>Tim Hollebeek (t...@handel.Princeton.EDU) wrote:
>: Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>: > InterMUD connection:
>: > This needs some thought.
>: Ok. [I create the UberBeek, havoc on your MUD implied]
>: People will have an incentive to play the easiest mud in the group.
>: Pretty soon all the muds will be involved in an arms race ...
>Like Mark sez, what's required to make this workable needs some
>thought. Your keen insight on what would no doubt happen without some
>controls is what I like to think about, being as I am more interested
>in the social consequences of connecting MUDs than forging a work of
>coding art.
One of the other problems is banishing a site/player/whatever. How
can you banish someone if they can log on elsewhere and just wander
onto your MUD? how do you know who to speak to about a problem you
just ran into? Are you going to make all the who lists local?
Blue,
David.
--
d...@iinet.com.au - The ends and the means are the same --- Gandhi
- May your Pinkfish never swim backwards.
http://www.iinet.com.au/~ddt
Tim Hollebeek
Strange Journey <sjou...@netcom.com> wrote:
>Tim Hollebeek (t...@handel.Princeton.EDU) wrote:
>: Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>: > InterMUD connection:
>
>: > This needs some thought.
>
>: Ok. [I create the UberBeek, havoc on your MUD implied]
>
>: People will have an incentive to play the easiest mud in the group.
>: Pretty soon all the muds will be involved in an arms race ...
>
>Like Mark sez, what's required to make this workable needs some
>thought. Your keen insight on what would no doubt happen without some
>controls is what I like to think about, being as I am more interested
>in the social consequences of connecting MUDs than forging a work of
>coding art.
Agreed. I don't think it's that difficult from a coding standpoint anyway.
>If it's true that players will flock to the easiest MUD, then this is
>probably going on with MUD islands as we speak. In fact, it's the big
>debate among wizzes on the LP I spend most of my time on: do we make
>it easier to attract players or retain our integrity by challenging
>them and risk having no players at all? IMHO, easy MUDs are boring.
I think most people agree that easy MUDs are boring. They used to
have an attraction back when it was hard to wiz (i.e. I can play AA
for 2 years and not even get close, or I can play FooMUD and wiz in a
month or so ...) But that's not really true any more since you can
pretty much log onto FooMUD and ask to be wizzed and you will be.
Most of the people these days are playing for fun and not to wiz,
hence would rather play on a difficult, well thought out, _unique_,
fun mud than an easy one. However, my point was that if characters
are transferable, it creates an entirely new problem, as you can gain
stats on an easy mud, then use it to play on a more fun mud (and it's
always more fun to play if your character is good; getting the crap
beat out of you by chipmunks isn't fun). I think the key to
attracting players is to make your mud _unique_ and fun to play.
Emphasis on _unique_ in this paragraph as linking muds together tends
to work against that goal.
>I see players having a native MUD on which they are pledged and on
>which they want to wiz. This would probably be the policy, but it's a
>natural human reaction to get attached, however irrationally, to
>something. And it won't be the easiest MUD, it will be the one that
>they think is best. While they may try to seek the easy battle to
>raise faster and MUD admins may try to court them with cheap XP, I can
>think of at least one way to minimize this: floating rates.
Yes, I've seen this suggested before on individual muds and it has
some promise, although it can be a pain to keep balanced. A mud could
conspire to 'inflate' it's 'currency', etc.
>Following the mechanism suggested in posts in the thread a few steps
>down from this one, we'd have ourselves a central intermud server that
>keeps track of the dynamic conversions so each mud wouldn't have to
>deal with them. It might keep track of how many XPs, etc, are
>exported and open up the possibility to float the exchange rate. The
>more points that are given away, the less they are worth on a players
>native MUD. You can tell me that this would be incredibly difficult
>if you want to, but I know that all ready.
It's not all that bad, actually :) Again, I think most of the
problems aren't on the implementation side.
Of course, with all this said, you should know I'm slightly biased :)
Let's face it. There are 100's of LPs in development. If you've been
around a while, you know that within a year >90% of them will have
disappeared. It'd be nice if instead of everyone wanting to open
their own mud, people would actually get together into reasonably
sized staffs and work on creating something unique and worthwhile.
If it happens to be a distributed project, fine. But the last thing
the LP world needs is more carbon copy muds thrown up at random.
-Beek
Strange Journey
: Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
: > InterMUD connection:
: > This needs some thought.
: Ok. [I create the UberBeek, havoc on your MUD implied]
: People will have an incentive to play the easiest mud in the group.
: Pretty soon all the muds will be involved in an arms race ...
Like Mark sez, what's required to make this workable needs some
thought. Your keen insight on what would no doubt happen without some
controls is what I like to think about, being as I am more interested
in the social consequences of connecting MUDs than forging a work of
coding art.
If it's true that players will flock to the easiest MUD, then this is
probably going on with MUD islands as we speak. In fact, it's the big
debate among wizzes on the LP I spend most of my time on: do we make
it easier to attract players or retain our integrity by challenging
them and risk having no players at all? IMHO, easy MUDs are boring.
I see players having a native MUD on which they are pledged and on
which they want to wiz. This would probably be the policy, but it's a
natural human reaction to get attached, however irrationally, to
something. And it won't be the easiest MUD, it will be the one that
they think is best. While they may try to seek the easy battle to
raise faster and MUD admins may try to court them with cheap XP, I can
think of at least one way to minimize this: floating rates.
Following the mechanism suggested in posts in the thread a few steps
down from this one, we'd have ourselves a central intermud server that
keeps track of the dynamic conversions so each mud wouldn't have to
deal with them. It might keep track of how many XPs, etc, are
exported and open up the possibility to float the exchange rate. The
more points that are given away, the less they are worth on a players
native MUD. You can tell me that this would be incredibly difficult
if you want to, but I know that all ready.
As for your UberBeek: first of all, you'd have to be a member of our
growing league o' MUDs which would help to weed out the weenies in the
first place. And then, members might have the discretion not to admit
chracters over a certain Beek rating, say, no 9 megaBeeks allowed
outside of their own MUD without permission. And even if I did let
you in, you acquired all the good weapons and wiped out a quarter of the
MUD, so what? I reset every two hours, or so. Knock yourself out.
: >Continue this thread!!
: Nah, let it die :) This should be in the FAQ along with 'can emacs be
: implemented?'
I wish it were in the FAQ so I could see what greater minds than mine
have come up with. But since it isn't and I'm interested in it, I'd
just like to thank all the people who pointed me to information, told
me of their projects and contributed their ideas. Once we're all
connected, we can work on implementing emacs. Should be a breeze.
Strange Journey
--
sjou...@netcom.com
Strange Journey
: My point is, what if you can't get a large number of muds
: interested in this? People tend to create muds because they
: have a particular idea of what a mud should be that they want
: to share with others
Trying to bring me down to earth, eh? Your point is taken, Travis.
There may well be only a few people interested at the moment. It
would take just two MUDs with a desire to experiment. It might even
be best to start that way. Perhaps *their* particular idea that they
want to share is that connected MUDs create synergy. Perhaps they'd
create two really lame but interconnected MUDs...it'd be a great
start. I wasn't there when the first MUD went on-line, but I'm
sure compared to what we have today it would be screaming lame.
: The biggest problem that I see is immature players using this
: kind of setup to allow them to advance faster.
: [...] if statistic increases on a "foreign" mud can be transferred
: to the "native" mud, then it opens up problems with keeping players
: from advancing too fast.
I tried to answer this point in a response to Tim Hollebeek. Let me
know what you think.
: I don't know how many mudders out there are old-time pencil-and-
: paper RPGers like me, but those who are are probably familiar
: with "open worlds" vs. "closed worlds." An "open world" is
: like what you're describing--a game in which people are allowed
: to bring in characters from other games.
I know exactly what you mean. I ran my campaign as open, but retained
discretionary power over what was allowed in, assuming other GMs would
do the same with what I sent out. Something similar might occur in
our virtual campaigns. On the other hand, to embarass myself with
physics here, the severity of the problem would depend on how you
defined what constituted a closed system. Individual member MUDs, or
the MUDnet? Maybe at first like-thinking MUDs would band together, in
which the admins held similar beliefs. But I don't want to spook you!
I don't mean to imply a forced march in lock-step with the others, but
rather a loose congregation of people who don't step on each other's
advancement sovereignty.
: Using some of these ideas, here's what I see as a sort of
: psuedo-code protocol for moving from one mud to another:
[and]
: Ways to make this easier:
These are excellent ideas, and yes, they would take a lot of effort.
Whether that effort would be better spent on other improvements is a
matter of opinion, I guess. You know where I stand; I wish you were
on this side of the fence. :) Meanwhile, I'm hanging on to your
suggestions, if you don't mind.
Strange Journey
--
sjou...@netcom.com
Travis S Casey
>
>One of the other problems is banishing a site/player/whatever. How
>can you banish someone if they can log on elsewhere and just wander
>onto your MUD? how do you know who to speak to about a problem you
>just ran into? Are you going to make all the who lists local?
I don't know if you saw my post with my psuedo-code idea for doing
the intermud transfer, but it handles that. The first thing that
is sent is the character's name, player's name, player's email
address, and IP address the player logged into the mud from, so that
the mud being transferred to can refuse to accept the transfer for
any reason based on that info. Examples would be a character name
that's the same as that of a character "native" to that mud,
the player of the character being someone who's been banished, the
IP address of the player having been registered, etc.
For problems, there would be several things. The transfer process
probably ought to give all the standard stuff you get when logging
onto the mud the normal way, like updates on changes, who to
contact if you have trouble, etc. Secondly, users would have to
be educated to send mail to the admins on the mud where they had
trouble; a help in this might be to redesign the command shells of
participating muds so that people who transferred in by intermud
transit would have a "mud-name>" prompt instead of the normal ">"
prompt. This is no worse, IMHO, than having to train users of
the Web, Gopher, etc. to send complaints about problems at remote
sites to the admins of those sites instead of their local admins.
I'm not sure what you mean by "are you going to make all the who
lists local?" What I think you mean is whether the who command
will display who's on your native mud, or who's on the mud you're
currently logged in on. What I would do is this:
Characters on their native muds are displayed however they are now.
Characters native to this mud who are currently on another mud
would have an entry with [currently on X] appended to it.
Characters on this mud who are native to another mud would have
[visiting from X] appended to their who entries.
This ought to give all the needed info, I believe.
Travis S Casey
>
>beat out of you by chipmunks isn't fun). I think the key to
>attracting players is to make your mud _unique_ and fun to play.
>Emphasis on _unique_ in this paragraph as linking muds together tends
>to work against that goal.
Hmm... I'm not too sure about that. It all depends on how you do it.
As someone else noted, a transfer system might encourage more
uniqueness, as people get to see the dozens of Star Trek areas,
Pier Anthony-inspired areas, etc. out there, not to mention the
ubiquitous Orc Quest. :-)
>Let's face it. There are 100's of LPs in development. If you've been
>around a while, you know that within a year >90% of them will have
>disappeared. It'd be nice if instead of everyone wanting to open
>their own mud, people would actually get together into reasonably
>sized staffs and work on creating something unique and worthwhile.
Here's an interesting question: Why are there so many muds with
theme X around? (Pick a theme... any popular series of fantasy or
science-fiction books or movies should do.)
First off, some themes are more popular than others. There are a
lot more fans of Ann McAffrey's Pern novels than there are of
Brunner's Traveller in Black stories, for example; the more popular
themes are going to wind up with more people wanting to do a mud
based on them.
Second, people have different mudding philosophies. Role-playing
vs. combat-oriented, player-killing vs. non-player-killing, etc.
People also have different interpretations of the books/movies/whatever
they're basing the mud off of. For example, some people might want
to create a Pern mud set before _Dragonriders of Pern_, while others
might want to set theirs at the time of _The White Dragon_. With
Star Wars, some people consider the _Jedi Academy_ trilogy to be
trash and would want their mud to ignore it, while others want their
jedi to be god-like.
Third, there's ignorance. Someone might create a mud based on Pern
without even knowing that there are several such muds already out
there.
Number three can be controlled some via the various mudlists, but
not everyone knows about them and there is no complete list of
muds out there. Numbers one and two aren't anything we can do
anything about... there'll always be a number of different MU*s
based on Pern, for example.
>If it happens to be a distributed project, fine. But the last thing
>the LP world needs is more carbon copy muds thrown up at random.
What I'd really like to see is more muds based on *original* ideas,
rather than existing worlds; this would almost certainly reduce
the "carbon copy" feel of many muds, IMHO.
Tim Hollebeek
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>Tim Hollebeek <t...@debusy.Princeton.EDU> wrote:
>>
>>Let's face it. There are 100's of LPs in development. If you've been
>>around a while, you know that within a year >90% of them will have
>>disappeared. It'd be nice if instead of everyone wanting to open
>>their own mud, people would actually get together into reasonably
>>sized staffs and work on creating something unique and worthwhile.
>
>Here's an interesting question: Why are there so many muds with
>theme X around? (Pick a theme... any popular series of fantasy or
>science-fiction books or movies should do.)
Well, you're free to disagree, but it's far simpler. Everyone wants
their own mud, and very few mud admins are mature enough to work
together with other people. It's that simple.
Over half of the new muds don't have any unique theme/goal/whatever at
all. They simply exist for the sake of existing. And that IMO is a
waste of talent and very sad.
Mark Clements
OK. I'm going to answer some questions, and add some suggestions
in response to the last four or five articles. Some good points, some
bad points.
Tim first:
(Writing about transferring stats)
> This assumes all muds are so boring that they all have the same
> stats/skills/etc.
You miss the point. Each MUD can have it's own set of stats/skills
which can be as unique as necessary. Any skill should be portrayed
in the transferred file as a percentage. If the player already has
the stat/skill on another MUD, it's value there is used (adjusted
to fit in with local maximums - hence the percentage). If it does
not exist already, it is simply added at a default value. Thus some
MUDs will react to certain skills, some to others, and they can be
diverse as is wanted, BUT THE SAME SKILL WILL BE THE SAME ON DIFFERENT
MUDS! As the MUDs are connected, the admin will be able to add
special cases, so that (for example) if one MUD has 'Intelligence' but
another has 'Magical Ability' both of which affect (or is it effect?)
the same sort of things, a conversion will be made. Similarly if one
MUD has two skills, for anothers one (or whatever).
--> The standard setup will work in general, but admin will have to
code the special cases.
(Talking about balancing rewards/perils between MUDs)
> Ok. I start up BeekIsReallyGreatMUD. I quickly advance in levels and
> stats through the GiveMeGobsOfStats command until I have all my stats
> maxed and I'm level 1 zillion. Then I transfer my character to your
> mud ...
Obviously there would need to be some kind of check to keep the various
MUDs from being too unequal. I don't think they should all be the same,
however as this would be dull - the best idea would be to have fluctuating
difficulties - so people are unable to gravitate to a particular MUD,
knowing it to be easiest, however this raises the problem of warning the
player. Perhaps some sort of lock should be created - so you can only
earn X amount of experience (or whatever - levels etc.) before you
have to move on to another MUD. Alternatively the server could
automatically give experience based on damage done - thus (as all connected
MUDs would need the same server) this would balance it. The problem
with this lies in MUDs which decide not to use exp. (or whatever stat.
we're talking about). Maybe there shouldn't be any control! You want an
easy MUD stay in an easy area - advance by cheating etc. You'll finish
easily and maybe Wiz. However - if we keep a check on where each
player advances etc. we can tell the players who do this, and perhaps
not let them Wiz. It's a tricky question - I'll have to give it some
more thought... (Check out what ...err... 'Strange Journey' has to say).
(Context not important)
> This would be a balance headache at best, ignoring the fact that the
> muds would have to be very similar for the code to transfer decently ...
A point I've been meaning to make from the start of this post is that
to be a successful designer - DECIDE WHAT YOU WANT TO DO! Only worry
about whether it can be done when you know exactly what you want to do.
The most innovative ideas come from people sitting in a room, saying
'Wouldn't it be neat if...' or 'How about this...' rather than
'Nah - that might be too tricky' or 'It's a shame we can't...'
David:
> One of the other problems is banishing a site/player/whatever. How
> can you banish someone if they can log on elsewhere and just wander
> onto your MUD? how do you know who to speak to about a problem you
> just ran into? Are you going to make all the who lists local?
Not a problem - the same check will be done when you log into the MUD
as when you change MUDs, and you may simply be not allowed to enter
a particular MUD from any position. It would also be possible to
banish people from using certain entrances to a MUD. If you wanted
to banish a player from all MUDs, however, it would have to be done
manually (on each MUD separately).
Tim again (alright, so it's not as many people as I thought <G>):
(Talking about creating unique MUDs)
> Emphasis on _unique_ in this paragraph as linking muds together tends
> to work against that goal.
It needn't. It depends on the admin - the people who make dull unconnected
MUDs will make dull connected MUDs. Connecting them together won't make
them any more dull. In fact - it's likely to make them better, as you
won't be so tempted to copy a good area you've seen somewhere if that
somewhere is just south of the Jungle (or whatever).
If you mean unique in terms of stats, combat etc. this is also not
a restricting factor. As nowadays - people who want what already exists
will leave it, others will modify or completely change the systems. As long
as the Admin. are aware of the other MUDs and how they should link, it's not
a problem. e.g. I was designing a MUD where instead of generic Hit Points,
each limb would have it's own degree of healthiness, and functionality (e.g.
how much permanent/temporary damage) If a MUD you are connecting to does
not support this, you can get an average, and call it Hit Points, and,
likewise when you return, they will be converted back - either randomly
(if it is your first visit) or in respect to their previous values (working
out how much your HP has changed, and altering them accordingly).
This is complicated - but if you have enough enthusiasm to create your
own system, it is likely you will be enthusiastic enough to want to
integrate it.
That's the end of my responses, and as it's late, and this is getting
long, I'm not going to write any more right now. I have further ideas
on the following topics, which I shall detail in my next post (whenever
I get round to it - <Grin>):
:- Shared player names.
:- Economy, currency and all the things we hate about money.
:- Overlapping areas.
:- Portable objects?
:- How omnipotent is a God?
:- Why I like shoes.
(I bet I forget some of them. Especially the one about shoes).
George Reese
: I dunno about that... the underlying idea of hooking together muds has
: day... INTERCONNECTIVITY. Good experience for when 'real world'
: situations arise (for all you college geeks out there <grin>). 'sides...
: even if it doesn't come about, it'd be a helluva mental exercise. Maybe
: someone should create an RFC for it.
Well, I build applications for distributed environments. And I fail
to see how that is useful here at all.
What is the point of distributed computing? It gives you horizontal
scaleability so that as things grow, you only need to add another
sparc 10 instead of some monster from IBM for 100,000 dollars. The
fact of the matter is that no single MUD as it stands now really can
see the benfits of distributed MUDs. They may be slow, but they are
slow in taxing the smallest of machines. I know of no MUD out there
which would bring a sparc 10 to its knees.
Before you ask how you do this (which IMHO is not that big of a deal),
you need to ask yourself why. I have not heard why articulated at
all. And, as the point of this letter I hope is clear, I feel that
there is no reason to do distributed mudding.
--
George Reese (bo...@imaginary.com) http://www.winternet.com/~borg/
phone/fax: (612) 829-5495 ftp://ftp.imaginary.com/users/borg
"No one ever conquered Wyoming from the left or from the right."
-Camper Van Beethoven
Travis S Casey
>Before you ask how you do this (which IMHO is not that big of a deal),
>you need to ask yourself why. I have not heard why articulated at
>all. And, as the point of this letter I hope is clear, I feel that
>there is no reason to do distributed mudding.
There are several reasons:
1. Because some people are annoyed at having to create a new
character on every mud they play on.
2. To widen the possible number of people you can meet and
interact with.
3. To see if it can be done. :-)
4. To allow for the distribution of a mud over multiple
servers. With this kind of interconnectivity, you could
have several large "areas", each of which runs on its
own server.
5. In general, because people think it might be fun. Isn't
that the whole reason for having muds in the first place?
-------------
Personally, I'd love to try it just as an experiment; I doubt
that the original poster's idea of getting lots of existing
muds to sign on would ever go over with many mud admins, but it
could be interesting to play with for a while.
The real question you're trying to get at is, "What could you
do with this that you couldn't already do?". The only thing
I can think of is that people could use the same character on
many different muds (that is, transfer stats over, rather than
create a new character with the same name, etc.). Most muds
probably won't *want* people to be able to do that, which is
why I don't see it ever catching on with mud admins. However,
I could see it being used to create a small network of muds
that have agreed to participate, being used in this case as
a way to easily differentiate areas of the mud (i.e., to have
a pure-fantasy area, a pure-SF area, etc.).
Of course, that could be done with the tools we already have;
given the incredible flexibility of LPC, almost anything can
be done with an LPMUD. It *might* make it easier though, and
I feel that it's worth exploring just for that possibility.
Mark Clements
Ma...@mabsy.demon.co.uk "Mark Clements" writes:
In a recent post, I said I'd discuss some of the following problems:
> :- Shared player names.
> :- Economy, currency and all the things we hate about money.
> :- Overlapping areas.
> :- Portable objects?
> :- How omnipotent is a God?
> :- Why I like shoes.
This post will cover one of them:
SHARED PLAYER NAMES.
What if player x is known as 'Astra' (for example) on MUD 1, and
player y is known as 'Astra' on MUD 2. This would immediately preclude
each player from being able to use the other MUD (unless by some strange
quirk of fate they had the same password).
In an ideal MUD, i.e. one which had added realism (50% extra free), you
would allow more than one player with the same name. I mean, there are
loads of people called Mark, and at least a few of these are called
Mark Clements. (Although I SERIOUSLY doubt that anyone shares my middle
names <Grin>). The same thing should be allowed on the MUD.
Ideally, the following system would be used:
When you meet someone for the first time, they are referred to as
'a stranger' or similarly ambiguous remark. Perhaps there could be a flag
setting to specify whether a strangers description is printed when you
see them.
If you then met them again, they would be referred to as 'a familiar face'
or similar.
You would also have the facility to name someone. So if they told you
their name was 'Tigger' you could type 'name Tigger'. If there was more
than one stranger present, you would use 'name 1 Tigger' or 'name 2 Tigger'
etc.
Similarly you could type 'identify' or 'identify tigger' to automatically
name yourself for all present (1st) or just one person (2nd).
Obviously this leads to situations where you could use a pseudonym or
alias, which would be very useful. (I would love this MUD).
(Also things like their level and so on wouldn't be obvious by looking at
them as it is in a lot of MUDs - only how they look, and what they are
obviously carrying/wearing (not everything), nothing about alignment etc.
unless it's presented in the form 'He looks quite friendly.' Ideally,
this information could be misleading.
In actual fact, this system is way too resource intensive (although not
_theoretically_ impossible) to be practical - although it *may* not be too
difficult to code. The amount of data that would need storing and
transferring would become huge and unweildy. Also, problems would
arise with commands such as 'who' and similar. The game may also become
too complicated to play.
However I do think that players should be able to specify first, last
and middle names, and be referrable to by either first or last (or both
together) thus giving 3 potential names for each player. e.g. I could
be referred to as 'Mark', 'Clements' or 'Mark Clements' - so if there
was another Mark you could use one of the other names to avoid confusion,
or Mark 1 / Mark 2. (no jokes). You could possibly also use the
middle names in the event of 2 'Mark Clements'.
This would require the use of an ID code, as well as a name for
the player, which would be created with the character in the form
MUD-ID/CHAR-ID, thus making it unique.
I hope I haven't confused this issue too much - but if I have, PANIC, as
there's more to come.
Some problems:
-->Player X is created on MUD 1. At a later date they log
into MUD 2, which they have never visited before. There
needs to be a way of making sure they use their original
character.
-->Player one changes their password on MUD 1. How will MUD 2
know about the change?
The best method I can see for these is to require the user to be
told their ID (as detailed above) when they create their
character. Then whenever you log on, you are prompted:
'Enter character ID or type 'new' if you wish to create a new character:'
(or something along these lines).
The player will then log on using their ID, which might be easier
to remember if the MUD-ID was a text string rather than numeric.
This way it will check the current player list on the local MUD.
If the player is there, it finds the most recent version of the file
(See previous post) and checks the password against this, responding
accordingly.
If it is not, it queries the original MUD for it's last location
of the player, and attempts to locate it from there. Either way it should
find the file, and check the most recent password.
I hope this letter hasn't been too hard to follow - feel free to
query me on anything ambigous. I'll remember things I've left out
at some stage soon, and shout 'POOS' loudly and detail them in a
subsequent post. Don't hesitate to reply - here or at my mail address.
George Reese
: >Before you ask how you do this (which IMHO is not that big of a deal),
: >you need to ask yourself why. I have not heard why articulated at
: >all. And, as the point of this letter I hope is clear, I feel that
: >there is no reason to do distributed mudding.
: There are several reasons:
: 1. Because some people are annoyed at having to create a new
: character on every mud they play on.
Then why play other MUDs? Just play a few or even one well-built and
diverse MUD.
: 2. To widen the possible number of people you can meet and
: interact with.
Large MUDs have large numbers of people.
: 3. To see if it can be done. :-)
This I can respect, but the answer is yes :)
: 4. To allow for the distribution of a mud over multiple
: servers. With this kind of interconnectivity, you could
: have several large "areas", each of which runs on its
: own server.
Why does each area need its own server? A single server is
sufficient.
: 5. In general, because people think it might be fun. Isn't
: that the whole reason for having muds in the first place?
Whatever floats your boat :)
: The real question you're trying to get at is, "What could you
: do with this that you couldn't already do?". The only thing
: I can think of is that people could use the same character on
: many different muds (that is, transfer stats over, rather than
: create a new character with the same name, etc.). Most muds
: probably won't *want* people to be able to do that, which is
: why I don't see it ever catching on with mud admins. However,
: I could see it being used to create a small network of muds
: that have agreed to participate, being used in this case as
: a way to easily differentiate areas of the mud (i.e., to have
: a pure-fantasy area, a pure-SF area, etc.).
I still fail to see how this cannot be accomplished by one single MUD.
Basically you are talking about a bunch of people pooling their talent
to create an awesome mega-MUD. The fact is, however, that you do not
need 5-10 CPU's to make this happen.
Rick Franchuk
> : I dunno about that... the underlying idea of hooking together muds has
> : basic problems of the type that a lot of major companies deal with every
> : day... INTERCONNECTIVITY. Good experience for when 'real world'
> : situations arise (for all you college geeks out there <grin>). 'sides...
> : even if it doesn't come about, it'd be a helluva mental exercise. Maybe
> : someone should create an RFC for it.
George Reese (bo...@winternet.com) wrote:
> Well, I build applications for distributed environments. And I fail
> to see how that is useful here at all.
> What is the point of distributed computing? It gives you horizontal
> scaleability so that as things grow, you only need to add another
> sparc 10 instead of some monster from IBM for 100,000 dollars. The
> fact of the matter is that no single MUD as it stands now really can
> see the benfits of distributed MUDs. They may be slow, but they are
> slow in taxing the smallest of machines. I know of no MUD out there
> which would bring a sparc 10 to its knees.
> Before you ask how you do this (which IMHO is not that big of a deal),
> you need to ask yourself why. I have not heard why articulated at
> all. And, as the point of this letter I hope is clear, I feel that
> there is no reason to do distributed mudding.
There is a lot more to interconnectivity than simple distributed
computing. Take the WWW. Distributed computing? Hardly. Cycles
wasted on the transfer are virtually non-existant. Perhaps distributed
database. But I guarantee, without a common frame of reference, something
like the Web simply wouldn't exist. Undoubtably there are detractors out
there that whine about how web usage has sucked back bandwidth and is
essentially useless outside of 'toy value'. Probably so, but it is
immensely popular, in part, I believe, that because the interface from
one document to another (cough - the interconnectivity, savvy?) is
virtually seamless, and the lure of publishing your pictures of little
johnny at the beach is enticing.
The point is, when some guys were poking around with SGML years ago, they
probably thought that adding little connections around the machines in
the shop were handy. I doubt few had the insight to see it turning into
the 'nets "killer app". Obviously, aside from a dramatic increase in the
'coolness factor' of muds that'd be interconnected, there'd be no
immediately obvious benefit... but who's to say what could develop in the
future?
History has proven that better communications lead to improved social
structures, faster increases in technology due to the timely sharing of
ideas, etc... why not encourage better communications thru muds? And
what better way than to let people step (preferably seamlessly, altho
that's unlikely) from one mud to another with little effort?
George Reese
: Most of the arguments against realizing intermud connections privilege
: the administrator's experience over the player's. Admins won't like
: reliquishing control, admins have certain ideas of what a MUD should
: be, admins want to personalize a world. Sure, it's the admin's game
: and she names the tune, but where is the player in this? You can't be
: an author without a reader; both experiences are important, so let's
: look at the player's side.
The problem is that this cncept of connecting MUDs is being theorized
in a vacuum without taking into account the social reality in which
MUDs are built. As Beek (Tim for you non-LP people) stated, every
person who can scam the resources tries to start a new MUD. These
MUDs live maybe a week to two months. Almost all eventually die.
Before we talk about connecting our individual MUDs, doesn't it make
sense to make our individual MUDs better?
: When you look beyond the game you see that MUDs are about community
: and mudding about being a part of that community. My brothers and
: sisters in arms, my guild members, my clanspeople, my fellow MUDders.
You talk of players, but then use yourself, me, and Beek as examples.
The fact of the matter is that name recognition only does a handful of
people any good. Most mudders sit on one or two MUDs anyways and make
their fame playing there.
: There are only so many mudders. Let's band together and make our
: small towns part of a whole, expand our horizons.
I very much agree. I think the solution here is for people to *think*
before they start their own MUD. Can they actually put together the
talent and the time necessary to create a new MUD? If not, they might
should be considering working on another MUD as a team. Two MUDs
connected offers us nothing that a single well-built MUD could not
offer.
: No matter how good
: you make Nightmare, only a certain percentage are going to go there.
: The word of mouth gets sucked up in the vacuum between your MUD and
: mine. But imagine a world of MUDs, mudders together swapping battle
: stories, building reputations, spinning tales of some far-off land,
: fighting together. Maybe not the entire MUD community--which I see
: from this soapbox as a whole from the lowliest MOOer to the mightiest
: Diku stud--but some. At least until someone starts to clamor for
: more.
This is why LPMuds have Intermud 3 to connect them. Take a look at
http://www.imaginary.com/intermud/intermud3.html for the design specs,
and join the intermud mailing list to get in on conversation. And I
must point out Intermud 3 is NOT for LPMuds. Any type of MUD can join
it, and we hope other types will.
: It'd be a grand experiment and who knows what might grow from it?
: Maybe nothing, but maybe something more together than anything we can
: achieve separately. The example is more frivolous than I would like,
: but it's the difference between Wolfenstein and Doom. I suppose they
: could have asked, why waste resources making the game networkable when
: we could be making the AI stronger, or build more intricate dungeons,
: or hire the Fat Man to write some tunes for us?
See, I do not feel that connecting MUDs gets you anything. In other
words, I have a Trek MUD and a fantasy MUD which I connect. Why
couldn't I have done those as one single MUD? I feel in the end you
would have ended up witha stronger product.
: No one is threatened; we're not splitting the atom. The energy
: expended in working on this wouldn't be a huge drain, so there really
: needn't be the question 'should we do this?' We should if we want to.
: We'd be answering a question the way the other famous Linus did when
: he asked 'Can we build a better MINIX?' The way the NCSA people did
: when they asked 'Can we improve WWW?' The way you did when you asked
: 'Can I build a better mudlib?' I like Linux, Mosaic and Nightmare.
I do not have any problem with someone actually doing this. In fact,
I am working on a stupid version of this for the Nightmare LPC
Library. Namely something I call interguest which allows people to
visit other MUDs as a guest. If you want to do as you plan, I do not
wish to stop you. I am simply expressing in this forum my doubts that
it adds anything tangible to the table. This of course, does not make
it so. However, i have never been one known not to express his opinion.
Strange Journey
particular, with proper obeisance:
(Aside: George, I take the way that use the term 'distributed muds' to
mean a system for easing computing load. What we're talking about
here is attempting to make gateways from individual MUD to individual
MUD.)
Most of the arguments against realizing intermud connections privilege
the administrator's experience over the player's. Admins won't like
reliquishing control, admins have certain ideas of what a MUD should
be, admins want to personalize a world. Sure, it's the admin's game
and she names the tune, but where is the player in this? You can't be
an author without a reader; both experiences are important, so let's
look at the player's side.
As a player, what I want is to infuse a character with my personality,
to have *one* recognizable, on-line character. Right now I'm
Sjourney, but which Sjourney am I? Am I Sj the programmer of
LambdaMOO, Sj the wizard of Dragon's Den, Sj tyro adventurer of
Frontiers or Sj #n of whatever MUD? The answer 'yes' doesn't satisfy.
When you look beyond the game you see that MUDs are about community
and mudding about being a part of that community. My brothers and
sisters in arms, my guild members, my clanspeople, my fellow MUDders.
But we're isolated on our little MUD islands and whenever we venture
out, we're somebody else. I'm a new Sjourney, you're a different
Descartes, a character without a history. You might be anyone trotting
about that name, who's to know you are *the* Descartes, driver hacker
extraodinaire?
There are only so many mudders. Let's band together and make our
small towns part of a whole, expand our horizons. No matter how good
you make Nightmare, only a certain percentage are going to go there.
The word of mouth gets sucked up in the vacuum between your MUD and
mine. But imagine a world of MUDs, mudders together swapping battle
stories, building reputations, spinning tales of some far-off land,
fighting together. Maybe not the entire MUD community--which I see
from this soapbox as a whole from the lowliest MOOer to the mightiest
Diku stud--but some. At least until someone starts to clamor for
more.
This is not entirely about players, though. There is so much wasted
energy on the admin side. As Tim Hollebeek, eminent patcher of MudOS,
pointed out:
Over half of the new muds don't have any unique theme/goal/
whatever at all. They simply exist for the sake of
existing. And that IMO is a waste of talent and very sad.
And why? Tim again:
Everyone wants their own mud, and very few mud admins are
mature enough to work together with other people.
Maybe we should try to work together. Maybe differenting a MUD by
having a donkey riding skill rather than a coin flipping skill is not
the best way to do that. Cross-pollination would be better. Some of
the resistence we might experience would probably be from admins
worried that their personal fiefdoms won't be as important in their
players' hearts, but if they really have something to add...no
worries.
It'd be a grand experiment and who knows what might grow from it?
Maybe nothing, but maybe something more together than anything we can
achieve separately. The example is more frivolous than I would like,
but it's the difference between Wolfenstein and Doom. I suppose they
could have asked, why waste resources making the game networkable when
we could be making the AI stronger, or build more intricate dungeons,
or hire the Fat Man to write some tunes for us?
No one is threatened; we're not splitting the atom. The energy
expended in working on this wouldn't be a huge drain, so there really
needn't be the question 'should we do this?' We should if we want to.
We'd be answering a question the way the other famous Linus did when
he asked 'Can we build a better MINIX?' The way the NCSA people did
when they asked 'Can we improve WWW?' The way you did when you asked
'Can I build a better mudlib?' I like Linux, Mosaic and Nightmare.
Let's evolve.
Kid/Strange Journey
--
sjou...@netcom.com
Travis S Casey
>: There are several reasons:
>
>: 1. Because some people are annoyed at having to create a new
>: character on every mud they play on.
>
>Then why play other MUDs? Just play a few or even one well-built and
>diverse MUD.
I can't say why, not being one of those people who likes to play
dozens of muds... :-)
>: 2. To widen the possible number of people you can meet and
>: interact with.
>
>Large MUDs have large numbers of people.
That's true... but two large muds together have more people than
either of the two individually.
>: 3. To see if it can be done. :-)
>
>This I can respect, but the answer is yes :)
Ok... let me rephrase that... to see if, how, and how efficiently
it can be done. Some things that seem simple in theory are
difficult in practice, and vice-versa.
>: 4. To allow for the distribution of a mud over multiple
>: servers. With this kind of interconnectivity, you could
>: have several large "areas", each of which runs on its
>: own server.
>
>Why does each area need its own server? A single server is
>sufficient.
That depends on the size of the areas and the CPU speed, memory,
and disk space of the servers. A mud with, say, over a million
rooms would probably bring any reasonable single server to its
knees. (I can see it now... Cray-Mud! Don't I wish...)
>: The real question you're trying to get at is, "What could you
>: do with this that you couldn't already do?". The only thing
>: I can think of is that people could use the same character on
>: many different muds (that is, transfer stats over, rather than
>: create a new character with the same name, etc.). Most muds
>: probably won't *want* people to be able to do that, which is
>: why I don't see it ever catching on with mud admins. However,
>: I could see it being used to create a small network of muds
>: that have agreed to participate, being used in this case as
>: a way to easily differentiate areas of the mud (i.e., to have
>: a pure-fantasy area, a pure-SF area, etc.).
>
>I still fail to see how this cannot be accomplished by one single MUD.
>Basically you are talking about a bunch of people pooling their talent
>to create an awesome mega-MUD. The fact is, however, that you do not
>need 5-10 CPU's to make this happen.
You'll note that I didn't say that the second thing couldn't
be done with a single mud... just that it *might* be easier to
do with a distributed mud.
George Reese
: George Reese (bo...@winternet.com) wrote:
: > Well, I build applications for distributed environments. And I fail
: > to see how that is useful here at all.
: > What is the point of distributed computing? It gives you horizontal
: > scaleability so that as things grow, you only need to add another
: > sparc 10 instead of some monster from IBM for 100,000 dollars. The
: > fact of the matter is that no single MUD as it stands now really can
: > see the benfits of distributed MUDs. They may be slow, but they are
: > slow in taxing the smallest of machines. I know of no MUD out there
: > which would bring a sparc 10 to its knees.
: There is a lot more to interconnectivity than simple distributed
: computing. Take the WWW. Distributed computing? Hardly.
No, the WWW has nothing to do with distributed computing. It has to
do with navigation. Navigation used to be a HUGE problem with the
Internet. A non-changing fact is that all users originate from
different physical locations using different types of hardware. WWW
solves the problem of giving them a consistent navigational tool for
anything out there.
: The point is, when some guys were poking around with SGML years ago, they
: probably thought that adding little connections around the machines in
: the shop were handy. I doubt few had the insight to see it turning into
: the 'nets "killer app". Obviously, aside from a dramatic increase in the
: 'coolness factor' of muds that'd be interconnected, there'd be no
: immediately obvious benefit... but who's to say what could develop in the
: future?
They may or may not have known it would be the next killer app. But
they did have a well-recognized problem in front of them. The problem
people for years had been saying was why the Internet will never
become a big thing. Seems to figure that they thought solving this
problem might change the face of the Internet. But, again, even if
they did not, they had identified a problem with the way the Internet
currently works and they solved it.
Only one problem with MUDs has been identified here, and that is the
fractured talent pool. Connecting MUDs does not solve that problem.
Strange Journey
> [Lots of interesting comments to several people] <
Sure, there's no need to have different MUDs at all since they could
all have been implemented on one machine under one administration,
except that people *will* be so stubborn and self-assured as to want
to start their own. One might as well ask why all the other countries
in the world don't give up their sovereignty and join the US? It'd be
more efficient and less of a hassle. They don't want to, but because
they don't want to doesn't mean that their people shouldn't be able to
travel here.
It's easy to call for would-be MUD admins to join an existing MUD
rather than start one up when you're already running your own. You
had a vision, you implemented it, that's great. Everyone who wants
should have that chance. Linking MUDs would not be in order to create
one mega-MUD. I see a big difference between one monolithic MUD with
a lot of variety and lots of little MUDs linked together. Connecting
MUDs allows us to have our MUDs and community, too.
> Only one problem with MUDs has been identified here, and that is the
> fractured talent pool. Connecting MUDs does not solve that problem.
You're not going to get people to stop wanting to start their own
MUDs. Connecting MUDs solves the problem of erratic quality by giving
us players the opportunity to pick the best of what's out there
without having to give up emotional attachment to our characters by
having a hundred different characters scattered about.
> Then why play other MUDs? Just play a few or even one well-built and
> diverse MUD.
If it's not in my own backyard in Kansas, I probably didn't want it
anyway! <petting Toto>
>>: 2. To widen the possible number of people you can meet and
>>: interact with
>Large MUDs have large numbers of people.
Again, it's a matter of thinking broadly. The US has a lot of people,
but it's nice to meet people who live somewhere else. One MUD isn't
enough, several MUDs isn't enough. We shouldn't have to cut ourselves
off from each other just because we're on different MUDs. That a
large MUD has a large number of people isn't an argument against
linking up and having more people.
> Most mudders sit on one or two MUDs anyways and make their fame
playing there.
They do so because they don't have any way of going to other MUDs
without starting over from scratch.
> See, I do not feel that connecting MUDs gets you anything. In other
> words, I have a Trek MUD and a fantasy MUD which I connect. Why
> couldn't I have done those as one single MUD?
A better example would be, you have a Trek MUD and I have a fantasy
MUD, but I don't want to have to follow your policies, obey how you
think a MUD should be run, ask your permission to start it up in the
first place as I would have to if I wanted to add a fantasy area to
your Trek area. But players shouldn't be punished for that;
connecting our MUDs would allow us to have the best of both worlds.
Kid/Strange Journey
--
sjou...@netcom.com
Daxboeck Patrick
: In article <803774...@mabsy.demon.co.uk>,
: Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
: >InterMUD connection:
: >
: >One way of doing it might be to create a MUD client which stores
: >player information in much the same way as the WIN.INI file that Windows
: >uses. e.g. a heading in square brackets indicating the MUD name, which can
: >be added to.
: A format for storing the data is the trivial part ...
: >name=Dennis;
: >password=dh12nb4 **
: >ip_address=156.24.312.42
: >LastMud=Mudname1|192.64.36.115/6666
: >
: >[Mudname1|192.64.36.115/6666]
: >LastEntered=12/04/95
: >Race="orc"={
: > strength=+4
: > wisdom=-2
: > }
: >Strength=17
: >Wisom=20
: >LockPick=12
: >Level=4
: This assumes all muds are so boring that they all have the same
: stats/skills/etc.
: >It then checks to see if it already has a section in the file, if so
: >it creates a character based on the information held there. It then
: >searches the other MUDs' sections in order they've last been visited (most
: >recent ones first) to try and fill in any stats it doesn't have listed.
: >Thus, if MudName2 in the above example made use of the strength stat, it
: >would look through the other sections and find it under MudName1.
: >These may (probably) need to be expressed as a percentage of the maximum,
: >but things like levels (which sometimes are unlimited) it would need
: >to be expressed differently. This needs some thought.
: Ok. I start up BeekIsReallyGreatMUD. I quickly advance in levels and
: stats through the GiveMeGobsOfStats command until I have all my stats
: maxed and I'm level 1 zillion. Then I transfer my character to your
: mud ...
Well, the format noted above could be changed to:
name=Dennis;
password=#$Ljhjkuy
ip_address=156.24.312.42
LastMud=Mudname1|192.64.36.115/6666
[Mudname1|192.64.36.115/6666]
comrades=Mudname11
friends=Mudname3|Mudname10|Mudname23;
public:
enter="appears within a red smoke"
leave="vanishes with a loud zzziiiiinnnngg"
long="Dennis the hyperfreak"
level="The stupid wanderer"
private-encrypted:
MMN23988asdhkjfhlk2345kjhasdjhk345j389j;
MMNasoai8743898749879a8s9d87fd98a7s9d8f;
MMNjkao34904a8asdlq4uhadkgjhlequw32kjha;
MMNlqwadslkfjwkejlaijldkjeljwkjlkjlaskd;
end
friend-muds-encrypted:
FRMasiouieu3oii35892saoiu89a239898dshSA;
FRMalkswerjklwjkheiuwweu367s7a67w676673;
end
end-Mudname1
[Mudname2|134.34.64.132/4296]
public:
long="Hrun the Gatesmasher"
private-encrypted:
MMNwoiueoriuoaidofiuaso3879asdf793sadfh;
end
end-Mudname2
[Mudname3|132.32.54.113/1701]
lookup-friend=Mudname1
private-encrypted:
MMN238949782aasdfjklweriuoasAWEKJR2387f;
end
end-Mudname3
[Mudname11|183.23.18.132/4000]
lookup-comrade=Mudname1
end-Mudname11
end-User-File
Note: the key for private encrypted sections is in the MUD !
same is the friend-muds key !
comrade: a MUD fully sharing the User
friend: a MUD partly taking over some Info of the USER
public: visible Texts, maybe overridden by encrypted info, so
you could make Level, Stats visible for the User, but not
changeable.
lookup-friend: read public and friend informations from another entry
lookup-comrade: read all informations from another entry
: Obviously, I'm exagerating, but this could happen if even if you
: restrict the muds you'll accept characters from. People will have an
: incentive to play the easiest mud in the group. Of course, that's no
: problem. I'm sure the admins can easily resist the temptation to make
: their mud easier so as to attract more players *wink*. Pretty soon,
: all the muds will be involved in an arms race ...
: If you don't think this will happen, consider the fact that it happens
: on many muds wrt individual areas.
Don't criticize, make better suggestions!
a) Many Muds still have different Areas! They wouldn't have, if it was
impossible to balance them.
b) On most Muds, there is no specific information, restricted to one area,
not visible or decryptable by others (on a small unit like a mud
unneccesary, i agree)
c) with different friend levels: comrade|friend|friend-class2
or different shareable parts: level-friend|stat-friend|skill-friend
you could connect and separate between muds what you wish !
d) But don't make it too complicated !
: >Special things which have no obvious effect from their value, but have
: >an effect on the game (e.g. 'race' above) could have a little sub-section
: >dealing effects - possibly in C like code e.g.
: > if(weapon="club"){ DamageDone=+4; }
: >for an orc, as they have extra club-weilding ability. These will only be
: >used if the specific instance is not available on the current MUD. Values
: >such as the ones in the example may be sufficient however.
: Sufficient? Only if your mud is a really lame hack and slash with no
: originality. Have you suggested this to Diku's? :)
: >Objects could be dealt with (alright I lied earlier) by having
: >an [inventory] section which lists the object code of the items, and
: >a little information, such as name and desc. so it can access their
: >original MUD if necessary, but this will only be when they are
: >to be used. Both the incoming MUD and outgoing MUD can screen
: >against certain objects being transfered.
: This would be a balance headache at best, ignoring the fact that the
: muds would have to be very similar for the code to transfer decently ...
see above !
: >(I wonder how plausible this all is?)
: >
: >Continue this thread!!
: Nah, let it die :) This should be in the FAQ along with 'can emacs be
: implemented?'
No, don't let it die! Think about it for some weeks and start to code it!
I like the idea of fully and partly connected muds!
It's something i've been waiting for a long time!
Patrick Daxboeck
phda...@stud.ee.ethz.ch
Jennifer Kleiman
>: Nah, let it die :) This should be in the FAQ along with 'can emacs be
>: implemented?'
>
>No, don't let it die! Think about it for some weeks and start to code it!
>I like the idea of fully and partly connected muds!
>It's something i've been waiting for a long time!
Have any of you looked at UnterMUD? It's got net-links built into
it (see ftp.tcp.com:pub/mud/UnterMUD). It was written several
years ago by Marcus J. Ranum. You can walk from one Untermud server
to another carrying whatever you like, and all your information is
carried with you. Or coolmud is a fairly completely distributed mud
( see http://csclub.uwaterloo.ca/u/sfwhite/coolftp/
for more info). So, no need to wait!
Jennifer Kleiman
Martin Friedrich
I thought about connecting Muds already some years ago, technically I don't
think it to be such a big problem. But two Muds, wherever they are, are too
different to allow a good transferrence of characters. And where's the point
in going into another Mud, if you start as Level-1-Newbie with no equipment?
You'd have to build two similar Muds to connect them, but then, you can also
put them together in just one Mud.
-Efchen the Sage of TAPPMud (now 2 MBit/s!!)
--
/~\ | Martin Friedrich IRC/MUD: Efchen
C oo | Postfach 1602 Solace TAPPMud: 141.65.40.11 6510
_( ^) | 91006 Erlangen Dragon m...@surprise.pro.ufz.de
~\ | GERMANY -=(UDIC)=- email:efc...@solace.franken.de
Tim Hollebeek
>: stats through the GiveMeGobsOfStats command until I have all my stats
>: maxed and I'm level 1 zillion. Then I transfer my character to your
>: mud ...
>
>Well, the format noted above could be changed to:
>
> levels for muds]
Your way is going to cause hundreds of megabytes user files for
anything but a really simple distributed system (i.e. more than 3-4
muds with #'s of players corresponding to open muds), so it really
doesn't scale well at all. At the low end, you gain very little from
the flexibility, so hard coding the trustedness is better anyway.
Again, I stand by my original statement. You are either joining a
small number of muds, in which case you lose more than you gain since
they could all be on one machine anyway, or you're connecting a large
number of muds, in which case you have yet to show that you can
effectively and efficiently deal with the balance and scaling issues.
>: Obviously, I'm exagerating, but this could happen if even if you
>: restrict the muds you'll accept characters from. People will have an
>: incentive to play the easiest mud in the group. Of course, that's no
>: problem. I'm sure the admins can easily resist the temptation to make
>: their mud easier so as to attract more players *wink*. Pretty soon,
>: all the muds will be involved in an arms race ...
>
>: If you don't think this will happen, consider the fact that it happens
>: on many muds wrt individual areas.
>
>Don't criticize, make better suggestions!
No, if I feel the concept is flawed, I am free to say such a thing.
I don't think there is anything to be gained by this idea. It ISN'T
a new idea; people have been suggesting it for years and years and
years. The reason you don't see it implemented is because it doesn't
offer any significant gains.
>: >(I wonder how plausible this all is?)
>: >
>: >Continue this thread!!
>
>: Nah, let it die :) This should be in the FAQ along with 'can emacs be
>: implemented?'
>
>No, don't let it die! Think about it for some weeks and start to code it!
>I like the idea of fully and partly connected muds!
>It's something i've been waiting for a long time!
Like I said, it's not a new idea. If you want to fiddle with it, feel
free. I'm just pointing out what people have concluded after thinking
about it and trying it before.
Frank Crowell
: Have any of you looked at UnterMUD? It's got net-links built into
: it (see ftp.tcp.com:pub/mud/UnterMUD). It was written several
: years ago by Marcus J. Ranum. You can walk from one Untermud server
: to another carrying whatever you like, and all your information is
: carried with you. Or coolmud is a fairly completely distributed mud
: ( see http://csclub.uwaterloo.ca/u/sfwhite/coolftp/
: for more info). So, no need to wait!
Yes, they both are interesting muds. However, my view of
the mud world would not require true distributed muds,
just cooperative muds. MegaMuds need some type of
distributed worlds (by mega I mean muds that can handle
population sizes in the thousands). Travellers have
a different need.
I see my character as a traveller through space/time
sort of like Dr Who and the Tardis. As a traveller
I would like:
-transfers from mud A, point x to mud D, point y
automagic (i.e. no login or walking to point y)
The linkage are hyperlinks; transfer, login, and
movement is done with client. If the client is
telnet, then you can't do the transfer.
This method would allow 10,000 muds or more to be
part of the same web.
-consistent stat, point, economic system. Possibly
use some universal system; everything is scaled and
translated from that.
-object transfer. I want my npcs and objects
to move to mud D, point y. I can fake this on
MUSH or MOOs where I have programmer character.
Client builds the objects on the mud; removes
the objects on departure (assumes all objects
are temporary). Actually the mud should cooperate
with this part too.
-visit my ship/travel with me. Haven't simulated
this yet.
If every traveller has a home, then foreign muds don't
need passwords or character files. Your character
becomes Lumpy from "Traveller Home" or Lumpy@travellerhome.
Foreign muds would remove your character and your objects
after you leave. Naturally you have a password at the home mud.
However, foreign muds could require some form of passport.
Static objects can easily be described in some common format.
Don't know how dynamic/npc objects would be handled.
-frank
--
___________________________________________________
Frank Crowell fra...@maddog.com
maddog's studio http://www.maddog.com/
Mah / Nicholas (MGM)
>all. They simply exist for the sake of existing. And that IMO is a
>waste of talent and very sad.
Far worse ;/
--OH
--
That is the tale the women tell each other, in their private language, that the
men children are not taught, and that the old men are too wise to learn. And in
that version of the tale perhaps things happened differently. But then, that is
a woman's tale and is never taught to men. (Gaiman/ "The Doll's House")
George Reese
: > words, I have a Trek MUD and a fantasy MUD which I connect. Why
: > couldn't I have done those as one single MUD?
: A better example would be, you have a Trek MUD and I have a fantasy
: MUD, but I don't want to have to follow your policies, obey how you
: think a MUD should be run, ask your permission to start it up in the
: first place as I would have to if I wanted to add a fantasy area to
: your Trek area. But players shouldn't be punished for that;
: connecting our MUDs would allow us to have the best of both worlds.
You make the (IMHO invalid) assumption that your policies are separate
from the character of your MUD. This gets us back to the game balance
issue. By connecting my MUD to your MUD, I am giving up total control
of how a player advances in my game. This directly affects the
policies of my MUD. The problem here is of course that I am seeing
this as my MUD. If I see it as our MUD, which you are encouraging,
which is in fact necessary for connecting MUDs to work, then the whole
problem which you feel necessitates connecting MUDs goes away. Why?
Because if it is OUR MUD, then we both get to choose what themes go
into the MUD, right?
Mark Clements
bo...@winternet.com "George Reese" writes:
> I still fail to see how this cannot be accomplished by one single MUD.
> Basically you are talking about a bunch of people pooling their talent
> to create an awesome mega-MUD. The fact is, however, that you do not
> need 5-10 CPU's to make this happen.
Say MUD X is down for a while, or disappears completely. Your level 4000
character is gone. Kaput. Blotto. Kablooie (thanks Andy). Or you could
just log into one of the other connected MUDs and carry on playing.
Say group of wizards A disagree with group of wizards B as to a new aspect
of the MUD. What happens. Fighting. Bitching. Blood-shed. Tool-shed.
(er... maybe not tool-shed). (Oh, Sod it! Why not :- Tool-shed). The MUD
is finished. Kaput. Blotto. Kablooie (thanks again, Andy). Maybe they'll
go off start a new MUD - but the old one will be lost. Take Highlands (the
original) as a case in point. Disagreements between to wizzing factions
caused the MUD to split and a new one to be created (from scratch? I might
be wrong) and the original Highlands to be lost.
On an interconnected set of MUDs - one set of wizards can go start a new
section, which they will have control over, but which is still 'part' of the
original MUD. (see next point) This just leaves the problem of
which group this should be <Grin>.
Say you're starting a new mud (MUD N-1) you're getting it up - player object
in place, some locations etc. Open for testing, but how many players will
you have? None. Zip. Nada. Buggery-shite-all. Kablooie (Not this time,
Andy). And why? Because people don't think it's worth going to a MUD,
creating a character and so on, only to have very little to do. Case in
point: St. Andrews MUD. Very few players - no new players. Very few areas.
Kind of circular, huh? MUD closed.
Having said all that, think 'Hmmm. Connected MUDs ain't so bad!' and give
yourself a nice biscuit.
Dr. Cat
: As a player, what I want is to infuse a character with my personality,
: to have *one* recognizable, on-line character. Right now I'm
: Sjourney, but which Sjourney am I? Am I Sj the programmer of
: LambdaMOO, Sj the wizard of Dragon's Den, Sj tyro adventurer of
: Frontiers or Sj #n of whatever MUD? The answer 'yes' doesn't satisfy.
You know, it's worth pointing out that the question of what the pros,
cons, implementation difficulties, and worthwhileness of linking muds are
varies GREATLY depending on whether you are talking about combat muds,
social muds, or roleplaying muds. This discussion may be biased mostly
towards the combat muds, since it is posted on rec.games.mud.lp and not
on, for instance, rec.games.mud.tiny. But I am reading it on
rec.games.mud.misc, so I feel that here in MY chosen mud newsgroup it is
fair game to discuss all three types. :X)
The question you mention of "Which Sjourney am I?" is a case in point.
What the important aspects of what defines "me-ness" are vary quite a bit
between the mud types. On a combat mud my class, equipment, hit points,
magical abilities, etc. might contribute significantly to my "self image".
On a social mud, it's just name and description - and for some *really*
casual players, only the name really matters. So the whole issue of
balancing statistics when travelling between worlds of different
toughness is a non-issue on the social muds.
Frankly, though, what a lot of people do there, myself included, is
either disconnect from one mud and log on to another as an easy-enough
way to "travel" between them - or just log onto two or three at the SAME
time using tinyfugue, screen, xwindows, or whatever. It is very common
on the MUCKs for people to have the same character on several, copying
the exact desc from the first one they created themselves on. A few
people even copy over their homes, room for room!
So to me, when I run into one of my best friends on one of the MUCKs I
frequent, we are the same people having the same sorts of conversations
no matter where we happen to meet, as if they were ALREADY linked
together, even though they're not. I am the guy who pretends to be a cat
and talks to my friend in California about what happened at my job or my
recent trip to the zoo whether we're meeting in a mud that's set in a big
park, or in a different one that's down under the sea. :X)
For the combat muds, I would break down what you're trying to accomplish
from two angles. One is looking at the possibility of getting a lot of
existing, well developed, established muds to modify themselves so that
they connect.
Ain't gonna happen.
Second angle is the possibility of getting a bunch of newly forming muds
and muds that form in the future to do this. More practical.
But of course, here the "optimum" solution to getting all these talented
builders and wizzes to make all of their adventuring areas available in
one big linked structure is to make one huge mud, and have them all build
parts of it. The *only* reasons this couldn't be done are because the
combat muds tend to always be short on resources as it is, on the
machines people can get to run them on, and because the community is too
diverse, scattered, and difficult to gather together for one big
mega-project.
The former point could be addressed. I think clearly someone would have
to write a new server (or expand upon an old one) to create a SINGLE
distributed server program that ALL the linked muds would be running.
Thinking you can have different code bases that all implement an agreed
upon standard... That takes far more work, and produces far inferior
results. I would say that you either code up an actual distributed
server and then this experiment produces some results, or nobody codes up
the server, and then this whole discussion is just talk that doesn't lead
anywhere.
I don't see any clear way around the issue of the diversity of the mud
community, though. You would certainly get at least a handful of muds
linked if you made a distributed server. Maybe more, and maybe several
small independent clusters of linked muds.
I still think one mud with really talented people running it would easily
be more fun than half a dozen mediocre ones linked. One really great mud
and five mediocre ones wouldn't be much different - everyone would flock
to the cool part, difference is it might get overcrowded a bit faster.
Only way you'd really be establishing something novel would be to get
multiple good/great muds linked together, then you might have something.
Alas, the density of talent in the world is light, and this kind of thing
is VERY hard to do. Gathering talent together is a very valuable skill,
which is why people like producers and agents are actually allowed to
continue living. ;X) I have two partners working with me on our little
mud, and we're hoping to add a fourth person by the end of the year, and
I'm quite happy to have that many. Getting dozens and dozens of people
to work on a really cool project is a VERY rare thing.
***********************************************************************
Dr. Cat / Dragon's Eye Productions ** Come play DragonSpires!
******************************************** ftp.eden.com pub/dspire
Dragonspires is a graphic mud for PCs. ** has everything you need!
***********************************************************************
** http://www.realtime.net/~gauntlet/dspire.html for more info **
***********************************************************************
Daxboeck Patrick
: In article <3su638$s...@elna.ethz.ch>,
: Daxboeck Patrick <phda...@stud.ee.ethz.ch> wrote:
: >Tim Hollebeek (t...@handel.Princeton.EDU) wrote:
: >
: >
: > [really huge format including encrypted keys and various trust
: > levels for muds]
: Your way is going to cause hundreds of megabytes user files for
: anything but a really simple distributed system (i.e. more than 3-4
: muds with #'s of players corresponding to open muds), so it really
: doesn't scale well at all. At the low end, you gain very little from
: the flexibility, so hard coding the trustedness is better anyway.
A: I was thinking about the connection of only a handful of muds, when
i wrote the text above.
B: This protocol including encryption doesn't need to be stored on each mud,
it could just be handled by the users client, which would be necessary
for joint mudding.
C: If the user doesn't have a compatible client, a mud will only keep the
information of the nearest and best connected muds.
D: Even the user Information could be distributed, e.g. the users home-mud
contains the full information, the other muds only contain the information
about their own mud and a reference to the full user information.
: Again, I stand by my original statement. You are either joining a
: small number of muds, in which case you lose more than you gain since
: they could all be on one machine anyway, or you're connecting a large
: number of muds, in which case you have yet to show that you can
: effectively and efficiently deal with the balance and scaling issues.
[some stuff deleted]
: >Don't criticize, make better suggestions!
: No, if I feel the concept is flawed, I am free to say such a thing.
: I don't think there is anything to be gained by this idea. It ISN'T
: a new idea; people have been suggesting it for years and years and
: years. The reason you don't see it implemented is because it doesn't
: offer any significant gains.
I know, it isn't a knew idea and they will be talking about it, until
someone realizes it.
: >: >(I wonder how plausible this all is?)
: >: >
: >: >Continue this thread!!
: >
: >: Nah, let it die :) This should be in the FAQ along with 'can emacs be
: >: implemented?'
: >
: >No, don't let it die! Think about it for some weeks and start to code it!
: >I like the idea of fully and partly connected muds!
: >It's something i've been waiting for a long time!
: Like I said, it's not a new idea. If you want to fiddle with it, feel
: free. I'm just pointing out what people have concluded after thinking
: about it and trying it before.
It needs some thought and definitions.
What I really think about is:
Mud-Freak A,B,C have all their Machines on the Internet, containing Muds
These Muds have the disadvantage of being quite small, but together they
would make a complete, well balanced mud.
Neither of the Muds is extremely stable.
Why shouldn't we define a protocol, which allows these Muds to appear as
a single Mud D.
D would be stable, with the exception, sometimes some areas are blocked
due to shutdown/crash/upgrade of one of the machines.
Sometimes the Users of Mud D would like to talk/whisper to a comrade on
one of the Muds E,F,G. Because E,F,G is on the Mud-Net they can.
and armours, they had gained in Mud E, last time, they were there.
What i'm iterested in most, is the ability to have a handful of compatible
Muds appear like a single and stable one for the user.
This surely helps reducing the number of similar (boring) muds and increases
quality (stability, large worlds) of them.
: Tim Hollebeek 'There will be a better sig when I have time'
MudOS is great, keep on!
greetings
Patrick Daxboeck
phda...@stud.ee.ethz.ch
Strange Journey
bo...@winternet.com (George Reese) writes:
> You make the (IMHO invalid) assumption that your policies are separate
> from the character of your MUD.
There are policies that affect the atmosphere and playability of a MUD
and there are policies and personality issues that effect the
environment for the wizards there. To make linked MUDs workable would
require cooperative policies on player issues, but those are the only
issues we need to deal with. It's a different set of politics--
probably just as frustrating but different from that between wizards
on the same MUD, particularly one on which one god has her finger on
the reset button. Working on someone else's MUD requires agreement
not only as to what themes go in, but what wiz heirarchy and
advancement is set up, whether it's cooperative or competitive, whether
old wizzes call the shots, how new wizzes prove themselves and are
accepted. Any number of things which would be irrelevant to MUD net
administration.
I'm encouraging we look at it as our MUD NET in that light, not our
MUD. If we reach an impasse, we break the link. Were I a wiz on
another's MUD, I'd have no other recourse than to abdicate. Hopefully
I'd be allowed to keep my code, but that's asking a lot.
While it's pleasant to envision people working together on the same
MUD, I don't see the impulse to roll your own going away soon, and I
certainly don't expect existing MUDs will close down to make a better
product. That's the situation we have now, we have to deal with it.
Linking would be a better bet than altruism.
Kid/Strange Journey
--
sjou...@netcom.com
Strange Journey
: You know, it's worth pointing out that the question of what the pros,
: cons, implementation difficulties, and worthwhileness of linking muds are
: varies GREATLY depending on whether you are talking about combat muds,
: social muds, or roleplaying muds.
I feel differently about my character than others must. To me it's
not the place that's important but the character, so much so that I
don't even want to think about place. (By place I mean where on the
net a particular virtual community is run, not setting and atmosphere
which are important and would not be effected by connection.) Sure, I
can duplicate myself on mutilple MUCKs, run multi session with my
client and consider it the same character, but I have a perverse
desire to not see the man behind the curtain, to connect once and be
*there*. MUD world. It's me, it's my avatar. I'm annoyed that to
@join a friend on PMC MOO while I'm on Lambda requires that I run a
seperate session and log in there, switching windows to see what
others have said to the other me. As an admin, ok, I can see what a
pain in the butt it is to break down the barriers, but as a player it
breaks the illusion and interferes with my suspension of disbelief.
On more game oriented MUDs this becomes that much more intense. I'm
brainwashed, though. The Net convinced me that geography doesn't
matter, the Web that the hardware and OS don't matter. It's a hard
lesson to be told we'll have stay in our little boxes.
Cheers, man. I dug your post.
Kid/Strange Journey
--
sjou...@netcom.com
stephen f. white
> I would say that you either code up an actual distributed
> server and then this experiment produces some results, or nobody codes up
> the server, and then this whole discussion is just talk that doesn't lead
> anywhere.
it doesn't seem like anyone in this thread knows, but there have
already been written at least two distributed MUD's, UnterMUD and
COOLMUD. (there was also a project called "DOME" that someone was
working on, but as far as i know it's still vapourware).
neither of them is the ultimate server, but both solve the distributed
problem in different ways, UnterMUD through loose coupling and object
migration, COOLMUD through tight coupling and message passing.
UnterMUD is available at
ftp://ftp.math.okstate.edu/pub/muds/servers/
(files called "umud*")
COOLMUD can be found at:
ftp://csclub.uwaterloo.ca/pub/coolmud/
as a side note, personally i don't think have a distributed MUD
particularly changes the nature of MUD's or anything. it was just
something i wanted to try my hand at coding.
-=- sfw
--
stephen f. white
sfw...@undergrad.math.uwaterloo.ca
http://csclub.uwaterloo.ca/u/sfwhite
"language is a virus from outer space" -- w.s.b.
Alexander Weidt
>it doesn't seem like anyone in this thread knows, but there have
>already been written at least two distributed MUD's, UnterMUD and
>COOLMUD. (there was also a project called "DOME" that someone was
>working on, but as far as i know it's still vapourware).
The DOME project is currently still rather vapourous, although large
subsystems are running and have been tested (what's still missing is
the I/O synchronisation).
>neither of them is the ultimate server, but both solve the distributed
>problem in different ways, UnterMUD through loose coupling and object
>migration, COOLMUD through tight coupling and message passing.
DOME resolves the problems presented by asynchronous execution by
providing a conventional single-threaded execution model, and
implementing this with a lock-free object access synchronisation
mechanism. I.e. you can provide _sequential_ object specifications,
and the run-time system will see to it that the resulting asynchronous,
parallel execution is sequentially consistent, without deadlocks.
The current DOME system contains no interpreter. The object code
is written in C (an extension to C++ is in the works) and dynamically
link-edited into the executable on demand. Communication between
individual DOME servers is implemented on top of PVM, and the thread
management uses the Pthreads library.
Interested persons might want to check out our WWW page at:
http://www.cs.tu-berlin.de/~demos/dome.html
where a paper which was presented at this year's "European Advanced
Research Seminar on Distributed Systems" can be found.
Happy hacking, Alex (Demos@TubMud).
P.S. In case you're dying to take a look at the current status of
the implementation, and are willing to participate in the
development, don't hesitate to drop me a line.
George Reese
: : No, if I feel the concept is flawed, I am free to say such a thing.
: : I don't think there is anything to be gained by this idea. It ISN'T
: : a new idea; people have been suggesting it for years and years and
: : years. The reason you don't see it implemented is because it doesn't
: : offer any significant gains.
: I know, it isn't a knew idea and they will be talking about it, until
: someone realizes it.
There are a few questions which run around forever on the MUD
newsgroups like this. One is "Can I get vi on my MUD?". Another,
this one, is "Can I connect my MUD to other MUDs?". Why do they keep
getting asked and never solved? Not because they are too hard.
Indeed, they are not *that* hard that no one would have done it by
now.
The problem is that they are not the right questions. The proper
question with respect to vi is "How can I create MUD files more easily
from my home computer?" The answer invariably is NOT to put vi into
the MUD. People only continue asking the question because they are
trying to apply a solution to another problem (creating files on a
UNIX machine) to MUDs. They think "I edit my UNIX files using vi, why
can't I edit my MUD files that way."
The questions about MUD + WWW are misguided in this same manner.
What is the real question behind the connecting MUDs? I have been
trying to get at that in this thread. The thread asks the wrong
question. It proposes a solution (connecting MUDs) to a problem that
has not been defined. The first step is actually to define the
problem THEN you talk about solutions. Multiple solutions.
None of the problems people have posed seem to me to be honest
problems, nor to be problems for which connecting MUDs is the best
solution. Connecting MUDs, IMHO, is a solution to the problem of I
have huge MUD X which can either mov to a sparc 20 or scal across 2
sparc 5's, which should I do given that I already own 2 sparc 5's?
: It needs some thought and definitions.
: What I really think about is:
: Mud-Freak A,B,C have all their Machines on the Internet, containing Muds
: These Muds have the disadvantage of being quite small, but together they
: would make a complete, well balanced mud.
: Neither of the Muds is extremely stable.
: Why shouldn't we define a protocol, which allows these Muds to appear as
: a single Mud D.
: D would be stable, with the exception, sometimes some areas are blocked
: due to shutdown/crash/upgrade of one of the machines.
: Sometimes the Users of Mud D would like to talk/whisper to a comrade on
: one of the Muds E,F,G. Because E,F,G is on the Mud-Net they can.
: and armours, they had gained in Mud E, last time, they were there.
You have a solution here, and you are trying to engineer a problem for
it. However it does not work.
The answer here is NOT to connect the three MUDs, but instead to pool
their resources and build one large MUD.
George Reese
: UnterMUD is available at
: ftp://ftp.math.okstate.edu/pub/muds/servers/
: (files called "umud*")
: COOLMUD can be found at:
: ftp://csclub.uwaterloo.ca/pub/coolmud/
IMHO, neither of these properly deals with distributed muddin, as they
do not scale well and create a lot of interdependence. If I were
actually to do this thing, I would take a three tiered approach which
would make the distributed nature of the MUD invisible to the client
application whether it be telnet or a custom client.
Dave Austin
bo...@winternet.com "George Reese" writes:
> Daxboeck Patrick (phda...@stud.ee.ethz.ch) wrote:
> : : No, if I feel the concept is flawed, I am free to say such a thing.
> : : I don't think there is anything to be gained by this idea. It ISN'T
> : : a new idea; people have been suggesting it for years and years and
> : : years. The reason you don't see it implemented is because it doesn't
> : : offer any significant gains.
>
> : I know, it isn't a knew idea and they will be talking about it, until
> : someone realizes it.
>
> There are a few questions which run around forever on the MUD
> newsgroups like this. One is "Can I get vi on my MUD?". Another,
> this one, is "Can I connect my MUD to other MUDs?". Why do they keep
> getting asked and never solved? Not because they are too hard.
> Indeed, they are not *that* hard that no one would have done it by
> now.
>
The one that is ALWAYS coming up across all newsgroups is variations
on the theme :-
"how do I connect to these MUDs"
"I can connect but I don't have a password or username"
Now if we could all solve that one, we would have the time to look into
the more technical questions you are talking about. Personally I
believe anyone who WANTS to use Vi should seek medical attention
urgently.
Dave Austin
--
+ - The Legend Lives - Avalon-rpg.com 23 (204.248.237.2 23) - +
+ - - http://www.avalon.co.uk - - +
Strange Journey
: What is the real question behind the connecting MUDs? I have been
: trying to get at that in this thread. The thread asks the wrong
: question. It proposes a solution (connecting MUDs) to a problem that
: has not been defined.
I can't say about the vi thang, but here's an answer to your question
about why this keeps getting asked and never done. This is an issue
about cultural benefits, not technical ones, yet it keeps getting
argued from a technical position. It's a player desire that
administers don't see, can't see, or won't see. It's the
administrators that write the drivers and since they don't see a
return on their MIPs they don't care to do it. We've been talking
about why players would want it and you keep attacking it on the
grounds that distributed MUDs don't add anything. This is not about
one MUD distributed over many machines. You've won that point, but
that's a point from a different argument with no bearing on this
discussion.
This reminds me of commercial game makers who held out for so long
against offering their audience the chance to play against each other,
saying that people weren't really interested in that sort of thing.
So GEnie reaps the big bucks in the vaccuum until iD figured it out.
Now we get some. It's what *we* want and we're not getting it.
I understand it's your party, you're not getting paid and you have the
right to do whatever you choose. You choose to say no, that's cool.
Disappointing, but cool.
Problem: So many MUDs but all isolated, tired of a hundred characters
of varying levels, frustrated knowing there's a huge MUD community out
there and only seeing a fraction of it, desire to have full range of a
lot of individuals MUDs that exist already and will be born with one
character that I can identify with instead of a prime one and its
offspring, think that linking MUDs would generate good benefits for
the players and possibly some synergy leading to unknown, unforseen,
wholly new results.
Proposed solution: One monolithic MUD.
Reasons for: It can be done easily.
Simulates a multi-MUD environment.
Stricter controls implies better quality.
Creators have captive audience.
Reasons against: Doesn't do anything about existing MUDs.
One person/group owns machine.
*Simulates* is key word.
Stricter controls implies stifling beurocracy.
Forces agreement on wide range of issues:
difficult.
Proposed solution: Connecting MUDs.
Reasons for: Allows existing MUDs to participate.
Individual creators retain control.
Players can see repetition between MUDs implying
improved quality, more variation.
More than one vision allowed to be implemented.
Agreement on how to handle player advancement
issues all that's required.
No one person owns machine.
Reasons against: Somewhat more difficult to implement
technically.
Creators no longer have captive audience.
Kid/Strange Journey
Tim Hollebeek
George Reese <bo...@winternet.com> wrote:
>Daxboeck Patrick (phda...@stud.ee.ethz.ch) wrote:
>: [about connecting muds]
>
>: I know, it isn't a knew idea and they will be talking about it, until
>: someone realizes it.
>
>There are a few questions which run around forever on the MUD
>newsgroups like this. One is "Can I get vi on my MUD?". Another,
>this one, is "Can I connect my MUD to other MUDs?". Why do they keep
>getting asked and never solved? Not because they are too hard.
>Indeed, they are not *that* hard that no one would have done it by
>now.
Actually, this one has been done. Quite a number of people have done
it, then promptly realized what they had just created was rather
useless, and let it fall into obscurity.
Lookup bamfing in TinyFugue to see how simple the client side
implementation can be; the server side implementation is just about as
trivial.
I have a funny feeling Desc is going to add a section on this to the
FAQ :)
--
---
Aaron Brand
: > I would say that you either code up an actual distributed
: > server and then this experiment produces some results, or nobody codes up
: > the server, and then this whole discussion is just talk that doesn't lead
: > anywhere.
: it doesn't seem like anyone in this thread knows, but there have
: already been written at least two distributed MUD's, UnterMUD and
: COOLMUD. (there was also a project called "DOME" that someone was
: working on, but as far as i know it's still vapourware).
What does vapourware mean? For the rest of us who speak English 8-)?
: ftp://csclub.uwaterloo.ca/pub/coolmud/
I take it you mean that the source files are at this site and not the
actual muds. In which case where are the actual MUDs what happened to them?
--
Aaron
-oOo-
De Original
| . . . . |
--==*==-- . . . . . . . .. --==*==--
. | . ___ _ _ _ . . |
. . .. | \ | |_ _| |_ (_) __ _ _ __ . . . .
. . | |\ \ | | | | | ' \| |/ \' | _ \ . . ..
. . . | | \ \| | U | - | | - , | | | | . . .
. . .|_| \___|\___/|___/|_|\__/|_|_| |_| . . . .
. ______________________________________ . .. ... .
(______________________________________) . . . .
. . . . . . . . . .
.. . . . . . . . . .. . . . .
===============================================================================
Aaron Brand
: sfw...@calum.csclub.uwaterloo.ca (stephen f. white) writes:
: >it doesn't seem like anyone in this thread knows, but there have
: >already been written at least two distributed MUD's, UnterMUD and
: >COOLMUD. (there was also a project called "DOME" that someone was
: >working on, but as far as i know it's still vapourware).
: The DOME project is currently still rather vapourous, although large
: subsystems are running and have been tested (what's still missing is
: the I/O synchronisation).
: >neither of them is the ultimate server, but both solve the distributed
: >problem in different ways, UnterMUD through loose coupling and object
: >migration, COOLMUD through tight coupling and message passing.
: DOME resolves the problems presented by asynchronous execution by
: providing a conventional single-threaded execution model, and
: implementing this with a lock-free object access synchronisation
: mechanism. I.e. you can provide _sequential_ object specifications,
: and the run-time system will see to it that the resulting asynchronous,
: parallel execution is sequentially consistent, without deadlocks.
: The current DOME system contains no interpreter. The object code
: is written in C (an extension to C++ is in the works) and dynamically
: link-edited into the executable on demand. Communication between
: individual DOME servers is implemented on top of PVM, and the thread
: management uses the Pthreads library.
I take it this problem with the "I/O synchronisation/asynchronisation"
(whatever you are trying to say by using these terms) is
to do with moving players from one MUD/server to another without any
noticeable lag or effect on the player?
What is wrong with simply giving a 'please wait' message whilst their
player files are transferred between machines? OK, its a bit crude
but have you even thought of how many times players would travel
from one domain (on one mud) to another (on the sister mud)?
Have you considered how many points of contact administrators
would want between their MUD and their sister MUDs?
The idea that a distributed network is required is probably just
a red herring. These networks are the Ideal. To say that the whole
porject would be useless without these is like saying is no use
getting a car if its not a Ferrari or a lambourghini.
khper...@miavx1.acs.muohio.edu
> George Reese (bo...@winternet.com) wrote:
>
> : What is the real question behind the connecting MUDs? I have been
> : trying to get at that in this thread. The thread asks the wrong
> : question. It proposes a solution (connecting MUDs) to a problem that
> : has not been defined.
>
> I can't say about the vi thang, but here's an answer to your question
> about why this keeps getting asked and never done. This is an issue
> about cultural benefits, not technical ones, yet it keeps getting
> argued from a technical position. It's a player desire that
> administers don't see, can't see, or won't see.
> This reminds me of commercial game makers who held out for so long
I think that you need to define the problem more clearly. As I
view it, the problem you really seek to address is a totally
legitimate one: You would like the opportunity to play a variety
of muds without having to start as a newbie on each in order to
do so, and furthermore to be able to retain your advancement on
one when another goes temporarily or permanently down. I think
this is a legitimate desire, and while it may not be possible or
worth the trouble to implement a solution, neither should it be
casually dismissed.
The biggest problem I see, besides the technical problems which
probably could be solved, is the balance aspect. I don't blame
people for not seeing the extent to which this is difficult, when
they have never tried to balance a mud before. But it is not easy
to balance one mud, let alone many in a system, and here is the
reason why: Basically, one too-powerful item available, or too-easy
area, or bugged command, can unbalance an entire mud. And it happens.
I have seen it.
It is not so difficult to contain the damage, at least somewhat,
when it is your mud. You change the object or monster as soon
as you learn of it. Hopefully, that will be before you have
ten players gain ten levels each in two hours or something.
Also, one finds it necessary to toggle the difficulty levels of
one's mud in various ways, either because players are advancing
too fast as a whole, or are finding themselves frustratedly unable
to advance...so one changes the overall difficulty. The overall
difficulty of a mud also changes on its own, as new areas, quests,
etc. are added.
So, let us say that I agree with the Admin of mud X that two xp
on his mud are worth one on Chaos II, and we thereby set the exchange
rate. Without my knowledge, maybe without his immediate knowledge,
the overall difficulty of his mud declines, making mud X experience
worth 1/3 of Chaos II experience rather than 1/2...and suddenly
players are advancing considerably faster than my mud is allowed
to let them advance. If I suddenly change the exchange rate I
likely have player mutiny, especially because mud X's admin may
not accept the exchange rate reciprocally.
This is not intended as a flame, or even criticism of your desire,
which I see as a legitimate one. I think you have a desire that
it would be nice if it were possible to meet, so I simply challenge
you to address the question of how to handle the issue of the dynamic
nature of balance under such a circumstance.
--Nirvana
Alexander Weidt
>Alexander Weidt (de...@cs.tu-berlin.de) wrote:
>: The DOME project is currently still rather vapourous, although large
>: subsystems are running and have been tested (what's still missing is
>: the I/O synchronisation).
>: DOME resolves the problems presented by asynchronous execution by
>: providing a conventional single-threaded execution model, and
>: implementing this with a lock-free object access synchronisation
>: mechanism. I.e. you can provide _sequential_ object specifications,
>: and the run-time system will see to it that the resulting asynchronous,
>: parallel execution is sequentially consistent, without deadlocks.
>I take it this problem with the "I/O synchronisation/asynchronisation"
>(whatever you are trying to say by using these terms) is
>to do with moving players from one MUD/server to another without any
>noticeable lag or effect on the player?
Actually it's not. In the DOME project we are not trying to take a bunch
of different MUDs and connect them, but have _one_ MUD and distribute it
over several hosts on a local area network; i.e. distribute the MUDs
component objects across servers which reside on the various hosts in
the cluster.
The synchronisation problems encountered are easily demonstrated by the
famous ``Dragon's Dinner'' problem.
[Taken from our WWW page:]
Consider the following problem (dubbed "Dragon's Dinner"). Assume, in
an asynchronous distributed system, that there are two room objects
(r1, r2) and a door object (d) that connects them. R1 contains a hungry
dragon (hd) and r2 contains an adventurer (a). The door is currently
open, the adventurer has just fled from r1 and is about to close the
door. The dragon, on the other hand, wants to go after the adventurer.
Code for the dragon is something like:
if (d->is_open())
hd->move_to(r2);
And the code for closing the door is something like:
d->close();
Now what if the following happens: The thread that executes the
dragon's action has checked that the door is indeed open, while the
other thread which is concurrently executing on a different processor,
closes the door. This succeeds and the adventurer sees the door
closing. However, when control returns to the dragon's thread, it
still believes that the door is open and steps through it, much to the
surprise of the adventurer who sees the dragon walking through a closed
door, before being devoured by the dragon.
Naturally this is merely a race-condition dictated by the asynchronous
execution of two data-dependent threads. The main goal of the DOME
project is to provide a system where the component objects can be
programmed in a sequential fashion, but have the run-time support
resolve such race-conditions (in a deadlock free manner) so that
parallel execution can be achieved.
>What is wrong with simply giving a 'please wait' message whilst their
>player files are transferred between machines?
This is a moot point.
>The idea that a distributed network is required is probably just
>a red herring.
I'm not quite sure what you're getting at here. A system of
hosts connected by a network is per se. a distributed system.
>These networks are the Ideal. To say that the whole
>porject would be useless without these is like saying is no use
>getting a car if its not a Ferrari or a lambourghini.
Actually for this purpose local area networks connected by
ethernet supporting TCP/IP is far from ideal. I am currently
experimenting with ``true'' parallel systems such as the T3D
and PowerPC networks aswell as workstations connected with
ATM technology.
Happy hacking, Alex (Demos@TubMud)
--
``Shut up Baldrick. If I'd wanted to talk to a vegetable,
I'd have bought one at the market.''
-- Blackadder
Dr. Cat
: Sure, I
: can duplicate myself on mutilple MUCKs, run multi session with my
: client and consider it the same character, but I have a perverse
: desire to not see the man behind the curtain, to connect once and be
: *there*. MUD world. It's me, it's my avatar. I'm annoyed that to
: @join a friend on PMC MOO while I'm on Lambda requires that I run a
: seperate session and log in there, switching windows to see what
: others have said to the other me.
Most people who have feelings like this in the MUCKs will follow the "log
off one mud completely and then log onto another one" usage pattern,
rather than connecting to multiple worlds simultaneously.
: As an admin, ok, I can see what a
: pain in the butt it is to break down the barriers, but as a player it
: breaks the illusion and interferes with my suspension of disbelief.
I think muds depend HEAVILY on a strong ability and desire to
deliberately suspend disbelief. Kind of like reading novels - something
most American don't do, and a small minority do. It seems odd to me to
have developed that ability, and utilize it, but then to get tripped up
by little details. If the "unrealistic" aspects of having the "same"
character in two different muds feel too jarring to you, avoid causing
yourself that problem. Playing on only one mud ever solves the problem.
Playing on multiple muds, but making up a new character on each solves
the problem. Some people can happily play the same character on multiple
muds as long as they only connect to one at a time, and that's fine too.
Other people will play the same character on multiple muds
simultaneously, multiple characters on the same mud, or both! Some
serious mutations in the social evolution process to generate people that
can do all that at once, but it's an exciting time that way. :X)
It seems to me only the people in the EXACT same category as you when
grouped by "what does and doesn't bother me and 'break my reality'" would
really stand to gain anything significant from this proposed form of mud
connecting. And if it's only going to benefit a minority of players,
that's another point against it.
To me, if there's a group of players who feel they can already acheive
what you want to acheive because recreating their character on multiple
muds doesn't bother them, there's another way you could look at this...
You *could* say "Since I am not that way, I will propose this other
solution." But... You could *instead* say "Since other people are able
to enjoy muds in the way I want to, I will learn to feel the same way
they do about the way they do it, so I can also." This is a MUCH more
expedient course of action, as you can do it totally on your own.
Whereas making all that other stuff happen requires a lot of people to
change over, and is staggeringly unlikely to actually take place.
: On more game oriented MUDs this becomes that much more intense. I'm
: brainwashed, though. The Net convinced me that geography doesn't
: matter, the Web that the hardware and OS don't matter. It's a hard
: lesson to be told we'll have stay in our little boxes.
Surmountable limitations on computer systems don't matter IF some
programmer or programmers is willing to do the work to surmount them.
But they are very real because sometimes nobody wants to badly enough -
and even when they do, it takes real, genuine work to do so. And there's
a law of diminishing marginal returns there.
If there's a solution that's 5%, or 20%, or 50% as good as some
yet-unimplemented alternative, then somebody will get around to
implementing it. But if what people already have is 90% optimal...
Then you may not get anyone bothering to squeeze out an extra 5 or 10
percent.
To me, if I want to wander from AlphaMUD to BetaMUD and keep the same
character... Creating a character with the same name, class, etc. on
both, and then "walking" between them by logging off AlphaMUD and logging
onto BetaMUD feels close enough to travelling through a portal from one
mud to another to satisfy me, and to satisfy the majority of mud players.
Since most people don't much care whether they have a smoother transition
or not, nobody is likely to do all the work to give them one.
If the little details like seeing a message from AlphaMUD that says you
have stopped playing, typing quit and logon commands instead of a
movement command, etc. are bothering you... You could always write up a
script on your terminal program or for your mud client that A) Lets you
type something like "gobeta" to make the transition, and B) supresses
enough of the logout text from AlphaMUD (and maybe the login text from
BetaMUD if that bothers you also) to make it "feel" to you like you
really did walk/teleport/whatever from one to the other. This is still
MUCH less work (and therefore much more practical) than the huge work of
connecting muds. And much more appropriate if it's really a few little
details that are only unpleasant to a minority of the mudding community.
George Reese
: George Reese (bo...@winternet.com) wrote:
: : What is the real question behind the connecting MUDs? I have been
: : trying to get at that in this thread. The thread asks the wrong
: : question. It proposes a solution (connecting MUDs) to a problem that
: : has not been defined.
: I can't say about the vi thang, but here's an answer to your question
: about why this keeps getting asked and never done. This is an issue
: about cultural benefits, not technical ones, yet it keeps getting
: argued from a technical position.
I have only made one technical statement on the subject, and that was
about how I would do it if I were to do it. As a matter of fact, I do
not know of any technical reason why it *cannot* be done. I have
asked you what the problem is which needs solving. In order to
propose some sort of solution, you should have a problem.
: It's a player desire that
: administers don't see, can't see, or won't see.
I have not heard a lot of players asking for it.
: It's the
: administrators that write the drivers and since they don't see a
: return on their MIPs they don't care to do it. We've been talking
: about why players would want it and you keep attacking it on the
: grounds that distributed MUDs don't add anything.
No, you have not stated a single reason why it would give players
anything.
: This reminds me of commercial game makers who held out for so long
: against offering their audience the chance to play against each other,
: saying that people weren't really interested in that sort of thing.
: So GEnie reaps the big bucks in the vaccuum until iD figured it out.
It is not the same thing. The problem: people could not compete
against one another. The solution, build a game which allows them to
compete against each other. The problem we face? Undefined. The
solution, connect MUDs. It simply does not follow.
: Now we get some. It's what *we* want and we're not getting it.
: I understand it's your party, you're not getting paid and you have the
: right to do whatever you choose. You choose to say no, that's cool.
: Disappointing, but cool.
Who is we?
: Problem: So many MUDs but all isolated, tired of a hundred characters
: of varying levels, frustrated knowing there's a huge MUD community out
: there and only seeing a fraction of it, desire to have full range of a
: lot of individuals MUDs that exist already and will be born with one
: character that I can identify with instead of a prime one and its
: offspring, think that linking MUDs would generate good benefits for
: the players and possibly some synergy leading to unknown, unforseen,
: wholly new results.
Ok, this really does not make sense. In order to have an entity which
is you, you must have something in common among all those players
being identified as you. Something must remain the same in order for
character on MUD A to be identified as the same as the character on
MUD B. Define first what that is. The minute you do, you have torn
apart your concept of the MUDs being separate but connected, since
immediately those characteristics which define you as you must be true
across the spectrum of MUDs.
You say it is you in virtue of the fact you are playing the character?
Well, we have that solved already. It is called logging into multiple
MUDs. You clearly want to identify yourself (as a player) on something
greater than who is controlling the character. It is my belief than
in so doing that, you tear down the distinctions among MUDs which
makes them useful as separate MUDs, meaning that it makes no sense to
do them as separate MUDs.
: Proposed solution: One monolithic MUD.
: Reasons for: It can be done easily.
: Simulates a multi-MUD environment.
: Stricter controls implies better quality.
: Creators have captive audience.
Captive audience? Where do you get this idea?
: Reasons against: Doesn't do anything about existing MUDs.
: One person/group owns machine.
: *Simulates* is key word.
It is no more a simulation than a real multi-mud setup.
: Stricter controls implies stifling beurocracy.
There is always bureaucracy on MUDs. Politics is human nature.
Conneting MUDs would only serve to magnify this problem.
: Forces agreement on wide range of issues:
: difficult.
Difficult?
: Proposed solution: Connecting MUDs.
: Reasons for: Allows existing MUDs to participate.
: Individual creators retain control.
No, they do not.
: Players can see repetition between MUDs implying
: improved quality, more variation.
They can do this using a mud client.
: More than one vision allowed to be implemented.
Same with your above solution.
: Agreement on how to handle player advancement
: issues all that's required.
No, agreement on player identity is what is required, and that
fundamentally affects the nature of the game.
: No one person owns machine.
This is neither good nor bad.
: Reasons against: Somewhat more difficult to implement
: technically.
Not really.
: Creators no longer have captive audience.
I still fail to see what the hell this means. Have you ever used a
MUD client? It lets you login to as many muds as you like at the same
time.
The problem you state, again, is a non-problem. The reasons for
advocating the solution you advocate are questionable at best.
Dr. Cat
: already been written at least two distributed MUD's, UnterMUD and
: COOLMUD. (there was also a project called "DOME" that someone was
: working on, but as far as i know it's still vapourware).
If there are a couple of distributed servers out there, and there aren't
many MUD admins out there taking advantage of that to set up linked MUDs,
that suggests to me that the demand for this feature amonst the mudding
community really isn't very strong.
Strange Journey
: Who is we? [and] I have not heard a lot of players asking for it.
In response, a quote from another one of your posts, Descartes:
: There are a few questions which run around forever on the MUD
: newsgroups like this. One is [...] "Can I connect my MUD to other
: MUDs?". Why do they keep getting asked and never solved?
Which is it?
: The minute you do, you have torn
: apart your concept of the MUDs being separate but connected, since
: immediately those characteristics which define you as you must be true
: across the spectrum of MUDs.
You would imply that the sum total of a MUD's essence is some
statistics attached to a character? I say basic elements of what
makes up a character must be agreed upon, but that hardly means that
MUDs must be so similar as you claim.
: You say it is you in virtue of the fact you are playing the character?
: Well, we have that solved already. It is called logging into multiple
: MUDs.
And spending hours improving each one. I have a life outside of MUDs,
I can't afford to do that. Besides, it's jarring. Contrary to Dr. Cat's
implication, I do have enough imagination to overcome it, I just want
something better.
: Captive audience? Where do you get this idea?
Working on a character means investing time in it, something not
easily thrown away. The tendency is to stick with one MUD, because it's
a pain in the ass to start from scratch elsewhere. I'd say that makes
a player captive. If she wants a change of atmosphere, she's punished
for it by forfeiting her work. It's a subtle argument, but just as
true as the MPAA's rating being implicit censoring of movies since no
one can afford an NC-17.
: : Individual creators retain control.
: No, they do not.
We seem to be debating from such completely different standpoints that
you're missing my point, while I must be missing yours. You honestly
don't see the difference between a situation in which several fiefdoms
call the shots for the MUD on their machine, and that in which several
talented people are banded together to make a megamud on, say, *your*
machine?
: : Players can see repetition between MUDs implying
: : improved quality, more variation.
: They can do this using a mud client.
I see a vast difference between having multiple characters of varying
accomplishments spread out over multiple addresses and having one
character that can travel about at will. You don't. What more can we say?
: : No one person owns machine.
: This is neither good nor bad.
I admire the faith you have in people. This would be quite good
compared to a situation in which one god tries to lord it over the
others, decides to take her ball and go home or runs afoul of, say,
faculty, staff, or the IRS.
: I still fail to see what the hell this means. Have you ever used a
: MUD client? It lets you login to as many muds as you like at the same
: time.
Bah, of course I use a client; I'm irked by the condescension that
comment displays. But I'm not a newbie to USENET, either, so I won't
follow up on that.
: The problem you state, again, is a non-problem.
I can see it's a vision thing. You have a vision I don't share, and
I have one you don't. S'okay, though, it's fun debating.
Kid/Strange Journey
Strange Journey
: If there are a couple of distributed servers out there, and there aren't
: many MUD admins out there taking advantage of that to set up linked MUDs,
: that suggests to me that the demand for this feature amonst the mudding
: community really isn't very strong.
Depends on what you consider to be the MUD community. If it's
players, they can't support MUDs that don't exist. If it's admins,
one might explain it by saying they're more familiar with LP, Diku,
Aber or MUCK and so tend to start those. Then, too, that some people
put so much work in developing said drivers with more on the way
suggests that there is demand.
Either way, it's not as pat as all that.
Besides, there are two concepts being bandied about here: distributed
MUDs and linked MUDs. I don't care for the concept of distributed
MUDs, myself. I'm interested in connecting the ones we already have.
Kid/Strange Journey
George Reese
argued here is that you are tried of spending all your time playing
Monopoly and then having to start over when you move to Doom or Risk.
You want to have your success at Monopoly translate into success at
Doom and Risk. My point is that you cannot come up with any
meaningful way to translate success in one game to success in another
without turning the two games into the same game. At that point,
connecting the games becomes kinda like taking a space shuttle ride to
get from florida to california.
Strange Journey
: You want to have your success at Monopoly translate into success at
: Doom and Risk.
To use your metaphor: I want my rating in the Colorado Monopoly league
to allow me to enter at a certain level in other states. Whether each
state uses the *exact* same rules is irrelevent so long as everyone
agrees to what makes up the essence of the game. Some of us are
playing, for the most part, the same game, it's just some of us put
Free Parking to other uses. Which doesn't mean that New York is the
same place as Colorado and ought to be renamed New Colorado for
efficiency.
Kid/Strange Journey
Mark Clements
about why we (That's me and like-minded others - don't quibble) think
connected MUDs would be a good idea, and what problems we think they
solve.
These have been detailed before in this thread, although
the most important ones, off the top of my head, were more reliable
(actually just as reliable as single MUDs, but if one part goes down
you can still play *WITH THE SAME CHARACTER*. So from a players point
of view is more reliable), 'damage limitation in times of admin crisis'
(Huge splits can be solved by having one group of admin start up a new,
but connected MUD - their individual ideas without having to start
from scratch). There were others, but I can't remember, and I expired
my earlier post.
All this as well as the problem of human sentimentality, which, I hate
to point out exists. Getting attached to a character is something I'm
sure most MUDders experience. Too bad if that character is locked into
a box. <G>
Strange Journey answered a lot of the misunderstandings in an earlier
post, but there are a couple of COMPLETELY misunderstood statements that
need explaining.
(From George Reese):
> : : Players can see repetition between MUDs implying
> : : improved quality, more variation.
>
> : They can do this using a mud client.
No! The point is that on a load of connected MUDs, there is going to
be more variation, because if the same thing occurs on more than one
MUD *It will be noticed!*. Leaving Mordor, take the left hand fork into
the village. Leave it to the south and follow the river, and eventually
you will end up in Mordor. It just doesn't figure. Therefore more
variation.
There was a similar misunderstanding where a mud client was given as
the solution, when the problem was something completely different, but
I can't remember what it was.
Alright, so this is another rambling post. It's late. I'm tired.
I've got a memory like a shoe.
Just a final point: Big cheer to Strange Journey!
(To Descartes)
>
> I can see it's a vision thing. You have a vision I don't share, and
> I have one you don't. S'okay, though, it's fun debating.
>
--
George Reese
I doubt the Colorado club would go for that :)
But let's say they would just for the sake of argument. That only
holds if MUD A is the same game as MUD B. It is sad that all too
often MUDs out there are poor copies of some other MUD. However, if
they are being built well, they should be *different* games
altogether. And if they are different games, your analogy does not hold.
George Reese
: These have been detailed before in this thread, although
: the most important ones, off the top of my head, were more reliable
: (actually just as reliable as single MUDs, but if one part goes down
: you can still play *WITH THE SAME CHARACTER*. So from a players point
: of view is more reliable),
The point I have been trying to make is that you cannot define what it
means to be THE SAME CHARACTER in a way in which the term is
meaningful as a solution for connected MUDs. If you are able to
create such a defintition, my point is that you will end up talking
about the same game.
Take for instance two MUDs, Igor and Nightmare.
What would it mean for my PC to be the same PC on both MUDs?
Level? Can't be that, level has different meaning on the two MUDs.
Skill? Igor does not even have skills.
Stats? They have two different sets of stats.
The problem is that the moment you get together a core identity which
you take to stretch across two MUDs, you have basically made the two
MUDs instances of the same game. At that point then, connecting MUDs
gets you nothing that would not be better served by uniting the MUDs
into a single MUD.
: Strange Journey answered a lot of the misunderstandings in an earlier
: post, but there are a couple of COMPLETELY misunderstood statements that
: need explaining.
: (From George Reese):
: > : : Players can see repetition between MUDs implying
: > : : improved quality, more variation.
: >
: > : They can do this using a mud client.
: No! The point is that on a load of connected MUDs, there is going to
: be more variation, because if the same thing occurs on more than one
: MUD *It will be noticed!*. Leaving Mordor, take the left hand fork into
: the village. Leave it to the south and follow the river, and eventually
: you will end up in Mordor. It just doesn't figure. Therefore more
: variation.
My point is that if all you can come up with to identify a person
across MUDs is the person controlling the player, then a MUD client is
your solution. In fact, that is all I believe you can come up with to
identify a player across MUDs.
: Just a final point: Big cheer to Strange Journey!
: (To Descartes)
: >
: > I can see it's a vision thing. You have a vision I don't share, and
: > I have one you don't. S'okay, though, it's fun debating.
: >
I have no problem with the concept that i might be failing to see some
important idea. However, I do feel no one as yet has shown to any
degree that connecting MUDs solves any problem. The problems so far
introduced are not in fact solved by connecting MUDs.
Steve Fleischaker (ICDApps)
x
<state B>
x <state A>
It's possible, although it's an unjustifed burden, to map players between
a given state and another state. In professional MUDs, players were mapped
between Gemstone and Legends of Futures Past during the Beta-testing period
of Legends of Futures Past, and the two systems were largely dissimilar.
One was a class-based system, the other a centralized experience pool, classless
system where skills were bought and exp/build point increased with level.
I saw players who felt that this was a mistake, and who made a point of
saying it was a mistake, *two years* after it happened. The ill-feelings
lingered. Some players felt the players who were transferred in lost the
best part of the game, and only cheated themselves. Others felt that hte
players who were mapped in did not earn their new status <they didn't work for
it, and in a simple way the term 'work' is very important, here>.
Irregardless, players were not constantly mapped in and mapped out again,
transferring between one system and another. If that had happened, the system
would have been in chaos.
If you were to ask me for a scenario more likely to cause negative feelings,
I couldn't design one. Every slaying weapon in the game's power was reduced
by a factor of two and the wielders of those weapons shrugged, and felt it
was acceptable for game-balance reasons. A spell may be tweaked for one reason
or another and players can compensate. Players will deal with internal changes
with some grace, and others they'll erupt in fury and threaten to leave.
But if you cheapen the investment players have made in the game, by
providing a route to reach the state that player has reached at a lower cost,
or in simple terms if you reduce the cost to go from one state to another in
the game, reduce the work required.. then people remember. Players begrudge this.
There are social hierarchies that develop in part on the basis of RP skill and
in part based on relative personal power, and unbalancing that hierarchy is
asking for every player to compete for their niche <again> in the social environment.
It's extremely annoying leaving a game for 3 weeks and coming back and finding that
every two-bit hustler has taken advantage of some bug in the code, or some
weakness in the design to accelerate their advancement. It's more annoying when
the players who have reached level 67 or higher are the sort who think
poking you in the chest and saying 'yeah, so whaddya think youze is gonna do about it?'
is the height of roleplay. It's important that it take roughly 3 weeks to reach
level 15 <for an average player> whether it is 3/94 or 3/95.. or more precisely
that it require a certain level of effort.
I will say flat-out that the concept of connecting MUDs is an incredible, and almost
ridiculous burden from a management POV. Every time you expand the circle to another
MUD you need 2n additional filters <filters for every system in the circle to
the new system, and filters from the system to every system in the circle>.
It's not a simple mapping from one system to another, because you wish for this
connection to be maintained.
That is, instead of asking for this:
x
<state B>
x <state A>
Which is a bloody nightmare of raw emotions of it's permitted any time after early
Beta testing..
What you are asking for is this:
Time 0:
x
<state B1>
x <state A1>
Time 1:
x <state B2>
x <state B1>
x <state A2>
x <state A1>
A player begins at state A1, moves to system and is mapped to B1.. the player
moves to B2, and then maps back into system A as state A2.
Question: is the work involved going from A1 to A2 equivalent to B1 changing
to B2?
If it is, then the systems are balanced. If it isn't, and I'll vow that you'll
never be able to convince 100% of your players that it is equivalent even if it is,
or that you'll find two systems where it *is* equivalent <one has better high-level
hunting grounds than another.. or the high-level quests on one yield better
experience than the other.. a GM on one is more attentive to players than GM's on
the other, etc.>... If it isn't, what you've done is destroy the conservative
nature of a closed system.
Hell, the whole concept of warp speed, or hyper-drive is that you skip out of
a given system <euclidean space> and skip into another.. you travel 3 parsecs
in space B, skip back into space A, and you've travelled 3,000 light years.
[Kudos to USA network for showing the star wars trilogy again this last weekend].
The work going from A1 to A2 is different along one path than another.
Do that and your *numbers* are meaningless. Your experience system which you
carefully tailored and monitored and tweaked your creatures and objects to
maintain has been thrashed.
What you've done to your social structure is worse.
Druids who spend three months mastering meteor-summoning spells and lightning
spells, who roleplay for twelve months, 10 hours a week, do *not* enjoy seeing
a player come over from a light-roleplay system as a 42nd level player-equivalent.
A tower of swordsmen, where the guild leader spends 10 hours a week nurturing new
players and tower initiates is not going to be grateful when your 5th level
initiates <who've passed all their tower training exams and gone through
initiation rites> are slaughtered by the horde of classless 89th level swords
from beyond the rim.
Sorcerors who pass through rites of initiation, etc. will not appreciate people
who have no respect for what they have throwing it about at random. I've seen
plenty of people who felt that another person had not earned a given spell,
or had not earned their 'power,' within a game system.
The key point here, good or bad, is that this isn't conjecture. This is
the relation of my experiences, where players were mapped from one system to
another in very small numbers during a beta-testing period, and then later other
players begrudged them those abilities. Factions emerged among older players where
players who were mapped over were outcasts. I knew a player who was essentially
driven from the game this way, and he was a well-liked, industrious individual
who could have contributed *a lot* to the roleplay environment of that game.
And that was *nothing* compared to what you're asking here. The power they
were granted during that beta-test transfer was miniscule compared to what most
players who arrived long after that had acquired by exploiting one weakness
of the system or another. Even with 170-250 level players walking around, there
were some old players who felt another player <level 20> had not earned his place.
Even if some one *gave* you a system of interconnected MUDs, centralized code,
filters, and so forth.. the balance would last about 2 weeks.. until some overeager
developer attempted to attract players to his world by offering this or that
item or unique advantage. A given developer would add spells orrooms or hunting
areas, another would modify the skills system, another would decide the engagement
system was lacking, or that the class-skills were 'unrealistic..'
I don't see a tremendous demand for this kind of interconnectivity. Speaking from
experience, I've seen a real backlash, not from management, but from players, against
a *lesser* form of mapping.
Just my two cents.
Steve
<opinions my own>
Mark Clements
bo...@winternet.com "George Reese" writes:
> The point I have been trying to make is that you cannot define what it
> means to be THE SAME CHARACTER in a way in which the term is
> meaningful as a solution for connected MUDs. If you are able to
> create such a defintition, my point is that you will end up talking
> about the same game.
This is getting philosophical. The similar identities may only exist
in the mind of the player. I expect that the connected MUDs _would_ share
similarities, but even if they don't, there is still a continuity between
them in the mind of the player.
Take the famous problem 'Anna's Boat', which basically details how
over a long period of time parts of her boat get worn out or broken, and
are subsequently replaced. Over a period of 10 years or so, so much has
been replaced, that no part of the boat as it is now was there at the
beginning, yet she still considers it to be the same boat. There is a
continuity of thought that makes them the same, though. She saw each minor
change happen, and just because you replace a rotten plank doesn't make
it a different boat.
A similar continuity of thought is what holds a character to a player, even
when different stats etc. are used on different MUDs.
> : > : : Players can see repetition between MUDs implying
> : > : : improved quality, more variation.
> : >
> : > : They can do this using a mud client.
>
> : No! The point is that on a load of connected MUDs, there is going to
> : be more variation, because if the same thing occurs on more than one
> : MUD *It will be noticed!*. Leaving Mordor, take the left hand fork into
> : the village. Leave it to the south and follow the river, and eventually
> : you will end up in Mordor. It just doesn't figure. Therefore more
> : variation.
>
> My point is that if all you can come up with to identify a person
> across MUDs is the person controlling the player, then a MUD client is
> your solution.
Yes, but that has nothing to do with the statements we have made. This
is talking about repetition in the MUDs, which would be lessened if
they were connected. A single MUD wouldn't duplicate areas, so a
set of connected MUDs wouldn't (or at least wouldn't for very long, once
the players realised).
Lymph Glands Forever!
George Reese
I have been avoding technical reasons why I think connecting MUDs is
problematic, instead sticking with the conceptual reasons. However, I
think this technical bit cannot be avoided:
s...@icd.teradyne.com (Steve Fleischaker (ICDApps)) once wrote:
>I will say flat-out that the concept of connecting MUDs is an incredible, and almost
>ridiculous burden from a management POV. Every time you expand the circle to another
>MUD you need 2n additional filters <filters for every system in the circle to
>the new system, and filters from the system to every system in the circle>.
>Even if some one *gave* you a system of interconnected MUDs, centralized code,
>filters, and so forth.. the balance would last about 2 weeks.. until some overeager
>developer attempted to attract players to his world by offering this or that
>item or unique advantage. A given developer would add spells orrooms or hunting
>areas, another would modify the skills system, another would decide the engagement
>system was lacking, or that the class-skills were 'unrealistic..'
This is actually an extremely well-stated point. On any given MUD,
the very act of adding one normal area is a destructive process to the
MUD which must be properly managed, otherwise in the least you risk
unbalancing the system. At worst, you unbalance the system, create a
war among creators who think the new cre is just pandering to the
masses to get players, and older players who resent the sudden
introduction of an easy area they did not get the advantage of.
Multiple this across multiple MUDs. Multiple this across multiple
balance staffs of varying ability.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg/
Strange Journey
[about Gemstone, etc.]
Any budding net sociologist worth the weight of her degree could
produce a fascinating ethnography of the twin worlds you describe. An
ugly situation worth the study, but a straw-man argument if used in
this debate. To say that two similar MUDs cannot link because two
dissimilar MUDs cannot is faulty reasoning.
: the two systems were largely dissimilar.
: If you were to ask me for a scenario more likely to cause negative feelings,
: I couldn't design one.
Consider how the situation might have been different if both MUDs used
similar advancement systems. There are only so many ways of
advancing. Given the sheer number of MUDs in existence and the
relatively small number of drivers, surely two share a common base.
We need only two, at first; they can connect. Now instead of having
an arbitrary mapping, you'd have a workable exchange rate derived not
from fiat over how many apples make up an orange, but by a fair
evaluation of how the MUDs compare in their rates of rewarding
oranges. This can be expanded, of course, to include any number of
MUDs with a similar base to no ill-effect on the player's sense of
righteousness.
And to pre-empt the inevitable response (not necessary by you, Steve):
two MUDs sharing a subset of rules does not mean that they are the
same worlds and so should be one. I understand the reasoning behind
it, but reject the conclusion.
Kid/Strange Journey
Steve Fleischaker (ICDApps)
>advancing. Given the sheer number of MUDs in existence and the
>relatively small number of drivers, surely two share a common base.
>We need only two, at first; they can connect. Now instead of having
>an arbitrary mapping, you'd have a workable exchange rate derived not
>from fiat over how many apples make up an orange, but by a fair
>evaluation of how the MUDs compare in their rates of rewarding
>oranges. This can be expanded, of course, to include any number of
>MUDs with a similar base to no ill-effect on the player's sense of
>righteousness.
Let me give you an example by analogy:
Legends of Futures Past was/is a loosely skills-based system. There is
a central experience reservoir, and each 'level' was gained when you
gain 10 build points. Build points can in turn be traded in for
skills, which cost a set amount regardless of race, background, current
skill, etc. <that is, the first level of spellcraft is 20 points, the
second and all additional levels are 5 points.. at first level, a build
point is about 100 experience/build point, at 2nd level, a build point
is 200 or so exp/ build point>.
So a character was a given level, and their level dictated the cost of
skills.. nottheir background or where their skills were allocated or
anything exotic. It was a very simple system.
By level 60, the cost/build point for a PC is about 30,000 exp. So a
rank in spellcraft was 5 BP <still>, or about 150,000 exp. vs the same
rank in spellcraft at level 3 or so, which would cost 1,000 exp.
You could spend BP in any area at any time, and the cost, primarily,
was in fracturing your skills so that you couldn't acquire exp for
additional BP. There developed fast-tracks: focus on combat for 5
levels, then pour build points into spellcraft or psionics until you
reach 15 ranks in psionics, then pour build points into .. etc.
This happens in every system, but a good design tries to balance one
route against another, if diversity is a goal.
At one point, high-level characters on LOFP were around level 40-60. A
few dedicated powergamers were level 80, and up, but this was the 1% of
the society. Certain areas were known to yield good experience, and so
adventurers clustered there, killing creatures on scripts, trying to
gain enough exp to buy skills so they could get more exp, so they could
buy more skills, etc.
Around the end of 1993, the Planes are introduced to LOFP. The Planes
were a hunting ground, where your old skills did not immediately
transfer. Instead, if my character, Reisthfaer, was level 70 and had
spellcraft 23 polearms 42 necromancy 13 etc.
then on the planes, Reisthfaer had
spellcraft 0 polearms 0 necromancy 0
until he acquired a skill called Transcendance. Transcendance allowed
for a level of every skill to be used for every level of
transcendance. The Cost of transcendance was 10 BP for the first rank,
and 2 BP for every additional rank.
IE.
Transcendance 15
Spellcraft <effective: 15/23>
Polearms <effective: 15/42>
Necromancy <13> etc.
The immediate effect was that hunting areas became a challenge forsome
players, again, at least for a while. Players retained all of their
equipment, and on most of these planes, the equipment worked.. but the
players had to acquire additional levels of transcendance to have the
same skill levels in the Planes as they had on Andor, their native
plane. For a few days or hours, they had the skills of a newbie.
Note however that the high-level players gained back more skills <more areas>
with each rank of transcendance, generally, but it cost them considerably more.
Players were presented with two options, since they could acquire any
skill at any time if they had the BP: 1. spend bp <$'s, and time> on
transcendance, so that the characterwould have an increasing percentage
of his Andor-level skills in teh Planes.
2> ignore the planes, and advance the skills on Andor.
The choice was: spend 2 BP to increase transcendance from 15 to 16, so
that the player would have
Transcendance 16
Spellcraft 16/23
Polearms 16/42. etc.
Or spend 5 BP to increase spellcraft to 24, or polearms to 24,etc.
[In this discussion, this woud be the equivalent of being in two systems:
A and B, where there was a cost to transfer to B, but it was possible to
transfer between A and B directly]
On the face of it, it's a bad choice. some players chose not to map
into the Planes, investing the time and resources, and others chose
<such as myself> to take the risk and see whatthe benefits were in the planes.
The two systems <Planes and Andor> were identical systems. There was a
simple and direct mapping between one and another. The equipment
mapped precisely, save in those planes where magical equipmet became
non-magical for balance purposes <on Idemmu Ag, weapons took an instant
-30 to their plus, and so magical weapons suddenly couldn't strike
creatures that could only be struck by magical weapons.. because those
weapons were no longerpowerful enough>.
The Planes were not well-balanced, though. And they remained unbalanced
for the better part of 18 months, until I left, and from what I've heard
they never were well-balanced.
The lure was that the experience rewards ofthe Planes were
extraordinarily high. On Andor, the average creature was worth about
1-3 experience points for every damage point. Do 39 points of damage
to a sand worm and you'd see roughly 128 experience. It was
consistent. Worms were worth 3.1 and took extra damage from cold,
trolls were worth, etc.. A player with 12 spellcraft could hit mounds
maybe 90 percent of the time, and worms <in the same hunting area>,
about 30 percent of the time. So at spellcraft 23, a player could hunt
the Wastes with an average return of experience per hour <function of #
of creatures genned over aperiod of time and the value of those
creatures>. of about 35K if you were very good at that area/had
structured your character to take advantage of that area. one way to
structure your character was to spend BP for specialization.
In areas in the planes, the return was about 100K/hr. There were areas
where I could gain 230k/hr in the Planes, using a slaying weapon.
Note the difference was as high as a factor of SIX.
There were areas introduced that were so poorly balanced that two or
three players gaiend 20+ levels in about three days, exploiting weaknesses.
There were areas so rich that prices on highly valued items in auctions
jumped from mid 10k's, to over a million gold for high-quality weapons.
Andor's smiths were essentially put out of work because no one wanted
swords that weren't crafted from elemental ores that were found on the
planes in quantity, and andorian miners were put out of work because no
one wanted their goods, as well. And neither profession generated
suffiicient exp/hr to warrant investing in transcendance so they could
transfer to the planes. The best miners in the planes were characters
whose owners transferred high-quality goods to them to wear <heavy
defense items>, and had them jump to the planes for high-exp hunting so
they could advance faster. I hand-held a miner to get him the exp to jump
to the planes, and rezzed his character when he died there. Not many
players had that luxury, and in the end, his character became tremendously
wealthy, while most miners were left in the dust.
In a year, the average mid-level for players went from about 45 to
about 130. Right now there are players pushing 230-300 on that
system. <remember, before, there were about 2 players over 100, but a
good bulk of players were 45 - 60>. A bi-modal distribution started to
emerge: if you wanted to advance, go to the planes. It had always
been pretty much the rule thatif you wanted to advance, you need to
hunt, but now it was 'hunt in the planes.'
New Players were skipping andorian hunting spots entirely and jumping
straight to the planes. Transcendance cost less at low levels <a build
point at level 1 was 100 exp, a build point at level 60 cost 60,000...
transcendance was 10/2 : 10 bp for the first rank and 2 for every
after>.
Young players were outpacing older players whose skills were more
highly developed, because it's harder to add in 20 ranks of
transcendance at level 60 than it is to create a new character with
minimal RP and get him 20 ranks of 2 or 3 key skills so he can hunt in
a high-yield area. The high-yield area in turn boosted the character
in money, skills, experience.. but not RP.
I knew players who had been on that system for two years who saw their
investment in their characters entirely devalued. It is insulting to
people who have been on a system to see new players reach their level
of power or surpass it several times over within weeks.
The end-result <and I could go on> was that the RP was seriously
effected. The economy was seriously effected. The value of certain
professions was seriously effected <not because of their viability on
andor, but because their counterparts were so much more effective>.
Relative measures are extremely important in interconnected systems..
not absolute measures.
So how does this relate:
1. The two systems used identical skills structures.
2. The two systems used similar experience systems, and hunting areas
were overseen by the same administrators <loosely speaking>
3. The equipment on one system was the same as the equipment on another.
Your mathematical mappings were trivial.
But the effect of adding in the planes was horrendous on the game,
IMHO. Players mastered every skill in the game that garnered
experience, virtually. Instead of making a choice at being great at 1
thing, and good at 1-2others, or being good at 3-4 things, players
emerged who were unrivaled in 3 major areas and had dozens of
buildpoints to spare. Players came back from the planes with so many
build pionts they learned 40 ranks of a new skill the day it was
introduced <Endurance inthis case>. Prices on everything skyrocketed
during auctions. More and more, players on Andor began to resemble
what was effective for the hunting grounds in the Planes, and that in
turn effected RP, as these bored 100-130 level players came back and
fought creatures or players on Andor, before they went back to the
Planes for a fewmore hours ofhunting. We had a rash of clones
<psi-sorcerors.. learn bow to level 10, then learn psionics to haste,
then master freezing sphere, etc., etc., etc.>, and fewer RPers.
A GM I knew had to introduce a routine for his NPC that healed that NPC
up to full hit points periodically because these PCs were so powerful
they could destroy the NPC in a few moments. if the NPC was made to
withstand those players, the Andorian players who never went to the
Planes couldn't touch the NPC. If the NPC was made to betouchable by
the Andorian players, the planes players found it to be little
challenge.
Or as a friend said, "when players can kill Gm's, something has become
unbalanced."
I'll reiterate my experience on the subject: even if I gave you a
system that was entirely balanced, with multiple sites interconnecting,
it would be an entirely trivial period of time before a GM would
redesign an area so that it yielded better experience for certain
skills. Or a design team would add a new spell.. or a design team would
tweak the way a skill worked so that it was more effective/realistic.
Do you map in cash from one system to another? Do you map in
equipment? Do build points in one area not transfer to another? Is
experience fromone area not transferrable to another? In eachof those
areas, I can point to significant negative consequences of an
interconnected system, from personal experience.
MUDs are a finely tuned control system, a balance of various elements.
The social aspect, the economic aspect, the mechanics, all are balanced
against one another <if gaining rank gave you an item or money, or if
having money allowed you topurchase rank or acquire items, or if it
became trivial because of the mechanics of a place to acquire money or
power.. if any leg of the three shows a weakness, all three become
unbalanced>.
When you have a dozen designers on multiple platforms, what I saw
*will* happen. Young players will form a caravan going to the
high-yield area, then returning to another area as their home base, or
jumping to the next high-yield area, leaving behind in the dust those
players who remain in one area. Players will exploit the weaknesses of
each system to their advantage, be it commerce or experience or power.
Why have rent on one system if you don't have it on another?
Why restrict players from being wizards if they can be a wizard or lead designer
on one system and be a player on your system?
I don't believe a society can be set up where the designer has the
option to let another design team own the balance of their system.
This is difficultenough in teams of three or five. If you give me a dozen
teams of varying skill as George put it, the end-result would be a backlash
against the players mapping from one system to another.
I'm also not convinced that the idea is entirely proper. as I said to
some one in a note, Vlad Taltos in Jhereg is not Vlad Taltos in
Alice in Wonderland, and Ishmael in the Wheel of Time has no logical
corrolary in the Middle Earth universe. How many barons can you have..
how many dark gods can you have, and how many worldviews can coincide
simultaneously? Do we not permit priests in from one system ifthe
other insists ona monotheistic society <or do we make their spells null
and void?>.
the last few thoughts are whimsical, but my experience <which is purely
anecdotal> is that the issue of balance is not something that can be
left to the hands of strangers for months at a time. Most designers would
see the effect it was having on their system and respond appropriately.
There would be a strong backlash among the players.
Just my two cents
Opinions my own.
Trademarks/etc. of their appropriate authors/entities/clusterf*(d organizations
Steve
John Viega
> I have only made one technical statement on the subject, and that was
> about how I would do it if I were to do it. As a matter of fact, I do
> not know of any technical reason why it *cannot* be done. I have
> asked you what the problem is which needs solving. In order to
> propose some sort of solution, you should have a problem.
>
Actually, it currently can't be done, because if you keep calling
get_char(), your text will get formatted all wrong, and you can't
correct for it. There are rather sizeable known problems w/
get_char()... Hopefully, there should be a new get_char() in the next
series of mudOS alphas, which will fix these problems.
Also, so far as I know, MudOS is the only driver that even comes close
to allowing a char mode text editor to be written for it.
George Reese
>And to pre-empt the inevitable response (not necessary by you, Steve):
>two MUDs sharing a subset of rules does not mean that they are the
>same worlds and so should be one. I understand the reasoning behind
>it, but reject the conclusion.
Rejecting the conclusion is fine, but if you are going to do so, you
should produce some sort of arguments stating why. The most central
object to any MUD game is the user object. It determines the very
nature of the game, from things as abstract as what defines success or
failure to things as concrete as exact attributes a player has.
Either you are committed to some sort of standard user object (or
standard set of attributes and methods with supersets of them) or you
are committed to some arbitrary translation method.
If you choose the former, then you have created basically a single
poorly distributed MUD. You have committed yourself to too much in
common. And thus there is no point in allowing for connecting MUDs.
If you choose the latter, you have event more of a balance nightmare
than with the former, compounded with a huge public relations fiasco
as you try to justify your translation scheme. No translation scheme
can satisfy a great portion of the people so long as it is arbitrary.
A general administrative rule for MUDs is that nothing should be
arbitrary.
George Reese
>In article <3trfd9$m...@blackice.winternet.com>
> bo...@winternet.com "George Reese" writes:
>> The point I have been trying to make is that you cannot define what it
>> means to be THE SAME CHARACTER in a way in which the term is
>> meaningful as a solution for connected MUDs. If you are able to
>> create such a defintition, my point is that you will end up talking
>> about the same game.
>This is getting philosophical. The similar identities may only exist
>in the mind of the player. I expect that the connected MUDs _would_ share
>similarities, but even if they don't, there is still a continuity between
>them in the mind of the player.
Yes, it is getting philosophical to an extent, but you do need some
sort of base from which to build your MUD. I am pointing out that you
have none here. The mind of the player is hardly something I am going
to base rules of my game on.
>Take the famous problem 'Anna's Boat', which basically details how
>over a long period of time parts of her boat get worn out or broken, and
>are subsequently replaced. Over a period of 10 years or so, so much has
>been replaced, that no part of the boat as it is now was there at the
>beginning, yet she still considers it to be the same boat. There is a
>continuity of thought that makes them the same, though. She saw each minor
>change happen, and just because you replace a rotten plank doesn't make
>it a different boat.
>A similar continuity of thought is what holds a character to a player, even
>when different stats etc. are used on different MUDs.
This is totally misunderstanding the problem. First, identity across
time is something very different from identity at a given point in
time. What makes you different from me at this instant? It is
basically the fact that you are there and I am here. Nothing more,
nothing less.
What is it that makes me the same person who went to RE Lee high
school in Houston (which physically, I am not made of the same matter
I was then). It cannot be time-space location as I identified above.
The fact is that it is the continuity of me across space-time.
Meaning that basically I am some sort of continuous map across a
space-time graph.
That's probably a bit esoteric. The essence of what I am saying is
that I am that same person because I am the result of a set of changes
to that initial object retaining the same essential characteristics as
the initial object. At this point we get into the question of what it
is to be George. That is the question I have been asking you all to
define. That is simply a base set of characteristics which cannot
change for Descartes to be Descartes.
>>
>> My point is that if all you can come up with to identify a person
>> across MUDs is the person controlling the player, then a MUD client is
>> your solution.
>Yes, but that has nothing to do with the statements we have made. This
>is talking about repetition in the MUDs, which would be lessened if
>they were connected. A single MUD wouldn't duplicate areas, so a
>set of connected MUDs wouldn't (or at least wouldn't for very long, once
>the players realised).
Most MUDs do not allow the duplication of areas.
Strange Journey
: sjou...@netcom.com (Strange Journey) once wrote:
: > I understand the reasoning behind it, but reject the conclusion.
: Rejecting the conclusion is fine, but if you are going to do so, you
: should produce some sort of arguments stating why.
We both know that I have stated arguments as to why, both here and via
our e-mail. You've never responded to them, you just keep reiterating
the same argument.
Kid/Strange Journey
--
sjou...@netcom.com
Dr. Cat
high-level, powerful character there, you're a very different kind of
animal than I am. I would think whether you have fun on a new mud should
have more to do with A) do you find some nice friends there, B) are there
neat places to explore that a fair amount of time and thought went into,
and C) is there neat stuff to do. Saying you have to start out as
powerful as you were on your other mud makes it sound like somehow the
act of playing the mud is no fun when you're low level and only starts
becoming fun when you're high level. I think a good mud should be fun
whether you become high level instantly, over a fair period of time, or
even never. If it isn't fun just to be there and play, it's not well made.
The other way to look at it is that your powerfulness is an important
part of your self image, and you can't feel that sense of "me-ness" if
the "me" in question varies in power. Well, I think name, race, class,
and above all the personality you act out online should be MUCH more
important in defining the character and making it a unique individual
that you identify with when you play it. Alas, even the RPGs that muds
were inspired by are far too prone to players defining themselves more as
"I am an 18 strength fighter, level 16 and have a +5 sword!" rather than
"I am an orphaned warrior, raised by the priests at the moon temple, with
a scar on my left cheek. My personality seems rough on the outside, and
I'm not very polite to strangers, but deep down I have a strong sense of
honor and fair play, and will always stand up for my friends."
If you really have the imagination to create a character with the same
name on multiple muds - try imagining yourself wandering out of your
"home" mud into a new one that is a "strange land of godlings, all twenty
times as powerful as beings in my home dimension, so that my mighty
strength is but that of the merest novice adventurer in this place."
If your levels are really so important to you. I really don't think
they're quite so important to most people. And you know, if you kept
them everywhere, you would be totally missing out on the interest and
balance of the beginner and intermediate adventuring areas on every mud
you played on but the very first. It's not much fun wandering through a
dungeon full of monsters aimed at challenging 3rd and 4th level players
if you're 20th level.
Joel and Lynn GAzis-SAx
I am coming in on the middle of this discussion, so pardon and gently correct
me if I am misunderstanding the issue here. From this point, I am heading off
in my own oblique direction. :)
On VampMUSHes, we've often had people who have come online asking to have the
same character they have on several other Mushes. For example, there was one
woman who ran a chain of esoteric shops at several sites. This character was
killed on one MUSH. Did this mean that she was dead on the others, too? If
it was the same character, my argument is yes. The player in question wanted
only the cream -- she wanted to be able to enjoy the timeline which she
developed on the different worlds (she was careful to be actively roleplaying
on one world at a time), but she didn't want to deal with repercussions like
dying. She, in effect, conferred on herself a special kind of immortality and
it seemed to me and some others that she used the fact that she had not been
killed on other MUSHes as a kind of moral blackmail to leverage her recreation
of the character on the MUSH where she had died.
At Darkweb, we simply discourage this and ask people to create unique
characters for our MUSH. It makes player/staff relations easier, I think, to
do this in the absence of direct links to other MUSHes, which we do not seek.
I recognize also that some people work very hard to make one character
complete with stats and background. When they come to a new MUSH, they don't
want to repeat the work they have already done. But these are usually willing
to accept that their characters can die on Darkweb and do not attempt to bring
in histories from other MUSHes. The kind of repetition I am speaking of is
when a player says that the character has a single life across all the MUSHes
and can enjoy the xp, the stats, and the knowledge he/she has accrued on one
MUSH on any of the MUSHes where he/she plays.
Linking MUDs is one solution, but I think that the MUDs should use very
similar, if not identical, rules to govern IC situations. The two staffs will
have to become one when it comes to setting rules. This is reality and
nothing more. Your policies on OOC behavior may diverge, but the IC standards
must be identical or there will be individuals who shamelessly exploit the
situation, inflicting pain on other players and one or both of the MUD staffs.
A confederacy simply will not work.
Sincerely,
Joel GAzis-SAx
************************************************************************
Joel and Lynn GAzis-SAx
ly...@elan.com Visit Alsirat, the horror magazine
gazi...@netcom.com http://www.best.com/~gazissax/alsirat.html
js...@igc.apc.org http://www.best.com/~gazissax/gazissax.html
The Marx Brothers@Darkweb (Joel) Whoopi@Darkweb (Lynn)
************************************************************************
George Reese
Your reasoning is:
I have a character on X Mud.
I want to have the same identity across MUDs.
Therefore those MUDs should be connected.
In order for the conclusion to follow, you need to argue that
connecting MUDs is the best way to preserve your identity across MUDs.
You have not shown at all that connecting MUDs preserves your
identity. In fact, my argument is just the opposite... that the very
act of preserving identity across two MUDs erases the distinction
between the two MUDs. This is because the entire MUD is centered
around the user object. It defines the MUD. Once you have blurred
the boundaries between two MUDs enough to allow for connecting MUDs,
you have, in essence created a single MUD which has no advantage over
it having been built as a single MUD. in fact, it has many technical
disadvantages.
So, please explain how it is connecting MUDs preserve identity.
--
George Reese (bo...@imaginary.com) http://www.winternet.com/~borg/
George Reese
>In article <3tjago$2...@blackice.winternet.com> bo...@winternet.com (George Reese) writes:
>> I have only made one technical statement on the subject, and that was
>> about how I would do it if I were to do it. As a matter of fact, I do
>> not know of any technical reason why it *cannot* be done. I have
>> asked you what the problem is which needs solving. In order to
>> propose some sort of solution, you should have a problem.
>>
>Actually, it currently can't be done, because if you keep calling
>get_char(), your text will get formatted all wrong, and you can't
>correct for it. There are rather sizeable known problems w/
>get_char()... Hopefully, there should be a new get_char() in the next
>series of mudOS alphas, which will fix these problems.
>Also, so far as I know, MudOS is the only driver that even comes close
>to allowing a char mode text editor to be written for it.
*Descartes slaps Rust.*
This thread is about connecting MUDs Rust :) Not vi!
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg/
Travis S Casey
>>two MUDs sharing a subset of rules does not mean that they are the
>>it, but reject the conclusion.
>
>Rejecting the conclusion is fine, but if you are going to do so, you
>object to any MUD game is the user object. It determines the very
>nature of the game, from things as abstract as what defines success or
>failure to things as concrete as exact attributes a player has.
>Either you are committed to some sort of standard user object (or
>standard set of attributes and methods with supersets of them) or you
>are committed to some arbitrary translation method.
Why do you believe these to be the only two choices? Why not create
a mud-independent format for representing characters and allow each
mud to write its own translation modules to and from that format?
The format could be a superset of the attributes, classes, etc.
that are most commonly used on muds; granted, no format could
possibly represent everything that all muds have in the way of
attributes, etc., but a reasonable attempt could be made.
Muds would then translate their own "native" formats to and from
the "universal" format. Thus, they would not have to have a
native format that was tied to the universal format, nor would
they be commited to an arbitrary translation method, since each
mud could create its own translations to and from the universal
format.
For an example of such a format, created for pencil-and-paper
RPG's, take a look at:
http://www.webcom.com/~apcrypha/features/envoy/fs040195a.html
Naturally, a format meant for automatic translation and targetted
for muds would need to be a good bit different from this, but it
should give you a good idea of what I'm talking about.
>If you choose the former, then you have created basically a single
>poorly distributed MUD. You have committed yourself to too much in
>common. And thus there is no point in allowing for connecting MUDs.
>
>If you choose the latter, you have event more of a balance nightmare
>than with the former, compounded with a huge public relations fiasco
>as you try to justify your translation scheme. No translation scheme
>can satisfy a great portion of the people so long as it is arbitrary.
>A general administrative rule for MUDs is that nothing should be
>arbitrary.
Nothing should be arbitrary? On the contrary, most muds have a
great number of things that are arbitrary... arbitrary classes,
arbitrary rules about chat lines, arbitrary attributes... the
list goes on and on.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' confirmed cat person
'---''(_/--' `-'\_) No one agrees with me. Not even me.
Strange Journey
: Geez, if your ability to enjoy a MUD is dependent on your being a
: animal than I am.
: The other way to look at it is that your powerfulness is an important
: part of your self image, and you can't feel that sense of "me-ness" if
: the "me" in question varies in power.
Thanks for that analysis, Doc, but I come from a social MOO
background, relatively recently arrived at advancement oriented MUDs.
I wizzed as fast as I could on my favorite MUD so that I could add to
the world and the first thing (almost) that I coded was a bin for
remote emoting. Before MOOs, I was a a GM for RPGs, playing only when
I felt like taking the occasional break.
The idea of linking MUDs is an interesting philosophical excursion for
me, not a desire to flex statistically enhanced virtual muscles at
other players. I'm enjoying the debate. It's over something I think
players would appreciate and so argue as both admin and player because
I have sympathies with both. I see linked MUDs as a role-playing
enhancement, but there seems to be some disagreement on that issue.
Oh, well. The debate itself is the important thing, and it's helped
me clarify my position, sharpened my argument from a clumsy, heavy club
to a sharp, pointy stick. And I happen to be rated 28.8 in sharp,
pointy sticks. I also have 406 HPs, 7.2 million XPs. I...
Damn. There I go again. Tell me again about this "role playing"
stuff.
Kis/Strange Journey
--
sjou...@netcom.com
Travis S Casey
(in response to Strange Journey)
>Your reasoning is:
>
>I have a character on X Mud.
>I want to have the same identity across MUDs.
>Therefore those MUDs should be connected.
>
>In order for the conclusion to follow, you need to argue that
>connecting MUDs is the best way to preserve your identity across MUDs.
>You have not shown at all that connecting MUDs preserves your
>identity. In fact, my argument is just the opposite... that the very
>act of preserving identity across two MUDs erases the distinction
>between the two MUDs. This is because the entire MUD is centered
>around the user object. It defines the MUD. Once you have blurred
>the boundaries between two MUDs enough to allow for connecting MUDs,
>you have, in essence created a single MUD which has no advantage over
>it having been built as a single MUD. in fact, it has many technical
>disadvantages.
>
>So, please explain how it is connecting MUDs preserve identity.
Hmm... somewhere along the line I must have missed this argument
that you speak of. So far, all I've seen you do is say that
preserving identity between muds erases the distinction between
the two muds. You have not offered any reasoned argument why
you believe this to be so; the best you have done is to make an
analogy with finding a way to relate Monopoly, Risk, and Doom.
I answered that post, providing a way in which those three games
could be related, but you never responded to my post.
In addition, you begin by saying that you don't believe that
connecting muds preserves identity, but you argue against this
by stating that two (or more) connected muds are effectively
one mud. Following your argument to its logical conclusion, I
am forced to conclude that you must believe that the identity of
a character is not even preserved on a single, unconnected mud;
after all, if connected muds are equivalent to a single mud, then
for identity not to be preserved on connected muds, it must not
be preserved on a single mud.
It seems to me that you simply have something against allowing
players to transfer their characters across muds. If this is
so, then why don't you simply say so, so that we can file you
under "those who can't be convinced" and give up a pointless
argument?
Please don't take this post as a flame; I have great respect
for your abilities as a coder and a mud administrator--I simply
do not understand how you can simultaneously believe that
connecting muds does not preserve identity and that it effectively
makes the connected muds one mud.
Peter Stewart
[snip]
: At Darkweb, we simply discourage this and ask people to create unique
: do this in the absence of direct links to other MUSHes, which we do not seek.
: I recognize also that some people work very hard to make one character
: complete with stats and background. When they come to a new MUSH, they don't
: want to repeat the work they have already done. But these are usually willing
: to accept that their characters can die on Darkweb and do not attempt to bring
: in histories from other MUSHes. The kind of repetition I am speaking of is
: when a player says that the character has a single life across all the MUSHes
: and can enjoy the xp, the stats, and the knowledge he/she has accrued on one
: MUSH on any of the MUSHes where he/she plays.
Just my own two cents here ... IMHO, if a person wants to create a character
on a given MU* that's an exact duplicate of a character on another MU*, I
would not worry about it. If I'm running MUSH A, how that person plays on
MUSH B, MUCK C, MUD D, etc, is none of my concern or my business. I would,
however, want the person to know that along these same lines, what happens
to that character on the other MU*s has no bearing on that person's character
here. If that character gets some sort of promotion on another MU*, that person
should not expect the same thing automatically here, for example (which is
pretty much what your policy states, but stated a little differently)
As for the idea of linking MU*s in general: I think its a great idea only
if you created the MU*s in question with the specific intent of linking them.
This would allow you to set up compatible systems between the MU*s ahead of
time, rather than to have to adapt them later and make changes likely to piss
off a lot of players. So unless the MU*s were created with this in mind, it's
far more trouble than it's worth.
Pete
-------------------------------------------------------------------------------
Pete Stewart | "Violence is the last refuge of the incompetent"
ste...@bae.bellcore.com | - Salvor Hardin
-------------------------------------------------------------------------------
Strange Journey
: At one point, high-level characters on LOFP were around level 40-60.
: Around the end of 1993, the Planes are introduced to LOFP. The Planes
: were a hunting ground, where your old skills did not immediately
: transfer.
: The immediate effect was that hunting areas became a challenge forsome
: players, again, at least for a while.
It sounds like the company running this game thought they had found a
way to keep those who were known to be willing to pour a lot of money
into the game interested as well as make it easier for newbies to
advance in power quickly, getting them hooked. Here, they had a
financial incentive to create such an unbalanced system. Whether it
will pay off for them in the long run is questionable.
: I don't believe a society can be set up where the designer has the
: option to let another design team own the balance of their system.
: the issue of balance is not something that can be left to the hands
: of strangers for months at a time.
Ah, this is excellent. What you're saying is valid, IMHO, and one of
the chief enticements for starting a system like this, the challenge
of it all, a new level of MUD interaction. How to do it?
To play on NickD's point in a companion thread, we do something
similar in the real world. The US, a capitalist country, trades with
China, a communist one. Somehow we manage to agree on what the
exchange rate of yuan to dollars is without going broke. And, of
course, there are many types of capitalism, with different laws,
different regulations. We work it all out with negotiated agreements
and attempts to regulate imbalances so that arbitrage doesn't get out
of hand. Occasionally, despite our best efforts, things do get out of
balance. One country might dump something on a market below cost to
drive competitors bankrupt, but others work to stop it when that
happens. And we do all this with our own individual, unique
governments. It may not be more efficient that way than having one
monolithic government but it's a cultural necessity and keeps us
diverse.
Linked MUDs would not have a laissez-faire, monetarist, start it up
and watch it go system of exchange, but a dynamic give and take.
Social institutions would have to develop to handle disagreements,
agree on trade policies and revise them as the need arises. A UN of
MUDs to resolve debate issues, a Hague to settle disputes? Who knows?
I'd like to see what happens.
: how many worldviews can coincide simultaneously?
Hee! That's the problem of a postmodern world, where every worldview
is known by every other and every other is a challenge to your own.
Yes, we could permit priests from polytheistic societies to exist in a
monotheistic one. On their own MUD, they are true believers, on
another, heathens. Perhaps the one would persecute the other...just
like the real world.
Kid/Strange Journey
--
sjou...@netcom.com
Joel and Lynn GAzis-SAx
ste...@bae.bellcore.com (Peter Stewart) wrote:
>Joel and Lynn GAzis-SAx (gazi...@shell1.best.com) wrote:
>As for the idea of linking MU*s in general: I think its a great idea only
>if you created the MU*s in question with the specific intent of linking them.
>This would allow you to set up compatible systems between the MU*s ahead of
>time, rather than to have to adapt them later and make changes likely to piss
>off a lot of players. So unless the MU*s were created with this in mind, it's
>far more trouble than it's worth.
>
>Pete
>
the beginning. Even in the World of Darkness we have gone our own ways
despite (because of?) the existance of the books which White Wolf has put out.
I am not "against" this idea, but I warn anyone implementing it that there is
a lot of work that needs to be put into it. What matters most is the
organization: the more you do in the beginning to organize it well, the less
fixing you'll have to do later.
So link MU*s if you wish. Just understand and respect why some of us feel at
this time we can't link. For my part, I wish anyone who does my sincerest
good wishes and hopes for success.
Respectfully,
Mark Clements
been answered: character dying, multiple logons etc.
In short - it is like playing ONE MUD although your player file exists
on each MUD you visit, when you log on, it traces the most recent copy -
if it is already in use, you will be unable to use your character.
Similarly as you are one character, when you die you don't remain alive
on another MUD.
As for travel (e.g. log out of MUD X, and into MUD Y), there are two
options: either MUD Y immediately logs you back into MUD X, or you
are transported from X to Y. I guess the second is preferable (remember -
it's only a game) but there would have to be a penalty - the standard
losing equip etc. that you get for logging out of a standard MUD should
be enough.
I forget if there were any other points I thought I should make.
However - good comments from Dr. Cat and various others. If a copy of
earlier posts are wanted, I could send them - just e-mail me. I lost
some of the earlier posts, but I've still got about 72 posts in this
thread <grin>.
Mark Clements
( Festival for the last week, but I'm back now, and so are my posts. )
Descartes wrote:
> Cogito Ergo Sum.
No wait - wrong Descartes...
George Reese (Descartes) wrote:
> This is totally misunderstanding the problem. First, identity across
> time is something very different from identity at a given point in
> time. What makes you different from me at this instant? It is
> basically the fact that you are there and I am here. Nothing more,
> nothing less.
[etc. etc.]
Let me see if I can grasp what you're saying.
This first paragraph (reprinted) seems to be saying that two people are
different because of physical location, a debatable point - I would say
it is more to do with where you think you are - either way this isn't
very relevant. On a MUD two different people are just that - different
people.
The second and third paragraphs (snipped) seem to say I am me because
of a continuous train of experience. Although I have changed physically,
there are aspects that remain the same, and the change has been visible.
Therefore I am the same person. On two differing MUDs, these aspects
may be lacking - the differing systems may make them incompatible. Therefore
they cannot be the same.
I hope this is what you were trying to say - it was quite hard to
follow, but I guess this might be too ;)
However I must disagree (it's in my contract). Whilst you may have
two wildly differing MUDs connected, there must be some sort of
continuity. Whether this is simply setting up a standard (which I don't
recommend, as it restricts freedom - although it may be the only way)
or simply organising the worlds and their links, I'm not sure.
One thing to remember is that there will be more than two MUDs - between
two wildly differing MUDs could be a third which is in the middle, and
between each of those three, others which will blur the distinctions
even more. You therefore will travel from one style to another, just by
having the MUDs linked up wisely.
Also taking a human analogy - skill X may not be present on MUD
A, but is on MUD B. This is no different to learning something in real
life. Similarly with attribute Y. I may not realise until I need to
use force that strength matters. (a weak argument, I know).
As for advancing - there is no problem with different methods of
advancing, as long as the player knows there is a difference. As city
people gravitate to a city, and country people stay in the country,
mudders who like killing will gravitate to an exp based advancement
system, and so on. This is no bad thing.
I hope I haven't completely misrepresented either your view, or my own :)
One last (lengthening) debacle:
> >>
> >> My point is that if all you can come up with to identify a person
> >> across MUDs is the person controlling the player, then a MUD client is
> >> your solution.
>
> >Yes, but that has nothing to do with the statements we have made. This
> >is talking about repetition in the MUDs, which would be lessened if
> >they were connected. A single MUD wouldn't duplicate areas, so a
> >set of connected MUDs wouldn't (or at least wouldn't for very long, once
> >the players realised).
>
> Most MUDs do not allow the duplication of areas.
>
Ding Dong - Missed point!
I know this is true - but how many MUDs have you been on with a Mordor?
How many with the same LP cathedral and village etc. Connect these MUDs
together then it will be painfully obvious. Thus the admin will remove/alter
them, and there will be less repetition. Voila. Easy, huh?
George Reese
>As for the idea of linking MU*s in general: I think its a great idea only
>if you created the MU*s in question with the specific intent of linking them.
>This would allow you to set up compatible systems between the MU*s ahead of
>time, rather than to have to adapt them later and make changes likely to piss
>off a lot of players. So unless the MU*s were created with this in mind, it's
>far more trouble than it's worth.
At that point, you end up with basically one large MUD with a lot of
overhead to support the connecting. So what is so neat about the fact
that they are connected?
George Reese
>> This is totally misunderstanding the problem. First, identity across
>> time is something very different from identity at a given point in
>> time. What makes you different from me at this instant? It is
>> basically the fact that you are there and I am here. Nothing more,
>> nothing less.
>[etc. etc.]
>Let me see if I can grasp what you're saying.
>This first paragraph (reprinted) seems to be saying that two people are
>different because of physical location, a debatable point - I would say
>it is more to do with where you think you are - either way this isn't
>very relevant. On a MUD two different people are just that - different
>people.
>The second and third paragraphs (snipped) seem to say I am me because
>of a continuous train of experience. Although I have changed physically,
>there are aspects that remain the same, and the change has been visible.
>Therefore I am the same person. On two differing MUDs, these aspects
>may be lacking - the differing systems may make them incompatible. Therefore
>they cannot be the same.
>I hope this is what you were trying to say - it was quite hard to
>follow, but I guess this might be too ;)
Close. And yes, I did not explain it in the clearest fashion. In
fact, you actually take a very Cartesian view of what I said,
something I think is completely wrong. Everything you said is
centered around "I"... "my" experiences... what "I" think...
You are the same person as yourself since you occupy the same physical
space. Not two distinct entities may occupy the same physical space
(this does not deal with components). Of course, across time, you do
not occupy the same physical space. You are the same person you were
10 years ago because of a continuity of real events which happened to
that physical thing 10 years ago ends with you.
Now you seem to be wanting to make the analogy that I can move myself
to some parallel universe and the universe would still be different
from my old one. That does not apply to MUDs, however, since the
entire design of a MUD is centered around the player object.
>However I must disagree (it's in my contract). Whilst you may have
>two wildly differing MUDs connected, there must be some sort of
>continuity.
My argument is that you must have enough continuity that you gain
nothing by connecting the MUDs. It might as well be done as one huge
MUD.
> Whether this is simply setting up a standard (which I don't
>recommend, as it restricts freedom - although it may be the only way)
>or simply organising the worlds and their links, I'm not sure.
>One thing to remember is that there will be more than two MUDs - between
>two wildly differing MUDs could be a third which is in the middle, and
>between each of those three, others which will blur the distinctions
>even more. You therefore will travel from one style to another, just by
>having the MUDs linked up wisely.
Or by having the areas wisely distributed on one MUD.
Joel and Lynn GAzis-SAx
ca...@sed.cs.fsu.edu (Travis S Casey) wrote:
>Why do you believe these to be the only two choices? Why not create
>a mud-independent format for representing characters and allow each
>mud to write its own translation modules to and from that format?
>
This is one reason why I retain faith in the USENET. For all the diatribes,
the nastiness, etc., sometimes we put our heads together on a problem and
voila! someone says "Hey, we've been looking at this too narrowly. There's
another solution out there and it works like this . . . ."
My hat is off to Travis Casey for bringing his intelligence and knowledge of
coding to bear on this discussion with a creative solution. Keep talking!
There may be others! :)
Following with interest,
George Reese
>George Reese <bo...@imaginary.com> wrote:
>>If you choose the latter, you have event more of a balance nightmare
>>than with the former, compounded with a huge public relations fiasco
>>as you try to justify your translation scheme. No translation scheme
>>can satisfy a great portion of the people so long as it is arbitrary.
>>A general administrative rule for MUDs is that nothing should be
>>arbitrary.
>Nothing should be arbitrary? On the contrary, most muds have a
>great number of things that are arbitrary... arbitrary classes,
>arbitrary rules about chat lines, arbitrary attributes... the
>list goes on and on.
They are only arbitrary when viewed from outside. On a well designed
MUD, heck, on any MUD worth anything, all of this stuff is consistent
within the context of the game. Once it becomes arbitrary, players
cease to feel comfortable about what they can expect from the game,
and they do not play.
stephen f. white
George Reese <bo...@imaginary.com> wrote:
> In
> fact, you actually take a very Cartesian view of what I said,
^^^^^^^^^
> something I think is completely wrong.
sorry for wasting bandwidth, but i thought this was kind of funny.
-=- sfw "yes i do have a sense of humour"
--
stephen f. white
sfw...@undergrad.math.uwaterloo.ca
http://csclub.uwaterloo.ca/u/sfwhite
"language is a virus from outer space" -- w.s.b.
Sam Denton
>Legends of Futures Past was/is a loosely skills-based system. There is
>a central experience reservoir, and each 'level' was gained when you
>gain 10 build points. Build points can in turn be traded in for
>skills, which cost a set amount regardless of race, background, current
[...]
>Around the end of 1993, the Planes are introduced to LOFP.
>The two systems <Planes and Andor> were identical systems. There was a
>simple and direct mapping between one and another. The equipment
>mapped precisely, save in those planes where magical equipmet became
>non-magical for balance purposes
>The Planes were not well-balanced, though. And they remained unbalanced
>for the better part of 18 months, until I left, and from what I've heard
>they never were well-balanced.
>Relative measures are extremely important in interconnected systems..
>not absolute measures.
>So how does this relate:
>1. The two systems used identical skills structures.
>2. The two systems used similar experience systems, and hunting areas
> were overseen by the same administrators <loosely speaking>
>3. The equipment on one system was the same as the equipment on another.
>Your mathematical mappings were trivial.
>But the effect of adding in the planes was horrendous on the game,
[...]
>Do you map in cash from one system to another? Do you map in
>equipment? Do build points in one area not transfer to another? Is
>experience fromone area not transferrable to another? In each of those
>areas, I can point to significant negative consequences of an
>interconnected system, from personal experience.
[...]
>When you have a dozen designers on multiple platforms, what I saw
>*will* happen. Young players will form a caravan going to the
>high-yield area, then returning to another area as their home base, or
>jumping to the next high-yield area, leaving behind in the dust those
>players who remain in one area. Players will exploit the weaknesses of
>each system to their advantage, be it commerce or experience or power.
Sorry, I quoted more than I really intended to, but I wanted to make
sure that I had the important parts of this really long and well
thought out message. Now, let me refute it.
The biggest problem, it seems to me, was that players could bring
everything back from the Planes at no penalty. If experience had
transfered back and forth at a discounted rate, players wouldn't have
been jumping back and forth, etc. Look at the real world: Go to the
nearest large bank and change a hundred bucks into a foreign currency,
then change it back. You will get back less than you started, because
there is a small discount built into the exchange rates.
Now imagine that in your example, the designers had set things up so
that Planes and Andor points were normally kept seperate, but could be
converted via some exchange rate, say 5 Planes points could be turned
into 1 Andor point, and 1 Andor point turned into 3 Planes points. In
this way, someone who moved back and forth a lot could keep separate
accounts (just like someone who repeated crosses the US/Canadian
border keeps both types of currency in their pocket), while players
who just want to stick to one area could keep (most of) their
character investment if they decide to permenantly move to the other.
The exchange rate need not be fixed, the designers could tweak it from
time to time if things started to get out of hand.
Strange Journey
: My argument is that you must have enough continuity that you gain
: nothing by connecting the MUDs. It might as well be done as one huge
: MUD.
You'll pardon my absence from this thread, I hope. I am sorting
through the previous postings and culling the umpteen, unanswered
challenges to George's mantra about it all being better done as one
MUD (George is, evidently, applying the tried and true USENET strategy
of reductio ad nauseum) so that I can air them and perhaps prod him
into taking a stab at bothering to respond to some of them. This is a
herculean task (the stables one, to be specific) and I am but a
feeble, minor wiz on a minor MUD in the backwaters of the net who
didn't save all the stuff bandied about here in a proper way.
In the meantime, may I point y'all to the advertisement on page 19 of
the latest "Computer Gaming World" for the inter-service, text-based
RPG "Modus Operandi". Anyone have any info about it?
Kid/Strange Journey
Steve Fleischaker (ICDApps)
>Sorry, I quoted more than I really intended to, but I wanted to make
>sure that I had the important parts of this really long and well
>thought out message. Now, let me refute it.
>
>The biggest problem, it seems to me, was that players could bring
>everything back from the Planes at no penalty. If experience had
>transfered back and forth at a discounted rate, players wouldn't have
>been jumping back and forth, etc. Look at the real world: Go to the
>nearest large bank and change a hundred bucks into a foreign currency,
>then change it back. You will get back less than you started, because
>there is a small discount built into the exchange rates.
>
>Now imagine that in your example, the designers had set things up so
>that Planes and Andor points were normally kept seperate, but could be
>converted via some exchange rate, say 5 Planes points could be turned
>into 1 Andor point, and 1 Andor point turned into 3 Planes points. In
>this way, someone who moved back and forth a lot could keep separate
>accounts (just like someone who repeated crosses the US/Canadian
>border keeps both types of currency in their pocket), while players
>who just want to stick to one area could keep (most of) their
>character investment if they decide to permenantly move to the other.
>
>The exchange rate need not be fixed, the designers could tweak it from
>time to time if things started to get out of hand.
>
In the planes, there was an upfront cost, and then the players advanced
at a skewed rate. There was a constant cost <opportunity cost> that
grew as resources were redirected to planes-oriented ventures instead
of Andorian ventures. And the direct investment to reclaim skill in
the plains permanently altered your character.. and none of that
investment directly mapped back. There were even items which had power
on the planes which turned to dust when you returned to Andor. By
expending points on Transcendance, you did not spend points on
Spellcraft, et. al.
That aside, a character gained points so much faster that the cost <7
points for 1 rank of transcendance and 1 rank of spellcraft vs. 5
points for 1 rank of spellcraft> was completely overshadowed by the
return <which was three to six times higher than on Andor>
So: cost was 1.4, but efficiency was increased six-fold.. so the
end-result was that the cost to advance was reduced by a factor of two
to four, or thereabouts. Levels which were effectively unattainable on
Andor were suddenly attainable on the Planes. Game balance went to
hell economically, experientially, and this in turn reverberated
through the game on a social and roleplaying level.
On an issue-by-issue basis, a decision can be made to reinstate a
balance for every occasion which arises which unbalances the system.
That's an administrative burden, though. There's no creative gain,
unless you consider your system to be improved by providing access to
another system.
My feel is that the administrative burdens would expand geometrically
and the unique attributes added would expand linearly. A *lot* of what
is out there is MOTS <more of the same>.. and not worth the
administrative and logistical efforts required to link it in and
maintain balance.
It's also not simply a matter of maintaining balance with system A.
using your currency exchange:
2 francs -> 3.7 german marks
1 german mark -> 300 lira
127 lira -> 498 dollars
137 dollars -> 16.7 francs
Is the mapping between the dollar and mark system reasonable?
What if the mapping were
2 green, 3.7 australian swallows, 4 lira -> 3.7 marcs, 1.9 levels, 2 battleaxes
I don't have time to rewrite the message I wrote a few minutes ago
but killed.. it was simply too long and listed too many reasons why I
felt connecting systems was a nightmare. Technically, any problem can
be resolved.. if you want, you can set it up so that special music
is played through sound cards from three manufacturers when a fighter
sub-class from Sojourn is ported to Phoenix. The technical issues
are relatively trivial.
By relatively trivial I don't mean they're cheap.. they're not rocket
science, but they'd take time. And time isn't fungible.
A core question, though:
Why would an A-class organization with a player-base of 1000 and 120+
players on at a time add to its workload the administrative, political,
and logistical burden of connecting <indirectly or directly> to several
other sites? If they wish to expand, they'll add an area, or develop
an existing area to a higher degree.
The most difficult issue in developing a roleplaying environment has to
be developing, articulating, and implementing a vision. Balance is
a component of that vision. You can't give away responsibility for that
vision, and you can't turn your back on it. And the more people involved
the worse it gets.
opinions mine, natch.
Steve
Dr. Cat
: You'll pardon my absence from this thread, I hope. I am sorting
: through the previous postings and culling the umpteen, unanswered
: challenges to George's mantra about it all being better done as one
: MUD (George is, evidently, applying the tried and true USENET strategy
: of reductio ad nauseum) so that I can air them and perhaps prod him
: into taking a stab at bothering to respond to some of them. This is a
George isn't the only person who disagrees with you. But since you have
yet to make a convincing case for your side of the issue, I haven't felt
as motivated to reply as he has. The most compelling lack for me, thus
far, is the lack of any demonstration that this is something a lot of
players want as opposed to a few. My suspicion is that something you and
a few other mudders with tastes similar to yours want very much, and that
most mudders don't really have much interest in having. As a developer
who's always seeking the widest possible audience, my instinctive
reaction to a request for a difficult feature from a small minority is a
shrug.
I am curious what your reaction is to the recent post stating that a
number of UberMUDs and UnterMUDs implemented exactly what you're looking
for with "Cyberports". I would think that news calls for either a "Wow,
I should go start using one of those two servers and trying to get other
wizards to link to me with Cyberports from other muds", or a "Gee, I
wonder why this didn't become immensely popular when people did it before
if it's really such a good idea as I think"? But of course your reaction
to this news might be something entirely different. Surely it merits
some reaction, being exactly what you have been advocating at such great
length.
: In the meantime, may I point y'all to the advertisement on page 19 of
: the latest "Computer Gaming World" for the inter-service, text-based
: RPG "Modus Operandi". Anyone have any info about it?
Sure. This went into open beta test on Genie a while ago (a couple
months, maybe?), and was developed by Simutronics. They are the same
people that did Gemstone and Cyber Strike and are developing the online
version of Magic: The Gathering to go with Microprose's home version.
(Microprose also has a deal with them to distribute the CyberStrike front
end software in retail stores.) Gemstone is the most successful text
based mud on the commercial online services - in fact possibly the most
successful commercial online game out there.
Modus Operandi is a new game based on the Gemstone server code. It's a
murder mystery game, backed by a book publisher (Warner Books, I think?)
that puts out a lot of mystery novels. They've got some professional
authors of said novels involved in the project in some capacity. I
haven't looked at the game yet but I probably will soon. They had some
fairly lofty design goals, I don't know whether they've managed to
accomplish them or not.
Strange Journey
: The most compelling lack for me, thus
: reaction to a request for a difficult feature from a small minority is a
: shrug.
I don't believe that players know what they want until they see it.
As independent producers, we're not compelled to go along with the
herd never to try something new because it's not proven, as if we are
Hollywood filmmakers with marketing reports and test audiences, slaves
to convention because we believe that's the way to reach the widest
possible audience. Truly successful enterprises give people something
they haven't had before, but once they see don't know how they lived
without it. Innovation, Cat.
What I see going on in this thread is a lot of technocrat myopia.
Very little thought given to what we're doing or why we're doing it,
no thought given to social dynamics beyond urgings to balance our MUDs
as if they're calculus equations to be solved. It's all about
optimization of code and not enough about evolution of culture.
People labeling connected MUDs as a solution without a problem as if
each innovation needs to be a solution in a concrete, engineering
sense. Well, that's who is responding here, we engineers, so it's
no wonder we can't see beyond the blueprints of the toys we design,
to see their social consequences.
: I am curious what your reaction is to the recent post stating that a
: number of UberMUDs and UnterMUDs implemented exactly what you're looking
: for with "Cyberports". [...] Surely it merits
: some reaction, being exactly what you have been advocating at such great
: length.
A lot of things said in this thread have merited reaction from both
sides, but haven't received any attention at all. It's why I gave up
bothering to reply for the most part. For example, I did comment on
Unter/UberMUDs when you jumped in about how since they hadn't been
implemented people must not want them. I must have missed your
response to that (assuming it was convincing enough to get one from
you). I may look into U*MUDs, but my original idea was not to start
over from scratch and build an empire or something, but to connect our
existing MUDs. Given that position, U*MUDs are interesting but
irrelevant to the topic at hand.
: Modus Operandi is a new game based on the Gemstone server code.
: [...] They had some fairly lofty design goals, I don't know whether
: they've managed to accomplish them or not.
The loftiest of those goals being that it is a shared world between
AOL, GEnie and Prodigy. My point in bringing it up was that I'm
wondering why those companies felt it would be a good thing to link in
that fashion. It could be that they think people will like the idea
of playing with people from the other services. In this case, the
psychology would seem to be similar to what I've described, with the
services themselves being the MUDs and the game the link between them.
Play with someone on another service/MUD...It's an intriguing concept.
But gosh darn it, what is it a *solution* to? Where is the *player
demand*?
Kid/Strange Journey
--
sjou...@netcom.com
George Reese
>What I see going on in this thread is a lot of technocrat myopia.
>Very little thought given to what we're doing or why we're doing it,
>no thought given to social dynamics beyond urgings to balance our MUDs
>as if they're calculus equations to be solved.
Come on, you have said absolutely nothing to suggest that actually
connecting MUDs is even a good idea. In fact, "Very little thought
given to what we are doing or why we're doing it..." is exactly what
you are guilty of. Again, I ask the question WHY DO YOU WANT TO
CONNECT MULTIPLE MUDS?
What does it get you?
Your response is simply that it allows you to transfer progress from
one game over to another. But if you do that, you are in fact saying
that the two games are in fact different aspects of the same game. So
why don't you just build them as the same game in the first place?
Again, why would you expect to be able to transfer your progress in
Monopoly over to Doom?
> It's all about
>optimization of code and not enough about evolution of culture.
>People labeling connected MUDs as a solution without a problem as if
>each innovation needs to be a solution in a concrete, engineering
>sense. Well, that's who is responding here, we engineers, so it's
>no wonder we can't see beyond the blueprints of the toys we design,
>to see their social consequences.
Contrary to your belief, I and many of the people who post to this
newsgroup are constantly looking for new ways in which to advance
MUDs. There are two parts to that. One is to empower larger numbers
of people to be able to bring their ideas out and make them real.
This is done by making the tools we use more powerful and more easy to
use. The other is creative ideas for new realities. Connecting MUDs,
intermud communication, and the like do not fit in this category.
Instead they are technical toys of CS types with very little GAME MUD
applicability.
Now, I actually believe intermud and distributed mudding have appeal
beyond game MUDs. And perhaps even connecting MUDs. But that is
another story.
Strange Journey
: Again, I ask the question WHY DO YOU WANT TO CONNECT MULTIPLE MUDS?
: What does it get you?
We share a MUD culture which is in its infancy. Having pioneered
virtual communities, we are barely evolving...except technically. We
reproduce by splitting like ameobas, differentiating ourselves by
subtle rule changes and gimcracks as if painting your car makes it a
wholly different car. Linking would be sex. The institutions that
would have to develop to handle things like balance, disputes and any
number of unforseen contingencies would be a leap forward in
administrative sophistication. I see it all leading to more
cooperation (by necessity), more differentiation (by necessity) and a
much needed stimulus to get us all together instead of hiding within
our little realms. No, not more rule differentiation. I don't think
that adds a whole lot to MUDding.
From the player's standpoint, transferring progress would be
appealing, but beyond that they would be sharing the MUD experience
with a larger portion of fellow MUDders without requiring that admins
give up as much of their autonomy as if they abandoned their creations
to work on One Mud. Sure, they have always been able to use clients
to bop from one place to the next, but that's like visiting friends in
their own towns. Linking would get us together in one place without
requiring that we move.
: Your response is simply that it allows you to transfer progress from
: one game over to another. But if you do that, you are in fact saying
: that the two games are in fact different aspects of the same game. So
: why don't you just build them as the same game in the first place?
Most MUDs are different aspects of the same game, whether they are
linked or not. Cosmetic rule changes do not make them so different.
Why do you distribute Nightmare, George? Surely by doing so you are
contributing to overall mediocrity of MUDs by fragmenting rare talent
when admins could just join you on your MUD. People want to run their
own MUDs, existing MUDs don't want to shut down. Giant MUDs would be
harder to administrate than individual MUDs agreeing on protocols, and
not nearly as interesting.
: Again, why would you expect to be able to transfer your progress in
: Monopoly over to Doom?
Yes, again. We've done this metaphor before. This time through I'll
add that the difference between your MUD and mine are not the same as
the differences between Monopoly and Doom. That should be so obvious
as to not even require mentioning. It's more like the difference
between strip poker with someone sexy and poker for matchsticks with
your grandmother. Same game, different atmosphere, best when they're
not combined, but one's skill at poker remains consistent in both
situations. Except of course, when you're down to your underwear.
: Contrary to your belief, I and many of the people who post to this
: newsgroup are constantly looking for new ways in which to advance
: MUDs.
Not my belief. I really believe that you and others are doing a hell
of a lot to advance MUDs, but your attitude in *this* thread has been
rather tightly focused on either balance issues, One MUD is better or
solution-without-a-problem arguments. It's the last that has led me
to wonder where innovation ranks in your list of priorities.
: Connecting MUDs, intermud communication, and the like do not fit in
: this category. Instead they are technical toys of CS types with
: very little GAME MUD applicability.
Heh, I disagree about the CS thing, but even were it true it doesn't
mean that we can't assimilate it and put it to our own uses.
At one time, computers were just technical toys of CS types until
people with imagination saw possibility in them.
Your emphasis of 'game MUD' is interesting. Now, I don't
differentiate between the two but rather see them as part of a
continuum with similar needs. Or, rather, I see game MUDs as a subset
of all MUDs, while you might see social MUDs as a subset of game MUDs.
Oh, well.
Kid/Strange Journey
--
sjou...@netcom.com
George Reese
>George Reese (bo...@imaginary.com) wrote:
>: Your response is simply that it allows you to transfer progress from
>: one game over to another. But if you do that, you are in fact saying
>: that the two games are in fact different aspects of the same game. So
>: why don't you just build them as the same game in the first place?
>Most MUDs are different aspects of the same game, whether they are
>linked or not. Cosmetic rule changes do not make them so different.
>Why do you distribute Nightmare, George? Surely by doing so you are
>contributing to overall mediocrity of MUDs by fragmenting rare talent
>when admins could just join you on your MUD.
This is basically the question: do you enforce an elitist coding
standard which allows only a few to open MUDs while preserving the
quality of MUDs in general but missing out on new ideas OR do you open
up the MUD creation process and empower those who desire it to build
their own MUDs, thus diluting the talent pool but creating more
innovation.
The answer to your question is yes. I am contributing to the overall
mediocrity of MUDs, as a whole, because there are a hell of a lot more
MUDs now than a year or two ago. But there are still stars out there
in the vast emptiness of space.
> People want to run their
>own MUDs, existing MUDs don't want to shut down. Giant MUDs would be
>harder to administrate than individual MUDs agreeing on protocols, and
>not nearly as interesting.
>: Again, why would you expect to be able to transfer your progress in
>: Monopoly over to Doom?
>Yes, again. We've done this metaphor before. This time through I'll
>add that the difference between your MUD and mine are not the same as
>the differences between Monopoly and Doom. That should be so obvious
>as to not even require mentioning. It's more like the difference
>between strip poker with someone sexy and poker for matchsticks with
>your grandmother. Same game, different atmosphere, best when they're
>not combined, but one's skill at poker remains consistent in both
>situations. Except of course, when you're down to your underwear.
We keep running over this metaphor because i think it is a very good
one. If my MUD and your MUD are that much alike, then they should be
one single MUD. Connecting them is pointless, and it spreads talent
thin. It certainly does not preserve the administrative autonomy
which led us to create separate MUDs in the first place.
However, I believe that if I am being successful, then my MUD quite
simply is not enough like your MUD. In fact, it falls into the
Doom/Monopoly analogy quite well.
Eric Olson
to read the newsgroup tonight to catch up on whats going on. The
MOOs people are connecting to WWW browsers caught my interest,
but then so did this thread!
A town is really small if it has less than 2000 people in it. None
of the existing MUD communities have that many people present. They
may have 2000 registered names, but only 70 people may login at one
time. That is analogous to a resort with 70 rooms and reservations
for 2000 spread out over the entire year.
It is dicussed in the FAQ that most MUDs aren't resource intensive
enough to require more than one machine. Now calculate with some
made up figures:
2000 users each at 1200 baud and each using 100KB on one server.
That makes 2.4 Mbaud and 200MB of RAM.
It seems to me the FAQ is right, MUDs can be made easily ten times
larger while keeping with a single server--a big expensive server.
The FAQ also mentioned that it'd be a headache to connect two muds
together if they were very different and pointless if they were the
same. Note, I'm not quoting the FAQ, but paraphrasing it as I
understand it. If they are so similar then why not close one of
them and make the other bigger, rather than connecting them?
MUDs are typically as different or similar as countries are here
in the real world. This works with the Doom and Monopoly analogy
if you assume they play Monopoly in the USA and Doom in Wisconsin.
Some countries are quite different and one isn't allowed to live
anywhere one likes. Sometimes one can get a tourist VISA, but
then one isn't allowed to earn wages, by slaying dragons in the
other country, for example. Some countries are very similar, like
Germany and France. WWII was an attempt at closing one country and
making the other bigger.
The final question the FAQ asks is why connect them? What is the
advantage? Let me assume as a truth that bigger is better. Then
it's easy to answer that question. Connecting two MUDs is a way to
make a bigger mud. I like big MUDs, and I think it is better than
closing one mud and enlarging the other.
Some system administrators will say a MUD is sort of like having a
hole in ones boat or a memory leak in ones computer. A bigger one
is a whole lot worse than a smaller one. A player with visions of
the New York subway or the local trains in Bombay might disagree and
want a mud with lots of people in it.
Connecting muds allows system adminstrators to have small holes
and players to have crowded happy trains. Everyone is happy.
So how should it be done? It's true connecting two muds is harder
than not connecting them. It's also true that managing a mud twice
the size is harder. I'm not suggesting everyone go out and spend
the rest of their free time connecting muds. Remember the super
conducting super collider for high energy physics that the government
was going to build? Many physicists said they could think of more
physically interesting ways to spend that money.
MUDs are the same way. There are other things to do that are more
interesting. Connecting them is fine, but imagine this: how about
a built in vi editor! No, no, just joking! I can't resist giving
my opinion, though.
Lots of people are busy making multimedia MUD games. My favorite
things are making it easier for former nonprogrammers to program
in the MUDding environment and making the MUD parser understand
natural languages better.
Bye, Eric
chiaroscuro
> Your emphasis of 'game MUD' is interesting. Now, I don't
> differentiate between the two but rather see them as part of a
> continuum with similar needs. Or, rather, I see game MUDs as a subset
> of all MUDs, while you might see social MUDs as a subset of game MUDs.
the distinction is important given the rapidly expanding potential for
the use of mud systems for things like business infrastructure purposes.
too bad the development seems to be taking place using the MOO base,
which i grew to despise thoroughly during my brief stint at coding in it.
chiaroscuro
Alan Cox
>2000 users each at 1200 baud and each using 100KB on one server.
>That makes 2.4 Mbaud and 200MB of RAM.
Amusing figure.. I see much over 1200 baud with AberMUD5 users, and about
16K a user including kernel buffer space. Close to 9600 baud average per
player - that may be because the UK networks are better than yours
>It seems to me the FAQ is right, MUDs can be made easily ten times
>larger while keeping with a single server--a big expensive server.
This is laughable .. see the next clause.
>understand it. If they are so similar then why not close one of
>them and make the other bigger, rather than connecting them?
One main cause of new MUD's is because 'I can do better'. Another is because
'xxx is a little **** who ought to **** and die...' (all permutations
thereof). Most people who run Mud's do it because they are wannabe
powermongers or because they cant play well enough to get that power
elsewhere.
Merging to games is also interesting because you have to check that each
object (1..N) from game 1 does not conflict or interact wrongly with each
object (1..M) from game 2, and write all the new interactions then debug
them.. are you familiar with the growth of N!
>it's easy to answer that question. Connecting two MUDs is a way to
>make a bigger mud. I like big MUDs, and I think it is better than
>closing one mud and enlarging the other.
Not from a programming or performance issue.
>Connecting muds allows system adminstrators to have small holes
>and players to have crowded happy trains. Everyone is happy.
Except for the issue of scalability and the fact they now have database
coherency/commit algorithms eating their network alive. And what happens if
you have a scroll of summon your magic axe and the axe is on a machine that
is down ?
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
Redistribution of this message via the Microsoft Network is prohibited
<A href="file:/dev/mouse">Click here to disable mouse.</A>
Herbert Rosmanith
: >Connecting muds allows system adminstrators to have small holes
: >and players to have crowded happy trains. Everyone is happy.
everyone smokes pot. everyone is happy. *final curtain*
--
-------------------------------------------------------------
he...@wildsau.idv.uni-linz.ac.at | Fighting for peace is like
Rosm...@Edvz.uni-linz.ac.at | fucking for virginity