<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] characters per account -->
<!--X-From-R13: Bnhy Epujnam - Sagrecevfr Ereivprf <Bnhy.EpujnamNrnfg.fha.pbz> -->
<!--X-Date: Mon, 10 Apr 2000 14:45:24 -0700 -->
<!--X-Message-Id: 200004101748.NAA01932#hutch,East.Sun.COM -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] characters per account</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:Paul.Schwanz#east,sun.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="msg00122.html">Previous</a>
| <a href="msg00126.html">Next</a>
]
Thread:
[ <a href="msg00094.html">Previous</a>
| <a href="msg00128.html">Next</a>
]
Index:
[ <A HREF="author.html#00125">Author</A>
| <A HREF="#00125">Date</A>
| <A HREF="thread.html#00125">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] characters per account</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></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] characters per account</LI>
<LI><em>From</em>: Paul Schwanz - Enterprise Services <<A HREF="mailto:Paul.Schwanz#east,sun.com">Paul.Schwanz#east,sun.com</A>></LI>
<LI><em>Date</em>: Mon, 10 Apr 2000 13:47:44 -0400 (EDT)</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>
Raph's suggestions for increasing social interaction in a multiplay
environment:
> - allow as many characters as there are genders in your game and force each
> slot to be of each gender.
> - allow as many characters as there are races in your game, each slot
locked
> to a race.
> - allow as many characters as there are classes in your game, each slot
> locked to a class.
> - allow another character only once the first has moved beyond whatever
> point on your advancement ladder that makes it pointless to associate with
> newbies: eg, each slot locked to a level range.
>
> All of these are designed to push n to the theoretical maximum of x.
Of these, I think the last is the most interesting. An intuitive way to work
this restriction into an MMORPG would be to implement families and children.
By the time a child "matures" to the point that it becomes playable, the
original character should be well beyond the newbie range. I think that
there are _many_ good role-playing and design issues that could be addressed
by families. I posted on this issue at Gamasutra. It's a rather simplistic
treatment of the issues, but I'll copy and paste it here for those who may be
interested.
--------------------------------------------------------------------
Inheritance: Saving a game in an MMORPG
The need for a dangerous world in order to promote
community in MMORPGs has been discussed at
some length. When gamers view themselves as part
of a society which faces significant challenges from
the outside world, they will tend to band together,
relegating the typical infighting to a secondary
concern. However, the solution of making an
MMORPG dangerous brings with it some
interesting challenges.
In the single player RPG (or even co-op
multiplayer) we see two things typically used to help
make a dangerous world manageable for the gamer.
They are (1) territory and (2) saved games.
I've talked about territory elsewhere, but let me
briefly summarize the idea here as well. Typically,
single player RPGs will have recognizable
territories which will be home to various critters
designed to challenge a certain level of character. If
I stumble into a territory which is way over my
head, I make a mental note to avoid this territory
until I am sufficiently skilled to handle the
challenges presented by it. Eventually, however, I
will enter this territory because I know that
territories with more danger usually give more
reward. In this way, the designer has allowed me to
select my own level of risk vs. reward so that I can
avoid frustration. But in MMORPGs (with the
exception of those which implement PvP flags), the
greatest challenge will be presented by player
characters who for some (hopefully in-game)
reason feel a certain level of animosity toward my
character. Elsewhere, I've presented some ideas
about how the designer of an MMORPG can use
this same concept of territory to help gamers select
a level of risk vs. reward with which they are
comfortable.
The second method for allowing the gamer to
manage his character in a dangerous world is to
give the gamer the ability to save a game. In an
MMORPG, for obvious reasons, it is not practical to
implement a save game capability. There is no way
to get a persistent game world back in the exact
same situation that it was in when a gamer chose to
save it without rolling back that same world for all
of the other players. So, instead of saving the entire
game world, designers basically come up with a way
to simply save the gamer's character. The standard
method for accomplishing this in an MMORPG is
to implement some form of resurrection. For me,
there are two problems with this approach.
The first problem is really a question of balance.
Resurrection can undermine the very design
concept being used to promote community. It can
take too much of the danger out of a dangerous
world. In order to prevent this to some extent, many
games have implemented seemingly arbitrary and
punitive consequences for those characters that are
"killed." They lose a certain number of items,
perhaps some skills, etc. In the end, it might appear
that their character has suffered more from the
game's ("stupid") design than from the player
killer.
My second objection is more a question of taste. I
suppose that I should be straightforward here, so let
me just come out and say that I despise the way
resurrection is treated. I'm not completely sure why,
but it just seems rather hokey to see what appears to
be a person (even a magical one) dying and being
rejuvenated on a regular basis. While I love fantasy
and magic, for some reason I have a hard time
stretching my imagination to this point. The world
just looses some of its veracity for me. Among the
fantasy novels which I've read and loved, I can't
recall any that treat resurrection with this kind of
complacency. Even in fantasy literature, I seem to
need my resurrections to be at least novel if not
nonexistent. It just seems like too cheap a plot twist,
too convenient, too limitless. When I walk around
in some MMORPGs, I cannot help but ask,
"Whence the headstones in yon graveyard?" Why
didn't those poor souls just resurrect themselves as I
do periodically?
The permanent death of a character can bring to a
world heroes who've taken the ultimate risk,
monuments for such heroes who were loved and
lost, eulogies, funerals, and revenge. Such themes,
both noble and ignoble, can bring a world to life.
But permanent death takes from the gamer a very
important method for managing his game in a
dangerous world. He is now not able to save his
game or character in order to avoid the frustration
brought on by misfortune.
Enter inheritance.
Here is the concept in a nutshell. A character's
children are his (or her) saved games. Not only does
this do away with rampant and hokey resurrections,
it can also bring some interesting and useful
concepts to our MMORPG. Consider some of the
following:
* Children inherit most of their parent's
possessions. All your work is not lost. You don't
have to start over completely. (But watch out for
that hefty inheritance tax.) This becomes the
method for managing your character in a
dangerous world. (As an aside, although some
powerful items will be inherited, "twinking" will not
be easy since a character's skill must be
comparable to the power of the item in order to use
the item effectively.)
* Children must mature before they are playable.
During this maturing period, it would be wise for
the gamer to play conservatively, since their "saved
game" is not yet ready. In other words, this could be
used as a realistic method for helping to restrict
"throw-away" characters.
* Children retain most of the "reputation" of their
parents. While you can always start a brand new
character, if you want to inherit the goods, you must
inherit the reputation as well. This too can be used
to restrict "throw-away" characters. If you get
wealthy by preying on others, upon your death, you
must choose between the wealth or a clean slate.
You cannot have both.
* Children are not invulnerable to death. This
provides a new impetus for protecting your home
land from attack. Community is strengthened as
characters band together to protect their families.
Killing a child is the most heinous of crimes in all
societies and cultures, and should not be common in
our game design, but its possibility can provide
depth to the game world.
* Children can go to trade school. You have the
opportunity to develop skills in your next character
by sending your child to different trade schools. (Of
course, college is not inexpensive.)
* Families can have more than one child. A
character can marry either an NPC or another PC.
When two PCs marry, they must designate which
children (saved games) will be under the control of
which PC. It will also be possible to take different
children along different paths of study and training
so that you can have a number of different possible
characters to play if you do have the misfortune of
dying. Also, control of a mature child (which will
be an NPC or perhaps a scripted player character)
can be given to another gamer so that that gamer
becomes a member of your family. This will
promote an even stronger sense of community.
* Children can avenge the death of their parent (or
the death of a brother or sister). To promote this
concept, a game designer could even implement
some way to encourage or reward the character
who avenges the death of his loved ones. Given the
current level of emotion surrounding the issue of
player killing, this probably wouldn't be necessary,
but it is a consideration. In addition, a child could
buy a monument or pay a bard to write a poem to
remember a loved one.
* Children could allow for realistic aging on the
part of all characters. This might be a more
controversial implementation. Hard-core role
players would probably be quick to support the idea,
but others might not like the idea of the eventual
deterioration of powerful, but aged characters.
* Children will cost money. Not only must you
provide some kind of sustenance for yourself, each
child will be a drain on your resources. There could
also be a natural in-game gestation period to
control the number of births. (But it would
probably not be a good idea to subject PC females to
the actual real-life restrictions of pregnancy.)
I think that MMORPGs could use a few more tykes
running around and a lot fewer ghosts. Also, as I've
outlined, I think that children can provide for much
richer gameplay opportunities. And certainly, they
are more realistic than an endless and steady
stream of resurrections, while at the same time,
they do not take the ability to manage a character
completely out of a gamer's hands. Through
children, a gamer can still save his game in an
MMORPG.
<A HREF="http://www.gamasutra.com/cgi-bin/ice/connection.pl?x-a=v&x-id=182217">http://www.gamasutra.com/cgi-bin/ice/connection.pl?x-a=v&x-id=182217</A>
------------------------------------------------------
> > The _currencies_ of an MMORPG are health, wealth, information, and power.
>
> Time, time, time, and time, to translate. :) Jonathan Baron calls these
> games "cumulative character" games because the persistent players ALWAYS
> wins. It's just a matter of how efficiently they go about acquiring all of
> the above.
Perhaps time is the _true_ "opposable thumb." Could we design a game in
which all players have the opportunity to be equally persistent? Mark Wells
(at the MEdev board) was a big proponent of character persistence as a design
feature. While not as radical in my support, I think that this design goal
has many potential benefits.
"Mules" are used because time in-game is too precious to be spent doing
menial or boring tasks, but the game is designed(*) so that these tasks are
either necessary or beneficial for "character development." It makes sense
that a fine piece of armor should take some time to design and create, but
how do we charge this time to the character without charging it to the
player? We might accomplish this by giving the player a choice to keep his
character in-game after he has logged off. The player could script(**)
_some_ of the in-game actions so that his character had _some_ of the same
opportunities available to a person logged on. The balancing concept would
be that scripted characters should also be subject to the same kinds of
dangers to which active characters are subject. While scripted characters
might not provide as much opportunity for social development as active
characters, do they provide less opportunity than NPCs? Perhaps we could
think of them as user programmed NPCs.
While I can't speak with the authority of experience regarding this, it seems
that such a design might put a much higher load on servers. However, I have
to think that the casual player may be more likely to participate in an
MMORPG where he doesn't ALWAYS lose to the persistent player.
--Phinehas
(*) I'm not arguing that this is a "bad" design. I was very surprised by the
number of posters at the MEdev board who insisted they only wanted to farm
pipeweed. :-)
(**) I use the term "script" without regard to the actual interface.
-----------------------------------------------------------------
Paul E. Schwanz, II
Email: paul.schwanz#east,sun.com
_______________________________________________
MUD-Dev mailing list
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="msg00122.html">RE: [MUD-Dev] Trouble Makers or Regular Citizens</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00126.html">Re: Re[2]: [MUD-Dev] Fw: 16K mud server competition !</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00094.html">Re: [MUD-Dev] characters per account</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00128.html">Re: [MUD-Dev] characters per account</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00125"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00125"><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] characters per account</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00055" HREF="msg00055.html">Re: [MUD-Dev] characters per account</A></strong>,
Darren Henderson <a href="mailto:darren#nighttide,net">darren#nighttide,net</a>, Wed 05 Apr 2000, 03:28 GMT
<UL>
<LI><strong><A NAME="00061" HREF="msg00061.html">Re: [MUD-Dev] characters per account</A></strong>,
adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Wed 05 Apr 2000, 18:22 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00086" HREF="msg00086.html">Re: [MUD-Dev] characters per account</A></strong>,
Paul Schwanz - Enterprise Services <a href="mailto:Paul.Schwanz#east,sun.com">Paul.Schwanz#east,sun.com</a>, Fri 07 Apr 2000, 20:37 GMT
<UL>
<LI><strong><A NAME="00094" HREF="msg00094.html">Re: [MUD-Dev] characters per account</A></strong>,
Kristen L. Koster <a href="mailto:koster#eden,com">koster#eden,com</a>, Sat 08 Apr 2000, 04:45 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00125" HREF="msg00125.html">Re: [MUD-Dev] characters per account</A></strong>,
Paul Schwanz - Enterprise Services <a href="mailto:Paul.Schwanz#east,sun.com">Paul.Schwanz#east,sun.com</a>, Mon 10 Apr 2000, 21:45 GMT
</LI>
<LI><strong><A NAME="00128" HREF="msg00128.html">Re: [MUD-Dev] characters per account</A></strong>,
Paul Schwanz - Enterprise Services <a href="mailto:Paul.Schwanz#east,sun.com">Paul.Schwanz#east,sun.com</a>, Mon 10 Apr 2000, 21:45 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00013" HREF="msg00013.html">[MUD-Dev] META: Topic List - 1999</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
<LI><strong><A NAME="00012" HREF="msg00012.html">[MUD-Dev] Fw: DESIGN: XML?</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
<LI><strong><A NAME="00011" HREF="msg00011.html">[MUD-Dev] Fw: 16K mud server competition !</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 03 Apr 2000, 03:36 GMT
</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>