[MUD-Dev] Usability and interface and who the hell is suppo

[Travis Casey]

Caliban Tiresias Darklock <caliban at darklock.com> wrote:
>On Wednesday, September 17, 1997 7:33 PM, Jon A. Lambert
>[SMTP:jlsysinc at ix.netcom.com] wrote:
>
>> Actually many of my FRPG friends refuse to mud because of the utterly
>> simplistic combat.  None of them are programmers.
>
>Why do people constantly misunderstand my statements? I was not saying
>'only programmers want complex combat systems', I was saying 'programmers
>generally design *overly* complex, difficult, and nonintuitive combat
>systems'. Get one of those FRPG friends to design what he considers an
>excellent combat system, and then run it by us. Or at least find out some
>of what he wants in a system, and try to give him some of it in your own
>work.

Don't forget that the requirements for a good paper RPG combat system are
different than those for a good mud combat system -- paper RPGs can thrive
on ambiguity, since the GM can add detail on the fly.  A computer RPG combat
system, if it is to be detailed, has to have the detail built in explicitly.
On the other hand, keeping track of data and number crunching are the
primary
strengths of computers, so a computer combat system can look simple from the
players' point of view, but be very complicated underneath.

Personally, I'd say that programmers tend to design complicated combat
systems
because they don't have to actually run them once they've programmed them.
Complex paper systems take large amounts of time and effort to run, so fewer
paper GMs use them.

>> The 'kill monster' is a great deal more simple than most p&ntivp rpgs.  I
>don't prefer the
>> syntax you cited, but I do prefer the complexity and choices of
>> action implied by it.
>
>I have several better suggestions for a more complex fighting system, like
>the idea of 'complex' moves. Rather than having the single high-level
>'kill' or the utterly inane 'stab/slash/hit/cut/bash/trip/gouge' series
>(with associated ridiculous modifiers for weapon, object, target, user, and
>additional verbiage provided by the player like 'cut orc viciously'),
>there's a middle ground where there are multiple types of attack which can
>be selected at any given time -- but which, instead of being a simple
>single-shot attack, would be a combination of associated attacks. (You
>could go farther with this by providing all the low-levels to define your
>own attacks -- but that would be just as bad as the atomic cut/stab/bash
>above.) These could be provided to the warrior types as individual skills
>similar to a wizard's spells, as I mentioned in an earlier post. You could
>become skilled in several different forms of attack, but it would take a
>long time.

>From some points of view, though, this might be worse than the typical
mud combat system.  Making combat more complex tends to reward those who
have more time to spend delving into the combat system, and can increase
the importance of the player's skills, as opposed to the character's
skills.

>Another option would be a series of attack/defense 'modes', which would be
>persistent. For example, if you set yourself to 'full on ferocious charge
>and attack', you would continue to attack in this fashion until you gave
>another order. You could give orders as often, or as rarely, as you liked.

This is similar to my own preferred system -- allowing players to select
combat attitudes (e.g., aggressive, defensive).  The difference is in the
level of detail revealed to the players.

>> > And lots of skills! A thousand, at least!
>>
>> Yes.  At least a hundred or two really "useful" skills/spells. A
>> thousand might be pushing it. *grin*
>
>When you add spells, the number goes WAY up. ;)

Why would I add spells?  There's no reason why spells have to be skills.

>> What's a class?  I thought many on this list advocated abandoning
>> this concept in favor of skills.  Not that there's anything wrong
>> with classes.
>
>I for one find classes a convenient way to represent a starting group of
>skills. If you want to spend an extra half hour in character creation, you
>could always modify a class slightly, or if you're completely insane you
>could go in and design frmo scratch.

A starting group of skills would more commonly be referred to as a
"template"
or an "archetype."  "Class," in paper RPGs at least, is pretty much reserved
for D&D-style classes.

>P&calyP is not the same as online. For one thing, it is close to impossible
to
>provide appropriate body language, facial expression, and accents online.
>On the other hand, online, you never need to roll huge handfuls of dice and
>lug forty books around in a backpack. Languages in P&esneP can add a lot to
the
>game; languages online add absolutely nothing.

