I'm creating a 2D game similar to Mario. What is a best practice to allow the character to move through the level given a limited screen size?

The way I have it now is the Player moves across the screen, and when they reach the far right edge, you reset them to the far left of the screen (basically teleport them back to the left side...). And if they're at the far left edge, keep resetting them to the far left side (to simulate a wall)

Check Player Bounds:

public void checkPlayerBounds (Player player) {
    if (player.getY() >= height-(playerHeight+25)) {
    else if (player.getY() < 0) {
    else if (player.getX() > width-(playerWidth)) {
    else if (player.getX() < 0) {


public void reset(String val) {
    if (val.equals("down"))
        yLoc = gameboard.getHeight()-(height+30);
    if (val.equals("up") ) 
        yLoc = 0;
    if (val.equals("left")) 
        xLoc = 0;
    if (val.equals("right"))
        xLoc = 0;

So I'm basically just either teleporting them when they get to the far right to simulate them (moving forward), at which point I would draw the applicable background and items (each time person reaches far right side, have a counter that is associated with the correct things to load on the screen)...

Or, should it be that the actual Player character doesn't move when you press right... it's actually the background items and map that moves (loads)?

If so, how would that look from a pseudocode/design perspective?

Thank you

  • \$\begingroup\$ Two objects need to move, your character and your camera. There are a number of "keeping character centered" type questions on the site. Have you searched through them? \$\endgroup\$
    – House
    Jul 16, 2013 at 14:25
  • \$\begingroup\$ gamedev.stackexchange.com/questions/55113/… \$\endgroup\$
    – House
    Jul 16, 2013 at 14:38
  • \$\begingroup\$ what game engine are you using? \$\endgroup\$ Jul 16, 2013 at 19:00
  • \$\begingroup\$ @AmitApollo I don't know how to use any existing game Engines. Should I be using one? I'm building my own Java game from scratch \$\endgroup\$
    – user3871
    Jul 16, 2013 at 19:24

1 Answer 1


Well, the whole solution is a lot of code, but there are a few concepts you need to be aware of:

The Camera: For every goomba and block's Draw method, they need a particular offset defined by the camera's position. So if the camera is at X:0,Y:0, the goomba's screen coordinates match their world coordinates. If the camera is at X:5,Y:0, then his world coordinates stay the same - none of his own values needs to change - but each run of his draw method would subtract 5 x from his own position to get the correct position to draw to.

Remember that the Player should not in any way be special, or "exempt" from the rules of the camera. He uses that same offset to draw. He'll usually stay at around the same spot as the camera, but many novice game programmers that always draw him at a special, locked screen coordinate tend to run into trouble fast (for instance, if you reach the end of the level, and the player should now move without the camera following him)

The World would likely be all loaded at once; no need to seperate it into individual screens. To ensure challenges are similar on each run, you could freeze each goomba's AI until their X coordinate is close enough to the Camera's X.

It might help you to draw it out a bit on paper. Initially, programmers are thinking in terms of how sprites should be positioned, and how they move across the screen. In truth, it makes more sense to think of how the world is laid out, and where your little rectangular view of it is moving around. It also makes it much easier to debug, since every goomba, block, and pirahna plant isn't having its position updated for each little camera movement.


You must log in to answer this question.

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