Hello, fellow travellers. These days have been a little chaotic but here we are, in the bastion of development.
So we asked ourselves, what is the thing you NEED to know now that the world is ending?
Yes, you got it, we’re talking about character control and how it was made!
The first order of business to create a good control was to figure out which were the principal actions we wanted the player to be able to take. In our case:
- Walk/Run
- Jum / Vault / Vault Wall
- Push
- Interact
- Crouch
Our priority was for the control to feel precise and fluid, and to make the player feel that they can reach any place without having to think about it for too much. In that sense we want the player to feel movement in the world is intuitive and organic. Movement and exploration should not be a puzzle in itself.
To do this we have used the following main components:
Character Input:
In our case, we considered it more important to work with controllers instead of mouse and keyboard. This allows for a more fluid feeling and a higher range of movement for the character.
But there’s one issue: today thousands of controllers exist, each one with its different buttons, mapping… Preparing the game for each of the controllers independently would have been a colossal task. That’s why we chose to use Rewired, a great and useful unity asset:
No, do not worry, this is not a brand deal. But after exploring and investigating we found that Rewired was one of the best assets in unity’s asset store to help with player control.
In addition, and to be able to have further control on player input, we have created an additional layer, the “CharacterInput”, which allows us to extract the player from the rest of the code from the input. This gives us more flexibility as developers and makes it easier for us to adapt: if we decide to stop working with Rewired at a given point, we will not have to recreate the player’s input code, we will just have to tweak this new layer.
Character controller:
In Unity there are two main ways to create character control.
- Using a character controller;
- Using a rigidbody;
The battle for “which option is better” has been talked about in detail already. You can watch here a video by Master Indie that explains very well the main differences:
In our case, seeing that we don’t prioritize realistic physics as much, we decided to use a Character Controller, that gives us a lot more precision and control. The downside of this is that we have to implement and add a series of things by ourselves, such as jump physics, gravity when characters fall, etc..
Animator:
As we said in the introduction, we are looking for a smooth and natural character movement. We achieved this, on one side, thanks to Motion Capture (or Mocap) animations. These give a more human and realistic aspect to the character, and contrasts nicely with the voxel aesthetic of the game.
Also, to add even more fluidity to movement, we have been very careful with transitions between animations. This allows us to avoid weird cuts when the characters goes from one action to another. It is also important for the character to adapt to the world it’s moving in. That is why we have a big variety of transitions possible. This is used for vaulting on top of objects of different sizes for example. The character will climb on small obstacles with only one foot. Inversely, they will jump and grab the edge of the platform if it’s too high to vault normally.
Unity allows us to assign scripts to each state of the animator. This lets us execute chunks of code only when the character is in a specific state. This comes very handy when we compartmentalize our code and helps to improve the traceability of our errors.
CharacterMove:
This is the main script we use for character logic. It handles each of the states of character control, activating in each situation the correct animation and moving the Character Controller in the desired direction.
InverseKinematic:
The Inverse Kinematic (or IK) is a technique that determines the movement of a series of bones and articulations (be it a leg, an arm, a neck…) to place them in a specific position.
The objective with IK (opposed to forward kinematic or FK) is to find the values that each bone has to have in order for them to be oriented and located following a specific position.
To make it clearer, when we record a Mocap animation and implement it in the character, the character bones will move following this animation. There we use FK. In FK the bones follow the position and rotation of other bones. In IK, you can force the bones to stay in a position or follow a certain rotation that might be unnatural. In our case, we use IK to force the bones to behave in a way they don’t in the original animation. For example, we use this so that the character looks at certain elements in the scene (maybe a key object, a hidden path… ). By doing that, we bring attention to the player to what the character is looking at. We tell the head bones their final position and rotation and, from there, we calculate the rotation of the body, neck and head for them to adjust to the final values.
We are currently working on improving the Inverse Kinematics in D E E X I T . The goal is to overall improve the way that the character interacts with the world. This would allow us to make it so the character’s feet adapt to the shape of the floor, for example. It would also make it so the character touches a wall when one is too close. In general, it would help us with improving realism and fluidity in character control.when one is too close. In general, it would help us with improving realism and fluidity in character control.
This is all for now. We will keep hard at work on character control and all other departments. And if you want to be more aware of what we do and help us on developing D E E X I T , we will also be sharing special testing zones on our Discord server. We would love it if you could check it out and give us your feedback on all this!
Discord : discord.gg/fx3dMh5
