Sign in to follow this  
Tocs1001

Seamless tile based game. Loading technique

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I would make it a truly generic system, since that seems to be the direction you're headed.

For each plane, link and load all tiles that are visible from the plane in which the player finds himself, note that this may be different than the planes which are directly connected to the player's plane. Stitch them together as appropriate, and when the player crosses into a new plane, re-evaluate which planes are now loaded. In all likelihood, this means loading some new planes and getting rid of others.

Each plane should contain its visibility list. If A contains B in its visibility list, then so too does B contain A in it's visibility list (unless you have a special reason not too.)

I also do like SotL's idea of having different types of transitions, but the non-panning case may be better handled by the teleport functionality it sounds like you already have in place.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this