[MUD-Dev] Better Combat

HRose hrose at tiscali.it
Wed Aug 18 12:13:50 CEST 2004


Raph Koster wrote:

> However, you seem to have arrived at a conclusion as to which of
> the above are in-game and which are out-of-game. I am not sure
> that the issue is quite that simple--I can read all of the above
> as "in game" or "out of game" depending on how we define "game."

Well, I agree with the rest of your message, so I quote just this.

Yes, I tried to define downtimes within the gameplay and downtimes
outside it. My whole critic is about that. In my opinion the best
way to make the distinction is right at the design stage. I already
said that single player games don't even have this problem because
the design NEVER goes out the gameplay. The problem comes up when we
involve the socialization as an external element (the "error" I
assume you are making is exactly about considering the socialization
as an external part). Parallel to the gameplay and not within it.

Let's make an example: travel.

Travel in Diablo 2 is managed in two ways. You can walk out the camp
or you can use teleporters. The first happens when there's gameplay
involved. The travel is part of the gameplay because you search
monsters, fight them, explore dungeons and so on. The movement is
gameplay. So it's in the game. The second way is about the use
teleporters. When you use them? When you need shortcuts to bypass
zones that you have already explored. It means that now the travel
is empty of the gameplay. You have killed already the monsters or
you are not anymore interested in their value. This is why the
designers have added a way to "jump" a part of a game where there's
no gameplay.

You see? Timesinks = empty part of a game. In a single player game
the gameplay is all. A "void" is of any use, so the timesinks (or
downtimes) are ditched.

Another example could be about a PvP game. In DAoC the players are
complaining because now they can port everywhere. This means that
you'll never be able to ambush someone else by patrolling a
zone. Because peoples use the teleporters and don't walk anymore on
the roads.

You see in this case? The timesink related to a long travel, in a
PvP context, becomes a STRONG gameplay element. Because the travel
gives depth to the geography. You can be attached when moved from a
place to another. The players could use strategies to attack a
village as a diversion while they plan a bigger attack far somewhere
else. IF the travel has a gameplay value the defenders won't be able
to port everywhere. And this, again, gives the travel a STRONG
gameplay value.

In both examples, single player and mmorpg, a "downtime" is allowed
or ditched based on the *gameplay*. When there's gameplay involved
the system remains. If there's zero gameplay the system is ditched
(teleporters in Diablo 2). This means, to go back at what you write,
that these cases happen "in game".

Instead, your "socialization requires downtimes" is *completely
different*. You *deliberately* open empty spaces into the gameplay,
so that the gameplay itelf is tossed away ("at the expense of fun")
to produce a space to encourage a different part. The other face of
the medal: The socialization. In your model the medal have two
faces. The game and the socialization. They exist on the same level
and "socialization requires downtimes" just explains that to allow a
face to exist you need to go against the other (a similar problem
happen with PvP hindering the PvE and vice versa). The downtimes (in
the gameplay) are required (compromise) to allow another part to
exist (socialization).

The downtimes *happen* in the gameplay. But AREN'T for the
gameplay. They are there because a designer needs them for an "out
of game" purpose: the socialization.

 From my point of view "in game" downtimes CANNOT be confused with
 those "out of game". It's way too obvious. Where the edge is
 blurred is when we go back To Jeff Freeman's message about
 "pacing". The downtimes regulating the "pace" always happen "in
 game". Even when the side purpose is to encourage
 socialization. Why? Because the downtime doesn't happen at the
 expense of the gameplay, but it's coordinated with it. Pacing is an
 important part of the gameplay, not outside it.

This is why a type of travel that has no role in the gameplay and is
in the game just to force the player to chat is a timesink/downtime
"out of game". In SWG this happens for the shuttles, this happens
for the "wounds" and it even happens in the relationships between
the professions. Because the interdependences are ALL "out of game"
to excuse the two face of the medal together (gameplay /
socialization). Like using the image designers to change the
statistics of the characters.

It is your "socialization requires downtimes" to produce an "out of
game" downtime. And just because you have a model where the
socialization exists aside the gameplay and not within it. This is
the whole center of the issue, the beginning of what I define "the
error".

>>  The firsts are excused and indispensable, the seconds are broken
>>  design to achieve artificially a different, external purpose
>>  from the game itself.

> Now you're making assumptions about what the "purpose of the game"
> itself is. You also seem to be using "artificial" pejoratively
> here, without justifying it (it may well be justified, but without
> clarification, it's a bit hard to tell when a mechanic is
> "artificial" and when it is "organic."

Here I borrow from a long thread from Corpnews. "Organic" in my
definition is when the "means" is the same of the "end".

The classes interdependencies are something I criticized and an
example of this. Peoples aren't really cooperating to achieve a
communal goal. They have only personal goals. These goals are
gameplay-related. To achieve them you involve gameplay but you need
also to involve the socialization. This is an example of not
organic: the goal (end) is personal and gameplay-related, the
process (means) is communal and social-related.

Means and end are different. So not organic.

What I said about the "purpose of the game" was just about the split
between gameplay/socialization. "Socialization requires downtimes"
means that the gameplay must be sacrificed for the socialization. So
it underlines the fact the one overlaps the other, like two faces of
a medal.

What I think is that the socialization shouldn't be discarded as
something not useful (all the discussions about the players
retention). But just be brought back inside the gameplay. Giving the
socialization a purpose into the gameplay. As in-game socialization
and not Out Of Character socialization.

What I wrote about breaking the "third wall" was about the model. If
you give importance to the socialization outside the gameplay you
break the third wall. If the socialization is brought back into the
gameplay, instead, the third wall isn't broken anymore.

I tried really hard to be understandable, so the message is long. At
least hoping that if we agree or disagree it will be still after
understanding what we say.

-HRose / Abalieno
_______________________________________________
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