[MUD-Dev] MMORPGs & MUDs

Dave Rickey daver at mythicentertainment.com
Sat Jan 12 13:29:58 CET 2002


From: "Michael Tresca" <talien at toast.net>
> Freeman, Jeff posted on Thursday, January 03, 2002 7:13 PM

>> What constitutes "long term" to you?

>> Creating social groups, discouraging griefers and rewarding
>> non-griefers all seem to me to be the same thing - carrot and
>> stick of the same pursuit, anyway, the purpose of which is to
>> foster communities to develop in game: MMO's try *very* hard to
>> do these things.  IMO, The social groups are key to retention.
>> Retention is The Name of The Game.

> Is it?  Or is it to get new players and not worry about the ones
> that are already playing?

Trust me, it's all about retention.  It costs money to get a new
player (advertising, plus it's the new players that need the most
customer support), while one who has been playing a long time costs
you nothing but bandwidth.

>> I think EQ does a wonderful job of creating social groups.  Not
>> as good a job of then tying that group to the world, but I think
>> MMO design, in general, is making a lot of progress on that
>> front.

> This would be what I mean by long term.  I've seen clans more
> detailed and have more depth than the games those clans play on.
> To me, any social aspect of a game should be contained within the
> game.  When that isn't being served, players will do it on their
> own.

And do it better than you can.

> This goes back to having a chat line (ICQ, AIM) within the game,
> as well as the ability to create social groups.  Players do it
> ANYWAY.  It's not a secret.  No MMORPG should be without those
> basic social supports that players create on their own.  By
> keeping it in the game, it keeps the social group online, which is
> of course part of retention.

DAoC has chat support, including special channels for Guilds.  I
agree that more closely binding the social structures into the game
is a good idea, but my reasons are nefarious: The more closely bound
the social structure is to the game, the less portable it is.
However, the community that is formed is independant of the game
structure by nature, and if you bind it to the game you have to bind
it in the form it would have taken *anyway*.  Dictate what form it
should take, and communities that can't sustain that form simply
won't exist.

>> One of AC's core systems was designed to foster the creation of
>> social groups.  I don't know how well it worked in practice, but
>> I know the developers thought that important enough to make it a
>> key component of their game.

> Ah yes, the fabled pyramid game.  I won't go into here because I
> haven't personally experienced it.  It does foster social groups,
> so in the context of the discussion, I agree.

Actually, I would point to AC's Allegiance system as an example of
what *not* to do.  By trying to impose a particular form on the
community, it actually stunted the natural community growth and
weakened the social groupings.

>> I agree, to a point.  I think the systems in place have an awful
>> lot to do with what tone the players set for the game.  Game
>> systems that force the players to compete, vs. game systems that
>> force the players to cooperate, vs. game systems that don't
>> really do either one, result in three distinctly different tones.

> Yes.  I believe MMORPGs set the tone of the game.  If it's a hand
> off setting with a level-based system, which by its nature
> generates competition (in effect, trying to be higher level than
> anyone else) or if it allows PK (directly conflict between
> players), these settings discourage social groups as a cooperative
> effort.  More likely, it turns into "soloers" trying to get ahead.

We could write a book on this point alone.  What it comes down to is
that if group activities are more efficient means of accomplishing
the goals, groups form.  The classic Tank/Nuker/Healer dependance
triad is the simplest form of this.

> However, I believe a lot of MMORPGs were not designed with any
> particular philosophy in mind (I imagine this changed with DAoC,
> though). That is, there's the general assumption that players will
> just "work it out."  They won't work it out.  A stable social
> system doesn't just start on a new game, it has to be cultivated
> first, then the social supporters reinforce the positive behavior
> and pass it on to newcomers, even as older players leave.  This
> ensures a more stable social environment.  Throw in a million
> people, give them all virtual bodies they can toss away at a
> moment's notice, and a point system for them to accumulate power
> by killing things...well now you're just asking for trouble.

Okay, major conceptual break here.  You see, players *will* just
"work it out", what they will work out depends on the challenge that
is presented to them.  Social grouping is an emergent phenomenon,
each individual in the grouping is not participating in the social
grouping because he likes the other people in the grouping, he's
participating because he has some goal he is pursuing that he needs
the other people to achieve.  He may actively dislike the other
members (as in some EQ "UberGuilds").

In fact, you *need* to let the players just work it out, they'll
find a better solution than you could.

>>> Flashy graphics, exciting gameplay, cool effects -- that draw
>>> players.  Viable social communities keeps them there.

>> I don't know of any designers that believe otherwise.

> Believe?  I'm sure it's easy enough to pay lip service to the
> idea.  It's a whole 'nother thing to recognize that cultivating
> viable social communities will require PEOPLE -- and thus money --
> to create.  Social communities cannot merely be coded into the
> system.

Nyet, nein, no, unh-uh.  Social communities form as a response to
the challenges the developers code into the system, and the goals
that players find to pursue within the system.  They cannot be
formed in a vacuum with neat slots and heirarchies.

--Dave Rickey


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list