[MUD-Dev] Re: Issues from the digests and Wout's list

[Adam Wiggins]

> >Right.  Currently muds and, in fact, computer games in general, are
> >very fond of boolean states like is_fighting.  As soon as you try to
> >expand the system and make things more all-inclusive, it quickly
> >becomes obvious that this method is not even worth bothering with. 
> >Of course, doing a free-form system as you've described above comes
> >with its own problems - when do you decide that they are 'in combat' 
> >and can't just go walking off? 
> 
> My current temptation is to scrap the entire concept of a "you are
> fighting" state.  So, yes, they could walk off at any time.  They may
> not get very far, but they could walk off.

Which was my point.

> The problem with losing the concept of a combat state is that it
> concomittantly also loses the possibility of knowing when/if to create
> a combat object, and if they are gone, there goes the whole concept of
> combat packages, combat scripts, combat rounds etc as they never know
> when to instantiate.  In a way, this all may be a good thing after
> all...

Hmmm.  Yeah, that's what I mean - we have nothing at all to indicate
any sort of combat state - certainly no combat object.  You simply have
two (or more) guys (or gals, or even objects) which are doing certain
things at certain times.  If those things happen to be hacking at each
other with big axes, we like to assign the tag 'combat' to the situation,
but the mud makes no such distinction.

> >Of course, I consider this sort of design problem quite
> >interesting -
> >leaving the realm of the finite state machine that most mud
> >characters opperate by and instead allowing just a bunch of
> >fluctating variables which the system must assess at any given time
> >to decide what 'state' (as it were) the player is in, and whether
> >they can and/or want to do a given thing.
> 
> Why have a state at all?

We don't, and that's my point.  Humans thing in terms of states, which is
why we build our computers to be complex state machines.  When someone
asks me what's the matter with my car, I say "It's broken."  To me
this is a state where the vehicle doesn't function in an acceptable
manner.  In actuality, this 'state' could be any one (or more) of a
thousand totally unrelated things.  I don't care, however - to me the car
is in one, easily definable state - "broken".
So...since my target audience for my mud are human beings, one has to
allow for this.  For instance, the example of walking off when you're
in combat.  The player sees this:

> l
A Room
Bob is here, fighting you.
> s
If you try to walk off, Bob will stab you in the back!
> s!
You leave south, despite your better judgement.
Bob stabs you in the back!  Ouch!

To the player, this is related to a 'state' which they call 'combat'.
The mud simply analyzes the situation, decides that walking south would
be dangerous because of the person in the room who is intent on attacking
you.  This is the same analysis by which it determines that walking south
is a bad idea since the area to the south is a blazing inferno which would
incinerate you in seconds.

> >Again, once one gets rid of a few kludges, they all have to go.  The
> >concept of a "give" command which places an object in the target's
> >possession without their consent is abhorent.  
> 
> True.  However UggUgg's just tossing his magical objects into your
> general vicinity may be enough to create enough of a mana sink to
> destruct your inventory and spells.  (Excuse: It was a hacked combat
> written off the cuff)  The key is that he was indirectly able to cause
> the destruction of your magical items.

Right.  So if you want your system to be able to make decisions about
the intent of an action rather than having the player just decide, you
have to either do some sort of traceback, ie:

My mana is suddnely all gone, which makes me angry.
My mana is all gone because of the objects nearby, so I am angry at the objects.
The objects are nearby because UggUgg tossed them there, so I'm angry at UggUgg.

This, of course, is exactly how humans think, which is why people often
do the 'shoot the messenger' routine.  That is, the real object for their
anger is not nearby, so they take it out on the next closest thing, which
in the aboev example would be the objects.

> >Our goal was to make combat (and other stuff, but
> >combat is the most important due to its mortal nature) sort of 'play
> >itself' without any intervention from the player...
> 
> Which is actually something I also expressly wanted to avoid.  I
> really dislike automated combat -- well system automated at least.  A
> specific goal is to have combat be required to be intensely
> interactive.
> 
> Sure, the guy can stand up and run if someone attacks him when he's
> sleeping, or some other reasonable, simplistic action that can be
> presumed upon autonomous reaction.  But intelligent reactions should
> depend on user installed/customised/programmed features, or hands-on
> interaction.

It's a matter of playability.  I see a lot of things that we do as being
similar to DartMUD, but DartMUD had some severe failings that kept it
from really being what it should have been.  Mainly this relates to
playability and learning curve.  A friend of mine played on DartMUD
when they first opened a few years back.  This is a guy who has played
scores of mud from every possible family and thinks assembly language
programming is a fun way to relax, so I don't think he's exagerating
when he said that it was 'too hard to get into.'  He didn't like you
you had to set up a bunch of things about percetang of times you wanted to
block attacks with a given limb, where you wanted to target your opponent,
etc etc before even entering combat.  He just wanted to *play*.  I'm the
same way; even though I appreciate these details, when I'm learning a new
mud I want to be able to stick to the defaults and have everything work
resonably well.
On our mud, you can go immediately get into a fight, and your character
will make semi-intelligent decisions.  Now, you can do infinitely better
if you a) customize his fighting style and other options before combat
and b) interject command during the fight to take the ideal action.  But
if you just get into a fight without knowing what any of these commands
and options are, you won't be swearing at your player for acting like a
total dumbass.
Thus, the default is to stand up after you get knocked down, attack
whenever you see a resonable opening, block when you see a blow that you
think is gonna be potentially dangerous to you.  As you go along you'll
probably decide to customize your character quite a bit - for instance,
setting your agressiveness very low, which wlil keep you character
circling and then manually typing "swing" or "thrust" or whatever to
time your blows just as you like.  Or if you've got a magical sword made
of glass, you can toggle off parrying for the time being, even if you're
a master fencer and this is your main defence.  Or if you're a judo type,
you may not want to get up when you get knocked down - you'd rather try
to drag your opponent down with you, since that's where you're at an
advantage.
But the point is, your character as he or she enters the game will do
basically what you'd expect a normal, unskilled person to do in a given
situation (and this applies to many things other than combat).  From there
you can customize and tweak as you develop them.