I'm writing basically a pokemon game clone for a little fun and challenge, I'm working on the overworld system. So far I've broken the tile world into different objects called "planes" basically an object that holds a 2D array for tiles that handles rendering and collision. I've created a file format that those can be loaded in from, it has the graphics data embedded right inside the file so everything is in one file. I wrote a world editor for it and I want connecting planes together to be easy from an editing standpoint so my computer illiterate friends can use it. Its come time to create a way to hook these planes together. Theres 3 different ways, that I can think of, to move between planes. 1. Walk across a boundary to the next plane. 2. Walk onto a "teletile" used for creating stairs doors and warp tiles. 3. Use an in game function to teleport such as the move "fly" to take you to a completely different plane that is not in anyway linked to the one you were at. This does not really need to be concidered because it will be loaded when you teleport. I'm having a hard time deciding how to go about linking these planes together so that they load and connect together in game. Planes dont have a uniform size so adjacent planes can be anywhere in relation to the current plane. I cant use the technique of loading all 8 adjacent planes in a grid. Because there might be more or less planes. As well as planes being connect together through teletiles. that are not rendered next to each other. I had one thought on how it could work, however its flawed and hoping for a better solution. My original thought was to have planes contain a list of "linked planes." When entering a plane it would load all the linked planes into memory. This way it would load any possible outlet from the plane so you would find no loading screen. However this becomes a problem for the plane files. Example: If I create plane A and attach it to plane B through the linked planes list. Plane B does not know this plane is linked and the loading will not occur if you walk backwards through the world, which is quite possible in a pokemon game. It also fails when in the situation. Plane A connects to Plane B. The player is standing in plane A. Plane B connects to Plane C. Plane C should be visible from where the player is standing, but it has not been loaded. Help would be appreciate, or you could just laugh at me... the choice is yours. I'm going to continue searching.

Why are planes not a uniform size? Why can't you just load the 4 adjacent planes but not load them if there is no plane connected in that direction?

Load the plane the player is on, and check the four compass-point planes, if they are non-zero(or non-empty strings), load the map that the number(or string) represents, otherwise don't load them, and have that map point to NULL. Don't let the camera pan in that direction, and make the end of the current plane be a wall in that direction.

You could have two kinds of plane-connections, one which the camera does not pan over, and acts as a 'transition' wall, and that the camera does pan over, which makes it a seamless transition.

This would allow you to have areas of weird shapes, such as L shaped maps, and also allow you to have map boundaries you can walk into that lead to different maps.

Teleporting tiles can be handled by the collision, and 'fly'/'teleport'/'dig' moves as well as 'escape rope' type items can be done using scripts, or else hard coded into those skills/items.

It'd really simplify things if you kept 'planes' as a constant size, say, 50*50 tiles, or 100*100, or whatever size works best, and allowed 'maps' to contain several planes attached together at the four sides.

Well i've given it some further thought. I've decided to create a larger object known as a grid. Which contains a grid of uniform sized planes which can be used for adjacent planes. If i wanted to create something that was L shaped I'd simply block off parts of the plane with trees or something similar. Planes can have other planes that they are linked to by teleport tiles that allow for buildings. Planes not in a grid can be any size they want to be. The intention would be to create a grid for the overworld. And then other planes for indoors. Other planes, so to speak, cannot have adjacent planes. If "other planes" want to go back to a grid plane they have to use a different tele tile which will tell the game its a gridded plane and it will need to find the adjacent ones. Thanks for the help.

This should handle my adjacency issues. I could also use this to create multiple grids as well. I could have one for underground. or underwater. Or multiple regions. Etc.

You could get away with not using the grid and using a node/tree based system as you previously mentioned. The tricky part is placing the "tween" nodes, where the loading actualy takes place. Mind you, most people still use a "square" map, but it doesent need to exist in a set place on a grid.

Basicaly, when you load a node up, you place it in the "world" at a specific location. In other words, you are going to have to store a seperate "coordinate space" refering to nodespace and worldspace. You then load a plain node at an offset of your worldspace. When a map is loaded you then code in various surrounding nodes at the outskirts of your primary node by positioning them at a specific worldspace.

Mind you, this does add segnificant complexity, but in theory it would work fine.