I am making a game similar to Legend of Zelda: Link to the Past (top-down 2D action-adventure). I want the character to stay centred on the screen when he moves.
Currently, whenever the player wants to move, I move all of the map in the opposite direction. This works, but as I add more objects to the world, moving them all gets more complicated.
Is there a better way of approaching this?
The typical way of handling this is to create a camera object. The simplest form of a camera is just a position. This simple camera defines the "center" of the current view. So you don't modify all the positions of your tiles/entities, you just subtract the camera coordinates from the positions when drawing. In this situation, the camera does not "move".
While the camera and your character will share a position most of the time, you may still want to have them as separate values, so you can, for example, stop the camera from moving when it reaches the end of the world, but allow the player to continue moving.
A slightly more advanced camera does move. All entities and tiles are drawn without offset and the position from which you're rendering changes. This is very similar to the most basic camera, and you can still perform many of the same optimizations for selective rendering (only calling draw on what the camera can see), on both. It's essentially just a different way of thinking about it.
cam variables... and offered an alternative method... stackoverflow.com/questions/18199373/…
\$\endgroup\$
No this is the wrong way to go about this.
How are you going to do trap detection? What about when the player reaches the edges of the walls? Will your viewing system work for dungeons or will you have to re-write a significant portion of the code?
The world is geometry. The player is geometry. The world doesn't move. The player does. Set the camera's position to center on the player. Always. And that's all there is to it.
Don't try and get fancy with "oh if I slide the world, then it will give the appearance the player is moving". You're just going to complicate the math with weird coordinate systems at the end of the day.
It is true that OpenGL's rendering actually works by "fixing the camera to point down - z, and transforming and rotate all world geometry so it fits in the canonical view volume", but you're not meant to think about it that way when programming. gluLookAt has parameters named eye, look, and up for a reason -- so you can think in terms of a sensible coordinate system.
