[MUD-Dev] On socialization and convenience
Freeman
Freeman
Mon Jun 18 07:40:57 CEST 2001
> From: Koster, Raph [mailto:rkoster at verant.com]
> Yay, on this one I get to smack down someone who works for me. ;)
> *poke Jeff*
Oh lucky me. :P
"Semantic disconnect" best describes this. I agree with the
conclusion, but you lose me all along the way.
> In a level rat race design, you have a player-directed pace, and
> ALSO an enforced activity schedule determined by the need for
> stats to regenerate. It's loosely enforced, since there's usually
> ways to accelerate the process. While within the encounter
> itself, it's designed to be relatively brief; it too is also
> designed to overwhelm you (or for you to overwhelm the
> opponent). A given combat is not planned to last days like a chess
> match, but rather to be self-terminating in a much shorter period
> of time.
With regard to EQ here, you really lose me. I chat *during combat*,
and specifically look for opponents and build the right group so
that gameplay looks like this:
a. Find a mob.
b. Bring the mob to the group.
c. Kill it.
And repeat - with no "rest period" per se - no time where we're all
just sitting around waiting for mana or whatever. The Casters
meditate during combat and while I'm pulling a mob.
We chat and socialize in step 'c' there. I *can't* chat while I'm
pulling a mob, because I need the keyboard to move (but pulling a
mob takes mere seconds, so that's not all that big a deal).
For people using gamevoice or the like, the chatting is non-stop
during all of the above.
> So I am defining "downtime" as the periods when a player is on
> that cycle and is not in the combat.
Right, and since I tend to socialize while in combat, this is where
you're losing me.
> Given that mechanically speaking, you're probably not typing while
> you are hitting keys to get things to happen (such as striking
> blows) I would guess that a lot then depends on the granularity of
> your perception of downtime.
Well, there is the point that combat in EQ consists of pressing the
'A' button and then waiting for your opponent to die. Every few
seconds I might tap 'KICK', but apart from that, there's more
opportunity to chat in combat than there is while, say, travelling.
Most of the socialization I did in UO was while chopping trees and
carving bows. Walking from tree to tree, hitting the "carve" button
(a macro setup to stand there a while and carve all the wood), and
chatting willy-nilly all the while (generally not chatting while
carving, even though that was the "downtime", because the spam
prevented me from communicating during that time).
Walking back to town to sell the bows was a big chunk of downtime,
but again I couldn't socialize while doing that - we were on the
move.
> If you're walking from one close spawn to another, then that's a
> form of downtime.
Right, and we don't talk then. No socializing while running from
one close spawn to another. We socialize once we get there and
start killing the critters. Talking while moving is hard, and all
that.
> A zero-downtime game would be like an arcade shoot-em-up game (and
> even they pause when you clear a wave).
I tend to play EQ like an arcade shoot-em-up game. :P
> In a GoP environment, players who are engaging in the activity are
> going to want to devote their full mental faculties to the
> activity itself (in fact, that's how they get those endorphin
> highs, entering quasi-meditative states while engaging in the
> activity). They're not going to chat during that time; if they
> don, they won't be all that successful at the activity unless they
> are expert enough players that they can time-slice the activity so
> tightly that the space between one blow and another is perceived
> as downtime by them. (And this is pretty common, and a lot depends
> on the pace and nature of the activity).
I never thought of myself as being THAT much of a GoP player.
> For the layout described to work to that purpose, it's evident
> that SOME of the tasks the people had must have been lower
> priority than "sniff other mice's butt" or else there would have
> been zero interaction even in the courtyard area. Or perhaps some
> of the tasks were higher priority but had that sort of enforced
> downtime (I can easily see this layout working if every Xerox
> machine in the entire company were located in the counrtyard, for
> example).
And now we're back in agreement. Bring people together to achieve
some goal in the same space, and they may hang out there and
socialize for a bit rather than rushing off as soon as the copier
spits out their copies.
>> People need the opportunity to come into contact with other
>> people. Crossroads are good. Forced downtime is baaaaaad.
> Opportunity is not enough; there must be coincident troughs in the
> graph. I rest my case. ;)
And I agree with that. I think "Downtime is required for
socialization" is maybe just not the best way to express this idea,
though.
It's not *just* downtime. It's opportunity to communicate (nothing
prevents us from communicating - no carving spam or the fact that
you need your keyboard for something else at the moment, etc.),
shared-location, shared-purpose ("I want to repair armor. You have
broken armor. Let's chat." - or even "I'm killing rats. You're
killing rats. Let's chat.").
i.e. Two guys in the sewer killing rats will socialize while they
are killing rats. When one of them gets tired and needs to rest, he
pops over to the rest area and sits on his butt, waiting for hp's.
They socialized while they were killing rats, and not while they
were experiencing the joys of downtime. Quite possibly, they
socialize while they are killing rats *and* while they are waiting
to recover hps. Either way, there's a disconnect between downtime
and socialization.
To simply say that socialization requires downtime strikes me as a
gross over-simplification. It doesn't seem to me that the downtime
is the reason people are socializing. Coincident troughs, maybe.
And possibly coincident peaks as well.
_______________________________________________
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