Aztez – A Game of Conquest and Brutality
8Sep/1427

Frame By Frame: The Sword’s Basics

In the interest of both exposing the nitty gritty details of our really powerful combat technology and also sharing some design insight, I'm going to open up some of the sword's basic standing mechanics for viewing at the frame by frame level. Information at the frame level is typically only of interest to the designers or to the master class player types who are operating at competitive levels, but I'm going to try and make this fun and accessible by using (hopefully) easy-to-look-at-and-understand animated timelines. But first, let's take at the game's very first standing sword A attack. It's probably the first attack the player ever sees.

Sword Standing A1

MoveFrameDataSWORDSTANDINGA1

The timelines contain the following properties (please note that while these GIFs are rendered at 30fps, the game runs at 60 frames per second):

  • Hit Box Active: This is when the hit box on the move is on and will force a response on anything inside of it.
  • Dash Cancel: This is the window in which the move can be cancelled into a dash with dash input.
  • Movement Cancel: This is the window in which the move can be cancelled into regular left/right movement with left/right input.
  • Block Cancel: This is the window in which the move can be cancelled into a block with block input.
  • Absorb Cancel: This is the window in which the move can be cancelled into blood absorption with blood absorption input.
  • Next Move Listen: This is the window in which the game is listening for the player's A or B attack button input in order to fire the next move in the designer-made combo. In this case, "Sword Standing A1" links into "Sword Standing A2" and "Sword Standing B2".
  • Next Move Fire: This is the window in which the game will take the input it heard and fire the move. If it hears the input before this window opens, it will buffer the input and fire it automatically on the frame the window opens. If it hears the input while the window is open, it will just fire the move in the next frame.
  • Tech Move Listen: This is the window in which the game is listening for the player's command move input, which is up or down input plus A or B attack input.
  • Tech Move Fire: This is the window in which the game will take the input it heard and fire the command move.
  • Translation Active: This is the window in which the player character is translated during the move.

If the player pushes the A button again at any point during this move, and continues to push A, they will see the following 4 attacks:

Sword Standing A2

MoveFrameDataSWORDSTANDINGA2

Sword Standing A3

MoveFrameDataSWORDSTANDINGA3

Sword Standing A4

MoveFrameDataSWORDSTANDINGA4

Sword Standing A5

 

MoveFrameDataSWORDSTANDINGA5

