[MUD-Dev] A flamewar startingpoint.)

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Thu Dec 11 23:15:27 CET 1997


[Chris L:]

:For the technical reasons noted afore I'm moving away from combat scripts
:(they just don't work any more), and trying to move to a more losely pace=
:d
:clocked system.  I don't have much of a design yet, but I'm almost tempte=
:d
:to something of a tick based system where players define generic
:intentions (I want to try and do XXX action) which the system then
:periodically evaluates for opportunity and then executes when possible.=20
:Actions would then be defined as either ongoing on one-off's within this
:structure.  (This is somewhat inspired by reports on Wiggin's system). =20
:
:What I don't like about this is that it does not allow any decent level o=
:f
:complexity or careful fore-planning, and seems too close to the DIKU-styl=
:e
: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!

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.

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.

The execution of the steps in a multi-step response then become ongoing
activities, like other ongoing activities discussed here recently, the
main difference being that they are at shorter time scales.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA



More information about the mud-dev-archive mailing list