Best practices for camera handling in platformers

[thefox]

I wasn't exactly sure under which forum I should post this. Anyway, my question is, what kind of logic are people using for camera handling in multidirectional scrolling platformers? Currently in my engine the camera follows the player with pixel precision, which makes the camera look chaotic. I guess this is another thing where there's no perfect answer, but it would be interesting to see if anybody has anything to add.

The first/easiest thing to implement is a small "window", inside which the player can move without the screen scrolling. The screen starts scrolling as soon as the player hits the edges of this window. Other interesting behavior, e.g. in Super Mario World, is that sometimes when jumping upwards, the screen will not scroll until the player hits the ground.

So it's another seemingly simple, but at heart intricate problem. I guess I'm asking, because I kind of know the problem and how it's supposed to behave, but don't really have simple rules about how to implement everything. Also I haven't decided how complicated I want to make this.

Here's some info about this topic from Google:
http://replicaisland.blogspot.com/2010/ ... amera.html
http://blog.mimeoverse.com/post/5770607 ... uper-mario
http://blog.mimeoverse.com/post/5814677 ... d-minimize

[Shiru]

I used two kinds of camera - one that is always holding the object in the middle of the screen (expect for cases when the object is close to the level edges), and another that follows the player with a delay, or it has speed limitation. Second kind is looks nice when you 'teleport' the object, so it is scrolls through the level fast. It also created cool effect in Sonic games when you sometimes was moving so 'incredibly fast' that camera wasn't able to follow you at that speed.

What I don't like in games is the 'window' kind of camer - because usually that limits visibility, i.e. space between the object and edge of the screen, a lot. For some games it make sense to align camera in a way that the object is placed at left or right part of the screen, depending from direction - to provide better visibility. Well, it is done that way in most of top-view racing games.

[tokumaru]

I think that the "window" approach works great if you allow the window to be resized and repositioned dynamically. The only actual rule is: If the player is outside of the window, make the camera follow the player, while respecting the level's boundaries.

Then, by configuring the size and position of the window according to certain conditions you can adjust the camera according to your preferences. If you want to keep the player centered at all times, make the window the same size as him and place it at the middle of the screen. If you are worried about not being able to see much of what's ahead if the window is a bit wider, just move it left or right depending on the direction the player is facing (so that he gets out of the window sooner when moving forward). You can also make the window taller when jumping, to simulate that SMW effect you mentioned. There are a lot of possibilities.

In addition to that, you might want to add an acceleration system to the camera, to make it super smooth. That's not really necessary in most cases though.

[tepples]

Lode Runner uses window style with a huge window, and limited visibility hurts playability.

Some games will center the camera a few tiles ahead of the player, and the player can shift the view by facing a particular direction. Yoshi's Island does this, and I seem to remember David Crane games doing it too.

[Dwedit]

So how about a compromise between the "Window" camera, and the "see what's ahead of you" camera?

When you are moving solidly in one direction, the camera goes ahead, so you can see better what's in front of you. But when you stop or slow down, it ends "see ahead of you mode" and acts more like the "Window" camera. Maybe with a slow transition so there's less sudden jerkyness.

[Kasumi]

My game supports multiple players simultaneously. For 1 player, it's always centered directly on the player. For more players, it's centered on the average of their positions.

Since the main character can move at the max speed the camera can travel both horizontally and vertically, catching a "window" up when he's moving at that speed can't work. As well, I hate it when games wait until the character is moving right a little bit before the camera starts moving right. This means I can consistently see more of the left side of the screen where I'm not even heading. How useless is that?

The opposite is a little better, where it scrolls forward MORE in the direction I'm heading. (Not possible in my game, where the player can accelerate to max speed quickly and stay there.)

But even so, for horizontal movement I definitely prefer it to stay centered on the player, even if it's "rough". Maybe a TINY (<8 or 16 pixels) horizontal window is okay. For vertical movement, there's a good point that scrolling up with a jump actually makes it harder to see pits. For some reason that sort of camera window bothers me less anyway, so a vertical "trap" at the site called it is fine.

[tokumaru]

But when you stop or slow down, it ends "see ahead of you mode" and acts more like the "Window" camera.

But the "window" camera can be the "see ahead of you" camera, you just have to move the window according to the direction the player is facing (and even to his speed).