I never need to roll huge handfuls of dice or lug forty books around in a
backpack even when I'm playing paper RPGs -- sometimes I *like* to, but
that's
a different story.

Languages may add nothing in your opinion, but some of us believe they do
add something.  That's why we're not all working on the same mud.  :-)

>> It's interesting that you attribute the claims to more races,
>> classes, etc. to those on this list.  I haven't seen any postings
>> here advertising "heavily-modified Circle" muds. ;)
>
>Excuse me. I was saying THESE ARE STUPID THINGS TO DO, not that people here
>do them. What people here actually *do* tend to do a lot of is point at
>game mechanics and server details as though they are discussing a game.
>These are not the game, any more than the player's handbook is AD&ngdiD.
You do
>not NEED them. They are there strictly in a supporting role.

That's probably because this list is about mud development -- if you're just
going to create a chat engine and let people role-play everything, there's
not
much to develop.

To put it another way, the player's handbook isn't AD&D, but neither is a
group of people playing a freeform diceless RPG AD&D.

>> What seems to be lost in this is you have described a game with a
>> SINGLE overriding goal.  The traditional HnS goal of killing to
>> advance, advancing to max level, getting the best equipment.
>
>This is quite patently not true. What I have described is the simple fact
>that when you make a game overly complex, you can not realistically manage
>it and game balance goes straight to hell. It is not difficult to balance a
>penny on a pencil eraser. It is rather difficult to balance a dinner plate
>there, and balancing a stack of twelve dinner plates on it is a fool's
>errand.
>
>> I'm not sure how any of this would apply to my game or many of the
>> others I've read about here.
>
>Does it seem more clear now? People are spending a lot of time talking
>about creating an infinite diversity of skills and items and abilities.
>This is like trying to balance a dinner plate of infinite diameter on that
>pencil eraser. Think about it.

The problem is in deciding what's overly complex.  A system with a large
number of skills can be very simple -- if all those skills share a common
mechanic.  To put it another way, someone looking at character sheets for
beginning FUDGE and first edition AD&D characters might think that first
edition AD&D is simpler because there's less written down on the character
sheet -- but that doesn't hold water when you look at the game mechanics.

A system with many skills, traits, and items can be simple to balance if
they all follow a small set of clear rules.  Conversely, a system with
relatively few skills, traits, and items can be fiendishly difficult to
balance if each one follows unique rules.

Designing a game, *any* game, is a balancing act.  Adding more options
makes the game more complex for players, but subtracting options makes
it less flexible.  There is no perfect combination that will please
everyone, as many people have pointed out.  Thus, you have to decide who
you want to target the game towards.  It's important to realize, however,
that there's only one way that you can ultimately be wrong when designing
a game -- if you feel that you didn't get enough out of the game in
comparison to what you put into it.

I've spent years designing games that no more than fifteen people in the
world have ever played.  I've spent months on games that no one but
myself has ever played.  Why?  Because, as much as I enjoy playing games
and having others play them, I enjoy the sheer intellectual exercise of
*creating* a game even more.  Since I'm only doing this for my own
enjoyment, it doesn't matter to me if *anyone* ever plays the game -- even
if *I* never play the game.

I think you're wrong in faulting others for focusing on things that you
don't consider important -- instead of framing your ideas on what should
be discussed so that they appear to be attacks on others, why not advance
them in a more friendly fashion?  In several places in these posts, you've
said that you wanted to focus on the user interface -- if that's the case,
why didn't you simply post something like:

Adding more options to muds to make them more interesting is a nice idea --
but how are people going to use those options?  Does anyone have ideas for
improving mud interfaces, beyond the ideas of using NLP and graphical
interfaces?

To give people more to chew on, you could have added in some of your own
interface ideas -- like the idea quoted above on how to do combat, and
some of your thoughts on the tradeoffs involved with different interfaces --
such as how atomic interfaces give an advantage to players with programming
skill.
--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
     '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html