[MUD-Dev] A flamewar startingpoint.)

Stephen Zepp zoran at enid.com
Fri Dec 12 19:00:20 CET 1997


This is a multi-part message in MIME format.
--------------EF2E26493DD571249BC221C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adam Wiggins wrote:
[snip questions about scripts]

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


Hmm..one question for ya:  if your system is that complex, how can npcs
used it?  This is a topic that's plagueing me..


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


I'm moving towards a "queued event" system, sort of like "I'm starting
to swing my sword, I'm swinging my sword, he's moving his mace to block,
he's committed to block, OKAY..now, feint under his block, and slice his
guts open!  That's probably an overdone description, but with "segments"
like D&D used to have, tho wasn't much used in most version of rp-style
( the miniatures version of D&D used them :) ), you have this idea of
"some actions are just quicker than others"...thrusting a dagger is a
lot faster than an overhead blow from a heavy two handed mace..


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

Yeah, what he said :)

Zoran
--------------EF2E26493DD571249BC221C5
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stephen Zepp
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Stephen Zepp
n:              Zepp;Stephen
org:            Lords of the Shadow ( telnet://soe.nuc.net:8888 )
email;internet: zoran at enid.com
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------EF2E26493DD571249BC221C5--




More information about the mud-dev-archive mailing list