Camera and character control are two aspects of games that are closely related. Since the start of third person 3D games, when Sega Saturn and Playstation came to life around 1994, cameras have been a pain for developers. Games like Tomb Raider, Resident Evil, Metal Gear Solid or Super Mario 64 had different approaches that worked on some levels and failed on others. Since then, there has been some advancements on the subject. Resident Evil 4 introduced a new type of camera, closer to the player, that has become an standard for third person shooters (specially thanks to the success of Gears of War). 3D platformers are almost extint, but Nintendo still launches 3D Mario games regularly (thank god) and they have tried different approaches. First, they evolved the camera seen in Super Mario 64. That is, behind the character but keeping some distance and from a higher ground. The other approach they have tried is the one seen on Super Mario 3D Land and, specially, Super Mario 3D World . This camera follows the character, but not from behind the character. They keeping a big distance and height from him, and they only rotate when it makes sense on the context of the level.
My game camera
I’m explaining all this because that last approach is the same I’m following on The Curse of Pargo. I got to this through experimentation. Initially, my intention was to use an isometric view and leave full control of the camera angle to the player. This approach was seen recently in another Nintendo game, Captain Toad Treasure Tracker.
My game has some similarities with Captain Toad’s game, but as soon I implemented it I realized that this camera wouldn’t work. The main reason is that I’m making the game for PC, and rotating the camera with a keyboard sucks and the mouse was out of the picture. Using the free camera was a pain, and as soon as there was any obstacle you were force to rotate a camera that didn’t feel responsive or precise.
After failing with the free camera, I decided to go on and try a camera with fixed angles. The camera was still manual, but the player could rotate between the 4 corners of the level. This approach wasn’t bad, but I felt it was limiting me to work on small levels for it to work properly. I’m not going to do huge levels, but I wanted to do something bigger than what you can see on the video over this lines.
Although I wasn’t happy with the result, I thought the idea of the fixed camera angles could still work doing some changes. The first change was to follow and rotate around the character instead of just the level, keeping always the same distance to the player. That allowed me to work with larger levels. To avoid a “mechanic” look of the camera, I decided to give it some delay towards the movement of the character. I also used a Unity function (Transform.lookAt) that allows for an object (the camera) to look to another (the player). This gave the camera a very smooth feel. Combining this smooth movements with the fixed angles/positions worked pretty well but also created an issue with the character control.
Camera based control
As I said at the beginning, camera and player control are closely related on 3D games. In this game I’ve worked with an 8 directions control, depending on the camera. That means that pressing up will always get you away of the camera, down close, etc. That didn’t work that well with the free camera because of the keyboard, but now, with the camera constantly adjusting its position, it was an absolute mess. To avoid this issue I came up with a simple solution. I could take the angle of the camera and find out which of the fixed positions/angles is currently active. The movement of the player it’s then conditioned by this fixed predefined angle, not the real camera angle. This approach works surprisingly well, and now I feel like the combination of camera and character control are good. The character feels responsive and coherent at all moments, while at the same time the camera system is simple, smooth and works really well.
Right now I’m experimenting with camera triggers. It’s a way of automatize the camera rotation and make it easier for the player. I’m not convinced with this approach 100%, as it’s been seen in a number of games and it always has the same problem: the player doesn’t expect the camera to move and that leads to deaths or annoying situations. I will continue experimenting with it as I create levels for the final game. I believe cameras in games should never get in the middle, so hopefully I’ll make it work.
Below you can have a quick look to the current state of camera and control:
Also in case you want to check out the code I leave the player controller and the camera controller.