<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: MUD Design doc (long) -->
<!--X-From-R13: "Ybfgre, Dncu" <exbfgreNbevtva.rn.pbz> -->
<!--X-Date: Tue, 5 Jan 1999 09:54:33 -0800 -->
<!--X-Message-Id: 11A17AA2B9EAD111BCEA00A0C9B41793EDC884#forest,origin.ea.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: MUD Design doc (long)</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:rkoster#origin,ea.com">
</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="msg00043.html">Previous</a>
| <a href="msg00045.html">Next</a>
]
Thread:
[ <a href="msg00043.html">Previous</a>
| <a href="msg00090.html">Next</a>
]
Index:
[ <A HREF="author.html#00044">Author</A>
| <A HREF="#00044">Date</A>
| <A HREF="thread.html#00044">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: MUD Design doc (long)</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: "'<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>'" <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: MUD Design doc (long) </LI>
<LI><em>From</em>: "Koster, Raph" <<A HREF="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</A>></LI>
<LI><em>Date</em>: Tue, 5 Jan 1999 11:50:03 -0600 </LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> From: Emil Eifrem [<A HREF="mailto:emil#prophecy,lu">mailto:emil#prophecy,lu</A>]
> Sent: Friday, January 01, 1999 6:17 PM
> To: mud-dev#kanga,nu
> Subject: [MUD-Dev] Re: MUD Design doc (long)
>
> In fact, in my experience, the amount of admin work increases
> exponentially
> to the growth of your player base. Hmmm.. that may even
> qualify as one of
> Raph's laws. "The amount of administrative work increases
> exponentially to
> the growth of your player base."
It is in there already; it's certainly something I believe & have
experienced personally. In UO we went to great lengths to minimize the
amount of direct admin precisely for this reason.
> I think player-driven rule
> enforcement may
> help flatten the curve. On the other hand, maybe it won't --
> it may only
> serve to redistribute the effort to the players, which in the
> end will give
> the problems to the admin staff anyway.
That would depend on whether or not there is a means of recourse to the
admins for the given issue which players are dealing with. I always cite
the classic PK switch as an example of something that scales poorly;
it's generally easily circumvented, and since it is a "rule imposed from
on high" there is a clear path of recourse to the admins. When it is
circumvented, they can legitimately call an admin and say "hey, this guy
cheated." Thus admin overhead rises.
If, however, you have a player-driven system that does not have that
smell of "rule imposed from on high" then they may not feel there is
anyone TO complain to. In which case your admin cost is nil. An example
would be a player-enforced rule on not killing in town. If there is no
admin-provided rule against it, and no code to prevent attacks in town,
but players are rewarded for executing offenders, then when someone gets
away with it, no admin call is generated.
The drawback: you need to monitor the situations in the game to make
sure that the lack of admin-imposed rule is not proving damaging to your
playerbase. In the above example, the danger would be that players not
enforce it sufficiently. You won't get admin calls, but you also might
not have a safe enough town.
> >Yes. Its not necessarily a problem with untimed combat. One of my
> >pet criteria is that any game which can be usefully automated has
> >demonstrated the failure of its design.
Looking at what parts of your game players tend to automate is a great
way to judge which parts of your game are tedious.
> That counts out most of today's muds. Mine certainly. I am
> positive that
> all muds I've played can be successfully automated, at least
> to a certain
> extent. Wasn't there a Raph-law about that? Something like, "whatever
> design decision you do, people *will* find ways to automate
> playing." I'll
> have to look that up.
Eep, how many times are these laws gonna get cited? :)
Yes, it was a law. However, I think it's also a good goal to try to make
it impossible. A good design path might be "make it so that everything
automatable has drawbacks to doing it automatically". In UO a partially
successful method that tackled this problem was in the skill usage
system.
If you have read the original LegendMUD skill trees FAQ, it describes a
skill system whereby you can improve skills by merely using them, and it
includes an "autobalancer" mechanism, whereby the number of usages of a
skill mudwide is tracked in order to arrive at advancement rates for
each skill (each skill's advancement rate is figured off of a ratio of
usages of that skill to total skill tests in the mud). This is so that
skills used more frequently than others have correspondingly slower
advancement rates. It has the nice side effect that automating or
macroing a skill will not provide the dramatically faster advancement
that it could otherwise, since macroing tends to drive up the
URL: <A HREF="ftp://mud.sig.net/pub/Docs/skfaq.txt">ftp://mud.sig.net/pub/Docs/skfaq.txt</A>
You may notice some similarities to UO's system (as one would expect).
However, UO has a few key problems: one, there is no initial expenditure
of accrued points to begin practicing a skill (you can just start
practicing anytime) and two, there is no skill tree in place (although
there are skill-web-like dependencies), so players can move immediately
to practicing the skills perceived as most useful. Lastly, some skills
lend themselves more to automation than others (informational skills are
a good example: doing armslore on an item over and over costs you
basically nothing), and there are also good reasons (because of other
factors in the advancement system) to macro these sorts of skills.
Adding some fairly simple base modifiers to this, such as only tallying
one "usage" for say, five minutes of actual usage, would preserve the
system and reduce the effects of this odd stuff.
Also, I just need to get skill trees into UO. :P
-Raph
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00043.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00045.html">[MUD-Dev] Re: Levels versus Skills, who uses them and when.</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00043.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00090.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00044"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00044"><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>[MUD-Dev] Re: MUD Design doc (long)</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00030" HREF="msg00030.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Mon 04 Jan 1999, 04:09 GMT
</LI>
<LI><strong><A NAME="00037" HREF="msg00037.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Mon 04 Jan 1999, 19:59 GMT
</LI>
<LI><strong><A NAME="00042" HREF="msg00042.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 05 Jan 1999, 03:15 GMT
<UL>
<LI><strong><A NAME="00043" HREF="msg00043.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Tue 05 Jan 1999, 04:32 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00044" HREF="msg00044.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Tue 05 Jan 1999, 17:54 GMT
</LI>
<LI><strong><A NAME="00090" HREF="msg00090.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Fri 08 Jan 1999, 20:16 GMT
<UL>
<LI><strong><A NAME="00095" HREF="msg00095.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Fri 08 Jan 1999, 22:15 GMT
<UL>
<LI><strong><A NAME="00100" HREF="msg00100.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Sat 09 Jan 1999, 21:28 GMT
<UL>
<LI><strong><A NAME="00102" HREF="msg00102.html">[MUD-Dev] Re: MUD Design doc (long)</A></strong>,
Nathan F Yospe <a href="mailto:yospe#uhunix1,its.Hawaii.Edu">yospe#uhunix1,its.Hawaii.Edu</a>, Sun 10 Jan 1999, 01:31 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</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>