11
\$\begingroup\$

I'm about to start developing a sidescrolling game where the player's goal is to travel as far as he can in the horizontal axis before touching down. Note that I do not need to ever travel back on the horizontal axis.

I'm developing this with the AndEngine for Android which uses OpenGL and Box2d.

Before starting, I need to decide on something important: should I use the world around the player to simulate movement or actually move the player and follow him with the camera features of the game engine?

Both approaches seems to have different strengths and fallbacks, so I don't know which one is considered best. For example, what would make it easier to add power ups along the way and have a nice animated background?

Thanks!

\$\endgroup\$
  • 2
    \$\begingroup\$ Move the camera. \$\endgroup\$ – Jonathan Dickinson Jan 14 '12 at 19:31
  • 1
    \$\begingroup\$ Unless you have a specific reason for not wanting to use the camera (which has already been written for you), you should move the player and camera. Adding "power-ups" should not be affected either way. \$\endgroup\$ – Christopher Horenstein Jan 14 '12 at 20:41
4
\$\begingroup\$

It's pretty trivial really, it doesn't really make a difference from the things you've described.

Either you move the background past the camera and the player, or you move the player and the camera with him. I suppose there's one less thing to do if you just move the background.

Although I suppose if you move the background you'll have to parent any pickups and enemies to that, which again, is trivial but it's something to think about.

Personally I would move the player because I just like things to be done in a more realistic way.

\$\endgroup\$
9
\$\begingroup\$

Move the camera (attached to your player). I would imagine that your world has multiple objects such as enemies. If you went with moving the world, you would have to loop through all these objects to update their positions every time the world moved.

If you move the player, and attach the camera to the player then there is minimal resource usage. The game will get to its render phase, loop through everything once like it does every frame, and draw them at position - camera.position. Camera position would always equal your players position in this case.

\$\endgroup\$
  • \$\begingroup\$ Of course if the objects are enemies, you wouldn't have to loop through them, just add the worlds movement to theirs in their update method. \$\endgroup\$ – SirYakalot Jan 20 '12 at 17:11
  • 1
    \$\begingroup\$ +1. Use camera.setChaseEntity(player); to achieve this. \$\endgroup\$ – sm4 Jun 23 '13 at 9:14
6
\$\begingroup\$

I always move the camera and would recommend it - there are many reasons why I prefer this, but the most significant probably boils down to this:

  1. If you move the camera and player, that's only two entities that need to be updated to scroll the screen.

  2. If you move the entire world whenever the screen needs to scroll, that encompasses an unknown and possibly large number of entities that will have to be updated.

\$\endgroup\$
  • \$\begingroup\$ I do agree, but I would add that simply adding a line +='ing the worlds movement to the enemy class would be fairly trivial. \$\endgroup\$ – SirYakalot Jan 20 '12 at 17:10
  • \$\begingroup\$ @AsherEinhorn I suppose you're talking about a scenario such as a scene graph where each node shares the parent's transforms and simply moving the root node (i.e. the "world") would translate everything else automatically? Because in every other case, moving the world implies moving everything in the world - which was the point of my post. \$\endgroup\$ – David Gouveia Jan 21 '12 at 4:42
  • \$\begingroup\$ well if the world's movement is inversely proportional to the player. i.e - you move forward, world moves back, then you could just -= the players movement to all the gameobjects. I agree with you I'm just saying there are trivial ways to get both to work. \$\endgroup\$ – SirYakalot Jan 21 '12 at 10:22
0
\$\begingroup\$

Other answers are good, but I'd like to add a few points of what's better, hoping to help someone who tries to make the same decision for a different project.

Moving the Player:

  • It's simple, everything else is static(ish), so in simplistic terms, the only thing you need to do to move the player is player.x += 5; (pseudocode).
  • It "Clicks better" for most people. When you play a game, you always think that the player moves, not the other way around. So it's easier to think of it as "The player should move, not the world", which in turn, may make it easier for someone to organise it in their heads.
  • Easy to track where the player is (it's position is also its coordinates on the map)

Moving the World:

  • If your game is big enough, you don't have to worry about overflow/underflow, by moving too far away from the center of the world, as the position of the player is always very close to 0.
  • Similar to above, if you mess with 3D calculations, you don't have to worry about inaccurate results with floating points, because everything you see on the screen should be quite close to 0.
  • If done correctly, you can make an "infinite" world.
  • Have to track the player manually, the player's position will always be a small value, which signifies where the player is on the screen (kinda), to know if the player is on the top-left of the map or the bottom-right, you'd have to keep track of that in some way.

At the end of the day, it depends on the project. If someone is making an original Mario clone, moving the world could be complicated, while moving the player doesn't really create many problems. Wanting to make a huge open-world game though, it may be better to move the world instead.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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