<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Laws of Online World Design (was: realism) -->
<!--X-From-R13: "Ybfgre, Dncu" <exbfgreNbevtva.rn.pbz> -->
<!--X-Date: Thu, 10 Jun 1999 07:46:01 -0700 -->
<!--X-Message-Id: 11A17AA2B9EAD111BCEA00A0C9B417930210C3F2#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] Laws of Online World Design (was: realism)</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="msg00690.html">Previous</a>
| <a href="msg00692.html">Next</a>
]
Thread:
[ <a href="msg00703.html">Previous</a>
| <a href="msg00677.html">Next</a>
]
Index:
[ <A HREF="author.html#00691">Author</A>
| <A HREF="#00691">Date</A>
| <A HREF="thread.html#00691">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Laws of Online World Design (was: realism)</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] Laws of Online World Design (was: realism)</LI>
<LI><em>From</em>: "Koster, Raph" <<A HREF="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</A>></LI>
<LI><em>Date</em>: Thu, 10 Jun 1999 09:38:35 -0500</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#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>
> -----Original Message-----
> From: J C Lawrence [<A HREF="mailto:claw#varesearch,com">mailto:claw#varesearch,com</A>]
> Sent: Wednesday, June 09, 1999 10:56 PM
> To: mud-dev#kanga,nu
> Subject: Re: [MUD-Dev] realism
>
> Raphs' laws have a couple entries here.
>
> Raph, perhaps this would be a good time to just post the lot of them?
<A HREF="http://mud.sig.net/raph/gaming/laws.html">http://mud.sig.net/raph/gaming/laws.html</A>
--->start quote
The Laws of Online World Design
These are taken from both experience and from the writings of others. Most
are the sort of "Duh" things that many who have done this sort of game
design take for granted, but others may be less intuitive. Many of the laws
here were actually stated as such by others, and not by me.
A Caveat
Ola's Law About Laws
Any general law about virtual worlds should be read as a challenge rather
than as a guideline. You'll learn more from attacking it than from accepting
it.
Design Rules
The secrets to a really long-lived, goal-oriented, online game of wide
appeal
have multiple paths of advancement (individual features are nice, but making
them ladders is better)
make it easy to switch between paths of advancement (ideally, without having
to start over)
make sure the milestones in the path of advancement are clear and visible
and significant (having 600 meaningless milestones doesn't help)
ideally, make your game not have a sense of running out of significant
milestones (try to make your ladder not feel finite)
Modes of expression
You're trying to provide as many modes of expression as possible in your
online world. Character classes are just modes of expression, after all.
Persistence means it never goes away
Once you open your online world, expect to keep your team on it
indefinitely. Some of these games have never closed. And closing one
prematurely may result in losing the faith of your customers, damaging the
prospects for other games in the same genre.
Macroing, botting, and automation
No matter what you do, someone is going to automate the process of playing
your world.
Corollary:
Looking at what parts of your game players tend to automate is a good way to
determine which parts of the game are tedious and/or not fun.
Game systems
No matter what you do, players will decode every formula, statictic, and
algorithm in your world via experimentation.
It is always more rewarding to kill other players than to kill whatever the
game sets up as a target.
A given player of level x can slay multiple creatures of level y. Therefore,
killing a player of level x yields ny reward in purely in-game reward terms.
Players will therefore always be more rewarding in game terms than monsters
of comparable difficulty. However, there's also the fact that players will
be more challenging and exciting to fight than monsters no matter what you
do.
Never trust the client.
Never put anything on the client. The client is in the hands of the enemy.
Never ever ever forget this.
J. C. Lawrence's "do it everywhere" law
If you do it one place, you have to do it everywhere. Players like clever
things and will search them out. Once they find a clever thing they will
search for other similar or related clever things that seem to be implied by
what they found and will get pissed off if they don't find them.
Hyrup's "do it everywhere" Corollary
The more detailed you make the world, the more players will want to break
away from the classical molds.
Dr Cat's Stamp Collecting Dilemma
"Lots of people might like stamp collecting in your virtual world. But those
who do will never play with those who like other features. Should you have
stamp collecting in your world?" We know that there are a wide range of
features that people find enjoyable in online worlds. We also know that some
of these features are in conflict with one another. Given the above, we
don't yet know if it is possible to have a successful world that
incorporates all the features, or whether the design must choose to exclude
some of them in order to keep the players happy.
Koster's Law (Mike Sellers was actually the one to dub it thus)
The quality of roleplaying is inversely proportional to the number of people
playing.
Hyrup's Counter-observation
The higher the fee, the better the roleplayers. (And of course, the smaller
the playerbase.)
Enforcing roleplaying
A roleplay-mandated world is essentially going to have to be a fascist
state. Whether or not this accords with your goals in making such a world is
a decision you yourself will have to make.
Storytelling versus simulation
If you write a static story (or indeed include any static element) in your
game, everyone in the world will know how it ends in a matter of days.
Mathematically, it is not possible for a design team to create stories fast
enough to supply everyone playing. This is the traditional approach to this
sort of game nonetheless. You can try a sim-style game which doesn't supply
stories but instead supplies freedom to make them. This is a lot harder and
arguably has never been done successfully.
Players have higher expectations of the virtual world
The expectations are higher than of similar actions in the real world. For
example: players will expect all labor to result in profit; they will expect
life to be fair; they will expect to be protected from aggression before the
fact, and not just to seek redress after the fact; they will expect problems
to be resolved quickly; they will expect that their integrity will be
assumed to be beyond reproach; in other words, they will expect too much,
and you will not be able to supply it all. The trick is to manage the
expectations.
Online game economies are hard
A faucet->drain economy is one where you spawn new stuff, let it pool in the
"sink" that is the game, and then have a concomitant drain. Players will
hate having this drain, but if you do not enforce ongoing expenditures, you
will have Monty Haul syndrome, infinite accumulation of wealth, overall rise
in the "standard of living" and capabilities of the average player, and thus
unbalance in the game design and poor game longevity.
Ownership is key
You have to give players a sense of ownership in the game. This is what will
make them stay--it is a "barrier to departure." Social bonds are not enough,
because good social bonds extend outside the game. Instead, it is context.
If they can build their own buildings, build a character, own possessions,
hold down a job, feel a sense of responsibility to something that cannot be
removed from the game--then you have ownership.
If your game is narrow, it will fail
Your game design must be expansive. Even the coolest game mechanic becomes
tiresome after a time. You have to supply alternate ways of playing, or
alternate ways of experiencing the world. Otherwise, the players will go to
another world where they can have new experiences. This means new additions,
or better yet, completely different subgames embedded in the actual game.
Lambert's Laws:
As a virtual world's "realism" increases, the pool of possible character
actions increase.
The opportunities for exploitation and subversion are directly proportional
to the pool size of possible character actions.
A bored player is a potential and willing subversive.
Players will eventually find the shortest path to the cheese.
Featuritis
No matter how many new features you have or add, the players will always
want more.
Pleasing your Players
Despite your best intentions, any change will be looked upon as a bad change
to a large percentage of your players. Even those who forgot they asked for
it to begin with.
Hyrup's Loophole Law
If something can be abused, it will be.
Murphy's Law
Servers only crash and don't restart when you go out of town.
Dr Cat's Theorem
Attention is the currency of the future.
Dr Cat's Theorem as expressed by J C Lawrence
The basic medium of multiplayer games is communication.
Hanarra's Laws
Over time, your playerbase will come to be the group of people who most
enjoy the style of play that your world offers. The others will eventually
move to another game.
It is very hard to attract players of different gaming styles after the
playerbase has been established. Any changes to promote different styles of
play almost always conflict with the established desires of the current
playerbase.
The ultimate goal of a virtual world is to create a place where people of
all styles of play can contribute to the world in a manner that makes the
game more satisfying for everyone.
The new players who enter the world for the first time are the best critics
of it.
The opinions of those who leave are the hardest to obtain, but give the best
indication of what changes need to be made to reach that ultimate goal.
Elmqvist's Law
In an online game, players find it rewarding to save the world. They find it
more rewarding to save the world together, with lots of other people.
A corollary to Elmqvist's Law
In general, adding features to an online game that prevent people from
playing together is a bad idea.
A caveat to the corollary to Elmqvist's Law
The exception would be features that enhance the sense of identity of groups
of players, such as player languages.
Baron's Design Dichotomy
According to Jonathan Baron, there are two kinds of online games:
Achievement Oriented, and Cumulative Character. In the former, the players
who "win" do so because they they are the best at whatever the game offers.
Their glory is achieved by shaming other players. In the latter, anyone can
reach the pinnacle of achievement by mere persistence; the game is driven by
sheer unadulterated capitalism.
Online identity
We spend a lot of time making people able to have a very strong personal
identity in our worlds (letting them define themselves in great detail, down
to eye color). But identity is portable. How many of you have been playing
the same character in RPGs for 15 years, like me? You cannot count on a
sense of identity, of character building, to keep someone in your game.
In game calendars
It's nice to have an in-game calendar. But emotional resonances will never
accrue to in-game holidays. The only calendar that really matters is the
real world one. Don't worry about breaking fiction--online games are about
social interaction, not about fictional consistency.
Social Laws
Koster's Theorem
Virtual social bonds evolve from the fictional towards real social bonds. If
you have good community ties, they will be out-of-character ties, not
in-character ties. In other words, friendships will migrate right out of
your world into email, real-life gatherings, etc.
Baron's Theorem
Hate is good. This is because conflict drives the formation of social bonds
and thus of communities. It is an engine that brings players closer
together.
Baron's Law
Glory is the reason why people play online; shame is what keeps them from
playing online. Neither is possible without other people being present.
Mike Sellers' Hypothesis
"The more persistence a game tries to have; the longer it is set up to last;
the greater number (and broader variety) of people it tries to attract; and
in general the more immersive a game/world it set out to be--then the more
breadth and depth of human experience it needs to support to be successful
for more than say, 12-24 months. If you try to create a deeply immersive,
broadly appealing, long-lasting world that does not adequately provide for
human tendencies such as violence, acquisition, justice, family, community,
exploration, etc (and I would contend we are nowhere close to doing this),
you will see two results: first, individuals in the population will begin to
display a wide range of fairly predictable socially pathological behaviors
(including general malaise, complaining, excessive bullying and/or PKing,
harassment, territoriality, inappropriate aggression, and open rebellion
against those who run the game); and second, people will eventually vote
with their feet--but only after having passionately cast 'a pox on both your
houses.' In essence, if you set people up for an experience they deeply
crave (and mostly cannot find in real life) and then don't deliver, they
will become like spurned lovers--somebecome sullen and aggressive or
neurotic, and eventually almost all leave."
Schubert's Law of Player Expectations
A new player's expectations of a virtual world are driven by his
expectations of single-player games. In particular, he expects a narrow,
predictable plotline with well-defined quests and a carefully sculpted for
himself as the hero. He also expects no interference or disruption from
other players. These are difficult, and sometimes impossible, expectations
for a virtual world to actually meet.
Violence is inevitable
You're going to have violence done to people no matter what the facilities
for it in the game are. It may be combat system, stealing, blocking
entrances, trapping monsters,stealing kills to get experience, pestering,
harassment, verbal violence, or just rudeness.
Is it a game?
It's a SERVICE. Not a game. It's a WORLD. Not a game. It's a COMMUNITY. Not
a game. Anyone who says, "it's just a game" is missing the point.
Identity
You will NEVER have a solid unique identity for your problematic players.
They essentially have complete anonymity because of the Internet. Even
addresses, credit cards, and so on can be faked--and will be.
Jeff Kesselman's Theorem
A MUD universe is all about psychology. After all, there IS no physicality.
It's all psych and group dynamics.
Psychological disinhibition
People act like jerks more easily online, because anonymity is intoxicating.
It is easier to objectify other people and therefore to treat them badly.
The only way to combat this is to get them to empathize more with other
players.
Mass market facts
Disturbing for those used to smaller environments, but: administrative
problems increase EXPONENTIALLY instead of linearly, as your playerbase digs
deeper into the mass market. Traditional approaches tend to start to fail.
Your playerbase probably isn't ready or willing to police itself.
Anonymity and in-game admins
The in-game admin faces a bizarre problem. He is exercising power that the
ordinary virtual citizen cannot. And he is looked to in many ways to provide
a certain atmosphere and level of civility in the environment. Yet the fact
remains that no matter how scrupulously honest he is, no matter how just he
shows himself to be, no matter how committed to the welfare of the virtual
space he may prove himself, people will hate his guts. They will mistrust
him precisely because he has power, and they can never know him. There will
be false accusations galore, many insinuations of nefarious motives, and
former friends will turn against him. It may be that the old saying about
power and absolute power is just too ingrained in the psyche of most people;
whatever the reasons, there has never been an online game whose admins could
say with a straight face that all their players really trusted them (and by
the way, it gets worse once you take money!).
Community size
Ideal community size is no larger than 250. Past that, you really get
subcommunities.
Hans Henrik Staerfeldt's Law of Player/Admin Relations: The amount of
whining players do is positively proportional to how much you pamper them.
Many players whine if they see any kind of bonus in it for them. It will
simply be another way for them to achieve their goals. As an admin you hold
the key to many of the goals that they have concerning the virtual
environment you control. If you do not pamper the players and let them know
that whining will not help them, the whining will subside.
Hal Black's Elaboration
The more responsive an admin is to user feedback of a given type, the more
of that type the admin will get. Specifically, as an admin implements
features from user suggestions, the more ideas for features will be
submitted. Likewise, the more an admin coddles whiners, the more whining
will ensue.
J C Lawrence's "stating the obvious" law
The more people you get, the more versions of "what we're really doing"
you're going to get.
John Hanke's Law (cited by Mike Sellers)
In every aggregation of people online, there is an irreducible proportion of
... jerks (he used a different word :-)
Rewarding players
It is not possible to run a scenario or award player actions without other
players crying favoritism.
Rewards
The longer your game runs, the less often you get kudos for your efforts.
J C Lawrence on Utopias
Don't strive for perfection, strive for expressive fertility. You can't
create utopia, and if you did nobody would want to live there.
Who contributed (purposely or inadvertently!), sorted alphabetically:
Myself, of course.
Richard Bartle: along with Roy Trubshaw, developed the first MUD.
Jonathan Baron: producer & designer for Air Warrior.
Hal Black: And another MUD-Dev member!
Dr Cat: the man behind Dragonspires and Furcadia.
Niklas Elmqvist: another active MUD-Dev member.
Ola Frosheim Grostad: researcher into virtual spaces, MUD-Dev member.
Marion Griffith: leads the !Overlord Project.
Hanarra, aka Jason Wilson,: of Nightfall.
Darrin Hyrup: designer and/or programmer for Gemstone, Dragon's Gate,
Darkness Falls, and Magestorm.
Jeff Kesselman: helped run Dark Sun Online, and is developing DSO2.
Amy Jo Kim: consultant on online communities and web designer.
Jon A. Lambert: active MUD-Dev member.
J C Lawrence: moderator for the MUD-Dev mailing list.
Damion Schubert: a key designer for Meridian 59, Might & Magic Online, and
Ultima Online.
Mike Sellers: a prime mover behind Meridian 59.
Hans-Henrik Staerfeldt: one of the guys who wrote the original DikuMUD.
And all the members of the MUD-Dev list as well.
<--- end quote
_______________________________________________
MUD-Dev maillist - MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</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="msg00690.html">RE: [MUD-Dev] Gender and Mud Development</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00692.html">RE: [MUD-Dev] Re: MUD-Dev digest, Vol 1 #93 - 27 msgs</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00703.html">Re: [MUD-Dev] Gender and Mud Development (drifting off topic again)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00677.html">[MUD-Dev] Client-Server vs. Peer-to-Peer -- Implementing DIS on the Internet</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00691"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00691"><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] Game construction and a big mistake</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00707" HREF="msg00707.html">Re: [MUD-Dev] Game construction and a big mistake</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Thu 10 Jun 1999, 18:05 GMT
</LI>
<LI><strong><A NAME="00797" HREF="msg00797.html">Re: [MUD-Dev] Game construction and a big mistake</A></strong>,
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Sun 13 Jun 1999, 18:35 GMT
</LI>
<LI><strong><A NAME="00711" HREF="msg00711.html">RE: [MUD-Dev] Game construction and a big mistake</A></strong>,
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 10 Jun 1999, 19:29 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00703" HREF="msg00703.html">Re: [MUD-Dev] Gender and Mud Development (drifting off topic again)</A></strong>,
S. Patrick Gallaty <a href="mailto:choke#sirius,com">choke#sirius,com</a>, Thu 10 Jun 1999, 16:14 GMT
<LI><strong><A NAME="00691" HREF="msg00691.html">[MUD-Dev] Laws of Online World Design (was: realism)</A></strong>,
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 10 Jun 1999, 14:46 GMT
<LI><strong><A NAME="00677" HREF="msg00677.html">[MUD-Dev] Client-Server vs. Peer-to-Peer -- Implementing DIS on the Internet</A></strong>,
claw <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Thu 10 Jun 1999, 05:40 GMT
<UL>
<LI><strong><A NAME="00686" HREF="msg00686.html">Re: [MUD-Dev] Client-Server vs. Peer-to-Peer -- Implementing DIS onthe Internet</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Thu 10 Jun 1999, 07:31 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00672" HREF="msg00672.html">[MUD-Dev] Re: MUD-Dev digest, Vol 1 #93 - 27 msgs</A></strong>,
Dr. Cat <a href="mailto:cat#oldzoom,bga.com">cat#oldzoom,bga.com</a>, Thu 10 Jun 1999, 04:48 GMT
<UL>
<LI><strong><A NAME="00701" HREF="msg00701.html">Re: [MUD-Dev] Re: MUD-Dev digest, Vol 1 #93 - 27 msgs</A></strong>,
Greg Miller <a href="mailto:gmiller#classic-games,com">gmiller#classic-games,com</a>, Thu 10 Jun 1999, 15:28 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>