is movement in fighting game scripted?

Started by
2 comments, last by Bow_vernon 13 years ago
I played a fighting games, and wondered how those complex moves are managed. I guess they're using a script, am I right? and how would you decide when to 'hit' other object (I guess they only enable hit at frame x...y), but I have no idea. Care to share some thought/experiences?
Thanks
Advertisement
"Scripts" are another word for "code"; so yes, games use code.


Animations often have 'markers' attached to certain frames - they could mark frame(s) of the attack animation as "hit" frames. When the game engine get's a "hit frame" event, it'll do some kind of collision test between the hit location and the other player, which will trigger damage / flinch / etc events.
In my fighting game engine, a move is just a big list of timings/properties. Each move has a number of start up frames till the active frames in which they become active, at which point a hit box becomes active that defines an area in which it'll hit your opponent (properties like damage, hit stun frames, block stun frames, mana/meter cost, knockback, what animation to use, etc are defined here too). In a 2D fighter this would just be a rectangle on the screen, in a 3D fighter it would be an arc. Then each move has a set of moves that it can transition into after it hits, depending on what inputs you've entered in (to enable multi-hit attacks or changing to different stances [which can be thought of as moves that don't deal damage and might loop into theirselves]).



Being entirely data driven, lets me build a nice editor for defining moves, and gives me a set of data that the ai can use to play with (it can analyze the move list and know what each move will do and thus decide what an appropriate/optimal move to use would be, without having to be scripted to decide what moves to use). It also lets me run automatic analysis on the movesets of characters finding all of the combos (its hard to account for every stage position, so, some wall-dependent stuff might be missed), so I can hopefully find all of the infinites and anything unbalanced and adjust accordingly.



This is probably the best explanation on fighting game frame data out there: http://virtuafighter...tack_properties Everything in here you'd define as a property of each move.


The character's themselves are made out of hitboxes or some other collision primitives, that change frame to frame on a move.

If you look on youtube, you can find various videos where the hitboxes are made visible for various games.


As an example, a quick horizontal high sword swing can be represented in my game as:

Input: A
Active Frame: 13
Damage: 5
Attack Height: High
Move Duration: 26
Block Stun: 10 (your opponent recovers: 26 - 13 - 10 = 3 frames faster than you if they block it)
Hit Stun: 20 (your opponent recovers: 26 - 20 - 10 = -4 so 4 frames slower than you if they get hit)
Counter Hit Stun: 22
Attack Range: 1
Attack Angle Left: 45
Attack Angle Right: 45 (so an even arc on both sides of you)
Stance Moves: A (a second attack can be activated by hitting A again during this swing)
Default Next Move: Idle stance (goes back to the idle stance if you input nothing, this is usually the case unless its a stance move that leaves you in the stance afterwards)
Tracking: Yes (move will realign your character with your opponent when it begins)


A vertical stab could be represented as:


Input: 6B
Active Frame: 18
Damage: 15
Attack Height: Mid
Move Duration: 46
Block Stun: 15 (your opponent recovers: 46 - 15 - 18 = 13 frames faster than you if they block it)
Hit Stun: 35 (your opponent recovers: 46 - 35 - 18 = -6 so 6 frames slower than you if they get hit)
Counter Hit Stun: 45 (your opponent recovers: 46 - 45 - 18 = -16 so 16 frames slower than you if they get hit, so you could combo the fast horizontal attack above on a counter hit with this move)
Attack Range: 2
Attack Angle Left: 5
Attack Angle Right: 5 (so an very narrow arc in front of you, making it vulnerable to being sidestepped)
Stance Moves: None
Default Next Move: Idle stance
Tracking: No (move will not realign your character with your opponent when it begins)


There are a bunch of other properties other than these, but, this should give you the general idea. This ends up working well for me, and I can represent any move in my game with it.

<Edit Apologies for the wall of unformated text, for some reason gamedev is throwing away all of my new lines>
Ok, thx for the link andur. Will read it after I solved a problem here...

This topic is closed to new replies.

Advertisement