<!-- 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>