From Amir, one of the Crystal Space developer working on camera and movement system improvements:
No it’s not the new Hollywood blockbuster, it’s my test application for developing the camera and character movement controller! Because it takes a while to update python bindings when developing C++ code, I use this interim solution while doing heavy development.First you see character walking in and out of the camera. There is a slight spring, but only within a certain range of the relaxed position. You can visualise the camera as having a hard pole with a spring attached to the player. When the player walks into the camera, the spring becomes depressed and the camera will start to move backwards. If you move beyond the spring then you will just push the camera. So we calculate the desired forward movement to reach the player within our range for the camera using the equations:
cos (x) = camera_direction . camera_to_player
move = distance * cos (x)
=> move = distance * (camera_direction . camera_to_player) – forward_position_offset
Then you next see tilting the camera up and down. There is no standard or universal behaviour in games really for tilting so I took a bit of creative license here. Annoying the player with too many controls for just a camera can just be well, annoying. So how to incorporate the zoom? Well this looks like a nice solution. We actually describe the ‘hard-pole’ positional offset of the camera we just described as an elevation angle from the ground and a distance and can use the normal circle equations to find the camera position for tilting. For this zooming effect I just make the distance proportional to the elevation angle.
Then it’s collision detection when you walk into the wall. This more than anything causes lots of pain. Some games don’t even let you pan into the wall 🙂 cheaters. Not only is the collision detection dependent on a calculation in one place, but another calculation is dependent on the collision detection in another place. Throw in 2 or 3 more of these cases and then you have dependency nightmares. Then panning into walls at large perpendicular angles when you first touch the wall when panning, usually means that the camera is oriented halfway between nothingness and the world. Therefore you need to offset the camera from the wall. But if you get in close, then this offset will cause the camera to flip on the otherside of the player and so you need to linearly decrease this. Then you also need a vertical offset for the camera, above the players collision box if the target is inside the player… and you need to interpolate this value too. Coming out of the zoomed-iness the camera will jump, so you must interpolate the zooming out also. This needs some more work, but well everything interferes with each other 🙂
To finish off there’s some preliminary character movement demonstration. I haven’t worked too much on this yet so it’s a bit rough. TODO: Fix the jumping of the camera between movement modes. 🙂 The first mode is when you go into fighting mode. No enemy is around so you just strafe around. Suddenly an enemy enters the view! The camera locks onto the target and you move around the enemy, rolling and dodging and doing attacks. The player movement needs work though yet, like smoother turning when moving diagonal after moving straight. Straight to straight movement should be fast though we think.
Any suggestions for you preferences? What do you think of mouse control for the camera? This is popular but I sometimes get annoyed when I’m accidentally knocking the camera. Below is the written document for player movement.
Beside of developing in the Blender Institute we working remotely with other Crystal Space developers, they made a lot of new amazing improvements like new animation system, smoother collisions, new logic system, also camera, movement system and many other things. So without their work it would be impossible to release an industry-quality game. Cheers guys !