Issues from the digests and Wout's list

clawrenc at cup.hp.com clawrenc at cup.hp.com
Sun Apr 20 18:05:27 CEST 1997


In <199704191743.RAA187768 at out1.ibm.net>, on 04/18/97 
   at 09:26 AM, Adam Wiggins <nightfall at inficad.com> said: >
claw at null.net/clawrenc at cup.hp.com/coder at ibm,net, one of my IDs:

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

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

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

>I think this is because he's going for a more turn-based,
>strategy/wargame style combat system where you plot out your moves
>and then watch them unfold, as opposed to just throwing everything in
>immediately.  I vastly prefer the free-form system mentioned above,
>but his stuff looks interesting with a different context.  Since
>you're basically 'programming' your character anyhow, the actual
>role-playing/story/mood element is probably pretty low anyhow.  It
>more like a game of chess than D&D, for which turn-based is probably
>ideal.

True, and very accurate.

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

>With ya all the way.  There is a point at which the guy with the 150
>wpm typerate and the 30ms link is just gonna do better that others. 

I specifically want the very experienced guy who knows exactly what
he's doing but is also working over a 300baud SLIP link to retain the
advantage over the chaps on directly connected terminals.  I don't
know how, but I want this.

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

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list