It’s been a long journey until now, and there is much more to be done. I’ll be completely honest, why I’m writing this blog, it’s more for me than it is for anyone else, but if you’re interested, you might find a bit of useful ideas on how to tackle similar problems in game development.
This month we’ll look into:
- Climbing System
- Combat Revamp
- Game Feel
Climbing System
As many games today feature climbing systems in one way or another, you start to wonder if it’s something they include because everyone else does it or if there’s something more to it. The more I looked into it, the clearer it became – Erebion can’t jump! I don’t plan on adding it in the game because there is too much stuff to take into account if I were to allow the player to freely jump all over the map. The first and most obvious is level bounds. I’d have to make sure that the player can not jump over any level bounds or in pits, and such, even getting stuck within level geometry becomes an increasing risk. The other issue is that I really don’t want to allow the player to Skyrim their way up to the top of Olympus.
Now that the decision is final, I’m left with very flat levels, but we’re set in a fictional Greece, on the mountains; it just doesn’t make any sense to have flat levels. The next best thing to add some verticality is a climbing system. Having verticality in the levels adds a lot of visual breaks, both in the level’s silhouette and in the clearer separation between areas. Importantly, it also breaks the player’s sight line, so you never know what awaits at the top of the next climb.
Ok, the decision is made. How do we actually do it?
The first thing most of us probably do is look at games we like and have the same or a similar system. I know this is the easiest way of solving problems, just copy something that works, but please always keep in mind whether the same system would actually work for your game. It’s not just how the system is implemented, but also whether your team can implement a system like it. I immediately looked into one of my favorite games for answers, which is Breath of the Wild. Now there are a lot of technical challenges in the system in BOTW, and more importantly, the design of a free-form climbing system would break the game bounds too easily. There is also the other consideration, which is the stamina system and the fact that before each climb in BOTW, you first ask yourself can I actually get up there with my current equipment, it was way too many times where I’ve just barely got to the top, using the last few pixels of my stamina bar to jump and grab the ledge. But as I said before, this system would not fit my game’s needs.
On to the next one, then. I thought to myself, maybe something set in Greece? AC: Odyssey was next in line for analysis. It also has a lot of verticality, no stamina system, so getting over obstacles isn’t a hassle. This feels a bit more like what I need, but it still has the same problem of climbing anywhere, so using this as an inspiration would not work for me. What actually did work for me was the climbing animations. Now, for others that are as old as me, you probably remember the very best of the AC series, I’m of course talking about the late, great, Ezio Auditore. I know the AC games have massively evolved from then, but one thing is definitely true: the team on the Ezio games was a fraction of today’s, and they have much less refined tools, so it’s something that a small team could implement today. The other thing about the AC games of old is that you can’t freely climb any surface, but instead find which ledges you can grab. This makes every climb a puzzle to be solved, and I honestly prefer it that way.
I couldn’t just stop there with my research, I had to look at a few more games, just to see if I could see something find something else to be inspired by, or just to use as an excuse to play more games. I just had to give myself the pleasure of looking into the God of War games, not just the new ones, but also the older titles. Now, there is a huge difference between the new games, especially because of the way they switched to a third-person camera instead of a rail camera system. With this, the climbing system also had to change. Many of the games today use a fairly simplistic climbing system with clearly marked climbing holds and the god-awful yellow paint everywhere. Needless to say, Shadow of Nyx will not include this yellow paint, as it takes away so much from the player because they don’t pay attention to their environment, but only look for the game to hold their hand. So definitely something to keep in mind when the art actually starts coming in. But more importantly than the simple climbing system is the fact that these systems use a very standardised distance between each of the climbing points.
So now, finally, to the way I’ve designed and implemented the climbing system. First, I’ve used determined the distance between each climbing point so that I can minimize the amount of animations I need. Of course,e this had to be paired with animations for each of the cardinal directions and diagonals. After this was implemented, I manually added climbing points to the game. This was one of the first pain points in my game, so I decided I needed a tool to help me with this. This was the first time I got sidetracked and made a simplistic tool that adds a “climbing entrance” and above it the first climbing point. After the initial climb point is added, you can go in any direction you desire, and if you select a direction that already has a point there, it selects it, for example if i go up, up, up, then go one down it will select the third one from the root, from there I can make climb points in any direction.
With the climb points out of the way we have to make it so that we can change the player state in order to actually start climbing. I didn’t want the player to clunkily have to get in the exact position and only then be able to start climbing. I need a system that would move the player to the right spot and then change the player’s state. This made me develop an auto-traversal system for this. This takes the control away from the player and simulates how the player would walk up to the exact climb entrance point. This doesn’t use any fancy navigation as the level layout will always have to have a clearance in front of climb points. These are just the rules I have to set for myself. The good thing is that this system will be very useful for other systems, such as the execution system, which we’ll talk about in a later update.
This all works fine right now, the player can engage in the climb point and will move towards it automatically, but moving from one point to another is still not possible. This is quite simply solved by adding a double linked list so that each climb point knows which of its neighbours exist. It’s a simple pattern to use, but it solves our problem. Keep in mind that simple solutions are often better in the long run.
The next thing to tackle is how to exit the climb. This is done by adding an exit in the desired direction and changing the player’s state back to idle when the animation ends. Unity has a great feature in Mechanim where you add State Machine Behaviour to specific animations or groups of animations, such as climbing. But adding an exit at the top added a need for more animations, because not only do we need to exit and move an appropriate distance forward so that we don’t accidentally let the player fall off the edge, we also need an animation and system to enter the climb path from above,… and any direction we choose to exit the path. Now there is the possibility to add a path on which you can not reenter, such as jumping from down to a ledge on your right, but I haven’t yet tackled this. Definitely something to consider in a future update.
I think that’s enough about the first version of the climbing system. You can see a small demo below.
Combat Revamp
The combat system in this game might be a bit more than I could chew when I started this project, and to be frank, I had to do multiple rewrites because I was just too green. But looking at how far I came, it was worth it. I’ve been mostly focusing on enemy reactions and the state changes they undergo based on the damage they’ve received. I’m using a secondary type of “stun” damage for each attack that is attributed to these changes. In a very simplified version of the system, I add up how much damage is done in the last few seconds. If it goes over a threshold, the enemy first flinches, then staggers,s and finally they’re stunned when the bar is full. When an enemy is the stun meter is visible to the player, but the values in between are not visible. And they can flinch multiple times before they are staggered. If they don’t get damage for some time, they start reducing the stun meter over time.
The other biggest change, which is helping with my mental health in order to coordinate every attack, is the addition of the CombatManager class. It helps with solidifying a space where all of the attacks come together, either from the player or the enemy, melee or ranged, every single variation that can be, and handle it in a unified way. Do not misunderstand me, when I say a unified way, I mean in code, each enemy and also the player are then required to handle the event and talk it out, just as a couple in therapy.
There are a lot of things going on here, but I’ll try to simplify it because I’m not trying to write a whole book on this. The simplest version of this goes like this: when an entity attacks, they select an attack from their list and set the stats (these are configured in advance and are adjustable as settings), these also include the stun damage and a desired reaction, such as knocking the enemy into the air. Then the defender takes all of that information and checks with itself if it can oblige the request; if yes, then they also change state, but if not, they downgrade the response and gives feedback. The feedback they provide is actually crucial, as attacks can be blocked or parried, or even some attacks require them to go into a state change and use a paired animation, where both the attacker and defender go into a specific animation.
The other big addition is the stun and execution. I’ve had the Cyclops execution animation done years ago, but there was no system behind it to actually work with the animation; it was just something that looked cool and was honestly a big marketing plot. I knew where I wanted to get the game to be, and the overwhelming response I got on Reddit with that animation reassured me that this needed to be finished. I’ve already mentioned above that you need to fill the stun meter and then the enemy can be executed; this is more or less simple. The tricky part comes when you have to animate this and sync the animations. Anyone who needed to animate two or more characters in a tight sequence knows of the issues of making a good-looking animation where the two characters combine to make a weird-looking silhouette. I’ve tried my best to move the camera in a way that emphasizes the action and gives a clear view of the execution. I’ve also made a deliberate choice to only sync the part of the animation, so that I have a bit of a smoother transition from running state and back to idle. You can see that I can transition from any state into execution; this is because I don’t want to have it start the execution if you’re right next to the enemy, or at max distance to them. It’s also planned to be an “invulnerable” state while executing the enemy, as this is a mini pause from combat that is more than welcome when fighting longer battles.
The other huge time sync and a major hassle was adding a smooth transition for the camera. When the player is in control I use the 3rd person camera controller that Unity provides with Cinemachine, but for cinematic shots I’m using a different system that allows me to position the camera and it’s rotation for each specific animation. For these cinematic shots (and executions) I use the Follow style camera which is then hooked up to two bones on the players rig. These are then actually animated and imported into unity, so that they are always where they need to be, however, this presented a problem. The 3rd person camera uses an offset to the right so the player has a better view of the battlefield in front of them. This offset drove me crazy as I’ve tried so hard to match it, but it never looked right, until I added “Executions to Idle” state which is just the last part of the execution animation split into a new one, so that Cinemachine can start an ease in/out transition from one virtual camera to another. As I said, sometimes the simplest solutions can be the best ones =)
Game Feel
The all-important term that gets thrown around very loosely, and no one is to blame for it, as it was never clearly defined. Today, we’re talking about the immediate feedback the player gets from the game.
With that in mind, I’m of the opinion that you should add as much as you can until it becomes too distracting for the player. With that in mind, I had to add a few things to each attack to make it feel heavier and more impactful (no, I’m not done yet). As said in the previous chapter, I’ve reworked some of the combat system to make it more scalable. With that scalability, I’ve also added the ability for other systems to connect and react when the player hits the enemies, or blocks their attacks with his face 😉
I know a lot of you are using the Steam deck so I had to add vibrations on successful hits. At the moment, they are very basic, just as feedback to me, but are made with extensibility in mind so that the game reacts based on what is happening. You can see in the image below how each event can be manipulated with different curves.
As part of the combat revamp, I’ve also adjusted the enemy reactions based on the amount of stun damage they received within the last few seconds. Of course, each successful attack also has a small visual animation that doesn’t interrupt the enemy.
For the sound system, I started implementing FMOD so that I can have a dynamic audio system for various sound effects and music (when I find a composer). At the moment, the system contains some ambient sounds as a test track and different attack swing/strike/grunt effects to immerse the player and give confirmation to attack hits. There are also dynamic footsteps that react based on the floor type. At the moment I’m not focusing on environmental art at all,l so I had to manually change the ground type for specific parts of the map to test this out. And last, the wind is also dynamic and reacts when you’re indoors vs outdoors.
Camera shake is present in the game from almost the very beginning, but I had to change the way it’s called so it gives me more freedom and uncouples it from other systems.
What’s next?
For all of you who came here, I’d like to thank you for taking the time to read through this. For now I’m focusing on developing a thigher combat loop and more reactions from enemies. This is essential for making a great demo for you guys. Next month’s update should also contain a visual rework for the hoplite so we can see how they should be seen in the demo, if not the final game. I’ve also noticed I’m missing a few key features in the rig for the enemies. I’m definitely adding an inverse IK chain to the body so that I can more easily add more execution animations.