[MUD-Dev] A flamewar startingpoint.)

[coder at ibm.net]

On 11/12/97 at 11:05 PM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray)
said: >[Chris L:]

>:What I don't like about this is that it does not allow any decent level of
>:complexity or careful fore-planning, and seems too close to the DIKU-style
>:type-kill-and-wait-and-see-who-wins.  I also don't like moving to a
>:clocked system as it fairly well forces me to move the entire game to a
>:clocked system, which I'm resistant to.  I'm still much won over with
>:letting everything execute as quickly as it can.

>This *is* a change in thinking!

True.  Unfortunately I don't like it any more than the old approach.  It
also suffers from the same weaknesses as the old approach in that it
doesn't support a world where entirely innocuous actions, as simple as
dropping an object, pulling a string, or wiggling an eyebrow may prove to
be fearsome weapons in a fight.

I'm also having trouble figuring out how to make the base combat structure
extensible with user-coded patterns, routines, models etc using this sort
of approach.  Technically its not too difficult, but the public interface
is troublesome.

>How about more of a middle ground? Simple choices are available to the
>player for responses to various threats, and they operate at a speed
>determined by the apparant urgency of the trigger. If the player wishes
>to manually trigger one of the responses, that can be done too, and is
>then more of an attack. That explicit trigger can include an urgency
>which overrides the default one for that response.

This rather equates to Wiggin's model of:  The players circle each other,
looking for an opening to attack.  When an opening presents itself for a
selected attack form, they do that.  The rest of the time they operate of
a minimal set of defaults.

This works.  Sorta.  It also has problems in melee or group situations I'm
not comfortable with.  I'd like to support pack, regiment, melee and front
style assaults as well as the normal one on one.

>Given a framework, you can then allow more ambitious users to define
>their own "responses", and hence go back towards your scripts. Most RP
>games have ticks that govern how fast things can execute - those ticks
>would relate to the speed of script steps, also interacting with any
>urgency supplied, and the capabilities of the character.

Hurm. I like the basic idea of the user creating a stack of potential
actions which are then done on a best-fit basis as the fight progresses. 
I'd have to have the ability to have a DO-IT-NOW type command to bypass
the queueing.  Gotta think on this.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...