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
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.
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.
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.
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.
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.
Dwedit wrote:
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.
Quote:
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.
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.
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.
Bregalad wrote:
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.
Quote:
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.
Stargate on Genesis/SNES is a very good game, and there is no problem with the camera, it works very well.
tepples wrote:
Bregalad wrote:
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.
thefox wrote:
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.
Quote:
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.
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.
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
Super Metroid has great scrolling. How many people have even noticed the scrolling in that game? If people aren't noticing it, then it must be working well.
That would be because it's usually a pure vertical or pure horizontal scrolling zone, four-way scrolling areas are less common.
You're right. I thought Super Metroid had a lot of large multi-axis scrolling rooms, but after consulting a map I can see that there are fewer of them then I had remembered.
But still. The game does have its own ways of addressing the issues raised in this thread. And anybody interested in exploring them can mess around with a Super Metroid editor, some hacks, and the extensive documentation of the inner workings of the game.
Think of it this way:
Stand still. Now turn around 180 degrees. Now turn around 180 degrees again. Each time you do this, the entire view in front of you is
supposed to change, and if you do it too fast, you're
supposed to get sick.
3gengames mentioned Defender (
video), which also has the anti-hysteresis behavior. So if both
Stargate and
Stargåte do this, it can't be wrong
tepples wrote:
Each time you do this, the entire view in front of you is supposed to change, and if you do it too fast, you're supposed to get sick.
Yeah, but real life is in first-person 3D, while the games we're talking about are displayed in 2D from the side, I don't think the same rules apply.
A side-view 2D game is much more similar to a camera man trying to keep track of a person. There is a certain amount of prediction when the movement gets faster, but ideally the subject is centered most of the time.
With actual camera there is a thing called composition, and keeping an object always in the center is actually not the best idea. Look at any movie or TV show, like news - it is not a common case when a person is in the exact center.
I think I'm going to implement camera hints (in the map data) as well. The window method works OK, but some places, like narrow vertical passages, would work better if the camera was locked horizontally.
But what about camera handling in a two player co-op that has multi-way scrolling? Has anybody attempted that? I wonder if some variation of the window method would be applicable there as well.
Also I think it's almost a must to have some kind of feature where if one of the players gets too far away from the camera, he will come back in a bubble or something. Or it could "regenerate" him at where the other player is standing. Battletoads (and Chip & Dale) handles this in a different way: you can't get out of screen horizontally, and you'll die if you jump down off the screen.
thefox wrote:
Also I think it's almost a must to have some kind of feature where if one of the players gets too far away from the camera, he will come back in a bubble or something. Or it could "regenerate" him at where the other player is standing. Battletoads (and Chip & Dale) handles this in a different way: you can't get out of screen horizontally, and you'll die if you jump down off the screen.
If you're feeling especially crazy, you can even do it Toejam & Earl style.
Dwedit wrote:
If you're feeling especially crazy, you can even do it Toejam & Earl style.
I.e. split the screen when the two players get too far from each other. That would work, and would be kind of cool, but would probably limit the visibility too much for a platformer.
Mappy Kids on the NES has a 2 player split screen mode, as well as a single player full screen mode, but it can't switch during gameplay like Toejam & Earl does.
I just use the window method. There's a column of about 32 pixels in the center of the screen in which the player can freely maneuver without the camera moving. As soon as they go beyond the edge of the area, provided the camera isn't locked in place for a certain event, the camera will only move so that the player is not outside of the edge. The player won't be centered or anything like that. It works quite nicely, as the window in the middle of the screen is really small and you don't notice that you're not exactly centered. I feel like if you were exactly centered at all times, the camera would be jerky and it would be hard to make sense of what's going on when you switch directions or make subtle movements when things are flying at you.
thefox wrote:
But what about camera handling in a two player co-op that has multi-way scrolling? Has anybody attempted that? I wonder if some variation of the window method would be applicable there as well.
Also I think it's almost a must to have some kind of feature where if one of the players gets too far away from the camera, he will come back in a bubble or something.
Here's how my game handles that. (Though it hasn't been stress tested, since I only have the physics for the main characters done. No enemies, and no pit deaths are possible.)
I've already said I just use the average of their positions for the camera. I likely will not ever change this for multiple players, even if I add a window in single player.
If the players are slightly less than a screen away from each other horizontally, they can't progress further away from the other character horizontally.
If the players are slightly less than a screen away vertically:
It decides whether the player is higher or lower than the other player.
If the player is higher and airborne, it sets the airborne player's gravity to max speed.
If the player is higher and grounded, it does nothing.
If the player is lower and airborne, it does nothing if the other player is airborne. (I may 0 out the low player's velocity since it's a little safer to have the scroll slightly ahead of the lowest player)
If the player is lower and airborne, and the other player is grounded, it moves the lower player to the position and speeds of the other player and takes away some health. ( I may do a bubble thing instead of instantly setting the position, because this is likely a terrible idea for fast paced levels)
This solves a lot of problems. It's fairly difficult (but not completely impossible) for a player to "save" one who's falling into a pit from dying. If the pit is deep enough, it might allow them to not die but just lose some health. I accept this, I really can't do better with how my game deals with collision.
Kasumi wrote:
This solves a lot of problems. It's fairly difficult (but not completely impossible) for a player to "save" one who's falling into a pit from dying. If the pit is deep enough, it might allow them to not die but just lose some health. I accept this, I really can't do better with how my game deals with collision.
Why not just have some special tiles at the top of the pit, which when touched would immediately set a flag indicating that the player should die no matter what. In any case it's not a big deal, it can be considered a game play element. People like exploiting stuff like that.
tokumaru wrote:
Mappy Kids on the NES has a 2 player split screen mode, as well as a single player full screen mode, but it can't switch during gameplay like Toejam & Earl does.
Yeah, Skull & Crossbones (Unl) is another game that does split screen. It'd be a cool feature to have, but probably not worth all the extra effort, for me at least.
thefox wrote:
I think I'm going to implement camera hints (in the map data) as well. The window method works OK, but some places, like narrow vertical passages, would work better if the camera was locked horizontally.
Yeah, Donkey Kong Country has some serious hintage going on in its water levels.
Quote:
Also I think it's almost a must to have some kind of feature where if one of the players gets too far away from the camera, he will come back in a bubble or something.
Like in Kirby Super Star (Helper bubbles to Kirby) or Sonic 2 (Tails flies to Sonic)?
Quote:
I.e. split the screen when the two players get too far from each other. That would work
One problem with four-way split-screen scrolling on the NES is that you'd need to have two independent scrolling windows, which means single-screen mirroring. There are only two common boards that support that: A*ROM (#7) and S*ROM (#1). T*SROM and E*ROM also support it but are much less common, though rewiring any T*ROM to act as T*SROM is about as simple as rewiring it to take EPROM.