There's the entire Standing Sword A button combo. Let's take a look at some of the principles at work here!

  • Highly Flexible Canceling: All of these moves can be canceled at any point in the animation with a block, or a dash, or absorption. This was absolutely intentional from the start because I knew I wanted large groups of HIGHLY aggressive enemies, but I also wanted the player to respond with high aggression which is why the canceling windows are so liberal! If a player in Aztez is struck, it's because they didn't respond quickly enough, and not because they threw the wrong attack at the wrong time and they couldn't bail. This is also part of the courtesy Aztez extends to mashers; if you don't want to get intellectually bogged down in exactly what attack you're throwing, you're still safe if you're paying attention.
  • Movement Canceling At The End Of All Moves: No matter what weapon or what attack you're throwing, you can bail out of it at the end with movement input to avoid the Amalur Problem. TL;DR is that it makes a huge difference in the feel of a move if you don't have to sit through the entire animation, especially when you're in an energized state where you can't take your finger off the directional input.
  • Liberal Command Move Canceling: This one is interesting because I originally implemented these combos so that the command moves listened for input and fired it at the same time the next move fired, instead of just listening the whole move and firing immediately the way they do now. But high level players of mine would eventually tell me that because of the mobile properties of some command moves, they wanted to be able cancel with these moves at any point in the move INSTEAD of blocking/canceling/dashing in order to preserve a certain kind of momentum. Since the only downside was that you could now spunk the command move before the original attack hitbox opens, I obliged. After all, this makes it more interesting! "Do I let the hitbox open on the Sword Standing A3 and THEN cancel into the Up A command move, or do I do it NOW, lose the damage, and preempt this incoming enemy attack with a mobile hitbox of my own?!"
  • Translation From The Very Start: Making sure that attacker translation occurs right from frame 1 is a big contributor to brilliant attack mechanics. You want as much feedback as possible to go off THE INSTANT the players hits the attack button, and most forms of feedback just aren't practical at frame 1, but translation is!
  • Restricted Final Hit: Note that in the final Sword Standing A attack, there are no direct links to further attacks. Since it's the end of the designer created sequence, it makes sense that there isn't a listener for a "next move". But there's no listener for command moves because this is a big, powerful, final hit and it was designed to be the "...period at the end of a sentence." as the magnificent Saurian Dash once so eloquently put it. If you want to maintain your aggression once you've finished the sequence, you have to do some semi-fancy canceling. It is me putting a bit of a skill barrier in place to encourage the player to get comfortable starting and ending interesting sentences over and over again.
  • Deceleration Into Big Finish: There is a subtle thing happening throughout this entire 5 hit sequence (and in all other designer-made weapon sequences in the game); the sequence decelerates. Notice that with every attack, the hit box gets pushed back a little bit, the translation window gets a little longer, and the next move fires a little later than the last one did. So from a player point of view (assuming they're mashing the A button as fast as they can), what happens is that they begin mashing and the 1st attack hits in 8 frames, and then 22 frames later the 2nd attack hits, and then 24 frames later the 3rd attack hits, and then 28 frames later the 4th attack hits, and then 34 frames later the 5th attack finally hits, and the enemy is sent flying. This is subtle, but makes a serious difference in the sequence's overall sensation of power. This was a key piece of insight given to me by Eric Williams, one of the original God Of War designers and all around amazing dude. If done correctly, you get a rhythm that "looks" like this:

---!-----!-------!--------!------------!!!

These are just some of the principles, but they are biggies. There are subtle changes across the different weapon both in their mash sequences and their command moves, but they all adhere to the key ideas outlined here. If there's anything else you want me to elaborate on, bounce on into the comments and I'll see you there.

  • This was fascinating read, and as a beat ’em up newbie, seeing the full timeline for each animation really helps my understanding.

    Could you explain a bit more about what you mean by attacker translation? Is that predefined player character movement triggered by the attack itself? If so, where are the translation vectors defined?

    • Thanks! Glad you dug it!

      You’re right about attacker translation. I can animate the character’s position during the animation at any point to and from any point. I determine that in the move with the rest of the move properties, they’re just not displayed in the images here.

      • Hi Ben! Awesome blog, I followed all posts!
        How is translation implemented? Do you do it in Animation Timeline? Than, how do you synchronize the moves so that the next one comes at the same place where current one finishes?
        Also do you have translation and sprite animation in the same object? (otherwise I can’t see how you link them).
        Thanks in advance,
        Aldo

  • zain

    **EDIT** Fixed your revision. -Ben

    Amazing read !

    Can you please let me know whether you are using crossfade for each animation when they sync, or its just animation played one after another.

    And could you please post a web player demo where we can test out the combo, like how you did for the attack animtion earlier.

    This is amazing and thank you so much for the insight. I have been following your blog and Aztez since long time. Really Informative!

    • Thank you! And to answer your question, we’re just jumping right from animation to animation. It seems like it would be abrupt but it all happens so fast (at least in Aztez) that it isn’t really. And I animate for transitions; you’ll notice that when the move finally fires into the next move, that point in the animation is roughly where the next animation begins to mitigate noticeable transition.

      A web player demo of the combo is a good idea! I’ll see what I can cook up!

      • zain

        Great! I think i got it!

        Eagerly waiting for the web player demo!

  • As someone who may or may not be in the very early stages of making a fighting game, thank you immensly for this useful post! The reasoning behind how and when to cancel moves especially is of particular use to me, as well as the idea of immediate feedback through translation, which I hadn’t thought of yet!

    • Oops, I forgot, but I’d to add a question to this: Say you’re in attack A1, and the user hits ‘A’ on frame 3, then ‘A’ gets buffered and attack A2 gets executed on frame 10 (in the .gif at least, so I’m just staying 1:1 with that). However, what happens (or rather: do you feel should happen) when the player then hits ‘B’ on frame 8 for instance. Does the buffer get overriden, or does it stay on ‘A’? Note that I haven’t played with this at all yet, but just thought I’d throw the question out there. =)

      • Hey Pat! In Aztez, in a competition between moves eligible for buffering, the first inputted will always fire when the fire window opens. However, any eligible cancels (block/absorb/dash) will still work. So if you’re 3 frames into A1 and hit the A input, A2 will fire in 15 frames, but you can still block, dash, or absorb cancel before A2 fires at 20 frames.

        • Ah ok, that makes sense! So the buffer is first-come-first-serve, and cancels trump all, got it! =) Like I said, I haven’t really played with it yet, but it’s always good to have some reference & input, and this sounds pretty solid to me. Thanks! 0/

  • Tom

    Hey Ben, I really appreciate all the insight into the game. Small question though. I’m working on a combat gaming and am worried about our dash/dodge being too powerful. Just wondering Is your dash invulnerable and if so for the entirety of the move? Also can you instant cancel from dash into any move? Or just tech moves? Or back into dash again?

    Thanks

    • Hi, Tom! Do you know that I know Andrea and Andrew and am familiar with your game?

      I have 6 frames of invulnerability at the beginning of all of my dashes. It’s there so that if the player dodges at the last second it functions as a defensive maneuver. I don’t think this is too powerful, because it requires a non-trivial amount of skill to use as a safety mechanism.

      *EDIT*

      You can cancel all of the dashes (every weapon has a unique dash) into any of the command moves, with a few exceptions based on the specific dash. But when in a dash state, the A and B attack buttons become unique attack mechanics (as opposed to just firing the standing A1/B1 attacks), and one of the two is always there to initiate new assaults. None of the weapons can dash out of their dashes, with the exception of the spear. But even the spear only allows this once. I experimented with dash into dash cancelling but it was too powerful and essentially replaced walking.

      • Tom

        Thanks Ben! I’m super excited for Aztez as I’m kinda deep into combat mechanics and I’m looking forward into breaking it down. It looks super fun and satisfying.

        Yea Andrew and Andrea speak highly of you and your work and I really appreciated the feedback you gave us when you played the game. Its come on a tremendous amount since that point in time. Still loads to do but we’re progressing all the time. We’ve just been discussing dodging and dashing a lot recently and are trying to find a balance in what are relatively tight encounter spaces. I’ve a couple of ideas I want to try out soon. Hopefully we can send you a build someday soon and you can try it out again. Thanks

        • Right on, glad everything is still going well on Onikira! And it’s nice to meet you.

          I just realized I didn’t fully answer your question! I edited it with the rest of your questions answered…

  • John

    Doesn’t frame 1 translation and an early tech move cancel window mean that all tech moves can be kara’d? If so, how do you design around that?

    • It absolutely does!

      For anyone who doesn’t know what a “Kara” is, it’s when a mechanic with useful translation properties is intentionally cancelled right after start up into a different mechanic so that the second mechanic can utilize the useful translation on the first. For example, throwing a standing jab with Remy in SF3 and then immediately throwing. What is normally not a throw with any translation now gets some range, as that cancelled jab slid Remy forward a few pixels.

      To be honest, I don’t design around it. I decided early on that if an exploit doesn’t actually make the game’s combat easier, then I’m not going to mess with it. As it stands, the player can Kara across the play space like a maniac, but it’s not very useful in any particular way. The game is already loaded with super aggressive gap closers (dashes and long jumps galore) so performing any Kara techniques are just comparatively useless.

      Now, I fully realize that the players can and will discover exploits in the system, and if any of those (Kara related or not) make the combat easier when it shouldn’t, I’ll nip it in the bud.

  • nicholas ralabate

    whoa this is rad i want you to do this for every game.

    when you tune your windows, do you prioritize one window over the other? it seems like a bear to deal with ten different windows. also, do you tend to tune in code (change a number, recompile) or are you more playing with sliders in-game?

    also quick AV question — i notice the kicked-up-dust particles decay right when the movement cancel windows open up. is that intentional, if so do you think players will key into it on study or would it be more subconscious?

    ALSO, thanks for the ACES WILD rec on your twitter that game was great.

    • Thanks! I want to answer your questions, but I’m not totally sure what you mean. I think when you say “window”, you’re referring to the individual values that I chose to represent in the timelines with a colored bar. Truthfully, there are a huge amount of values in every mechanic, and I’ve only represented a few in these images. And I can’t really prioritize any of them in particular because they’re all crucial to the mechanic. Did you maybe mean to ask if I spend more time with any of them? Because I don’t believe I do.

      When I’m in Unity, most of these values are just values in fields. There aren’t really any sliders or anything like that.

      The rate of decay on the dust particles has no intended meaning. There’s plenty of effects that DO have meaningful cues, that just doesn’t happen to be one of them. It does appear to reliably indicate the movement canceling window though!

      • nicholas ralabate

        Yeah, you answered my question on time-spent… Thanks! Can’t wait to play some.

  • Really neat write up! I am redoing all the animations in Unity now using a tool I had a hand in writing called Unity Sprites and Bones, this gives me some ideas on how to use Unity’s animation editor with some of the code I will cook up to work with my current input and state handling. Thanks for this!

  • N.K.O.GD(new kid on game design)

    brilliant article real points out a lot of concepts I’ve seen in good beat em ups but helped me understand them on another level i have a question tho is that an in house asset that you used to show the frames like that?

    • No, I created these images by hand in Photoshop. I took footage of the attack, turned it into a GIF, and then used the GIF in the image.

      • N.K.O.GD(new kid on game design)

        So how would i go about creating combo’s and special attacks like a “hadoken”?

  • correojon

    Great article, I´ve been following your blog for some time now and I really love all your write ups, they are always full of insightful information. I always end up wanting to make a beat´em up of my own, but unfortunately I don´t have much spare time and just animating the characters would take me forever (btw, if you have any suggestions about any tools that could help with this I´d really appreciate it).

    May I suggest some future entries?

    Enemy behavior: I suppose the enemies will follow almost the same basic structure for their attacks as what you´ve explained here for the player, but how do you incorporated tells? I mean, when an enemy is going to attack they may shine or make a special noise or something that tells the player to watch out. Are you using this in Aztez? Also, I would like to know how you manage group behaviour, do you appoint a leader that attacks while the rest stays on the back waiting their turn, for example?

    Bayonetta 2 combat review: I love your reviews of beat´em ups mechanics and this game deserves one. You already did a review of Bayo1 but you didn´t go much into the combat mechanichs, so this may be an opportunity to go deep into them, or maybe do a comparison between Bayo1&2 addressing the differences in the combat mechanichs or other stuff.

    Good luck with Aztez and keep up with the great work!

    • Check out the front page of the blog! I got you covered. :)

      And thank you for the kind words!

  • siba2893

    Just for ask, which application are you guys using to make this animation?

    • RobMoody

      They are using Unity mate