My take on “RPG Core Combat Creator” – movement mechanics
In the last post I briefly described my experience with RPG Core Combat Creator course from GameDev.tv. This time I would like to focus on my additions to movement mechanics.
The basic movement system designed by the tutors relies on Raycasting and Navmeshes. The player clicks a location on walkable terrain. Next the Navmesh Agent on the player’s character tries to find the optimal route to that point. This is an ideal solution for a traditional Action RPG, like Diablo. However, I also wanted to add physical combat model.
Physical vs Mathematical combat model
Whenever I analyze systems of a game or attempt to design my own systems I categorize combat into two general models. Mathematical combat is and abstracted model of combat based on timing, range, chance to hit and similar mechanics. The weapon itself in this model serves a decorative purpose. Example: when you perform and attack in Diablo or Path of Exile, your actual attack animation or the weapon model does not matter. These games calculate hit and damage based on the enemy location in relation to the player’s hit range (speaking very generally). The games check how many enemy models are within the area and calculate resulting hits and damage. If another enemy enters the area even a fraction of a second later, the damage will not apply to them, even if the animation or weapon position aligns with that enemy’s model.
As the other end of the spectrum I see Physical combat. In this paradigm, the weapon model’s position predicts hits in combat. Example: in games like Dark Souls you can start attacks in advance and the enemy may walk into an attack that is already in progress. The game may even calculate damage based on whether you hit the enemy with the weapons’s blade or pole. An experimental dungeon crawler Exanima takes physical combat model to the extreme. It calculates weapon velocity and takes into account the actual collision location on the body.
My additions to RPG Core Combat Creator movement mechanics
The lengthy introduction was necessary to justify my movement mechanics additions. Dodge mechanics are not crucial when combat calculations are mathematical. Oftentimes, they are also not very smooth due to the fact that animations may not align with actual hits. Still, these mechanics steadily make their way into more and more ARPGs. However, their purpose is not to enable realistic and dynamic melee combat. Instead, these mechanics serve as a way to avoid damage from constantly growing crowds of enemies or template attacks from bosses.
In my version I needed to give the player a way to avoid physical attacks. The fact that I also added a stagger animation after receiving a hit had the potential to create a severe stun-locking issue. Therefore I introduced 4 additional movement types. Each type has 2 versions: standard and slow. If the player has enough stamina, they will perform a regular dodge/move. If stamina is depleted, they will perform a slower version of that movement.
Each movement has a set stamina cost. Avoiding physical contact is much more convenient using these movements than with only mouse click movement. The entire design of these moves is based on a rather simple state machine. Below you can see the Animator Controller for characters in my game.
All dodge movements are managed by a single blend tree named Defensive movement. It is located just above the Grounded default animation state.
The code that manages movement based on this blend tree is available here.
Reviewing the game for the needs of this blog series after so many months gave me a fresh perspective. I already noticed a major bug in the animator controller, which I will try to remove prior to discontinuing my work on this prototype. To be precise, the Death state is reachable only from Grounded and Attack states. This may mean that if we get stuck in a Get Hit loop or stay in a SitDown position, death animation will not trigger even if we reach zero hit points.
In my next post I will provide an outline of physical combat system. I will demonstrate how I created physical hit mechanics and provide details on how I managed to create combo moves using no code, just animation states and blending.