You can implement a rule like "if the speed is below X, the window is centered, otherwise it should move towards the opposite direction". That way, when the player starts running right and achieves a certain speed, the window moves left, so the camera will have to move faster to the right to catch up, effectively showing more of the right side.

The beauty of the window method is that it's highly configurable. Once you implement the basic rules, it's all about resizing the window and moving it around the screen according to certain game events.

Maybe with a slow transition so there's less sudden jerkyness.

For that I think you could just move the window smoothly, instead of teleporting it from one position to another.

[Kasumi]

Hmmm... reading tokumaru's post, I guess I technically DON'T just set the scroll to the player. If the character ever DOES get passed his max speed (which should be impossible now, but it was possible via a bug before), my camera will scroll as fast as it can to the average of the players' position. But as soon as the camera is close enough to that "goal point" to scroll there in one frame it does so. It doesn't slow down as it gets close or anything cool like that.

It would actually be easy for me to implement a "trap" by changing my "goal point" logic, but I assumed that was true for most people here. If your game doesn't and your character moves too fast via a bug or something, then you end up skipping tiles that should be drawn to the screen, or going over the time you have to write tiles in the NMi.

[Bregalad]

The "window" (I'd call it "hysteresis instead" pseonally) camera in the opposite direction is NOT the way to go, play Stargate on SNES, and see how you get easily headaches playing this game.

The hysteresis in the direction the player is facing is a bit annoying as it reduces visibility.
So I'd say just follow the player is the best way, all Mega Man games does this, all Castlevania does this, and it works perect.

[tepples]

The "window" (I'd call it "hysteresis instead" pseonally) camera in the opposite direction is NOT the way to go, play Stargate on SNES, and see how you get easily headaches playing this game.

I just looked at a video of Stargate, and I didn't see a problem.

So I'd say just follow the player is the best way, all Mega Man games does this, all Castlevania does this, and it works perect.

It's fine for games like those with fairly slow movement. But as characters get bigger (e.g. Mega Man series to Mega Man X series) or faster (e.g. Mario to Sonic), it becomes imperative to see farther ahead in order to react faster.

[Shiru]

Stargate on Genesis/SNES is a very good game, and there is no problem with the camera, it works very well.

[thefox]

The "window" (I'd call it "hysteresis instead" pseonally) camera in the opposite direction is NOT the way to go, play Stargate on SNES, and see how you get easily headaches playing this game.

I just looked at a video of Stargate, and I didn't see a problem.

One thing I noticed about Stargate is that as soon as the player character turns, the camera also moves ahead of him. In some other games, like SMW2 I think, the camera will not "change sides" until the player touches the edges of the window/trap.

[Bregalad]

One thing I noticed about Stargate is that as soon as the player character turns, the camera also moves ahead of him. In some other games, like SMW2 I think, the camera will not "change sides" until the player touches the edges of the window/trap.

Yes, and this is quite an annoyance in my opinion, even if it allow you to see farther ahead. It make me have headaches that the camera is consantly moving so much when I just want to do very small moves. For example if you need to go back just a few pixels so you are on the right spot before throwing a grenade you do it by pressing left a few frames and right again, but the camera will move a lot in both directions when you do this and this is annoying.

It's fine for games like those with fairly slow movement. But as characters get bigger (e.g. Mega Man series to Mega Man X series) or faster (e.g. Mario to Sonic), it becomes imperative to see farther ahead in order to react faster.

Mega Man X games also does not have any camera hysteresis, nor "anti-hysteresis" like Stargate. The camera just follows the player and this works well.

[3gengames]

I love Stargate and Defenders camera handling, the arcade ones. I think it's perfect for a space shooter, but only since you have the scanner to know what's behind you.

[thefox]

I made a little prototype of the window method (with leading) using Python and pygame: http://thefox.aspekt.fi/platformer-camera.py (Set DRAW_WINDOW to True to see the window/trap.)

It seems to be working nicely. The only thing that bothers me a little bit right now is that when the camera is at the left (or other) edge of the map, window is at the right side of the screen, so the player has to move quite far to the right before the screen starts scrolling. Interestingly enough, SMW seems to behave the same way at the beginning of this video: http://blog.mimeoverse.com/post/5770607 ... uper-mario