In this part of our discussion of Hero 2.0, I’ll be going over, in great detail, the changes we made to the player abilities and why.
Designing anything is a process. This is a common theme in a lot of my posts but I can’t stress it enough. It’s been true with everything I’ve worked on and Card Kingdom is certainly no exception. When we started the enormous task of iterating on our attack system, we had to take baby steps since we knew many of our decisions would build off of each other. To do justice to the iterative nature of our development and give you some insight into our thought processes, I’ll chronologically discuss the changes we made from our Alpha build to our Beta (showed at GDC).
This graph shows our key points of iteration over time. The time in between sections was spent playtesting and polishing.
Direct and Area Attacks
In Alpha, we had two types of grounded attacks: Normal and Area attacks. Normal attacks had a forward conic collision as well as a bit of forward translation. Area attacks had radial collision, a wider range, no forward translation, and a knockdown effect on enemies. The idea was that a player would use Normals as their main attack and Area attacks as a crowd control tool to limit the amount of enemies they had to deal with and to create engagement opportunities. This ideal worked out generally but there were some major problems that were causing frustration in some players affecting the flow of combat.
Since the Hero could only face one of two directions but could still hit enemies at different depths, it was very possible for a player to engage enemies and end up passing them due to forward attack translation. Technically, players could use the Area attack to damage the enemies in that particular circumstance, but that resulted in the flow of combat being interrupted since Area attacks also knocked down enemies. To mitigate the flow-interruption problem and attempt to better accommodate player intent, we added more attacks to the Area attack combo sequence, removed their knockdown property, and more explicitly strengthened the distinction between Area and “Direct” (formerly known as “Normal”) attacks. This change allowed players to direct forward assaults toward enemy groups and use Area attacks to deal further damage while maintaining an appropriate range.
Combo Graph 2.0
Added capability yields added complexity, which, in turn, breeds potential ambiguity in regards to identifying player intent. Prior to the addition of Area attacks, the attack system only had to allow for the two attack combo sequences to be performed linearly; that is, we never had to consider a combo-ing into a Direct attack from an Area attack since the latter basically ended any combo string (due to the knockdown effect). Since we now had additional and more useful Area attacks, players would be more encouraged to use them and we would need to accommodate. So we needed to update the Combo Graph.
In Computer Science, there exists the concept of a graph as a model of representation for a collection of objects with pairwise relationships. Apropos to a combat system, a “combo” (subsequently linked attacks that are triggered without interruption) can be considered as a graph (or, more specifically, a Directed Acyclic Graph) so I like to organize our combo representation as such. This is what our first Combo Graph looked like back in Alpha:
Humble beginnings...
As illustrated above, combo-ing into an Area attack at any point would always end your chain. So, when we added more Area attacks, it forced us to think more meaningfully about the connections between the two combo tracks as well as the purpose of each attack on the two tracks. We began to establish more of a ‘rhythm’ with each track. Each attack’s damage, animation length and immediacy were tuned to fit with the pacing of the track. While each track’s attacks were designed independently, they were designed with a similar rhythm such that we could blend between the two tracks seamlessly and appropriately. Our next iteration looked something like this:
Closer, but still not quite right...
These connections reflected player intent much more accurately. A player who was deeply committed to a direct assault that suddenly had to switch into using attacks with more coverage would be sequenced into an Area attack of greater influence (as opposed to starting from the beginning of the track with a lighter attack).
Dashing
In addition to our Hero’s ground capabilities, we also had Jump and Jump Attack implemented in our Alpha build. For navigation, Jump served two simple purposes: to provide the Hero with a burst of speed for quickly moving around the map and an option for dodging attacks or threats. While these navigational utilities turned out to be quite useful and justified, the airborne aspect of jumping was never really utilized, as we had no airborne targets or grounded threats that could be jumped over.
Jump Attack was a bit of a different story. From day one, Jump Attack felt awesome. It was fast, powerful and felt badass. Players understood Jump Attack since, conceptually, it was just a natural combination of two simple and core abilities, jumping and attacking. Unfortunately, it suffered the same problem as Jump in that it served no airborne purpose. In fact, the attack itself was inherently grounded as it caused the Hero to burst forward toward the ground and create a powerful impact. So, while the attack itself was fun to use, there was essentially an extraneous step to using it as players had to jump before being able to execute the attack. Additionally, after we removed knockdown-type attacks, Jump Attack didn’t really offer any unique tactical advantages. As a result, we cut Jumping entirely and decided to try something new in its stead.
Enter the Dash ability. Dash is a ground-based burst of speed that allows the Hero to ‘pass through’ (ignore collision) enemies and also acts as an attack. It shares Jump’s execution flexibility as players are allowed to cancel attacks into Dash at nearly anytime so it is almost always a very safe avoidance option. Additionally, since players are not locked into an airborne state, many of their options are open again almost immediately, which allows for combo extension and rapid target changes. Being able to pass through enemies also greatly increased Dash’s avoidance as it can effectively remove players from most combat situations.
360 Heading Control
One of the biggest complaints we got about our Alpha build was that the game felt too slow. From the very first time it was brought up, we knew that simply changing the movement speed would not solve this problem but even with the addition of dashing and tuning for increased agility (movement speed, attack translations, range, cancel timings, animations), the pace of the game still didn’t feel right.
Some more critical playtesting revealed the real problem: basically, moving left or right was way faster and easier than moving up or down. Since players could move in any direction but could only face left or right, all the movement influences – attack translations, knockbacks, and dashing – were only applied horizontally which, comparatively, made vertical navigation seem much less effective (note: “vertical” actually refers to movement on the Z-axis since. The Y-axis is mostly irrelevant).
This wasn’t as simply solved as just allowing for more vertical movement influences, however. It seemed that there was inherent dissonance in our offering of analog movement with digital heading. So long as players could move in any direction but only move faster in some, there would be disparity between what the controls allowed and player intent. Ultimately, this concept of preferred axes made us call into question whether this two-way character heading system was appropriate for our game.
Horizontal traversal was much faster than vertical. Players could cover more ground horizontally in the same amount of time.
In an attempt to remain true to the “old school beat-em-up” feel, we started off with a locked, binary character heading system. Given that our characters are flat playing cards, doing so also ensured maximum character visibility, as they would always be seen from the best possible angle. As discussed, this movement model heavily imposes constraints on players; however, it is still a model that is commonly employed by games in this genre for a good reason: it simplifies combat as players only need to align their character with targets to successfully land attacks. But this simplification comes as a cost. Here were some of the large problems we found with this movement model:
- Depth Perception
- It is difficult for players to determine whether an attack will hit at different depths (we actually mitigated this by showing some feedback when enemies were in range).
- Alignment
- Players have to align themselves with enemies before attacking. While this is perfectly easy to understand and execute, it’s another step removed from players being able to express their tactical intent.
- Collinear Targets
- This is really a culmination of the last two problems. When players are nearby targets, horizontally aligned but at different depths (i.e., collinear about the Z-axis), combat becomes rather awkward, as players have to re-align themselves to be facing the target.
So, we removed the lock and all characters could now face in the direction they moved. Initially, I was afraid to even try this out since it was 1) not how most old school beat-em-ups functioned (there’s that “appeal to tradition” fallacy sneaking up on me again) and 2) opened up the potential to see the card-based characters from their thinnest angle. But, since the change was so trivial in terms of implementation, we tried it anyway and it turned out to work fantastically! As soon as anyone tried it out, there was no going back. It was hard to even imagine the game working any other way.
- Intuitive Controls due to natural mapping
- More direct confrontations with enemies
- More intuitive target picking
- More agility. In close ranges, players could use their attacks to close distance
Players could now direct their attacks in any direction which, in turn, resulted in much more expressive gameplay and allowed player intent to come through much more clearly.
Attack Differentiation
After doing some external testing with our new combat systems and tweaks in place, we found we were running into a new problem: players were having trouble seeing the difference between the two types of attacks. We were not effectively communicating the unique affordances of each attack. Considering our audience, this problem should have been expected, as our attack affordances were very subtle (speed, area coverage, hit stun, mobility, damage).
To address this problem, we decided to attach the additional and ancillary property of “cutting direction” to attacks. The hope was that, by explicitly communicating a superficial differentiation, players would become more observant and look for other, more subtle differences. As such, we associated an attack’s cutting direction with a specific death animation (e.g., a kill from a vertical attack would slice the enemy in half vertically) so that their aesthetic presence would be first recognized and would, perhaps, encourage more experimentation.
Additionally, we tuned the two types of attacks to feel and behave more like “light” and “heavy” attacks. Vertical attacks were “heavy” since they were more damaging, slower, and interrupted enemy attacks. Horizontal attacks were “light” as they were quick and safe, did not do as much damage and did not interrupt enemy attacks (instead, they simply slowed down enemy attack animations). Even more explicitly, there are some game elements that require the player to use heavy attacks such as enemies with metal shields and metal, destructible crates.
At this point, our attack affordances can be described as such:
- X Button Attacks
- Light damage
- Quick recovery
- Horizontal cutting direction
- Wide area coverage
- Y Button Attacks
- Heavy damage
- Slow recovery
- Vertical cutting direction
- Narrow area coverage
- Breaks metal objects
Combo Graph 3.0
Players were catching onto to differences between attacks so, now, it was time to update our combo graph again to reflect new behavioral findings. We often found using light attacks to soak in damage up until the last second and dash-cancelling to avoid damage. We also saw players starting off engaging enemies with heavy attack but later canceling into light attacks when enemies later surrounded them. To accommodate these common use cases, we updated the combo graph.
Sometimes, even the smallest changes can make a big impact
The biggest change here was that the light attack sequence was now shorter but much quicker (because of the short recovery period of “Horizontal 2”) and the third horizontal attack, the one with the most area coverage and longest recovery period, could only be used if cancelled into from the heavy attack sequence. This change was most often more properly associated with player intent.
Concluding Lesson
Iterating on the player abilities is a long and often never-ending process. Adaptive designers need to be ready to observe player tendencies, extrapolate misconstrued intent, and tune mechanics and abilities accordingly. What is most important to remember is that, since this is a process, things decided on and implemented earlier on in the process are likely to be proven wrong later. Designers must look critically at all systems and be careful not to take anything for granted or forget about things that have stuck around for a while.
Good designers are diligent, humble, and ready to kill babies.
Thanks for reading. Until next time…
————
Claude Jerome
