Rewriting the character movement code for my character I found several approaches.
- Move by altering the transform.position of the character.
- Move using a character controller component and forces.
- Move using rigidBody component and forces.
The first of these worked fine but didn’t play well with my camera control code. Also, since I’d reworked the level generation code to automatically build invisible walls of box colliders in a corridor of any given width or height I wanted a solution that used these. Not using the colliders would have meant adding code to check whether the player would exceed the bounds of the level on the next frame, and I’d rather not have to write this if I can help it.
The second option seemed like a better fix. It would let me use the colliders I’d added to the level geometry but it became clear that I wouldn’t get the arcade style movement I wanted. Move() worked okay but SimpleMove() didn’t work at all, and neither allow any interaction with the Unity physics model. I saw a lot of negative feedback on the character controller component, so I decided to try the rigidBody instead.
In using rigidBody I was very much at the end of my rope in getting the movement I wanted. I found however that with some adjustments to the mass and drag of the player rigidBody and greatly increasing the gravity of Unity’s Input Axis functionality I could get very close to perfect movement; very responsive but with just a hint of inertia. It will need some tweaking no doubt once the game nears completion but it’s far better than it was. The final problem with this method is that, as it uses the physics engine of Unity it meant that friction was occurring between the player and level walls, though this was easily fixed by making a zero friction physics object and adding it to the box colliders of the level walls.
Some articles that were also useful in getting player movement right…