Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Implementing "actions" in an action game

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Gorge Express   Members   


Posted 23 May 2013 - 01:04 AM

I'll use Link to the Past as an example


Frame 1:



Link takes out his sword and begins the attack animation. Though the sword is being rendered, it has no hitbox yet. For the next couple of frames, pressing the d-pad or any buttons will have no effect on Link. 


Frame 3:



The sword now has a hitbox and can collide with enemies.


Frame 6:



The player can now press attack to interrupt the current attack animation and start a new one. Any other input is still ignored. 




On the last frame of the animation (13), the game checks to see if the attack button is held down. If it is, Link enters a new state where he begins charging his sword. If not, on the next frame, the animation ends, the sword disappears, and full control is given back to the player.


I'm wondering, how would people approach the problem of implementing "actions" like these in a video game? Where rather than the action taking place in a single frame, it takes place over several frames and updates certain things(like the position of the sword is always attached to link's hand, even if he is moved by some outside force during the animation) each frame. With access to today's technologies of course. 


Best i can come up with for an "attack" action is hard coding it based on states. Pressing attack puts Link in the "Sword Attack" state and starts a timer. The game sees this, then creates the sword and starts playing out the animations. Each frame, the game updates, checks the time passed to see if it should add the hitbox or whatever it needs to do. The second half of the animation would have its own state, so the game knows that it is allowed to accept input for another attack to interrupt the current one.


That means coming up with a different set of states for every action in the game though, which would be a pain. Especially in a component+entity system, where you would need to add the code into a State System or something instead of each entity's  own update method.  So i'm wondering to see if there are better ways to handle this, especially more data-driven ways. 



#2 Steve_Segreto   Members   


Posted 23 May 2013 - 01:40 AM

It's called a finite state machine (FSM).

#3 alnite   Members   


Posted 23 May 2013 - 05:40 AM

This is where tools come to the rescue.


My guess would be that they use an in-house development tool to compose the frames together, and able to inject extra information into each frame, such as collision boxes, tags, sound effects, and so on.  Then when the game loads the resource files, it creates a data structure of the animations and frames and tie them up together in such a way that simplify all these seemingly complex tasks.


For example:


Animation* animation = loadAnimation("link.dat");
// somewhere when checking for collision
// animation object already takes care of which frame it's currently playing, and whether there's a collision box in that frame.
if (animation->collides(another_animation))
   // do something here

Edited by alnite, 23 May 2013 - 05:47 AM.

#4 Gorge Express   Members   


Posted 23 May 2013 - 05:26 PM

LttP was made in assembly, so they would've had to do things the hard way :P but yea, i was just using it for an example.
FSM sounds like what i was saying I would do. Using only a FSM to address the problem would be a real pain if you need to implement a lot of actions though. 
Using a data structure that takes care of itself makes sense too. Though something in the code would still have have to handle adding and removing the sword entity, adding and removing the hitbox, and changing the player state. You can't just change the player state out of "attack mode" after a set amount of time, because that amount of time isn't always known(imagine the hookshot in any Zelda game. If it hits a wall, you gain control of the player back sooner.)

#5 shadowisadog   Members   


Posted 23 May 2013 - 09:38 PM

My thoughts would be to make the system far less complicated.


What I mean is I might start playing the attack animation when the attack key is pressed and then after a certain delay check to see if I an in range of the enemy (and facing the enemy). If I am then I assume that the sword hit the enemy.


I don't think I would mess with hit boxes or even creating the sword independently (depending on how many swords I had of course). I would probably draw or have an artist draw the hero with the sword. Or I would have the sword animated with the hero on a separate layer but I certainly would not attempt to position the sword somehow to the hero's hand every frame (as this would be asking for a lot of frustration).


When possible I would want to use other factors then animations and collision detection to determine my game state since animations and collision detection can take a lot of work. So to me the animation would be what is visible to the player, but it would not directly be involved in my game logic.


Just my two cents.

Edited by shadowisadog, 23 May 2013 - 09:49 PM.

#6 Nusakan   Members   


Posted 24 May 2013 - 10:31 AM

I think the complexity of the state machine depends on how we implemented it. If we use the old school FSM (with switch statements and if statements under one huge file) we are more likely encounter with the term "spaghettification".  


If we implement an FSM that uses the abstract class (I think its called modular FSM) the complexity will be reduced a lot since each set of rules for each state will  run only on their class scopes.  This also gives us the power of adding new states and running parallel states at the same time. An example would be a global state "Attack" and  the inner states of the Attack, like you described on your post. However, we might also end up with duplicated codes no matter how much we hate. 

Edited by Nusakan, 24 May 2013 - 10:33 AM.

#7 Gorge Express   Members   


Posted 26 May 2013 - 10:23 AM

Thanks for all the input.


fun fact: Not only did Nintendo have to position the sword near Link's hand each different frame, but they also had to determine how to rotate the sprite. There are 36 different frames of the normal sword swinging animation, but only 8 different sprites for the sword. Link himself usually consists of 2 different sprites(he is only 1 sprite in some arbitrary frames) and they just change the x and y position of his head to make it look animated. Must have been fun doing all that in assembly. 


Anyways, what is a good way to deal with the timing of  actions specifically? That is, the activation/addition of a hitbox to the sword after a delay(or the check to see if an enemy is in front of the player), and the removal of the sword+reverting the state of the player back to normal after the action(which lasts an unknown amount of time) is done? The action must also end early if the player is hit. 

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.