Re: [Algorithms] finite automata in fighter game

[R & D \(GameBrains\) <res...@ga...>]

I agree with Jeff and Bob.  I worked on two fighting games before and =
some info below may help...

1.  Store the input into a ring buffer.  If you maximum sequence of =
allowable presses (say for a super-duper kick) is 16 presses in a row, =
then make the ring buffer 16 input frames long where a frame contains =
all the bits you care about.  Generally joysticks are modifiers, not =
triggers, so a byte or word should be enough per input frame to get what =
you want.

2.  To define a combo, create a table with the bit pattern and mask, and =
the min/max tick-count before the next key in the combo needs to happen. =
 You need the mask because some key presses you want to cancel a combo =
in progress and other times you want bogus key presses to _not_ cancel =
the combo.  The reason is that many players press bogus keys on purpose =
to fake out their opponent and your game should be able to handle that =
or hardcore fighter fans will not like it.  This was an issue when =
designing arcade machines and granted that consoles may not need this, =
but I would support it anyway 'cos it isn't difficult.

3.  Each frame you need to:
if (key press)
{
  check all current combo tasks for next key and either cancel or =
progress combo
  or add a new task if the key is valid but doesn't match a combo in =
progess
  (note you can hardcode the task buffer to be 16 buffers since a combo =
can only be 16 presses anyway so you can use the current ring buffer
   offset as the index into the task buffer since you can only start one =
trip through the tree per input frame)
}
age the combo tasks and remove ones who waited too long or didn't wait =
long enough

Once you have a valid key press, select animation and blend.

4.  Note that generally you will want to know the "depth" of a =
successful combo entry in the tree and you ignore the combo if it is =
shallower than the one currently executing.  For example, you launch a =
super-kick combo and then press just kick; you don't want to cancel a =
lesser move when doing a better one, but you do the other way around.

5.  The final tricky part is modifiers.  In the middle of the super kick =
you can do a pile driver punch on the way down.  I would put these =
relationships into tables as there aren't that many modifiers per combo =
usually.

Whatever way you actually use to implement your fighting engine, make =
sure it is easy to add new combos, balance timing and add modifiers =
because you will go insane trying to maintain the relationships without =
a good plan up front :-)

Hope this helps.

Brett Bibby
GameBrains

----- Original Message -----=20
From: "Przemek Tomczyk" <caf...@ze...>
To: <gda...@li...>
Sent: Friday, December 21, 2001 12:24 AM
Subject: [Algorithms] finite automata in fighter game


> hi!
> it's my first post to this list, so greetings for everyone.
>=20
> I am going to write a fighter game - something with box, karate, =
aikido
> etc. think the way to implement all 'combos' and in general user input
> handling  would  be  to use a finite automaton with input signals like
> 'left',   'right',   'kick', 'you've been hit'  and  'clock  tick' for
> each  player. but, after discussion, my friend pointed me out that the
> required  number of states would  be  _very_  lagre.  so  the  idea of
> interpolating  between  states  of automaton (state of automaton would
> correspond  to  key  frame of animation). although interpolation would
> decrase   responsivity/playablity.  is  there  another  way? using ex.
> graphs seem to be equivalent.
>=20
> --=20
>  Przemek Tomczyk                  =
mailto:caf...@ze...
>  `When you've got a shiny new hammer, every problem looks like a nail'
>=20
>=20
>=20
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>=20