Crafting a Bespoke Dinosaur CCC System (Primal Dominion: Aftermath)
--
|| Introduction
Welcome! I’ve mentioned this project slightly in previous posts and I think it’s a good time to get the cat out of the bag and discuss the improvements and features I’ve created and implemented when making my own Dinosaur Controller, this post is not a complete list of things that I developed but rather what I’d like to focus and talk about.
What’s the game about?
For the sake of focusing just on gameplay on this post, I’ll briefly outline some context for the game.
Primal Dominion: Aftermath (PDA) is a multiplayer shooter comprising 4 teams of varying sizes. Ultimately it’s a free for all between humans and dino’s across different gamemodes.
With that in mind what was important was to analyse what worked in successful games with dinosaur controlled gameplay.
Going to the drawing board I knew that I needed to gather references to existing similar systems in order to base my system on. I gathered references from a few of the bigger and popular dinosaur-driven games; Primal Carnage, Exoprimal, The Isle. Each are very different games but yet have a huge overlap in how their dinosaur locomotives feel. Without a doubt each of them have great implementations and layered a good foundation for the requirements in my own system.
SECTION 1 :: Movement
This topic is about CCC (Character-Camera-Controls) so I’ll try my best to keep to it.
When I initially started this project, I was previously working on a prototype of the game that took a slightly different angle, I put a rag-tag controller together which summated to this:
From this gif we can visually describe quite easily how it works. We have a rudimentary camera direction based follow aswell as a simple blendspace that animates the characters left/right movement animations when pressing A/D respectively. For a prototype it sells somewhat of the feel of the controller. From a gameplay perspective it is incredibly rough and is in urgent need of a better and smoother solution.
First of all the character, the actualy blendspacing of the previous iteration was not entirely at fault, It worked as intended and was just being fed wrong values albeit needed some tweaks, here we can see that rapid changes are smoothened:
Next order of business was to drive this blendspace via camera direction properly. There are 2 variables to consider
- Speed
- Direction
Of which requires the following to be considered
- Movement Rotation
- Desired Input Values
- Camera Direction
To explain further we’ll need to compute a direction vector from both what the system will allow and the desired direction to produce a value that will drive our direction. The desired direction is determined by 3 states (Moving Forwards/Back, Left/Right, Obstacle Avoidance).
The second state is completely driven by the Desired Input. We interpolate the raw value to reduce snapping and then multiply it by the vector of the Control Rotations Yaw.
We then use this value on the interpolated final direction vector. This step is not neccesary and only add’s further smoothing and damping to the input’s.
These interpolation speeds can be altered to give snappier turning speeds if the dinosaur requires more agility.
Looking at the first state, this is the main focus of the camera direction. Normal WASD keys give very little control over the direction of the dinosaur especially considering when you need to move through tight spaces and guide your character towards a specific point. To get this working better than the snappier version from the previous iteration, we will use some interpolation:
In this snippet, we are creating an interpolated version of the control rotation of which is converted into a vector direction, much like the Left/Right state. We then multiply it by either 1 or -1 to determine whether the direction is going in parallel to the actors forward vector.
Okay so this is pretty trivial to think about, so how do we set this up for the blendspace? There’s a neat node in the Anim Graph which lets you calculate a direction angle from the direction vector and actor rotation
From this we can tweak the output value by either a multiplier or the range of values in the blendspace to get the correct value.
In the end, we get a much cleaner Camera Direction Based movement solution:
If you’ve noticed the additional smoothness on the tail, this isn’t a result of the Blendspace tweak, there is a physics animation layer applying at the end of the animation composition which allows the tail to react to any and all animations fluidly and realistically.
SECTION 2:: Camera
Moving away from the feel of the dinosaur, its easy to forget how the character should perform in a game scenario, we want to be able to line-up players and NPCs and be able to create a controlled bite that doesnt block the main portion of the screen as seen by this test:
The visual feedback we are getting is that the body is controlling where the attack is going instead of the head, this hinders the control the player has on the dinosaur, instead the attack should be driven by the head. Additionally here’s a frame of when I am attacking the tortoise where the body (darker red box) obscures the head (brighter red box) of the dinosaur. It’s safe to assume that the head will recieve inertia after a bite and so it will fall down before rising back up, from the current camera angle it becomes jarring to judge where the head is and if the attack has landed:
So why not move the camera pivot more forward?
Doing so brings the body closer to the camera. This does solve our issue of the head being obscured and the head being the driver of the attack but this position is not optimal for idle or crouched states as the player will have obscured vision when trying to look behind or infront from lower angles as it feels obvious that the camera isnt centered around the character.
I arrived at a solution that quite literally mixes the best of both worlds. At runtime, the character will interpolate between 2 location offsets, 1 for an idle position, 1 for a moving position. This way as the character moves into and out of a state, the camera will adjust itself to give the player the best possible viewing angle for that dinosaur.
One thing I have to note is that between the development footage from then (JAN 2023) and now (OCT 2023), the dinosaur in focus has had several tweaks and adjustments, furthering how much better it feels, as a result the pivot solution is very subtle. I’d also like to mention that it adds some physical visual feedback, it makes the player feel like its pulling the dinosaur as it starts to move, giving that satisfying inertia.
I think this is a good place to wrap for this post. I’ll be sharing more regarding the systems made for this game in future posts. But for now I hope some of this gave some useful insight into the development process!
