Layers vs Levels vs ??

#1 PS. dts objects are also a possiblility that we have considered, but we havnt looked into the possible hit due to creating say a tower via script using dts parts. Ie for a 2 level tower haveing 8 wall dts objects, 2 floor dts objects and a roof dts object and loading them in and peicing the tower together.

Still, any suggestions are welcome.

#2 Generally, if you don't need to see or interact with another floor, you should probably load it as a seperate level - especially since load time is relatively short. Depending on how robust your levels are, you could probably get away with not even throwing up a loading screen and still have near-seamless transitions.

Edit: SP

#3 Thats just it. Mobs will be able to move from the ground levels and wander up stairs to any of the tower levels. I'm not far enough along to have looked for any pathing logic to handle if it is loaded in a seperate level. Unless there is some? Personally, seperate levels would be alot easier to handle if there is a easy way to handle pathing logic across levels.

#4 When a level file is loaded it creates a scenegraph and all the objects in the level file are added to the scenegraph. In other words, each level file essentially represents its own 'scene'. Only one scenegraph can be loaded to a scene window at a given time and when a new level is loaded the contents of the old level are discarded, so traditional pathfinding between levels is impossible. While it's true that you can add the contents of another level file to an existing scenegraph (or, conversely, add the contents of an existing scenegraph to the scenegraph of a new level file), I'm not convinced that's what you're after. The process would be cumbersome and slow.

If it is essential to your gameplay to have all enemies in your dungeon/tower/world/thing to be able to move around at all times offscreen and decide when to traverse between floors you will have to sacrifice a lot because it will take a considerable amount of processing power to keep track of the total number of AI-controlled characters that any dungeon game might have all at the same time. In fact, many games cull all AI for characters that aren't within close enough range of a player to affect gameplay.

Game design is the art of 'faking it'. You might want to consider whether you really need all enemies to be able to transition between floors, or if you only need to keep track of enemies that might chase your player character across the transition. Why not save off the state of the floor you're leaving to disk (aside from enemies that want to chase the player) and leave it that way until the player returns?

I hope these suggestions were helpful. If there is anything you'd like me to elaborate on or if I'm way off base and totally misconstrued the feel you're going for let me know.

#5 Yes you are talking about exactly my problem.

Think of Ultima Online. You could walk up towers. And the level would not unload/load. That is basically what I'm trying to acheive. I dont know if they used layers, dts objects, or what when they transitioned from one floor to the next.

#6 Ok, I was immagining more of a Diablo-style game where each floor is expansive and full of enemies and on each floor the other floors are relatively distant and unimportant. In Ultima Online the floors of the buildings existed within the same 'level', so to speak. In that case, you would probably have to figure out some sort of way to determine what floor a character is on. That would include what to hide or show to the camera, what each character will or won't collide with, and what paths the AI-controlled characrers can follow. You could use triggers on staircases or elevators or whatever and check the direction of the player onEnter and onLeave and based on that show/hide upper floors. For all characters you would want to switch their collision masks to collide only with objects on that floor. As for pathfinding: you could set up a node-based graph system to only connect with nodes on each-other's same 'floor' and then have special nodes that you manually connect for paths between two floors.

Edit: Reworded some things for clarity.

#7 So, based on what you are talking about. Would it be better to have layers describing the different stories in the building, OR

replace the tiles for that floor of the building as the player enters it..... OR

use small dts objects to create the building. Ie one dts object for a section of a wall (ie 4 walls * around 3-4 sections per wall = 16 dts objects for the walls, then the floor, roof etc made of parts. And peice them together. We need the ability to change the building on the fly (think warcraft 1 building walls etc).

I'm guessing that it is probably going to be easiest to do option 2, and just replace the tiles around the player for the interior of the building as he enters. But I dont want to jump to any conclusions before I'm sure of the best approach.

#8 That's actually probably going to be the most painful way to do it due to the tileLayer interface. It wasn't really designed to be altered on the fly. It's entirely possible, but tile layers are best suited to be designed in the level builder (specifically: to be designed visually).

You could have different floors laid out in tile layers that overlap and keep the upper floors hidden until the player needs to see them.

I'd say just mess around with it. That's what prototyping is for, and it's really easy to prototype in TGB. Keep me posted on your progress.

#9 @Azmodeus

I'd be interested to see what you come up with. Right now for my game I only load a "blank" level once. Then I have my playing field quickly generated via script. To change fields, I just wipe the level and generate a new field in its place. I'm probably going to switch back to a one-level-per-field sort of scenario, but I'd be curious what results you get.