Chris3606
Full Multi Z-Level Map support in GameFramework and Pathing
Currently, the GameFramework system doesn't support layered maps (maps with mulitple z-levels) natively. It is possible to wrap multiple maps into one map-like entity, but there is a good bit of boilerplate that could be done automatically.
Further, the pathing algorithms (AStar in particular) only support pure 2D coordinates. While an AStar pather can be leveraged to support pathing between z-levels, this can pose some issues if, for instance, you want to path up and down stairs that link z-levels in the most efficient manner possible. It may be useful to include some pathing implementations that support 3D coordinates in that sense.
A class MultiElevationMap could represent a place such as a dungeon or house. It is effectively identical to existing maps except that it's maximum amount of layers is reduced (for memory management purposes) and it may have a connection to the layer above and below it, such as stairs or a ladder. Pathfinding in such a map will work by the same virtues that they work now, pathing towards the nearest stairs if the item they want is in another elevation.
As we get closer to the time-of, these ideas will need to be fleshed out more and better.
A few notes on this:
pathing towards the nearest stairs if the item they want is in another elevation
This works but results in an imperfect path. Going to the nearest stairwell does not result in a a guaranteed shortest path, or even necessarily a valid one; particularly in cases where that stairwell is farther from the destination. Even a more advanced approach that tries to path to a stairwell close to the destination and the current position can fail when you're dealing with things like locked doors that effectively segregate a dungeon into pieces if the thing that is pathing cannot open them.
I think what should happen here ideally, or rather what should happen to fully support this case, is that an AStarMultiLevel and a FastAStarMultilevel class should be introduced (corresponding to the current AStar and FastAStar classes. These classes would work nearly identically but would function with 3D coordinates (where the z was the level), and would expand the definition of neighbors to include up/down. That way the path-finding algorithm can operate in a provably correct way with respect to z-levels, but also keep many of the optimization concepts the current implementation uses by virtue of assuming operation on a grid.
Goal maps would be much harder to do this with, and in that particular case I think leaving only the 2D version might be sufficient, as I can think of relatively few cases where z-level goal maps (as opposed to pathing to a stair and then using a goal map on a specific level) would be the desired approach.
maximum amount of layers is reduced (for memory management purposes)
I'm not sure this would help much or even is necessary; working with layers currently involves bit-masking (which is very memory efficient and quite fast), and the layers themselves are represented by a spatial map. The difference between 2, and, say, 32, spatial maps (the maximum layers that the current implementation can support), would seem to be fairly trivial.
It's also worthy to note that this issue may be closely tied to #182 - in particular for use cases involving combining infinite maps with z-levels.