# Easiest way to make a 3D overworld [closed]

Using something like Blender, would it be easier and more time and space efficient to create 'tiles', and use some kind of software like Tiled to use these tiles in the various maps, or would it be faster to just create the entire maps in Blender?

I ask because the first approach sounds better, in that it takes less space, time and effort, but the second approach seems to be used everywhere. Right now my game uses tiles, but it's very hard to add any kind of elevation. So should I ditch tiles for building the entire scene in Blender or not?

(sorry if my question doesn't fit the format!)

• Why not both? Could you have "tiles" which are slices of the map, as a 3D model? Then, to save memory space, only load the ones nearest the player, and when a player gets a certain distance away, unload them. I think that's what's really commonly used, rather than slicing the model at runtime. – Fund Monica's Lawsuit Jan 15 '15 at 17:41
• That should be good. Let me know if you're confused about anything. – Fund Monica's Lawsuit Jan 15 '15 at 19:44
• "Easiest" is a subjective term, so any answers to this question will be opinions. These types of "help me make a subjective decision" questions are better asked on forums where the model of the site is more open to discussion. – MichaelHouse Jan 15 '15 at 19:55

Why not Zoidberg both?

Make a big 3D model of your map. Then, cut it into pieces. The size of the pieces doesn't matter all that much, but it'll be an inverse relationship between memory and speed. The bigger your "chunks" are, the more memory it will take, but the less often you'll have to load new ones. It's the opposite for small chunks.

In the code itself, only load the chunks closest to the player. As the player moves in a direction, load the chunks in that direction so that the map always appears roughly the same size.

One way that pops to mind immediately is to wait for a player to cross the border of a chunk, then load whatever chunk is next in that direction, and unload whatever loaded chunk is farthest in the opposite. Some pseudocode(ish) to illustrate what I mean:

void onPlayerMove(Player player):
do:
if (player.isOnCurrentChunk) break
if (player.xPos > player.currentChunk.xMax):
moveCurrentChunk(EAST)
else if (player.xPos < player.currentChunk.xMin):
moveCurrentChunk(WEST)
else if (player.yPos > player.currentChunk.yMax):
moveCurrentChunk(NORTH)
else if (player.yPos < player.currentChunk.yMin):
moveCurrentChunk(SOUTH)
else break
while true


loadChunk(direction) would load a chunk from a file or something and place it in the appropriate spot.

unloadChunk(direction) would find the chunk that's farthest in that direction and unload it from memory, saving it to disk if it might be changed so that those changes persist. Or not, if you don't want changes to persist.

Both could also load/unload the entire row of chunks in that direction, the chunk and the ones adjacent to it, whatever; the implementation is up to you. You could also use different boundaries for the chunks, but that might be more annoying to implement, since you'd have to separate the loading/unloading to prevent it from spiraling out of control.

moveCurrentChunk(direction) would change the chunk that the player is supposed to be changing on to the adjacent one in X direction.

This whole thing is looped so that if someone goes off the corner, it records them as going off in both directions, as opposed to one arbitrary one. In addition, this will automatically move to wherever they are, one chunk at a time, if you have some mechanism by which they can move more than one chunk at a time and you don't want to implement some special function for them.

You could probably also do something with their speed; loading the chunk early if they're going fast (e.g. on a mount or the like), or loading more than one at a time. Again, that's all up to you.

Hope this helped.