I have a basic game, in which the player moves the environment around the screen, to give the gamer an impression that the player is actually moving. I want this game to be large and have an open world, each piece of scenery is an object and each frame it updates the scenery to make itself move relative to the player. The trouble is with large amounts of objects this causes the game to slow down, but the objects HAVE to be updated otherwise they will become out of synch with the player. So how can I increase the performance of my game without splitting it up into tiny little levels?

Its a 2D top down game. The position of each object is updated each time, but when there are a large number of objects this takes a long time.

  • 5
    \$\begingroup\$ Do absolutely ALL objects have to be updated ALL the time? Is there any way you can split this world into area that is "visible" and active and the area that is in "sleep mode" and becomes active when player approaches it? \$\endgroup\$
    – Den
    Oct 15 '11 at 18:59
  • \$\begingroup\$ What's getting out of sync? Is this a rendering problem, or do you hae to update all entities because they have to perform some tasks that will then get out of sync? \$\endgroup\$
    – bummzack
    Oct 16 '11 at 8:17
  • \$\begingroup\$ I have to update them each frame to adjust their position to meet the players. \$\endgroup\$
    – Derek
    Oct 18 '11 at 16:22

The technique you're describing is called Scrolling.

Some suggestions:

  • Do not update the position of each object relative to the player (or the viewport). Instead, have your rendering calculate the screen position of each object before it renders it (e.g. subtract the current viewport position). This is known as mapping WORLD coordinates to VIEW coordinates (you might do something else, such as rotation / scaling as well, if the view can rotate or scale)
  • The technique to avoid rendering objects which are off the screen is known as "Culling". A simple way of doing it, is to perform the transformation to view-coordinates (as above), and if the object is clearly entirely outside the displayed area, it does not need to be drawn.
  • Say you have a world with 1M objects in it. Probably, it will take too long (each frame) to scan all 1M objects, to determine which ones are outside the view (almost all of them). Therefore you need to use some optimisation. The easiest way to do this, is to attach the objects to lists on a uniform grid, and only check the objects on the lists close to the viewport.
  • If your objects are not axis-aligned boxes, then you can calculate Axis-Aligned Bounding Boxes (AABBs) for them, which makes culling (and other things, such as collision detection) easier.
  • Another idea would be "lazy initialisation" of your world - only actually create parts of the world which are close to the player: split the world into "zones" or "blocks", and initialise the blocks as the player gets close to them. When the player is far away from a "zone" or "block", you can destroy it. This would save memory and mean that the world can be effectively infinite.

You have to decide which objects (or part of objects) are visible and only draw these.

You have to give more details: what kind of game? 3D, 2.5D, 2D? If 2D which kind? Platform, isometric, side-scroller, etc?

  • 2
    \$\begingroup\$ -1 for an answer which should have been a comment (request for more info), but +1 for a welcome to gamedev... so 0 \$\endgroup\$ Oct 16 '11 at 6:59

You must log in to answer this question.

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