[MUD-Dev] Re: CGDC, a summary
Mike Sellers
mike at bignetwork.com
Fri May 15 08:24:11 CEST 1998
At 04:30 PM 5/14/98 -0700, J C Lawrence wrote:
>On Sun, 10 May 1998 00:14:04 -0700 (PDT)=20
>Adam Wiggins<adam at angel.com> wrote:
> ...
>> His main theme was that conflict is essential, as it accelerates the
>> bonds between those involved, and since on-line communities have so
>> much less time availible to them (since most people play for a small
>> fraction of their total real-life time), this acceleration is
>> necessary to form meaningful bonds in a reasonable amount of time.
>
>Good stuff, tho I'd put a different mechanic underneath it. The
>essence is not combat, but problem solving. Combat merely allows a
>particularly simple and easily understood set of problem mechanics.
>Consider:
>
> A) Bubba goes about and gathers a group of players to go off and see
>if they can finally kill the Red Dragon. After a bloody and vicious
>fight, with great injury and some points dealt to all, the dragon
>finally dies.
>
> B) Bubba gets a team of people together to attempt to solve Fortress
>Fract. People need to push stones in order, ring bells together and
>otherwise actively causally cooperate in order to do this. After some=20
>time, you all figure out how to solve Fortress Fract, and finally
>return Princess Julia to King Mandel. Much stature and points are
>awarded by the final solution.
>
>Which builds the better community spirit? Why? Does it really, or is
>it just that the mechanics and model underlieing the combat risks and
>rewards of #A are just so much more obvious and familiar?
Actually, I think that there is an essential difference here. Both of
these are good and useful in some proportion, but there is considerably
less tension and resolution created by the second example, and this seems
to be a necessary ingredient to creating a bond between people. That is,
given two similar events (as above), the one that is the more threatening
or in some way creates more of a basal tension, creates a stronger shared
experience. This is true to the extent that a game like Doom or Quake can
create a sense of shared experience faster and easier than, say, a
multi-player Myst variant. I'm by no means trying to say this makes a game
like Quake *better*, but it does do a better job of pulling on those
sub-rational strings in our minds that engender a feeling of shared
experience with others. =20
Of course, most people don't like or quickly grow tired of a game like
Quake that has nothing _but_ basal tension, which is where examples like
solving Fortress Fract come into play: for people who are already building
a shared identity (party, group, guild, clan, etc.), other types of
experiences like this reinforce and broaden the sense of shared experience.
But I do not believe you can rely on essentially no-risk scenarios like
this to bring people together quickly in the first place. =20
>> There were a few folks from TEN, Mpath, Asharon's Call, the guy from
>> Avalon, several from Kesmai, and a whole host of startups looking to
>> break into 'massively' (this seems to be a key buzzword now)
>> multiplayer gaming.
>
>Which guy from Avalon?
Pretty sure this was Daniel James. I think he was the only one from Avalon
there. =20
There were a *bunch* of hopefuls in the MMPOG space at CGDC -- a
disquieting number. I see that Rubies of Eventide has somehow survived to
get to beta, for example. I expected to see a big shake out in this space
this year, as I thought we'd have Everquest and Asheron's Call up against
UO in the marketplace. Looks like we need to wait a little longer for that
to happen... but next year at CGDC I expect to hear even more tales of woe
about efforts that started and failed (did anyone else go to Steve
Meretsky's "Rise and Fall of Boffo Games" talk?).
--
Mike Sellers=A0=A0=A0=A0=A0=A0 Chief Creative Officer=A0=A0=A0=A0=A0=A0 The=
Big Network
mike at bignetwork.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<http://www.bignetwork.com/>http://www.bignetwork.com
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Fun=A0=A0 Is=A0=A0 Good =20
--
MUD-Dev: Advancing an unrealised future.
More information about the mud-dev-archive
mailing list