Theory: programming a Combo system

Started by
3 comments, last by brightknight 7 years, 10 months ago
Basically I'm asking how would one go about programming a combo system sorta like Tekken. Eg you could have attacks punch and kick, but doing punch punch kick, could perform a combo but with different animations.

How would one go about making something like that?

You can use actual code snippets if it helps to explain. Also concepts of state machines etc. To explain how it could work.
Advertisement

Many different ways.

The first in my mind is to leverage an event broadcasting system, if you've got one. On completing a move, broadcast the event. Have a listener pick up the event and the time. If there is a previous event in recent time, call it a combo.

So maybe require that two consecutive damage events within 100ms are considered part of a combo.

Pseudocode:

OnDamageEventListener(DamageEvent e) {

if( e.timestamp <= previous.timestamp + ComboTime

&& e.damageSource == previous.damageSource

&& e.damageTarget == previous.damageTarget)

{

++comboCount;

BroadcastEvent( event_combo, comboCount, e);

}

else

{

comboCount = 0;

}

previous = e;

}

I'd split it into actions:

Input - The input itself, usually you'd just input keys and you'd have a "timeout" timer, meaning after X ms you'd clear the combo keys.

Analayzing - The input is being analyzed for the combo you are doing. The keys are translated into actions.

Effect - The update and draw for all actions.

Then you tweak it to suit your needs. You need to find a good feel to your combo system, which won't come only from math or theory.

About the implementation itself, find a suitable solution for how you translate the keys into animations, it can change from one design to another, but the main points are choosing the animatino according to a configuration, which isn't a difficult task. For example a simple list of keys to move [ (-> -> X Y ), SuperKick ]

The "SuperKick" is another key to locate the animation and update.

This is almost usually best implemented as a DFA graph.

Each node would have a graph edge for the expected incoming key and the timeout parameters (which may be either a timeout to the next value or a timeout of the entire sequence).

A DFA handles subsequent combos (e.g. it can handle both a combo of A+A and a combo of A+A+B). Some games chain combos while some chain combo inputs, so that's a design question; e.g. is A+A vs A++A+B two different combos or does A+A+B actually mean that you combo off of the first combo as in (A+A)+B? A DFA readily handles either. e.g., for the first case, you'd place the first combo execution in this case on the timeout of the second A node, or on any other input (e.g. A+A+C would trigger it).

The events themselves should be the abstract moves (e.g. "High Kick" rather than a specific hardware input like "X button") in order to support controller remapping. The timeouts should be in reliable time intervals, like game ticks, rather than graphics frames, unless you're 100% sure your game never ever has frame spikes )which is effectively impossible to guarantee on the PC). If you need different combos for different input mediums for some reason, use different DFAs based on medium selection in order to retain remapping support.

Note also that in a fighting game you can use the statistical version of a DFA - a Markov Chain - in order to predict incoming moves.

Sean Middleditch – Game Systems Engineer – Join my team!

Thanks for all the replies,it truly helps. :-)

I'm open to more answers/suggestions!!!

This topic is closed to new replies.

Advertisement