March 2000
- Portal Matthew Mihaly
- randomly dropped connections Matthew Mihaly
- randomly dropped connections cg@ami-cg.GraySage.Edmonton.AB.CA
- randomly dropped connections Ben Greear
- randomly dropped connections J C Lawrence
- randomly dropped connections adam@treyarch.com
- randomly dropped connections Kevin Littlejohn
- Mud Network Setup Jon A. Lambert
- Mud Network Setup adam@treyarch.com
- Mud Network Setup J C Lawrence
- Mud Network Setup David Bennett
- Mud Network Setup Todd McKimmey
- Mud Network Setup David Bennett
- Mud Network Setup J C Lawrence
- Mud Network Setup adam@treyarch.com
- Mud Network Setup Jon A. Lambert
- Mud Network Setup J C Lawrence
- Mud Network Setup Emil Eifrem
- Mud Network Setup Dominic J. Eidson
- Mud Network Setup Emil Eifrem
- Mud Network Setup Eli Stevens {Grey}
- Mud Network Setup Todd McKimmey
- Mud Network Setup adam@treyarch.com
- Mud Network Setup cg@ami-cg.GraySage.Edmonton.AB.CA
- Mud Network Setup Steve Boleware
- Mud Network Setup Joe Andrieu
- Mud Network Setup John Bertoglio
- (fwd) MU* hiasb@cc.gatech.edstory? claw@kanga.nu
- (fwd) MU* hiasb@cc.gatech.edstory? cg@ami-cg.GraySage.Edmonton.AB.CA
- (fwd) MU* hiasb@cc.gatech.edstory? Ola Fosheim Grøstad
- (fwd) MU* hiasb@cc.gatech.edstory? adam@treyarch.com
- (fwd) MU* hiasb@cc.gatech.edstory? 송재경
- Processor Usage Christopher Kohnert
- Processor Usage J C Lawrence
- Processor Usage Dominic J. Eidson
- Processor Usage Ben Greear
- MUD-Dev digest, Vol 1 #298 - 11 msgs Dr. Cat
- MUD timeline Koster, Raph
- MUD timeline cg@ami-cg.GraySage.Edmonton.AB.CA
- MUD timeline Jon Leonard
- MUD timeline Richard Woolcock
- MUD timeline J C Lawrence
- MUD timeline Kristen L. Koster
- MUD timeline Kristen L. Koster
- MUD timeline Lovecraft
- MUD timeline Koster, Raph
- MUD timeline AR Schleicher
- MUD timeline Matthew Mihaly
- MUD timeline Matthew Mihaly
- MUD timeline Koster, Raph
- MUD timeline Dundee
- MUD timeline Darrin Hyrup
- MUD timeline Koster, Raph
- MUD timeline Moreland, John
- MUD timeline Darrin Hyrup
- MUD timeline jkerr@htech.withoutthisstuff.com
- MUD timeline __Deric___@yahoo.com
- MUD timeline Darrin Hyrup
- MUD timeline Erik Jarvi
- MUD timeline Travis Casey
- MUD timeline Jon A. Lambert
- MUD timeline Travis Casey
- MUD timeline Jon A. Lambert
- MUD timeline Travis Casey
- MUD timeline Bruce
- MUD timeline Daniel A. Koepke
- MUD timeline cg@ami-cg.GraySage.Edmonton.AB.CA
- MUD timeline Dr Richard A. Bartle
- MUD timeline Koster, Raph
- MUD timeline Hans-Henrik Staerfeldt
- MUD timeline Koster, Raph
- MUD timeline Hans-Henrik Staerfeldt
- MUD timeline Sellers, Michael
- MUD timeline Jon Whitehouse
- MUD timeline Derek Snider
- MUD timeline J C Lawrence
- MUD timeline Sellers, Michael
- MUD timeline Matthew Mihaly
- MUD timeline J C Lawrence
- MUD timeline Ryan Palacio
- Mud Timeline Darrell Michaud
- Mud Timeline Klimon, Ian
- Mud Timeline Matt Mihaly
- ADMIN: Ooops, damn... J C Lawrence
- FW: MUD timeline Daniel James
- MUD timeline F. Randall Farmer
- MUD-Dev digest, Vol 1 #298 - 11 msgs Koster, Raph
- Skotos Website Up Christopher Allen
- CGDC dinner J C Lawrence
- CGDC dinner Joe Andrieu
- CGDC dinner J C Lawrence
- CGDC dinner J C Lawrence
- CGDC dinner Joe Andrieu
- CGDC dinner Koster, Raph
- CGDC dinner Bruce
- CGDC dinner J C Lawrence
- CGDC dinner Derek Snider
- CGDC dinner Ryan Palacio
- CGDC dinner Koster, Raph
- CGDC dinner Sellers, Michael
- CGDC dinner Derek Snider
- CGDC dinner Joel Dillon
- CGDC dinner J C Lawrence
- CGDC dinner Emil Eifrem
- CGDC dinner Richard Ross
- CGDC dinner J C Lawrence
- CGDC dinner Wes Connell
- CGDC dinner Suess123@aol.com
- CGDC dinner Joel Dillon
- ADMIN: Posting delays J C Lawrence
- javascript Ola Fosheim Grøstad
- javascript cg@ami-cg.GraySage.Edmonton.AB.CA
- javascript Ola Fosheim Grøstad
- javascript Laurel Fan
- javascript Ola Fosheim Grøstad
- javascript Bruce
- javascript Ola Fosheim Grøstad
- javascript Bruce
- MUD-Dev digest, Vol 1 #302 - 6 msgs Dr. Cat
- Admin: Corrections, data loss, and interruptions in service. J C Lawrence
- Raph's collection of MUD design Laws Greg Underwood
- Raph's collection of MUD design Laws Wes Connell
- Raph's collection of MUD design Laws Kristen L. Koster
- Raph's collection of MUD design Laws Greg Underwood
- Raph's collection of MUD design Laws Caliban Tiresias Darklock
- Raph's collection of MUD design Laws David Bennett
- Raph's collection of MUD design Laws J C Lawrence
- (OT) Admin: Library memberships J C Lawrence
- Open Source Online Gaming Aaron Mitchell
- Open Source Online Gaming Koster, Raph
- Open Source Online Gaming Bryce Harrington
- Open Source Online Gaming Bruce
- Open Source Online Gaming J C Lawrence
- Open Source Online Gaming Bryce Harrington
- Open Source Online Gaming Ryan
- Open Source Online Gaming Erik Jarvi
- Open Source Online Gaming Derek Snider
- Open Source Online Gaming Aaron Mitchell
- GDC Dinner Matthew Mihaly
- GDC Dinner Justin Rogers
- ADMIN: looking for work? J C Lawrence
- [OT] Sound in games Erik Jarvi
- [OT] Sound in games Koster, Raph
- politics J C Lawrence
- Have openings Gary Whitten
- HTML as a MUD client . . . was javascript John Bertoglio
- ADMIN: Kanga.Nu will be moving (again) J C Lawrence
- ADMIN: Lost mail? J C Lawrence
- better usage through mechanics [from: CGDC dinner] Lovecraft
- better usage through mechanics [from: CGDC dinner] John Bertoglio
- better usage through mechanics [from: CGDC dinner] Joel Kelso
- better usage through mechanics [from: CGDC dinner] adam@treyarch.com
- better usage through mechanics [from: CGDC dinner] Ola Fosheim Grøstad
- Dynamic Load Balancing Kevin Scott London
- Open Source Environments (was: Open Source Online Gaming) scott guzman
- Open Source Environments (was: Open Source Online Gaming) Nathan F Yospe
- Fw: [RRE]MediaMOO birthday Celebration, March 20th 2000!!! Bruce
- Open Source Environments scott guzman
- MudDev FAQ part 1 Marian Griffith
- MudDev FAQ part 1 Todd McKimmey
- MudDev FAQ part 1 Marian Griffith
- MUD Dev FAQ part 1 Marian Griffith
- MudDev FAQ part II Marian Griffith
- Questions about the MudDev FAQ Marian Griffith
- Open Gaming? J C Lawrence
- Open Source Environments / MacOS X J C Lawrence
- Open Source Environments / MacOS X Chris Jacobson
- Star Wars gmud? Nathan F Yospe
- better usage through mechanics [from: CGDC dinner] J C Lawrence
- [CODE] unique items J. Coleman
- [CODE] unique items Draymoor
- [CODE] unique items cg@ami-cg.GraySage.Edmonton.AB.CA
- [CODE] unique items Matthew Mihaly
- [CODE] unique items Quzah
- [CODE] unique items J. Coleman
- [CODE] unique items Ben Greear
- [CODE] unique items Kevin Scott London
- [CODE] unique items Lord Ashon
- [CODE] unique items Marc Bowden
- [CODE] unique items J C Lawrence
- Kanga.Nu has a new IP J C Lawrence
- Licensing and Clauses Chris Jacobson
- The Meta list is now open and active. J C Lawrence
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Par Winzell
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really nec essary? Koster, Raph
- Object and class heirarchies -- are they really nec essary? Nathan F Yospe
- Object and class heirarchies -- are they really necessary? Draymoor
- Object and class heirarchies -- are they really necessary? scott guzman
- Object and class heirarchies -- are they really necessary? Chris Jones
- Object and class heirarchies -- are they really necessary? Dr Richard A. Bartle
- Object and class heirarchies -- are they really necessary? Lazarus
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? cg@ami-cg.GraySage.Edmonton.AB.CA
- Object and class heirarchies -- are they really necessary? Brandon J. Rickman
- Object and class heirarchies -- are they really necessary? Marian Griffith
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really nec essary? Brian Ashburn
- Object and class heirarchies -- are they really necessary? Par Winzell
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? adam@treyarch.com
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Matthew Mihaly
- Gamasutra: Online Justice Systems Draymoor
- Gamasutra: Online Justice Systems Vijay Weasel Prabhakar
- Gamasutra: Online Justice Systems J C Lawrence
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems adam@treyarch.com
- Gamasutra: Online Justice Systems Dundee
- Gamasutra: Online Justice Systems David Bennett
- Gamasutra: Online Justice Systems Wes Connell
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Fred Clift
- Gamasutra: Online Justice Systems Ola Fosheim Grøstad
- Gamasutra: Online Justice Systems Draymoor
- Gamasutra: Online Justice Systems Ananda Dawnsinger
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Todd McKimmey
- Gamasutra: Online Justice Systems AR Schleicher
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Wes Connell
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Ola Fosheim Grøstad
- (fwd) mud.design.ideas Nathan Fenenga Yospe
- Command interface for Coordinate based world WriterDL@aol.com
- Command interface for Coordinate based world Draymoor
- Command interface for Coordinate based world adam@treyarch.com
- Command interface for Coordinate based world Nathan F Yospe
- Command interface for Coordinate based world Vijay Weasel Prabhakar
- Command interface for Coordinate based world Jeremy Noetzelman
- Command interface for Coordinate based world Laurel Fan
- Command interface for Coordinate based world Lovecraft
- ADMIN: Moving house and posting delays J C Lawrence
- MUD-Dev digest, Vol 1 #18 - 17 msgs Dr. Cat
- Embedding C/C++ Draymoor
- Embedding C/C++ Justin Rogers
- Embedding C/C++ J C Lawrence
- multiplaying Tess Lowe
- multiplaying Lovecraft
- multiplaying Wes Connell
- Online Justice Systems scott guzman
- Online Justice Systems Matthew Mihaly
- Online Justice Systems J C Lawrence
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Wes Connell
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Wes Connell
- Trouble Makers or Regular Citizens Marc Bowden
- Trouble Makers or Regular Citizens adam@treyarch.com
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Rasdan
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Par Winzell
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Dan Shiovitz
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Chris Jones
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Dundee
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Fred Clift
- Trouble Makers or Regular Citizens Gunnar Kreitz
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Ananda Dawnsinger
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Kevin Scott London
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Marc Bowden
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Jon A. Lambert
- Trouble Makers or Regular Citizens adam@treyarch.com
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Jon A. Lambert
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Par Winzell
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Kristen L. Koster
- Trouble Makers or Regular Citizens Tess Lowe
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Tess Lowe
- Trouble Makers or Regular Citizens Ola Fosheim Grøstad
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Joe Andrieu
- Trouble Makers or Regular Citizens Chris Lloyd
- Trouble Makers or Regular Citizens David Bennett
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Chris Lloyd
- Trouble Makers or Regular Citizens Ola Fosheim Grøstad
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens Par Winzell
- Online Justice Systems (response to J C) J C Lawrence
- Online Justice Systems (response to J C) scott guzman
- Meta: Questions about the MudDev FAQ Jon A. Lambert
- RE:Troublemakers and their M.O. Aaron Leslie
- RE:Troublemakers and their M.O. Baldur Norddahl
- RE:Troublemakers and their M.O. Chris Jacobson
- RE:Troublemakers and their M.O. Lovecraft
- RE:Troublemakers and their M.O. Tess Lowe
- RE:Troublemakers and their M.O. Kevin Scott London
- RE:Troublemakers and their M.O. Sellers, Michael
- RE:Troublemakers and their M.O. Kevin Scott London
- Object and class hierarchies -- are they really necessary? Christopher Allen
- ScryMUD 2.0.11 released. Ben Greear
- ADMIN: Spam filters and being unsubscribed J C Lawrence
- World and History Creation Ling
- characters per account Matthew Mihaly
- characters per account F. Randall Farmer
- characters per account Jeff Freeman
- characters per account Sellers, Michael
- characters per account LexaH@aol.com
- characters per account Jeff Freeman
- characters per account Matthew Mihaly
- characters per account AR Schleicher
- characters per account Matthew Mihaly
- characters per account AR Schleicher
- characters per account John Bertoglio
- characters per account Sayeed
- characters per account Matthew Mihaly
- characters per account Sayeed
- characters per account Brian Green
- characters per account Timothy Dang
- characters per account F. Randall Farmer
- characters per account Paul Schwanz - Enterprise Services
- characters per account Kristen L. Koster
- characters per account Paul Schwanz - Enterprise Services
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.
http://www.gamasutra.com/cgi-bin/ice/connection.pl?x-a=v&x-id2217
------------------------------------------------------
> > 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
- characters per account Paul Schwanz - Enterprise Services
- characters per account Ola Fosheim Grøstad
- characters per account Timothy Dang
- characters per account Paul Schwanz - Enterprise Services
- characters per account Darren Henderson
- characters per account adam@treyarch.com
- characters per account Jon Lambert
- characters per account Darren Henderson
- characters per account J C Lawrence
- characters per account Zak Jarvis
- Richard Garriot's 'X' project Matthew Mihaly
- Richard Garriot's 'X' project Sellers, Michael
- Richard Garriot's 'X' project skeptack
- Richard Garriot's 'X' project skeptack
- Richard Garriot's 'X' project AR Schleicher
- Richard Garriot's 'X' project Jeff Freeman
- Richard Garriot's 'X' project Brian Green
- Debugging techniques adam@treyarch.com
- Lord British gone Geoffrey A. MacDougall