So I asked on twitter if there was anything folks wanted covered on the devblog and @tyronehenrie mentioned the camera. Seeing as it’s an interesting topic (I think anyway ^_^) and it’s the thing I’ve spent the most time on, here’s the post 😀
The main design issue with the camera, is that it is actually two cameras, one for mouse users, and one for gamepad users, and it has to be able to tell which is being used at any time and behave accordingly.
A little ranting first…
I’ll take this oppertunity to justify why Sarah’s Run supports a gamepad even though it’s only going to be released on Windows and OS X (for the forseeable future anyway).  The reason is for most games, gamepads are simply better. look at your keyboard, thats for writing. Now look at a gamepad, that’s for playing games. Now look back at me, I was inspired during the games early development by console platformers that never really worked on PC very, gamepads worked well for them.
So I know going in that this type of game traditionally suits gamepad best, the buttons are all within reach, analog control is wonderful etc, its all good. But I also know no matter how much a beg, no more than 25% of PC gamers will have gamepads and even then plenty of those will be at the bottom of some box tangled up with other random things and wont get used anyway. I have to make the game feel good on PC, and this isn’t just some port of a console game to squeeze a few extra bucks, this is a PC game; the controls have to feel good on PC, and the camera is a very (if not the most) important part of that in a game like this. The camera is the player’s eyes into the world after all, few people want to be without their eyes.
The quest for a good camera!
The first thing I did was to look around for platformers with good camera control on PC; I gave up pretty fast, 3D platformers on PC for the most part suck pretty damn hard. So plan B then, what really works on PCs? the mouse is a super good input device after all.
The answer is obvious really, first person shooters have a pretty standard control set and behaviour, plus it drops onto Sarah’s abilities pretty cleanly. (it’s mostly running and jumping after all)
So what’s the difference between the camera’s mouse control and gamepad control, and how did I get them to work? I’ll start off with:
1. Gamepad Camera
The code that drives the camera can pretty much be described in two steps:
- Position the camera at the center of its orbit (where it’s looking at, AKA Sarah)
- Translate the camera backwards
This keeps Sarah in the center of the camera’s view and a constant distance from the camera, and we can get different behaviour by doing extra stuff around these steps.
For the gamepad behaviour, we want the camera to ‘follow’ Sarah, so if she moves left relative to the camera, the camera turns left to see where Sarah is going.  much like in this diagram:
This behaviour is pretty standard for most all platforming games (even on PC, which I think is why most 3D platforming sucks… more on that further down). here’s how I go about doing it;
First of all, before positioning the camera at it’s target (Sarah), we make the camera look at it’s target.
This way, when we translate the camera back, the angle it’s looking at is different (if the player has moved) and it wil be looking more in the direction the player is moving. This process will be repeated each timestep and gradually the camera will pull behind the player.
I think this is the ideal behaviour for the camera, as it is showing where Sarah is going, she is always on the screen, and I even have the camera favour looking down a little, all so you can see where she is standing and you will almost always see what is relevant to the immediate platforming around Sarah. If there is a pit you likely wont miss it, if there is a gap you can best judge how wide it is.
But the player can control the camera too of course, that step comes after positioning the camera at it’s target and before translating it backwards, we just rotate the camera by however much the right stick is tilting. This way the camera orbits Sarah however the player likes. Plus we stop doing things like the camera favouring looking down when the player is directly controlling the camera; it’s not just that they might be wanting to look up, but if the player is changing the camera odds are it means they aren’t happy with where it is at the moment. So it’s not wise to impair the players control.
and that brings us to…
2. Mouse Camera
As I mentioned before, even on PC most platforming games have a camera that tries to follow the player character and look in the direction they are moving, this is frankly an asshat’s move and here’s why:
On a gamepad, if the camera turns a little and you want to keep moving in the same direction you just alter your input on the analog stick a little, it’s smooth, it feels natural.
On PC, if the camera turns a little, you have no analog input, you have four buttons, thats Eight directions total. When movement it relative to the camera, when the camera changes, all your buttons change. You can’t ease from one to the other really and you either end up running in a squiggly line or falling off the edge you were trying to avoid, or both. All because the camera changed.
We can keep our analog control by giving the player complete control of the camera with the mouse (the analog input on a PC), and because movement is relative to the camera, we can still weave in nice curves by running and steering with the mouse, just like in an FPS.
In practice, making the camera work this way is really just a case of taking the gamepad behaviour (look at target, position at target, rotate, translate back) and removing the first bit (look at target).
Like this, when you are pressing left, so long as the player doesn’t change the camera, left will always go left. And if the camera is changed, it’s because the player wants left to be some other direction within the game world.
Seeing as I’ve gone on long enough…
That’s pretty much it, we have both ways the camera can behave, and if the game detects no mouse movement for a while, it eases into gamepad camera behaviour. Overall I’d say it feels pretty good, and it certainly took a while to get it to the point where people didn’t complain about it when playing. Which is understandable, when the player’s control over something in a game feels bad, the game feels bad. And in this game, the camera is as important to control as the player character; the look is as needed as the leap so to speak 🙂
That’s not all there is to the camera though, for example the way sarah can run up walls gave me endless headaches for getting camera behaviour right (it still presents issues from time to time, but the number is always going down!) I think thats enough for today though. I probably went into way more detail than anyone wanted anyway. ^_^
Hi Sophie,
It’s cool to see how much thought you’ve put into the camera. If certain commercial developers applied that much thought, we’d be able to see and move in their games.
SInce you mentioned gamepad support, I tried connecting my X360 gamepad and playing. I couldn’t figure out a way to jump or run or be super, and the camera controls were really weird. I think this game’s also afflicted by the weird button mappings when using Unity with the Xbox 360 controller driver for Mac OS X.
(If we’re curious whose fault it is that the mappings are weird, it seems to be that Unity is making a mistake in the way it interprets the controller, but it’s not a completely unique mistake because Aquaria makes it too.)
There may be another weird thing with the analog triggers: “The good news is that this Mac HID driver exposes the triggers as separate axes (#5 & #6), like XNA, and unlike the Microsoft USB drivers which make the triggers into a single axis which destroys their usefulness. The bad news about this is that the triggers are initially 0.0f until the user touches one, then they move to a [-1 .. 1] range instead (with -1 being fully open).”
Thanks,
Ezra
yeah, I’m well aware of the problems of using a 360 gamepad on a mac, or any gamepad other than 360 on windows. I’ll be making sure the game has as fully comprehensive input configuration as possible.
I’m glad to hear the back triggers are treated as seperate axis, sadly on windows AFAIK they are still the one axis, both in is the same value as both out =/
So what do you do when the player is against a wall and moves so that the camera would be forced inside the wall? And do you do anything about other sorts of objects obstructing the line of sight?
ah, well at the moment it’s just a step before translating, I raycast from the player backwards (in the direction I plan to translate the camera) and if there is a collision I reduce the distance I translate back by.
I’ll be working on adding another layer to this in the future, of giving the camera a collision sphere as at the moment you can still place the camera ‘next’ to a wall and see through it. the camera really needs a radius, it’s not a point. 🙂