3
\$\begingroup\$

I am writing a 2d game that uses tile-based top-down graphics to build the world (i.e. the ground plane). Manually made this works fine.

Now I want to generate the ground plane procedurally at run time. In other words: I want to place the tiles (their textures) randomised on the fly. Of course I cannot create an endless ground plane, so I need to restrict how far from the player character (on which the camera focuses on) I procedurally generate the ground floor.

My approach would be like this: I have a 2d grid that stores all tiles of the floor at their correct x/y coordinates within the game world. When the players moves the character, therefore also the camera, I constantly check whether there are empty locations in my x/y map within a max. distance from the character, i.e. cells in my virtual grid that have no tile set. In such a case I place a new tile there.

Therefore the player would always see the ground plane without gaps or empty spots.

I guess that would work, but I am not sure whether that would be the best approach.
Is there a better alternative, maybe even a best-practice for my case?

\$\endgroup\$
  • 1
    \$\begingroup\$ What problems did you encounter or expect to encounter with this approach? When your answer is "none yet", then I would suggest you to go on with your approach until you do. \$\endgroup\$ – Philipp May 25 '14 at 23:20
4
\$\begingroup\$

To first generate the tiles, I would use Perlin Noise to determine where to place which tiles, and then render them accordingly. As for how to render them, I would see How'd they do it: Millions of tiles in Terraria

You could keep track of the tiles that are on the screen, and only loop through (and render) those. Depending on things like the size of your tiles, and screen size, this could easily cut down the amount of tiles you need to loop through, and that would save quite a bit of processing time.

Finally, and perhaps the best option (most large world games do this), is to split your terrain into regions. Split the world into chunks of, say, 512x512 tiles, and load/unload the regions as the player gets close to, or further away from, a region. This also saves you from having to loop through far away tiles to perform any sort of 'update' tick.

I think that thedaian does an excellent job of explaining the pros of this technique the cons of using what you planned and this combined with perlin noise can create a "endless ground plane" that you wanted to shy away from at first.

EDIT

As Eejin pointed out, instead of perlin noise I would use Simplex Noise as it is the successor, and more effecient and addresses some of the limitations.

\$\endgroup\$
  • \$\begingroup\$ I would use Simplex noise over Perlin noise as it is faster and improved in a few other ways (it is the successor). \$\endgroup\$ – Eejin May 26 '14 at 14:59
  • \$\begingroup\$ @Eejin Oh didn't know that perlin noise was outdated... Thanks check edits \$\endgroup\$ – Liam McInroy May 26 '14 at 15:43

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.