Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
19  
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. –  Byte56 May 7 '13 at 0:17
3  
+1for the great Futurama reference –  Roboinventor May 7 '13 at 0:38
2  
+1 for referencing his futurama reference :p –  Savlon May 7 '13 at 5:21
1  
+1 for referencing his referencing of his futurama reference :P –  Doorknob 冰 May 7 '13 at 13:09
    
@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? –  asbumste May 7 '13 at 21:59

2 Answers 2

up vote 8 down vote accepted

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.

share|improve this answer
    
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/… –  Growler Aug 13 '13 at 17:28
    
I'll take a look at it later, for now I suggest you ask about it in chat. –  Byte56 Aug 13 '13 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.

share|improve this answer
    
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. –  bobobobo May 8 '13 at 2:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.