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?

  • 19
    \$\begingroup\$ Create a camera and move that. Essentially, everything will be drawn with an offset based off the camera position. Moving the universe to move your character is a little excessive Professor Farnsworth. \$\endgroup\$
    – House
    Commented May 7, 2013 at 0:17
  • 1
    \$\begingroup\$ +1 for referencing his referencing of his futurama reference :P \$\endgroup\$
    – Doorknob
    Commented May 7, 2013 at 13:09
  • \$\begingroup\$ @Byte56 Thanks, that is close to what I am doing, so I might just keep it the way it is. But that makes a lot of sense. Want to put that in an answer so I can accept it? \$\endgroup\$
    – asbumste
    Commented May 7, 2013 at 21:59
  • \$\begingroup\$ What rendering subsystem are you using? \$\endgroup\$
    – bobobobo
    Commented May 7, 2013 at 22:24

2 Answers 2


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.

  • \$\begingroup\$ Hi Byte, I've implemented what you said with success... I think. But now I'm running into issues... can you help take a look? One guy said I actually don't need any cam variables... and offered an alternative method... stackoverflow.com/questions/18199373/… \$\endgroup\$
    – user3871
    Commented Aug 13, 2013 at 17:28
  • \$\begingroup\$ I'll take a look at it later, for now I suggest you ask about it in chat. \$\endgroup\$
    – House
    Commented Aug 13, 2013 at 19:03

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.

  • \$\begingroup\$ One of the biggest mistakes I made with a GL UI system I was developing was try to work in canonical coordinates ([-1,1]) "to make it simpler". All screen objects had coordinates in [-1,1]. This was a huge mistake, I was constantly trying to think in this [-1,1] range, converting between pixels and NDC, converting back. When I gave up on this idea of working in NDC and just worked in pixels and converted to NDC just before rendering like you're supposed to, there was a world of difference in how easy it was to think about positioning elements on the screen, process input events, etc. \$\endgroup\$
    – bobobobo
    Commented May 8, 2013 at 2:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .