[Help] Special considerations for Loading and Unloading Isometric Maps?

[HeadClot]

Hey everyone,

I am part of a group that is currently developing a 2D game engine called EnGo. We are currently implementing level streaming for large worlds into engo. 

Are there any special Considerations that need to be taken into account for Isometric maps and level streaming?

 

Any advice, Tips, or whatever would be appreciated.

 

Thanks for your time,

HeadClot

Edited April 22, 2016 by HeadClot

[lemmy101]

Hey!

 

First thing is this is in our own java engine. If you're using an engine like Unity I'm not sure how helpful this will be, or how much will be taken care of for you, but my general advice would be to do as much of the geometry of the buildings etc with 3D polys and an iso camera as opposed to sprites.

 

1) the draw order is a bit trickier due to the isometric nature of stuff - unlike orthographic or top down, you can't just draw all the floor, then all the tiles, then all the characters for example - you need to draw everything in back to front, bottom to top (if you have multiple z levels) and this involves characters in those tiles being drawn after the floor and walls of that particular tile. If you have lots of tiles this may lead to issues with having to have lots of texture switches which can slow stuff down on the graphics card, stopping batches and meaning you can't draw big parts of the screen in a single batched draw (which are lightning fast), especially since you'll have to texture change from floor/wall to character and back to floor/wall for the next tile, then potentially to character sprites again if there's another character and so on. As such we have a special program that packs all the tiles onto big compressed tilesheets so that it can minimize the performance loss of this. That all said in recent years graphics cards diminish this issue somewhat. Lighting is very tricky if you want to do smooth lighting like ours, since they are essentially black quads warped into the shape of the iso floors / walls, and drawn over unlit tiles to emulate the smooth lighting with different transparency for each corner, and stenciled so that the window holes or fence gaps don't have the lighting drawn over them. If I could start again I'd have made the floor and walls all actual polygons with textures, actually drawn skewed in-place, instead of them being hand drawn tiles in iso, so we could light them directly. We've thought about redoing this in the past but the work redoing them to benefit ratio has never been sufficient. 

 

2) re: streaming, there's not really anything special to consider compared to top down. We have the map seperated into 10x10x8 chunks of tiles. In retrospect we should really have done power of 2 and had 16x16x8 chunks to make things easier, I can't quite fathom why 10 was picked, I think it's because we originally had a 150x150 static map, doubled that to 300x300, and when it came to doing the streaming we had to pick a number that was divisible by. Either way 16x16 would be easier to manage / store / manipulate for various reasons. It basically amounts to a grid of these chunks, and when the player moves across one, they all are offset in the grid, the ones you head away from are discarded, and the strips along the sides your headed toward are loaded up. This happens on another thread that handles requests for chunks to be loaded as they come in so it doesn't pause the game while the chunks are loaded from files. Chunks that are discarded are saved first, and on load it determines if a saved chunk exists and loads it, otherwises loads from the base map data. There are no iso specific things about the map data.

 

Hope this helps, let me know if you want more detail on anything in particular.

[HeadClot]

Hey @lemmy101 -

 

Thanks for the reply. This info is going to be super helpful. I will chime back in if needs be.