Combo Inputs

Hello and welcome to an illustrative example of programming. Watch as the maestro tries to decide upon a method to use and gives reasons for its suitability.

The Alpha Conspiracy

Do you remember a little series of columns on game design I did, which cam eup with an outline for a game of this name? Well, I did. In short, it was to be a 3rd person beat'em'up with character progression through learning new moves and a scoring system based upon combos (much like the genre of sports games typified by 'crazy taxi')

Well, it's been ages, life intervened -but now I'm thinking about it again.

Pulling Off Moves

Ok, this being a fighting game - I want to have things like left-left-A pull off a certain attack; an attack which is different from both left and A on their own.

That's what todays column is about. I'm going to assume some system for grabbing what buttons the user is currently pressing exists, and I'm going to assume some system for "do this move" exists - and just look at this one sub-problem in detail.

Requirements

First of all, the system has to be fast enough that the user see's no lag. In practice this means that it takes less than 50ms to identify the move to start performing. (Although the routine will have to use less time than this, since other parts of the program will be using up some of that 50ms doing the sound and the graphics etc.)

Secondly, the system needs to be able to be expanded - that is to easily accept new key combinations as pulling off moves. This is important both while writing the game (don't want to have to specify every move right from the start) and because this game deliberately creates new moves based upon the players input. Note that adding something new does NOT have to be fast - a couple of seconds would be fine, since it is only going to take effect during 'loading' screens anyway.

Shouldn't be too hard to come up with something that does those, right?

Grammar Parser

This is the first choice I came upon. A grammar parser is a system that looks at a set of sentences (in this case the moves that can be performed) and comes up with a state machine (a set of states connected by the various keys that can be pressed) that 'accepts' that language. While it is very slow to build such a state machine, it is very fast to execute it - and it has the big advantage of only needing to know the current state and the current key being pressed. If we add 'short pause' and 'long pause' as well as seperate 'key up' and 'key down' letters to the language, then it should be able to run as needed.

There are a few problems with this method. The first is that the state machine it builds could be very large - in the worst case 'number of letters' raised to the powerr of 'length of sentence' - which for us would be somewhere in the region of 2562890625 (15^8) states. Each state would have to have a list of keys it accepts and destination states - this would lead to a state machine far too large to fit into any computers memory (80Tb or so). Of course, it is highly unlikely that the machine actually generated would approach this size; but it is a potential worry.

The advantages are that it would be very very fast to use (a single lookup and one variable to change) and there is a lot of software out there dedicated to generating these trees (such as lex)

Messages

Let's hop to the other end of the scale. If we built the system somewhat like a modern GUI - with each user keypress (or key release) being a seperate timestamped message, then we could simply have a number of components which listen to these messages, and place themselves into an appropriate state. Sometimes these components would reply by issuing a 'start the attack' type message.

This has the advantage of allowing me to cut down on the number states, by splitting it up in to smaller 'sut-states' - while retaining simpler functionality. (eg. 'forward' always means 'move forward' unless there is a 'cannot move' currently being signalled)

The disadvantage of this system is that it is not easy to add new functions to it. Older components would need to be taught about newer signals - it would be hard to maintain while writing it; let alone learning a new move while running it.

Think Functions

Think functions are the way AI is implemented in (for example) quake. Each entity waits until a given signal (such as a timer going off) is encountered and can then do stuff - stuff which includes changing its future responces to signals. A little thought will show that this is logically identical to the 'messages' method. It does have the advantage of having a standard set of base functions - and thus adding to it at run-time is a bit easier, but the fundamental problem remains.

This is a damn shame, because I'm already quite familiar with this method of coding. But the thought of putting together some 'user attack' function which runs from some sort of table and can thus be easily changes at run time makes me shudder. I end up going back to a grammar parser for it, and finishing with the worst of both worlds.

Parametirisation

Ok, I'm sure you know what parametric animation is - it's a system of animation whereby you give the character certain parameters (such as legs@4, arms@[5,6] ) instead of setting a specific frame of animation. This allows you to have, for instance, five frames of firing and five frames of running without having to have twenty five specifically programmed frames of 'firing and running' to cope with every possible combination. The different animations are combined for you automatically. Most new (halflife onwards) graphics engines will let you do this.

Now, I'm going to be sneaky, and use this in reverse. First I build up a library of simple functions to handle each of the button presses on their own. (Forwards means run forwards, A means jump etc.)

Then I simply attach my 'special' functions to ranges of parameters. For example, if 'jump' is between frame 18 and 24 (and no other special animation is going on) and 'punch' is at frame 2, then start the 'clothesline' animation. If 'clothesline' is between frame 18 and 24 and 'jump' is at frame one, then start a new attack... and so on.

This provides a way of attaching animations to the current action, rather than to key presses - but since the actions are wholly derived from your key presses, it equates to the same thing. It DOES require you to have seomthing watching the animation for each stage of each special attack - but 50ms is a long time in computer terms, and you will only have to watch for about 100 ranges at once (4 stages to each of 20 attacks, plus a few atacks with a more stages).

It is easy to add to - and has the added advantage of guarding against two special attacks being triggerred by the same sequence (which messages are prone to) and handles starting a new sequence in the middle of an old one nicely (which uses up a LOT of states in the grammar system)

Next up?