EPTThe Camera!
Now that I have a basic framework for a game setup (see part 1), it's time to work on moving things around. More specifically, the camera. I've hooked my player character up to some rudimentary controls for the time being, but without some work he'll just slide off the screen- there's no walk animation yet. That won't do at all.
Camera work in a 2d platformer is easy to make functional, but getting it right takes some work. Making the camera keep a player in the center of the screen is not hard at all. The problem is that's not what want to do. There's a big difference between a tight camera control and a camera that just follows the player along. At the very least I'm going to want to support horizontal only, vertical only, and free follow camera modes. In reality there's more to it than that. The camera is really another character in your game, or at least an extension of the main character. The way it controls has an impact on both the gameplay and the mood of the game.
The iPhone version of Canabalt is a great example of the camera imparting mood. In the iPhone version the camera is zoomed out further than the flash version. All of the buildings fall within maybe 25% of the screen's height (other than the start). If Canabalt never varied the camera's y coordinate it would still be completely playable. Yet the camera does move on the y-axis, and this adds a nice touch to the game. In a game all about making these long perfectly arced jumps, the jumps are given extra weight and feeling by allowing the camera to move up along with them. This is especially noticeable if you allow the character's speed to max out. Without this camera movement a lot of the jumping would feel flatter and stiffer. The camera control, not just the framing, has added to the game's mood and heightens the intensity of the character's run.
A Lesson Well Learned
Ok enough blabbering, time to get down to some gritty details. My plan is to setup a rudimentary camera to get things working, then expand on it with more sophisticated behavior. So I start by taking a look at what my engine gives me for camera controls. I find exactly what I was expecting: all entities are drawn relative to a camera view that can be set. There's no built in movement or controls, but at least I'm not managing how to translate from a game world position to where the thing should be drawn on the screen.
As my first stab, I create a camera class with an update function that takes the player entity as an input and centers the camera on the player. The camera is setup to stay focused on the level as well, when you go all the way to the left the camera will stop panning at the end of the level. Last thing we want is 1/2 of the screen to be black and the other 1/2 to be the leftmost edge of the level.
I add the camera to the player entity and have it call the update function every frame to move the camera. I don't like having this somewhat circular reference where the camera knows about the player and the player knows about the camera, but it's easy and efficient so I test it and move on.
That was easy... except it wasn't; something's wrong. As my character slides across the screen and the camera follows there's a noticeable problem. He's jiggling as if he is trying to stave off hypothermia. Rather than clearly seeing my horribly drawn sprite, I see my horribly draw sprite in some weird jiggly blur.
My first instinct is to check for math rounding errors, playing the character in the center of the screen means I need to do some math to go from the player's position to the camera. It's not uncommon for numbers to end up with odd remainders when programming. I thought perhaps the camera controls are reacting poorly to a misplaced .0000000000...1, but no such luck. My first instinct blew it this time.
With that out of the way I know the general issue, just not what's causing it. My sprites are being drawn without aliasing. This is great for performance and my art style (crap is an art style right?). The downside is that if my character is at {1.323, 100} he'll be drawn either at {1,100} or {2,200}. There's no in between for the character's sprite. For some reason he's occasionally moving, or not-moving, a pixel relative to the camera and it makes him look wobbly.
After digging some more into the issue; success! I take a close look at the following two lines on my player entity:
this.camera.update(this);
this.parent();
The first line is updating my camera. The second is running the engine's logic for controlling moving entities, it's responsible for taking the entity's velocity and translating that into a new position. Here's the lesson learned, the order you do stuff during a frame matters a lot.
![[image loading]](http://i.imgur.com/iyX16cC.jpg)
Not alot, a lot.
This is something I already knew. It's something that's also somewhat obvious, but it's very important. The involuntary refresher lesson is taken to heart for the future.
My issue is the camera is it is moving before the player does. It's lagging a frame behind the player at all times. With the way I have it, the following happens:
- The camera centers relative to the player's position a.
- The player moves to position b.
- The game draws with the camera relative to a and the player relative to b.
- The game centers relative to player's position b.
- The player moves to position c. When rounded to the nearest pixel it's the same pixel. In this case if the camera was stationary the player wouldn't have appeared to move at all.
- The game draws with the camera relative to b and the player relative to the same point (b & c).
- Since the camera moved from a -> b, but the player stayed in the 'same spot' when rounded to the nearest pixel the player moves backwards. This is the jitter.
Whew, now with that cleared up I make the change:
this.parent();
this.camera.update(this);
The previous steps change to:
- The player moves to position b.
- The camera centers relative to the player's position b.
- The game draws with camera relative to b and player at b.
- The player moves to position c (which rounds to b).
- The camera moves relative to position c (which rounds to the same as b).
- The game draws with the camera relative to b/c and the player at b/c. Instead of sliding back the player stays in the same spot on the screen and there's no jitter.
Now I have my basic camera setup working, time to get a bit fancy.
Boxing the player in
The first change to the camera I make is an important one. When a camera keeps the player centered at all times there's an issue with how much the camera moves: it moves too much. Anytime the player moves the character back the camera will follow immediately. This is distracting and disorienting. If a player is moving in a small area we'd like to keep the camera still to make things easier to process.
Instead of following the player, my camera is going to follow an invisible box around the player. An invisible box that the player will push. In my camera update rather than moving the camera directly I check to see if the player is outside of the box, if he is I move the box to correspond. Then I move the camera to reflect the box's position. I setup the box to be a little taller than the player's jump height and twice the character's width.
![[image loading]](http://i.imgur.com/QIFuwbP.png)
My player in his box. The box is being drawn for debugging and picture purposes.
The box serves several purposes. On the x-axis it means the camera will favor staying still until the player moves significantly from where they once were. If a player is making small adjustments back and forth on a platform the camera will remain stationary. Also, if a player decides to go the opposite direction the camera will have a lag to it that just feels nice. On the y-axis the advantage comes when the player jumps. Rather than making a small arc of the camera movements to match the player, the camera will stay level. Only when the player falls or starts ascending up platforms will the camera move. In Canabalt the y movement works to add weight to the movement, but here with a free moving player character it just adds wobble and noise. Generally the more stationary I can keep the camera while still following the player the better.
There's one last thing to stick between my player and the camera. Rather than updating the camera's position based on the box position, I update another coordinate that then gets used to determine the camera's position. This is going to allow me to support easing the camera in the future. It's also going to allow me an easy way to lock the camera to an axis, something I'll make use of right away.
The Camera Modes
I'd like to make complex level shapes; levels that look like Ls, Ts or other weird shapes. That means I'll need several modes for my camera that aren't based on the level's width/height. I'll also need the ability to switch between those modes. There are two types of unlocked modes I'd like to support: free follow and platform locked. In the latter case the idea is that the camera will only move on the y-axis when the player lands on a platform. This is nice for level sections that feature a series of ascending platforms. By using a platform locked camera the player can jump on the platforms while keeping the camera level. In a free form mode an ascending player will continuously be at the top of their camera box and each jump will move the camera. Plus this creates a nice delay effect in the camera motion, the camera moves a shorter distance when the player lands rather than tracking them through the air. Super Mario Brothers World used this type of camera technique (see video at end of blog).
So now I have my list of camera types:
- x-axis locked
- y-axis locked
- platform locked
- free follow
Each one is easily coded up and ready to go. There are some easing and panning issues to be dealt with later, but they're minor enough to push off for now. Each mode takes the box's current position and uses it to update the intermediate position I referred to earlier. When a transition happens the intermediate position may jump somewhat dramatically so it'll be up to clever transitioning and good camera easing to smooth it all out.
To handle transitioning between camera modes I make some new entities for my game world. I add invisible triggers can be placed as a game object in a level. When the player collides with them their velocity is used to determine which way the player is going. Each side of the trigger, the trigger can be horizontal or vertical, has an associated camera type that will be switched to based on the direction of the player. It's straightforward and simple; exactly what I need. I'll be transitioning the camera during levels, but I don't think I'll need anything too fancy in how I do it.
Conclusion
So that's it for now. My camera is functional enough to feel smooth and reasonable, and all the remaining work is lower priority. I now have a camera system that feels smooth and stable rather than the jittery and hyperactive camera I started with.
Next time I'll be getting into the of spawning enemies and may cover my creation of a real level layout that I'll use to fine tune my player's movement. I've also been trying to read up and practice my art skills as best I can with the eventual goal of making some art that doesn't look terrible.
For your further viewing pleasure here's someone analyzing the SMBW camera:
+ Show Spoiler +
This video is pretty awesome
Thanks again for reading!
thank you. I've never actually considered having different camera modes. Then again, I've only ever worked on one platformer camera system so far... and that wasn't even a proper platformer. I'm currently working one now though, am about to do the camera system :p
