[MUD-Dev] Re: Remote client connection (J C Lawrence)

Travis Casey efindel at earthlink.net
Mon Jun 26 11:37:39 CEST 2000


Friday, June 23, 2000, 4:03:21 PM, adam at treyarch.com <adam at treyarch.com> wrote:
> On Fri, 23 Jun 2000, Dmitri Zagidulin wrote:
>> J C Lawrence wrote:

>> >I argue that one of the prime values in a MUD, and this is the thing
>> >which elevats it in various essential fashions, is that the player
>> >is continually confronted with the question, "What shall I do now?"
>> >and there is nothing and nobody to tell him that answer but him.
>> 
>> Both sides of the debate agree that we're mostly in the business of
>> _entertaining_ people (with some teaching/artistic expression/whatever on
>> the side). When and how are players the best entertained?
>> 
>> The "game" camp argues that:
[snip]

>> The "simulation" camp maintains:
[snip]

> Actually, I am becoming more and more aware that, at least in the mud world,
> there is a position squarely between these two that is just as 'popular',
> as it were, as the two themselves.  This "middle ground" is where I have
> always found myself.  (I might note that we are ignoring the totally freeform,
> RP, MUSH-style type of game here, because mechanics in that case are almost
> irrelevant.)

> The 'pure' game position that you describe is much like single-player adventure
> games, and makes me think most of LP-style muds.  The designers lay down
> stories, puzzles, and obstacles for the player to overcome and reach a
> certain goal in a certain way.  There can certainly be a lot of freedom in
> this style of game - the 'way' to achieve one goal might be to get past
> an angry orc, and it's up to you to decide how to do that - but in the end
> the goals are all laid down qutie explicitly by the game's creator(s).  I
> think of LegendMUD as a prime example here.

I don't quite agree here.  The subgoals in accomplishing a particular
goal may be set -- but in most such muds, there are multiple possible
main goals around for you to choose from.  For example, I can take on the
goal of "stop the bandits" or "rescue the princess" or "kill the
orcs".  If there are enough such goals, with enough variety in their
types, then there can be plenty of opportunity for roleplaying in
choosing *which* goals your character will pursue.

