<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] GRUMPS -->
<!--X-From-R13: Fenivf Qnfrl <rsvaqryNcbynevf.arg> -->
<!--X-Date: Mon, 06 Apr 1998 00:59:42 +0000 -->
<!--X-Message-Id: 2873.980405#io,com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199804052344.QAA02273#pc4,zennet.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] GRUMPS</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:efindel#polaris,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00033.html">Previous</a>
| <a href="msg00035.html">Next</a>
]
Thread:
[ <a href="msg00033.html">Previous</a>
| <a href="msg00038.html">Next</a>
]
Index:
[ <A HREF="author.html#00034">Author</A>
| <A HREF="#00034">Date</A>
| <A HREF="thread.html#00034">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] GRUMPS</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: "Brandon J. Rickman" <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] GRUMPS</LI>
<LI><em>From</em>: Travis Casey <<A HREF="mailto:efindel#polaris,net">efindel#polaris,net</A>></LI>
<LI><em>Date</em>: Sun, 5 Apr 1998 20:57:32 -0500</LI>
<LI><em>Reply-To</em>: Travis Casey <<A HREF="mailto:efindel#io,com">efindel#io,com</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Sunday, 5 April 98, Brandon wrote:
> Travis Casey <efindel#polaris,net> wrote:
>>A mud that wanted to use the system would need two converters: one to
>>convert characters to the specification, and one for converting them
>>from the specification. Extra converters could be added as well, for
>>muds that have special agreements with each other for converting
>>characters.
> "special agreements" cause endless grief because they tend to develop into
> "proprietary extentions". But then those extentions are usually important
> features that were left out of the spec because of lack of concensus.
> (I'm thinking of the horror of VRML, which has things like the rather
> pathetic Box node and the inability to pass integer events without using
> Javascript.)
Well, in terms of "special agreements," I was thinking more of cases
where two muds are put together to make one larger mud, with the two
having very similar systems. For example, one could create a mud
based on Piers Anthony's _Apprentice_Adept_ series, with the fantasy
and SF worlds each being a separate mud. Since the two muds would be
designed with the idea of moving characters between them, a custom
transfer system would be desirable.
> The conversion of characters should be "easy"; it would be more of a
> challenge to make sure the characters are secure/certified. Maddog
> mentioned LEDOs, which are pretty much a marketing ploy, trying to
> turn character attributes into a commodity is a pretty iffy business but
> would be interesting in the short term.
I have no idea what an LEDO is, so I can't comment on that.
In my ideas for character transfer on the newsgroup, I thought of
having security work like this:
(The "receiving" mud is the mud the character is entering, and the
"sending" mud is the mud the character is originally from. If a
character wanders from mud A to mud B, then tries to transfer from B
to C, B will send a message to A to tell it to send the character to
C. This avoids several problems.)
- The receiving mud is told what mud the character is coming from,
and can verify it by the IP the connection is coming from. The
receiving mud can then decide whether or not to accept the transfer
based on which mud it is coming from.
- The sending mud sends, among other data, the character's name, the
player's name if he/she has given it to the sending mud, and the
player's email address if it has been given to the sending mud.
The receiving mud can also deny the transfer based on any of these.
- Indeed, a receiving mud can deny a transfer for any reason or for
no reason at all. Thus, you can refuse a transfer to character who
seems too powerful, or who would violate one or more of the mud's
rules.
- Lastly, remember that the receiving mud gets to write its own
"conversion routine" for characters coming from other muds, and can
customize it on a per-mud basis. The conversion routine could
"truncate" characters, making any character who is above a certain
power level be reduced to that power level, or could even just dump
an incoming player into the mud's character creation routine,
allowing him/her to create a new character on the receiving mud.
>>Note, by the way, that even if you have a "universal" RPG system,
>>there may be things that can't be conveniently expressed in it, and
>>things that it won't work for. GURPS, for example, breaks down at
>>high power levels unless you do a good bit of modification.
> Yah, but most muds break down at high levels too. Or rather, they fragment
> when there is too large a disparity between new, low level characters and
> the older, elite characters. Maybe powerful characters would migrate
> to more difficult muds if they could.
That's not quite what I mean by breaking down at high power levels;
even when all the characters are extremely powerful, GURPS does not
work well.
> That is the easy part. The hard part is figuring out what a particular
> mud world knows about lizards. Does the player have to
> roleplay when someone gives him a lizard-engraved sword? Is flying a
> physical ability (does the world have aerodynamics), or are flying creatures
> simply immune from the effect of gravity? To me these are the interesting
> differences between mud realms, that Doctor Who effect from the original
> post.
I agree. Any kind of mud transfer system would need to be very
flexible to handle all kinds of powers. A really good system would
need to carry meta-information about the origins of powers, in
addition to information about the powers themselves. That way, a mud
could decide whether to allow a power to work or to reduce (or even
increase) it based on the power's origin.
>>> So...does anyone have a suggestion of where I can start?
>>> The groundrules are such that the engine must be completely open,
>>> freely distributable, and no restrictions on its use. This just
>>> about eliminates everything that is currently available.
>>
>>If you want a character specification format, check out WotC's Envoy
>>system. It was to be the starting point for creating a specification
>>format for universal paper RPG adventures, but it never got far off
>>the ground. It is freely redistributable and can be used in any sort
>>of product, with the only "restriction" being that the people involved
>>in creating it must be credited.
> How about investigating ways to keep high level characters more balanced?
> Once someone figures out how to create a god-like character the fun
> is over.
Why is the fun over? Remember, a mud can always truncate the power
level of characters or do the "transfer" just by letting the player
create a new character.
Also, remember that "balance" and "level" are relative terms --
balanced in terms of what? Combat power? That's the most common
definition, but if a mud isn't combat-oriented, combat power may make
very little difference.
Does balance mean that high-level characters need to be able to find a
challenge? Or that they shouldn't be too powerful relative to lower
level characters? Or that a character who is level X should have
approximately the same amount of power as another character of level
X, no matter what other differences they have? Or all of these?
I'd like to note quickly that reducing the disparity between
"high-level" and "low-level" characters is very easy -- either give
characters more power to start with, or make their power go up more
slowly, or both.
Consider the example of RP-oriented muds -- on some muds, power can
only be gained through social connections, since all characters have
the same in-game powers. A high-power character on such a mud is
effectively taken back to square one on a different mud, unless he/she
can convince other people to transfer over as well.
To give another example, people often complain that high-level
characters in D&D/AD&D are too hard to kill relative to low-level
characters (or, conversely, that low-level characters are too easy to
kill). In my own campaigns, I solve the problem by using character's
constitution scores as their base hit points (increasing the hit
points of first-level characters) and not giving a per-level
constitution bonus as characters advance (making characters go up in
hit points more slowly).
In "standard" AD&D, a fighter, assuming a 16 constitution, starts
with an average of 7.5 hit points. At ninth level, an average fighter
with the same constitution has 67.5 hit points -- nine times as many.
Under the modified system, the same characters have an average of 21.5
and 65.5 hit points -- so hit points only approximately triple in the
same time. This allows a wider range of levels to take part in the
same adventure, since the hit points are more even.
> (Maybe I have something against superstar gamers, the kind that keep
> their character in a thick binder. I tend to die or suffer critical injuries
> within ten hours of play.)
> "Yes sir, you certainly meet all the skill requirements of our little
> brotherhood, but... you are left handed, and we have strict rules against
> that kind of thing."
> "Yes, we _do_ have a number of quests that need doing, but we feel you are
> perhaps a bit overqualified."
> "Congratulations, you are now a Guild Master. Have you filled out the
> proper paperwork?"
Yep -- since the system proposed allows the receiving mud to set the
conversion method, any of the above could conceivably be part of a
conversion process. :-)
--
|\ _,,,---,,_ Travis S. Casey <efindel#io,com>
ZZzz /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-' visit the rec.games.design FAQ:
'---''(_/--' `-'\_) <A HREF="http://www.io.com/~efindel/design.html">http://www.io.com/~efindel/design.html</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00033" HREF="msg00033.html">Re: [MUD-Dev] GRUMPS</A></STRONG>
<UL><LI><EM>From:</EM> "Brandon J. Rickman" <ashes#pc4,zennet.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00033.html">Re: [MUD-Dev] GRUMPS</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00035.html">Re: [MUD-Dev] caved in: Algorithms for for storing free space.</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00033.html">Re: [MUD-Dev] GRUMPS</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00038.html">Re: [MUD-Dev] GRUMPS</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00034"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00034"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] GRUMPS</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00132" HREF="msg00132.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Joel Dillon <a href="mailto:emily#cornholio,new.ox.ac.uk">emily#cornholio,new.ox.ac.uk</a>, Sat 11 Apr 1998, 13:38 GMT
</LI>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00092" HREF="msg00092.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 09 Apr 1998, 14:46 GMT
</LI>
</ul>
</ul>
<LI><strong><A NAME="00032" HREF="msg00032.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 05 Apr 1998, 21:17 GMT
</LI>
<LI><strong><A NAME="00033" HREF="msg00033.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Sun 05 Apr 1998, 23:44 GMT
<UL>
<LI><strong><A NAME="00034" HREF="msg00034.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Mon 06 Apr 1998, 00:59 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00038" HREF="msg00038.html">Re: [MUD-Dev] GRUMPS</A></strong>,
maddog <a href="mailto:maddog#best,com">maddog#best,com</a>, Mon 06 Apr 1998, 06:56 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00020" HREF="msg00020.html">Re: [MUD-Dev] Re: MUD Development Digest</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sat 04 Apr 1998, 23:21 GMT
<LI><strong><A NAME="00017" HREF="msg00017.html">GRUMPS</A></strong>,
maddog <a href="mailto:maddog#best,com">maddog#best,com</a>, Sat 04 Apr 1998, 21:14 GMT
<UL>
<LI><strong><A NAME="00023" HREF="msg00023.html">Re: [MUD-Dev] GRUMPS</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Sun 05 Apr 1998, 02:30 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
