[MUD-Dev] A flamewar startingpoint.)

Adam Wiggins nightfall at user1.inficad.com
Fri Dec 12 01:51:34 CET 1997


[coder at ibm.net:]
> >This seems to be the biggest area of difficulty.  I wish to avoid the
> >arcade-like quality to combat (fastest reflexes win), add a more=20
> >thoughtful approach (cf. JCL's combat scripts), yet preserve a sense of
> >urgency (a time limit on decisions) without imposing excessive lag on
> >players.
> 
> <nod>
> 
> 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

What changed, might I ask, to keep them from working?
And how does this affect your plans to leave characters always logged in
to the game world?
Scripts still work then?

> clocked system.  I don't have much of a design yet, but I'm almost tempte
> 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.=
> 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).

*bow* Actually, the flow of combat was mostly Orion's thing.  We came
up with the prioritized task system together when we realized that
a simple what_i_am_doing value was not enough anymore.
Secondly, I do like a sense of pacing to bring some urgency into the
fray, but I'm not interested in making it so that the strength of
your link directly determines how well you will do.  The 'intentions'
thing, as you call it, came from two desires - one, to make it so that
a little lag doesn't cause your character to turn into a drooling idiot
(the original 'intentions' stuff we put in was a direct descendant of
the 'wimpy' concept), and two, make it so that the sense of urgency
comes from actually *playing* the game, instead of struggling to get
your commands into the system fast enough.  This is the main thing I
don't like about recent realtime strategy games for the PC (Warcraft, C&C..)
- you spend all your time trying to direct your troops to where you actually
want them, rather than thinking about where they should be going.
This isn't quick thinking (I have no trouble thinking at the speed
the game runs), but rather quick mouse-work (which I am terrible at).

All in all, I think pretty much all systems can benefit quite a bit from
having some basic intentions stuff in there.  We just liked how it worked
out so well that we extended it to the point of being the major control
mechanism of the game.

> What I don't like about this is that it does not allow any decent level of
> complexity or careful fore-planning,

As to the former, I'm not so sure I agree.  The idea is to get the basics
'out of the way' before the battle in order to free your mind for the
important stuff in the heat of the moment.  I think of it like a general
training his troops in basic tactics, in order that he can focus on the
battle as a whole and assume that the lower-downs can handle maneuvering,
firing rates, troop morale, etc.  Of course, the general always has
the chance to interdict with new orders if the need should arise, but
micro-management is not necessary.

> and seems too close to the DIKU-style type-kill-and-wait-and-see-who-wins.

This is one of the things we were looking to avoid.  In particular a mudder
I knew back when we were getting started used to play a certain LP where
he would bring a book to the lab, chop off all the limbs of a certain
NPC, then leave his character fighting and kick back to read for twenty
to thirty minutes.  I find it ridiculous that one would do something
for entertainment that doesn't actually entertain 100% of the time.
We designed combat to be quick, brutal, and deadly, *especially* to
those who aren't paying attention.  This also means that, no matter
how strong your character, not knowing what you're doing will get you
killed just as quickly as any newbie.  This seems to contridict some of
my statements above, but battle is so unpredictable that the 'special
cases' requiring overrides actually happen all the time.  Assuming
we've done our job correctly, no amount of automation (client triggers
or even in-game scripting) could properly handle most combat situations.
More importantly, the situations themselves are so varied as to actually
stay interesting to the player, which was our #1 goal when we first
started crafting the combat system.

> 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.

Nods - your argument of 'why should I have to wait on the computer'?
I like pacing for what we're doing (fairly realistic combat), but I
thought the stuff that you proposed would work great without any
sort of timer.  If it's all based on resource stuff (which is easy to
do as soon as you get away from realistic swordplay), there's no reason
anything needs to be timer based.  Of course...once again this could
end up meaning that fast links and fast fingers always win over quick
wits and good planning.  Hmm.




More information about the mud-dev-archive mailing list