I am developing a 2d game where the world is made up of tiles.

I have an overworld and a "current world":

  • the current world represent the current tiles on screen at any given time, currently this is in a 2d array (14x10 elements).
  • the overworld is the entire world, currently 28x20 elements, which means there are four screens of tiles. Again these are planned to be stored in a 2d array

I had originally thought to take the entire group of tiles and break them in to 'current world' sized 2d arrays that get passed to the current world object. This would mean however, having to work with a 4d array in the overworld level, which seems to be pretty ugly and more confusing to set up and play with later on.

It would have looked something like:


where "tiles" is the 4d array and:


would get you a 2d array of the group of tiles that fit on a screen/current world. The only idea I can come up with to make this slightly better is to create a helper object that just wraps around a 2d array, breaking up a 4d array in to two 2d arrays, but in essence it is still a 4d array.

Any suggestions on a better way to do this or perhaps a different data structure I can use? Or maybe keeping only a large group of 2d tiles for the overworld, then coming up with some fancy indexing/slicing algorithm that can pull out 'current world' sized parts?

  • Extracting a smaller 2D array from a bigger 2D array the straightforward way requires two for-loops, utilizing two offset values, and is not really rocket science or "fancy indexing/slicing". So where is your question? – Doc Brown Feb 20 '13 at 7:27
  • just asking seeing if there is a better way to store the data so I can avoid using a 4d array (and the double for loops and offsets required to handle them) – mitim Feb 20 '13 at 8:04
  • It sounds like you're hinting towards spatial partitioning, which in this case would most likely be a quadtree. However since your game world is so small (28x20 elements) I would say this isn't even necessary, you could get away with processing and drawing all of those elements each frame without too much of a performance problem. Could be a case of premature optimization? – MattDavey Feb 20 '13 at 9:42
  • I only used 28x20 as it was the minimal size I needed to test the world spanning across multiple screens. But after a break, perhaps you may be right in that perhaps I am prematurely optimizing. It simply felt that having a 4d array was a bit inefficient and less readable (if I had wanted an underworld as well as an overworld, I'd have ended up with a 5d array, and so forth) and that there should be a better way. Nevertheless, I'll stick with plain arrays for now and optimize later if needed. The suggestion for using a quadtree for access may help further down the line. Thanks. – mitim Feb 20 '13 at 10:54

You're overcomplicating it. Just have a single 2d tiles array, and index it like so:

tiles[overworldX + currentWorldX][overworldY + currentWorldY]

  • I'll mark this as the answer as it gave me an idea to keep everything as a single 2d array and just store a reference point for each area. The end result being I can later expand the world in any level and still only just have a 2d array of all my tiles. Thanks. – mitim Feb 21 '13 at 4:30

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.