(Also, I'm a firm believer in the idea that "there should never be
only one way to do something".  In your example above, where a player
has to get past an angry orc, I'd provide multiple ways to do that --
for example, you might be able to fight the orc, find out what he's
angry about and help him, distract him with a decoy and sneak past, or
bypass him completely by taking another route.  Again, this offers
roleplaying opportunities; people can just play it as "kill the
monster", but they can also seek a way to accomplish things that's
more in line with their character's personality.)

> Simulation tends to boil down to: lots of complicated formulas and numbers
> which we hide from the players in hopes that they will forget about the numbers
> and instead just poke and prod at the world and see what happens.  If your
> mechanics and setting is good enough, players will "make their own fun".
> Very few have successfully achieved the proper balance - I can think only of
> DartMUD and Ultima Online right off the top of my head.  I believe the only
> tabletop game which sucessfully managed to implement number hiding was
> Cyberpunk.

Huh?  Number hiding from the players is possible in *any* tabletop RPG
-- it's a function of the GM, not of the system.  I've played games of
Rolemaster, D&D, Chill, and CoC where I didn't know what the numbers
were -- sometimes not even knowing the numbers for my own character.

Number hiding isn't necessary for a simulation, I'd say -- to me, what
makes a simulation instead of a game is a system that can handle
things the designer *didn't* explicitly plan for.  For example, in a
traditional game setup of "orcs are raiding the village, and someone
has to stop them", the only goals the player can really choose from
are "stop the orcs" and "mess with stuff".  You can't try to join in
on the orcs' side, for example, because the system isn't set up to
handle that.

In a true simulation, though, you *should* be able to try to join the
orcs' side.  Or to play the part of a double agent going either way --
someone working for the orcs who pretends to be working to stop them,
or vice-versa.  Or to be a huckster who tries to sell the villagers a
"magic item" that will stop the orcs, but really doesn't do anything.
And so on.

In a paper RPG, the players interact with a live GM, who can invent
things as needed if the players decide to pursue a different goal than
what the GM had planned.  (Of course, some GMs *won't* do that, but
that's not generally because they *can't*.  Generally, they either
find it to be too much work or have too much of an emotional
investment in the storyline they've already thought up.)

None of that requires number hiding, but it does require a system and
world which can respond to "unplanned" approaches.  You can create a
game which *seems* to have that level of response by careful crafting
and a whole lot of work, but to do it easily and reliably requires a
strong simulation.

> For me, the crux of what makes rule-based games so satisfying is the ability
> to make relevant decisions with highly predictable outcomes.  In a guided
> game, your decisions are largely a matter of "guess what the game designer
> was thinking".  You try one thing, and it has no effect, so you try something
> else, and so on, until you hit the right one.  It's the lock-and-key game: you
> come to a locked door, so you go looking for the key.  When you find a key,
> you bring it back to the door and see if it fits.  If it doesn't, you go
> looking again.  Repeat ad naseum.

> In a pure simulation, everything is more of a big soup of effects - a neural
> net of causality.  Your decisions tend to be muddy ones, and the effects are
> often delayed and hard to interpret.  In many ways it offers more depth for the
> explorer type, because cause and effect is a much more subtle chain.  You
> think, "This opponent is too fast for me.  Perhaps if I use a lighter weapon,
> wear lighter armor, and get someone to cast a 'slowness' spell on my foe,
> I will have a chance of defeating him."  But it is vague: you're not sure
> *how* much faster, or what the exact reduction in weapon weight, or exactly
> how many slowness spells need be cast in order for you to achieve the
> desired effect.

I think things are getting confused here because there are multiple
things that "simulation" can refer to.  To me, it means creating a
game that works like reality does at a high level, and aren't
artificially channeled into taking only the options that the game
designer thought of -- where you can do things like join the orcs
instead of fighting them.  It can also mean "making actions work the
way they do in real life", which seems to be part of what you're
thinking of -- having detailed mechanics that attempt to be realistic.

However, you can have one without the other:  either detailed
mechanics in a situation where you're still channeled into only doing
things the game designer thought of, or the freedom to choose what to
do in a system where actions are handled more abstractly.

To give examples -- I can write a pick-a-path book where tons of
factors are taken into account in whether you succeed in any given
action, but the reader still has few choices available to him or her.
E.g., the reader might be given the choices of "fight or run?" against
a particular monster, but the actual fighting or running be handled at
a high level of detail.

On the other side, I can run a D&D game where the players are free to
try *anything*, but I use standard D&D rules for everything.

> The rule-based game, in contrast to both of these, offers clear-cut mechanics
> that allow the players to make decisions which have precise and predictable
> effects.  You think, "My ogre has an offensive power of 3 and a defensive power
> of 4.  My opponent has a giant with an OP of 4 and a DP of 2.  Therefore they
> will kill each other in combat, unless I use a shield spell on my ogre, which
> will give him a point of DP, allowing him to survive the encounter while
> still killing the giant."

To me, the *important* thing about a simulation is that the players
can try anything -- otherwise, it's nothing more than a very detailed
game.  What you're calling a rule-based game, I'd call a simulation --
one that tries to make things "real", but doesn't try to be incredibly
detailed, and doesn't try to hide numbers.

> Obviously it doesn't need to be so numbers-oriented; my first example (chess)
> proves this.  Nor does it need to be so "cheesey" - although systems like
> D&D's hitroll/damroll/THAC0 fall squarely into the category of rule-based
> games, I certainly don't advocate dragging this tired and boring system back
> out of the closet.

Tired?  Boring?  No *system* is interesting beyond the time it takes
to analyze it.  What keeps a *game* interesting is the options.  If
you play D&D as hack-and-slash, it quickly becomes boring -- but with
a GM who's willing to let you join the orcs instead of fight them,
it's great fun.

> But the player choices are discrete and predictable, and the workings of the
> system are (mostly) exposed to all players.  Understanding the system and then
> making it work for you be chosing combinations of elements that the designers
> never intended can be intensely, directly, immediately satisfying.

Which is just what I'm getting at, and I think what JC was getting at.
What you're expounding on here isn't something different from what I
was thinking of, from what I can see -- it's just a longer statement
of it.

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)   





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



More information about the mud-dev-archive mailing list