Thread: [Algorithms] finite automata in fighter game
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Przemek T. <caf...@ze...> - 2001-12-20 17:14:58
|
hi! it's my first post to this list, so greetings for everyone. 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. -- Przemek Tomczyk mailto:caf...@ze... `When you've got a shiny new hammer, every problem looks like a nail' |
|
From: Jeffrey R. <jr...@he...> - 2001-12-20 18:32:04
|
You should think about having a high-level finite state automaton, and in each state use user input to parameterize the state. For example, some good state would be : Idle, blocking, charging-up, performing a special move, hitting, kicking, kneelling, dying. A high level description would be something like 20 different states. >From idle, for example, the "kick" button would bring you into kicking, from which "time" would bring you back to idle. You should keep the serie of button presses outside the state system. This would allow you to process multiple button presses across different states to make special moves. Example: Button A is a simple kick Button B is a punch C serve to block, and D to jump. ABABCDCD is the Big Impressive Kick. As soon as you press A, the kick is started. Then, while the kick is performed, and whatever else happens, the remaining BABCDCD is recorded. If the player is still in a good position to perform the Big Impressive Kick, you then get a single state change from "kicking" to "Performing a special move". Of course, "Performing a special move" would have a parameter telling which special move you want. I think a high-level state diagram, with some variationw in each state ( position, move, etc.. ) gives you the best of both world : simplification at a high level, a small diagram and a much more rich behaviour within each state. But I must I never made a fighter game. One thing I'm certain about, though, is that you want to separate the actual animation frame from the game-state. Your game-state has to be clean, portable. The actual frames will tend to be variables according to the platforms, will need tweaking at the end of the project, might change according to the players stamina, and so on.... Anyone on the list who participated in something like DOA or Soulcalibur would care to elaborate how they do it ? :-) Jeff. ----- Original Message ----- From: "Przemek Tomczyk" <caf...@ze...> To: <gda...@li...> Sent: Thursday, December 20, 2001 11:24 Subject: [Algorithms] finite automata in fighter game > hi! > it's my first post to this list, so greetings for everyone. > > 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. > > -- > Przemek Tomczyk mailto:caf...@ze... > `When you've got a shiny new hammer, every problem looks like a nail' > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |
|
From: Bob <ma...@mb...> - 2001-12-20 19:01:25
|
> One thing I'm certain about, though, is that you want to separate the > actual animation frame from the game-state. Your game-state has to be > clean, portable. The actual frames will tend to be variables according > to the platforms, will need tweaking at the end of the project, might > change according to the players stamina, and so on.... I agree for the most on this point, and LERP should be used for animations, but I want to point out that a lot of fighting games do use actual animation frames for timing. Although this causes timing to vary on different platforms, and does require timing to be set for every animation, it locks the timing relative to the framerate -- doing actual time based variations would be harder to tweak. --Bob |
|
From: R & D \(GameBrains\) <res...@ga...> - 2001-12-21 02:09:38
|
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
|
