[MUD-Dev] Re: Affordances and social method (Was: Re: Wired Magazine...)
Adam Wiggins
adam at angel.com
Tue Jul 7 14:32:06 CEST 1998
On Tue, 7 Jul 1998, Marian Griffith wrote:
> On Mon 06 Jul, Till Eulenspiegel wrote:
> > I presume you mean conflict is not justification for combat.
> > My observations on this subject are that the venue of the fantasy worlds
> > that I create are medieval, heroic and violent. I expect players to be
> > able to settle their affairs with words, gestures and violence if need be.
> > Now, there is a broad line between violence and brutality. This is where
> > the argument should revolve in my opinion
> > ... how to prevent brutality, not violence.
>
> Actually no. I meant exactly what I wrote. You can not justify the inclusion
> of violence in a game by stating that this way players can handle their own
> conflicts (e.g. player killing or stealing). You can have other (valid) rea-
> sons to include violence (or combat) in a game, but justice can not be one,
> as it leads to a circular argument.
I'm not sure I agree. An example from my own experience that I think I
have mentioned here before:
The mud I was playing did not allow any PvP. Although it was impossible
to directly attack someone, there were still a lot of things you could do
to other players. If the admin caught you doing anything they considered
harmful to another player, you'd get frozen for a while, or if the offense
was bad enough, nuked.
A player came on the mud named Imadork. He or she did nothing but spam
the global channels. This wasn't a big deal for those with clients, but
those going through standard telnet (which, at the time, included me) were
at the mercy of Imadork's ranting.
So, a friend of mine walked over and cast 'silence' on him/her. Everyone
cheered and carried on playing.
Twenty minutes later, or so, a god logged on and saw that my friend's
character had made an offensive action against another player. He was
thrown in hell, and nothing that the other players could say disuaded the
god from lifting the punishment. "We can't make special cases," they
said, "Vigilante actions will not be tolerated, no matter how much
everyone may have disliked the person." Etc.
Who was right? Was my friend justified in casting silence? Does this
count as "violence" against another player? What if the spell had been
paralyze? What about sleep? Or blind? What if he had cast one of those
spells, and as a result of being paralyzed/blind/slept/whatever, an
aggressive mob had wandered up and been able to kill them?
IMO empowering players to control their destinies is most certainly a
reason to include whatever mechanisms are desired. Whether these take the
guise of physical violence or not is pretty irrelevant to me.
> > >I know and agree that it can not be ignored, but it does not need to be
> > >justified either. Combat, and especially players fighting others is the
> > >problem, not part of the solution. The discussion is how to separate it
> > >from the in-game role combat can play.
>
> > Violence does not need to hinder the enjoyment of other players.
>
> It frequently does. Now my idea of fun may differ from yours, but somehow I
> do not think many players enjoy having their new characters slaughtered by a
> player in a bad mood. Or their low level characters harassed in some ways by
> high level characters. Paranoia is not my idea of a fun game and I find no
> thrill in constant danger. I am fully aware that there are many players who
> do like such atmosphere in a game but I think it is wrong to consider it the
> natural state of a mud. And as Dr.Cat frequently tries to explain, there are
> other ways to handle conflicts that do not involve combat, and games without
> any combat at all can still be fun.
The reason combat is so often a focus is that games, in general, revolve
around conflict. (Remember, conflict is NOT the same thing as combat, and
combat is NOT the same thing as violence.) It's just that as time has
gone on, the games' representation of that conflict has gotten more
vicereal. In chess, the "combat" is the very sterile act of taking
someone else's piece. One could, if one desired, imagine that the two
knights were meeting on the field of battle, one killing the other. (ie,
battle chess) Or you could simply imagine them as abstract tokens which
can't occupy the same space on the game board, and when one moves into
another's space, the other token gets set aside. Moving forward a bit, we
see video games: Pac Man involved little abstract creatures made out of
pixels trying to "kill" each other, but again it wasn't too combat-like
due to the abstractness of the graphics. Moving forward more, video games
get better graphics and sound, and thus games like Double Dragon introduce
"real" violence: graphics of people beating each other up, accompanied by
semi-realistic sound effects of the blows landing. Move into modern times
and you've got the likes of Quake or Unreal, where players use massively
powered weapons to blow detailed characters into tiny chunks of red,
quivering flesh.
The thrust of the game is still the same as chess - to best your opponent.
Games have gotten more vicereal in an attempt to look more impressive
(fancy alpha channel effects on your weapon's shots, hyper-realistic gore
splatter sounds on the impact, etc) and make a stronger impact on the
players, but in essense it's still the same thing.
Now, of course, there is a whole other option for "fun" through computer
games, and that's interacting with other players. This can be integrated
as much or as little as the designer likes with the traditional style of
game. Furcadia would be a terrible game without other players to interact
with. Dr. Cat has chosen to integrate with traditional gameplay almost
not at all, except for the mechanics of entities existing in a shared game
world. Quake chooses to simply tack multiplayer onto existing gameplay,
resulting in something that's not too different from playing the
single-player version - your opponents are just smarter. Most muds fall
somewhere inbetween; they attempt to provide traditional gameplay
(conflict and challange) integrated completely with the new (at least, new
in terms of computer games) "fun" of interacting with other players.
So it seems that there are actually three issues here which really have
very little to do with one another. One is the inclusion of conflict and
challange in the game. Pac Man was 100% of this, and 0% of the other two.
Another in the inclusion of realistic violence, which can range from lions
killing and eating game animals, to people hitting each other with their
fists, to spaceships shooting their guns at one another. The only game I
can think of that is 100% in this category is that silly old Lemmings
take-off, "Lamers", where all you could do was choose your weapon of
choice and mow down as many of the Lamers as possibly in a spray of red
pixels. (Most games that include violence also include the traditional
elements of conflict and challange.) Finally, there's human interaction.
IRC, and for that matter this mailing list, are 100% of that and 0% of the
other two.
Arguing for a game with no violence is quite a bit different from arguing
for a game where the only "fun" is social interaction. It would be quite
easy (at least, design-wise) to take violence out of Quake and have it be
the same game.
> > It's my opinion that opposing players can provide a more interesting
> > threat than I can with AI monsters. My challenge is to tune the balances
> > so that the antisocial behaviour isn't the most rewarding behaviour.
> > This as we all know is one of the greatest challenges.
>
> Actually, if I were able to program a game, I would attempt to achieve enti-
> rely different goals. But that does not make your interests any less valid
> of course.
You sell yourself short, I think. I never thought I could learn to
program; I was always the creative type, and I figured I'd grow up to be
a writer or an artist or a composer. But I found that games interested me
on a creative level so much that I was able to train my mind to work in
the logical way needed to program. I still don't think of programming as
fun, just a way to achieve my ends - it's a tool for creative output,
nothing more.
> > >The strange thing then is that so few people, on this list only Dr.Cat
> > >that I know of, attempt to create a safer game environment, at the ex-
> > >pense of some freedom of the players. Or am I being overly pessimistic
> > >now?
>
> > Dr. Cat does the extreme. The rest of us probably have our head in our
> > hands when it comes to this issue if they have had the same success/
> > lack of success we have had in controlling 'problem' behaviour.
>
> I think that his remark to think about why everybody talks about 'leaving
> out combat' rather than 'including combat'. Combat in a game is not nece-
> sarily the natural state, it is just a matter of legacy from the days of
> Diku and before that all games focus on combat.
See the stuff above. The 'legacy' goes much further back than diku.
Games have always been about conflict, and the most obvious metaphor for
conflict is combat.
> > The perservering abusive player always seems to find a new and
> > annoying way to disrupt the game for other players through cheating,
> > 'pkilling', abusive interpersonal behaviour etc.
>
> I know, but like I said, it is a circular argument to include combat just
> so players can strike back.
Not really. There are two extremes: a world in which no entity can
affect, in any way, any other entity; and a world in which an entity can
affect any other entity any way they like. The former is pointless,
because each entity exists in their own universe, and the social aspect is
lost. The later is impractical because entities have wildly different
opinions about how they want to spend their time. So usually the choice
is to go somewhere inbetween - entities have control over themselves, and
can exert limited changes on their environment. But by being able to
exert changes on the environment, however small (for instance, the "say"
command), they can now affect other entities.
So it's up to the game designer to decide - where do I draw the line?
Chat systems give you commands to be able to communicate with other
entities. Early muds and BBS doors let you interact with non-sentient
parts of the game world in a limited way - taking and dropping objects,
going to different locations within the game etc.
The discusion is *not* about how to let players "strike back". It's about
what sorts of forces they can exert on the game world, and what sorts of
the forces the game world can exert back. Including something like
"health" for entities (implying, of course, that something happens when
they run out of it) is only a design choice. If it doesn't add anything
to the goals you are trying to achieve with your game, don't include it.
But don't expect that you can include it and get only the good effects.
Including the "say" command has many benefits, but it brings in the chance
for verbel harassment. By the same token, introducing character "death"
in whatever form can be beneficial (pretend "danger" in your game world
can be exciting and fun), but by the same token it's going to allow other
entities to invoke that upon each other. If danger is not something you
crave, don't include it.
And never forget: if it's possible for something to happen to an entity,
it will be possible for other entities to make it come about. Thus if
it's possible to take damage, it will be possible for other players to
cause you to take damage by direct course of action. And if it's possible
for you to die, at all, ever, in a game - then other players will be able
to cause your death.
> My personal gripe is that this way you are in
> fact confirming the abusive players that 'yes, the game focusses on combat
> and it is perfectly all right to attack, harass or otherwise mistreate the
> other players as long as you can get away with it'. Even if it is not what
> you want it is still the unconscious signal you are sending. Or like some-
> body else said (sorry but I forgot who) Buffy the Tailor should not *have*
> to become a berserking killing-machine just to protect her shop from ram-
> paging warbands and thiefs.
Okay, again - all we're doing here is specifying the way the players can
interact with the world. Here you imply that someone is running a shop.
That implies possesions (the goods created), money (or something else
exchanged for the goods), possession of a location (the shop itself), and
player skills (tailoring). That's a lot of stuff. Biffy the Goon can
now steal or ruin Buffy's goods, Buffy's money, and Buffy's shop.
At this point it might be wise to argue against including money. After
all, think of all the ills in our world due to it! Of course, players
will just barter with other things, so perhaps objects should be gotten
rid of altogether?
This, of course, sounds a bit on the extreme side, but it is still true.
If it is possible for an entity to control or possess something of value,
and it is also possible for that thing of value to be transfered to some
other player, then you *will* have goons who will take control of that
thing of value without the consent of the other player. All you can
control is the mechanisms; how valuable is the thing in question, and how
does the other player go about getting it? Moreover, even if the other
player can't get it, a true goon will take the attitude of "if I can't
have it, no one can" and will attempt to deny it to the other player.
(Ie, building a forge on the shop's doorstep, denying entry.)
> > In our statistics a remarkably small percentage of players accounts for
> > a gross majority of problems. We've seen more success from banning
> > problem people. This option works for us however because we are not
> > a pay-for system and have no implied service level guarantee.
> > Not a scalable solution, IMO.
>
> It is my firm belief that sooner or later the staff of a game must step in
> to control problems. On a free for all game that probably is much later of
> course but there too some player will find ways to become so disruptive to
> the game that strong actions must be taken. If a player decides to repeat-
> edly crash a game because of some perceived gripe that will cause staff ac-
> tion very quickly. And of course in a way the new pk-control system of uol
> is also a staff intervention to a rampaging pk problem on that game.
> Empowering players will not prevent such things from happening, it can only
> postpone them.
I think most of the folks here that are interested in free-form worlds
which grant players a large amount of freedom are looking at our own
universe. I suppose at this point you can argue whether or not there is
some true "admin" staring down at us from the sky; but with or without
such a being or being(s), we are fairly free to do as we like, and that
includes ending other people's life. Yet our society exists with most
people living the full length of their lives, and a large number of people
never confronting much danger from anything except for old age. It seems
reasonble to assume that we could create 'virtual' communities which exist
in a very similar state. Obviously this is easier said than done;
unfortunately one of the in-between steps to achieving this state is going
through the same childhood that humanity did - that of barbarism. At that
point it's just a question of whether the game designer considers going
through such a stage to be worthwhile in pursuit of the ultimate goal. I
for one find it very enlightening as both an independant observer, and a
player inside the system, to examine the roots of our society; much in the
same way that I find it interesting and worthwhile to go to a museum and
look at artifacts from our past. Sure, a horse-drawn carriage is pretty
pathetic compared to an airliner, but I still think it is intruiging to
examine such artifacts. The state of online communities today are a
similar artifact, only much more hands-on.
This, of course, is not the only kind of comminuty worth
creating/participating in. But by the same token we shouldn't throw it
away just because it's "not working". Examining our own past, I'd say
that it's working exactly as it should.
Adam
More information about the mud-dev-archive
mailing list