Walking And Running Implementation
When analog sticks were born, the way walking and running was implemented in games changed. But before I go into that, it's important to understand the key differences between the joystick on a traditional arcade machine and the little analog stick on your console controller. When you push on an arcade stick, it's pressing down on one or two of four different little buttons that lie underneath the stick. Each button only has two states: pushed and non-pushed. So when you push the stick upward it's going to press on the northern button and when you push the stick up and left it's pressing on both the northern button and the western button.
Now when you push on an analog stick, it's cross-referencing two different axises (a "left to right" axis and a "up to down" axis) and the controller is finding the precise location the stick is resting at, which could be anywhere inside that plastic circle your analog stick is poking out of. With all this extra possibility space, you can alter the way the player tells the character on the screen to move. What I'm gonna talk about here is the three major ways this can be done based on the implementation across a handful of different games. The first variant of this is the most straightforward.
In these images the circle represents the analog stick possibility space. When the stick is not being touched it is resting inside the "deadzone". The deadzone is a very important mechanism on sticks of all kinds because it prevents input from registering until the stick is pushed on a specific amount. The reason you want this feature on a stick is to make it less sensitive to three meddling forms of very minor input:
- The thumb or finger of the player lightly pressing the stick.
- The stick being very subtly "stuck" a little bit in one direction.
- The microscopic bouncing that happens when the player lets go of the stick from a tilted position.
Truthfully, these three things are constantly happening but you don't know it because we game developers have been smart enough to make sure there is a deadzone on the sticks we make games for. Getting back to the this specific implementation, it was used in Viewtiful Joe but is the same in just about every traditional beat-em-up, since they couldn't help it on account of their simple joysticks. By pushing the stick past the deadzone, the character will move in the direction pushed at a specific speed while a movement animation plays at a specific speed. Very simple and again, very traditional. Easy to implement in every case. This next one is a little more complicated.
Devil May Cry and Bayonetta have given the player the ability to walk at a slightly slower rate if they so choose. By pushing the stick past the deadzone but not full-tilt, the character will walk in the direction pushed, and they will do so at a specific speed while a unique walking animation plays at a specific speed. When pushed all the way to the edge the character will run, and they will do so at a specific speed while a unique running animation plays at a specific speed. Slightly more complicated but not particularly difficult to implement, even in 3d. This last one is the most realistic looking of all these three major control types, but also the most convoluted and difficult to implement.
The characters in these games have two different movement animations: a walking and a running. Based on how far the analog stick is being pressed, the animations will not only be cross-faded into each other at different values (which only works with 3d animation), but the character will be moved at a very precise speed somewhere between not-moving and full speed. So if the player is pushing the stick 75% out from its default position in the deadzone, the character will be employing 25% of the walk animation data and 75% of the run animation data and will be moving through space at 75% of the character's top speed. It's why you can do everything from a slow tiptoe to a gallant trot to full-blown running in these games. But it's also very difficult to implement as the animations not only need to look good individually, but they need to look good at varying degrees of animation cross-fade. Personally, I find this all moot since no one ever walks in a beat-em-up unless they are specifically incentivized by the game. But this is where Matthew disagrees with me and says that it is part of the charm and polish and I'm not going to argue with that; but I'm also not going to kill myself implementing it! So we're going with a system very similar to one used in Bayonetta and Devil May Cry.
There is a little bit more information here only because we will be using up and down in attack mechanics; it would be frustrating trying to push up or down in a combo and have the game think that you are trying to move. So those upper and lower quadrants act as a deadzone, but only when it comes to movement. At the end of the day, you will be able to walk with the character if you so choose and it should be fairly easy to do. It's not the best way of doing it as a general rule, but it is the way of doing it in Aztez.
I’m Declaring War On Tedium
Over the course of the last year I have gone and devoured every beat-em-up I could get my compulsive hands on. It's been a lot fun because I love these games to death, but it's also been very frustrating because oftentimes I am required to perform very trivial tasks in order to progress. I realize this problem extends deep into many other genres as well, but it's particularly sticky with modern beat-em-ups because the features and mechanics that have been stacked on top of them to make them more appealing and engaging are inherently tedious.
The worst offender of these modern mechanisms is story, and the cutscenes that so frequently accompany them. Designers have taken the perfectly scant stories of the old arcade action games and erroneously assumed that the player needs a plotline and cutscenes and dialogue to stay engaged inside an action game environment. This simply isn't true, all the player needs is a motivating concept, i.e. save your girlfriend or clean up the streets. None of these require intricate explanations or drawn out custscenes, they just need to be openly stated. It is very important to note that I am addressing beat-em-up gamers here. If you were to kill the story and the cutscenes in a Final Fantasy game, you would alienate the people who play those games and consider those features to be core components of the experience. But no one has ever picked up a great beat-em-up with great gameplay and said "I don't want to play this great beat-em-up because there just isn't enough story." And while we're talking about it, let me just say this; I simply cannot excuse the hugely offensive decision that many designers have made to not let the player skip a custscene.
Feature unlocking is another huge distributor of tedium in action games and it must die immediately. It makes plenty of sense in other types of games for other types of players who are motivated by Pavlovian reward structures and love to see new things come into their possession at regular intervals. But again, the typical action gamer is playing your beat-em-up in the first place because they want to experience the sensation and thrill of combat. Anything and everything that is put behind a locked door in a game of this nature is something the player could have been given right from the start to increase their overall enjoyment of the game. I'm assuming the popular logic here is that you want the player to be motivated to complete your game or to perform certain tasks, and that unlockables act as a carrot in front of their face. This simply isn't true, all the player needs is a fun game. No one has ever picked up a great beat-em-up with great gameplay and said "I don't want to play this great beat-em-up because there just isn't enough things to unlock. There's too many features and mechanics available to me right from the start and I'm overwhelmed with fun!" And while we're talking about it, let me just say this; I simply cannot excuse the hugely offensive decision that many designers have made to make me unlock amazing weapons and gameplay modes for absolutely no reason.
Game structure is a much more subtle problem but no less important, both in and out of the main gameplay mode. There are just too many places in a typical game where the player must sit through something that takes way too long to play itself out. Why must the player sit through a bunch of logo/loading screens and then push a bunch of buttons and watch some irrelevant cutscenes to start playing the really fun game? Why does the player have to complete arbitrary chores over and over again? Why is this vehicle segment or quick-time-event so lengthy? There are too many times that the game puts the player in this awkward position where they are up against a tedium stack and that's when players stop playing. Quit doing this to the people trying to enjoy your game! No one has ever picked up a great beat-em-up with great gameplay and said "I don't want to play this great beat-em-up because there's just not enough time in between the fun parts of this great gameplay." And while we're talking about it, let me just say this; I simply cannot excuse the hugely offensive decision that many designers have made to make me run through an entire section of level just to make another attempt to defeat a monotonous boss.
I intend to circumvent these problems entirely with Aztez. The player is not going to have to sit through anything they don't want to. Anything that can be turned off or shortened CAN be if the player chooses. If a mechanic makes the game more fun, it will be available from the start. The goal here is to eliminate all of those moments where the player just wants to get back to having fun.
Challenge Vs. Punishment
One of the fundamental components of an engaging game (card, board, electronic, party, etc.) is that there is some degree of difficulty between starting the game and arriving at the success state, whatever that may be. While this can be applied to games of all lengths and depths, the bottom line is that a player that goes unchallenged for too long is going to get bored. It's one of the amazing properties we possess as living creatures; we need to go face to face with our environment in SOME way or else we start feeling numb.
The geniuses that developed the first arcade games realized that tapping into this evolutionary compulsion was the perfect business model. They realized that by engaging players hard enough with a game they must pay to play, then they will happily pay to play...over and over again. This is why coin-operated games were often times so difficult yet so successful; they managed to find the sweet spot between compelling and punishing. The problem here is that a lot of us game designers who grew up playing those games still think that challenge must be appropriated in those archaic ways. But times have changed. Different kinds people are playing different kinds of games and expectations have mutated, for better or worse.
Now I want to talk about Super Meat Boy for a quick second. Edmund McMillen (one of the two developers of the game) wrote an awesome post on the Team Meat blog about challenge in games and he broke it down into a really straightforward formula; (% chance the player will die) x (Penalty for dying) = Difficulty. This formula is basically addressing the player concern of "How often will I fail and how much and I going to be punished for it?" Super Meat Boy answers this question in a very distinct way - you die very often and are punished very little. This was a conscious decision on the part of Team Meat and they have specifically constructed all of their levels around this equation.
So what does this have to do with Aztez? It has to do with the fact that we are also going to answer this question in a very distinct way; by making it very difficult to die in addition to punishing you very little when you do. Of course this seems to introduce the problem of having too little challenge, and I absolutely agree that the danger is there. So my perceived solution to this potential problem is to alter the nature of the challenge itself and design accordingly. Instead of challenging the player to not die, Aztez will challenge the player to perform very well (phase 1 of the game). Games like Tony Hawk Pro Skater and Off-Road Velociraptor Safari have done this to great effect; the onus is on the player to accumulate high scores in creative ways as opposed to avoiding a death state. The only problem with those types of games is they are timed and you are restricted to experiencing the game in specific difficulty levels in specific amounts of time. I believe there is a way to circumvent these traditional restrictions and still create an engaging game.
How are we going to do this? Don't know yet! But I'll tell you this much - I'm asking the following questions: What if the player had control over the difficulty of the game on a moment-to-moment basis? What if the player could end the current gameplay segment whenever they wanted? What if the player was rewarded for taking creative risks by having their punishment states delayed, or even eliminated? Help me out here, gamers! 
Alpha Channel Problem In Unity
I just thought I would throw this out here because Unity has this unusual quirk and it has driven me (along with some other very talented developer friends of mine) to the brink of cosmic insanity. If you have ever created a texture in Unity that has an alpha channel but the alpha information in Unity is completely incorrect, then it's most likely because you have "empty pixels" in your RGB channels. What are empty pixels? Just think about anytime you've erased all the way through your layers in Photoshop and you can see the white and grey grid underneath. You can see that grid because you've removed color information from those areas and Photoshop just wants you to know that. Unity understands those empty pixels and will create an alpha channel for you if you have them in your image.
A quick and easy way to to test this out:
- Create a new layer at the bottom of the layer stack.
- Fill the whole thing with an arbitrary color.
- Re-save it and check it out in Unity. You should now see an alpha on the texture in Unity that looks like the alpha channel you intentionally created.
This happens because Unity has two different ways of recognizing transparent elements in a texture. One of these ways is through the alpha channel, and the other way is through empty pixels in the RGB channels. When it sees both it simply defers to the empty pixels. So all you have to do is fill those up with something so it knows it needs to look at the actual alpha channel. I hope this saves you some furious self-hair-removal.
The Attributes Of An Attack
Every single attack in a beat-em-up game contains a specific combination of attributes that determine the aesthetic and gameplay properties of an attack and subsequently, the combos the different attacks will form. This is a list of all the attributes that an attack could possibly have. It is very much a work in progress and was built entirely by reverse engineering existing beat-em-ups with analytical gameplay. I'm sure that a lot of these things will be repeatedly tweaked and played with, and I'm also quite sure that there are properties out there in the wild that I have yet to include. I'm exposing it so that it can be refined under scrutiny and implemented effectively!
First and foremost, there are two different types of attacks: Base Attacks and Connecting Attacks. Base Attacks are the kind of attacks that start combos. The player simply need to provide specific input while the character is in a specific state, i.e standing or jumping. Most attacks (both Basic and Connecting) possess "outgoing connections", which are windows of time within the animation in which a new attack can start, provided the player provides the right input before a designer-specified frame later in the animation. When the player does this successfully it is called a "successful connection" and a new attack in the combo will begin. If the player does not make a successful connection they are "dumped" back into a default state, i.e. standing or falling.
The most important part about building combos this way is that an attack can connect into many different attacks depending on which button the player pushes and at what time in the animation they push it. This is done to great effect in Bayonetta and Devil May Cry; you can perform a pretty straightforward combo by pushing Attack, Attack, Attack, but you can also push Attack, Attack, then wait half a second before pushing Attack again to see an entirely different combo. Of course this could potentially apply to any attack in a combo, not just the last attack. Obviously, every outgoing connection expands the possibility space the player can explore and this principle is what differentiates rigid, traditional combat from more modern, creative combat.
Universal Attack Properties:
- Attack Name - The identifying value.
- Attack Time Line Length - The length of the attack in frames. Very powerful value that overrides the length of the animation that the attack utilizes and squishes or stretches it neatly into the length specified here. It is against this length that all attack values are specified within. It is at the end of this time line that state dump occurs if no connections are made.
- Prerequisite State - The state the player character must be in in order for this attack to occur. This is an incredibly important property and determines whether or not the attack is a Base Attack or Connecting Attack. If one of the default states are chosen, i.e. Standing, Running, Dashing, Jumping, etc., then the attack is a Base Attack. If "Connecting" is chosen then the attack will only ever occur if another attack connects to it from within a combo. If the attack is a Connecting Attack, then the Base Input Array and Base Charge Capabilities options will no longer be accessible since you perform the input of a connecting attack from within other attacks.
- Base Input Array - A button, a button-charge, a combination of buttons pressed simultaneously, or sequence of buttons pushed in quick succession that the player must push in order to successfully perform the attack. If an input sequence is being utilized, the combat designer needs to be able to not only determine the exact sequence but manage the timing of the sequence as well in order to tweak the difficulty of execution on a per-attack basis
- Base Charge Capabilities - Determines whether the player can strengthen the attack by holding down the attack button instead of simply pressing it. If an attack can be charged, a variety of sub-values must be determined: which frame of the animation the character gets suspended in until the button is released, whether the attack will "Auto-Fire" after so many seconds of button holding or if it can be held indefinitely, and how much additional damage the attack will do if it successfully hits an enemy character in the various states of the charge.
- Character Animation - The animation that plays when the attack occurs.
- Weapon Effect - The visual effect object that gets instantiated when the attack occurs. Can manage timing of sub-effects inside the object itself instead of here.
- Angle Of Slash Effect - Orientation at which to instantiate the slash effect so it looks correct - see number 6 on the impact effects post.
- Target Animation Type - Type of animation the target character will play when successfully hit, i.e. a getting-hit-from-above animation or a knocked-down animation. Alternatively, the target can be forced into a ragdoll state.
- Attacker Translation - The manner in which the attacker will move around the screen as this attack occurs. If translation is to occur, the combat designer must specify a variety of sub-values: The direction the player will move, the distance the player will travel, the time after state entry that translation begins, the time after the translation start that translation ends, the translation acceleration type (whether it's linear or curved), and the translation path type (whether it's linear or curved). Ideally, the designer can create an array of translations so that if they want the attacking character to move multiple times in multiple directions they can.
- Damage Object - The invisible object inside the character's skeletal hierarchy that functions as a hit box for the attack. In our engine, there will be a whole slew of invisible hit boxes attached to the character's weapon at all times, and it's up to the combat designer to specify which object is used with this property and determine how it behaves with the next two properties.
- Damage Object Active Window - The frames of the animation in which the hit box will be active and and the attack can actually affect an enemy character.
- Damage Object Translation - The manner in which a damage object moves through space; this is used mainly to create attacks with projectile-like properties, but also just to fine-tune the feeling of certain attacks where a hit box will have to move to feel right. The combat designer will have to specify a variety of sub-values: the direction the attack object will move, the distance the damage object will travel, the time after state entry that the translation begins, the time after the translation start that the translation ends, the translation acceleration type (whether it's linear or curved), and the translation path type (whether it's linear or curved).
- Damage Type - The type of damage that a successful hit inflicts upon the character that has been struck: Stun Damage damages the target and forces them into temporary state in which they cannot act, and the combat designer must specify the length of the stun and the amount of damage dealt. This is the most straightforward type of damage that is used to keep an enemy in place temporarily while the player attempts to finish their combo. Deterministic Knock Away Damage damages the target but also pushes them around in a very controlled way. In addition to specifying the amount of damage dealt, the combat designer must specify the usual set of translation sub-values: target direction, target distance, translation start time, translation end time, translation acceleration, and translation path type. Physical Knock Away Damage damages the character but moves them around with physical force calculated by the game engine. The combat designer must specify a couple sub-values: the direction the target will get pushed in, the amount of physical force used to push the character, the gravity used in this specific attack, and the amount of drag on the target character as they are pushed around. Sacrifice Damage kills the target character immediately but still rewards the player with blood. Disintegration Damage kills the target immediately but they the player receives no blood. For all damage types except Disintegration Damage, the combat designer must specify how much blood the player receives for successfully hitting with the attack and how much blood the enemy loses when struck. These values are intentionally independent.
- Player Character Hit Box Switch - Provides the option to turn off the player character's hit box during certain attacks to create invulnerability windows. If employed, the combat designer must specify the frames within the animation to turn the hit box on and off. Additionally, the attack may utilize a completely different hit box for the duration of the attack; it simply needs to be specified here.
An attack can have an entire array (or not) of outgoing connections and for every one the combat designer must specify the following values:
- Destination Attack - The attack that is performed if the player successfully connects.
- Required Input Array - A button, a button-charge, a combination of buttons pressed simultaneously, or sequence of buttons pushed in quick succession that the player must push in order to successfully connect.
- Required Charge Capabilities - Determines whether the player can strengthen the attack by holding down the attack button instead of simply pressing it.
- Connection Window - The frames in the attack time line in which successful connection will occur if the game receives the Required Input Array.
- Transition Frame - A frame near the end of the animation time line that acts as a animation splitter. If there is a successful connection, the character's current attack animation will cancel when they hit this frame and the Destination Attack time line begins immediately. If there is no successful connection, then the animation will continue to play through the Transition Frame all the way to it's end, at which point the character is forced into the Dump State (see below). This is used not only to maintain smooth animation transitions in combos, but shaves off time between successful attacks.
- Dump State - The state that the character defers to at the end of the attack time line if a successful connection is not made.
With these properties in place we will be able to implement the following mechanics:
- Attacks that can be performed from a standing, jumping, falling, or dashing state that can start combos.
- Attacks that have wide varieties of connecting attacks that can be easily utilized by using different input and timing.
- Attacks that end combos in sensational ways.
- Attacks that move both the player and the enemy around during attacks and combos (which feels powerful).
- Command moves that are executed with a specific input sequence.
- Movement techniques that move the player character around that can also damage enemies.
- The ability to integrate both sacrifice and command moves into combos.
- Invulnerability windows that occur during specific attacks and techniques.
For a little bit of visual elaboration, check out this image. It shows A - what happens upon attack state start, B - the window of time in which the player is being moved, C - the window of time in which the weapon's hit box is active and can actually hit something it's colliding with, E - the time in the animation in which the animation will be cut short upon successful connection, and F - the end of the state in which state dump occurs and the character is returned to their idle state.
That's it so far; please help me refine it!
Introducing: The Priest
The Aztec Priests had a special place in Aztec society as the individuals who interfaced directly with the gods through the act of sacrifice. Men became priests after demonstrating great piety in addition to their combat prowess. The raddest part of the Aztec priests were that they continued to do battle and accompanied the warriors in ritual combat.
We will be using priests as our opportunity to experiment with fun magical effects. The idea here is that they have special powers granted to them by the gods. The appearance of a priest means it's time to get tricky as you'll no longer be dealing with simple weapon attacks.
GDC 2010 Highlights
I just got back from the Game Developer's Conference and like usual; it was amazing! As far as Aztez is concerned, I had some very relevant and insightful conversations with some very talented people and I want to share them with you.
It turns out that there is no known doctrine for the creation of beat-em-up games. I had a really great conversation with David Sirlin (please investigate his body of work! He has a lot of really interesting things to say about competitive gameplay and is also a talented designer) about what a beat-em-up looks like under the hood and how fighting games and beat-em-ups are very close relatives. I expressed to him my deep concern that legitimate reference material on the creation of deep combat systems does not appear to exist and he reassured me by saying that most of the designers out there who have made seminal beat-em-ups did the exact same thing I am doing now; intuitively reverse engineering the good combat that has come before them. It's a bummer that there is no reading material on the subject, but that's all the more reason to continue doing what I am doing and to keep exposing it publicly.
I also talked to Robert Velazquez (one of the lead in-game character animators on God Of War 3) after he gave a great session on Sony Santa Monica's animation and design pipeline. I asked him very directly if there were any combat designers that would be willing to talk to me about combat design and he said there very well might be! It turns out there are a good handful of them on the God Of War team. I'm going to contact him shortly about this and hope that one of the uber-talented combat designers there is willing to impart some knowledge on us as we move forward. Hopefully they'll recognize how serious we are about making sure that Aztez is deep and impactful.
Anyway, GDC is over and it's back to business as usual! I'm gonna spool up the blog machine once again, but know this! It's about to get pretty technical around here as I start to talk a little bit about the combat engine we're trying to build! As always, we encourage discussion and the sharing of knowledge so make sure you jump in there with us and help us make Aztez as great as it deserves to be!
Introducing: The Eagle Warrior
The other legendary warrior society one could enter upon successfully taking 4 captives was based on the mystical and divine eagle. The eagle had a very important place in Aztec society as both a majestic flying creature and as a herald of a new age; the ancient Mexica were told by their patron deities to build Tenochtitlan where they saw an eagle devouring a serpent atop a cactus. Truthfully, we do not know how the Eagle warriors differed functionally from the Jaguar warriors, but we know they were equally prestigious and most likely represented a tactical identity. The Eagle warrior was as glorified as the Jaguars and were just as frightening to behold to the common warrior.
The Eagle warriors will fulfill the same need as the Jaguar warriors do in terms of distinction, but will be slightly different threats. The carry different weapons and will fight a little differently from each other, but they will present a similar challenge and both will be far more rewarding to destroy then common and noble warriors.
Introducing: The Jaguar Warrior
When an Aztec noble warrior stepped his game up and took 4 captives, he was then inducted into one of two very special warrior societies. One of these two societies was based on the fierce and powerful jaguar, a highly revered and respected beast (I'll tell you about the other society real soon). Jaguar warriors were some of the most famous warriors in all of Aztec culture; they are celebrated countless times in art and in story and they maintained an inspiring position on and off the battlefield.
When these guys appear things will start to get serious. We will be using these decorated warriors to indicate stiffer competition, which is a classic trick typically done with palette swaps. The idea here is to be able to look at an enemy (in spite of the aesthetic similarity they all bear) and know what you're up against, which is essentially what the Aztecs did with their warriors as a way to trumpet the caliber of their military might.
Introducing: The Noble
Once a young combatant has taken his first captive and proven himself worthy of the warrior life path, he is inducted into the ranks of the noble class. He now has access to higher education, specialized war training, and will have front line position in the ritualized warfare the Aztecs practiced amongst themselves. It is at this point in the life of a budding career warrior that he will begin to form a battle identity and as his exploits increase, so will his formal decoration.
If this guy looks familiar it's because you've seen him in the concept art and in the technical demos. That's right; this is what you'll look like as you start out in the world of Aztez. Just like the noble warrior creates an identity for himself as he continues to fight, so shall you...I'll tell you how later.
About The Aztez Project
Aztez is an Aztec themed beat-em-up game currently in development using Unity3d. It will be playable right in your web browser and it will be completely free. And also incredibly violent.
Aztez is being developed by Ben Ruiz and Matthew Davey. Unsurprisingly, they are both incredibly violent.
Categories
Links
Archives
