It’s in a very basic stage. Some might even call them ‘faux’ z-levels, but one has to start somewhere, and really I just wanted to get it to a level so I could put a 4 z-level school, a la Gakkou Gurashi. The main devs wanted something like this:https://github.com/CleverRaven/Cataclysm-DDA/issues/6818, more interactive, and thus discussion followed. Since it looks like I will be working on the PR a little longer, I want to keep discussion to this thread, and leave the PR to more technical things.
The blue sky terrain functions exactly like the ‘open’ space in the missile silo-if you jump, you fall till you hit the lowest z-level without the trap. Eventually I want to change this to a flag, so we can have things like aircraft and birds.
As I haven’t programmed in years(and not in c++), I will need some help, as I won’t be able to do it by myself, and if I get the PR to a state where it will be merged, I’ll try to separate the issues into small ones to make it simpler(to me as well).
sounds like the problem is lots of legacy code so z levels require a big re-write of code. so anything we can do to be close to z-levels works for me. you may want to make this a ‘mod’ so if someone doesn’t like it they can turn it off. some people may not.
faux z levels are enought good for me and dev will have less work because adding fancy real z levels will force devs to dramaticaly change current gameplay and old maps may not work correctly
Insane rambling alert
Submap is 12x12 tiles,
Overmap point has 2 sub maps(for total of 24x24)
Overmap is 180x180 points or 360 submaps,
map::shift shifts the submaps when the player moves…
map::loadn is where submaps are loaded, if none exists creates a new submap from map::generate
The map class works double duty. Basically, it takes a parameter n at creation and holds n x n worth of submaps at a time. It also has a #define MAPSIZE 11 that is the size the game uses as the reality bubble. There is also defined a “tinymap”, which is the 2x2 version of map used for mapgen. The game object maintains a reference to the 11x11 map used for the reality bubble. For 3D-izing it, you’d have to have some way to keep tinymap 2x2x1 while making the bubble 11x11x11 (or x21, 10 above, ground, 10 below). Adding a parameter to the constructor would seem the best way to go.
I’m looking at the game::vertical_move function as a guide(because it’s one of the few functions that interact via z-levels), but it seems to best way to do it would be to define something like map *m[number of z levels](i.e put the map class in a array where you would have 21 or SEEZ objects). I’m not certain if this would be the most efficient, but I’m thinking you would need a 3Dmap class that would handle interactions between z levels, but I think it would be more robust.
The other way would be to add z-levels to the submap loading part, and might be more efficient, but it would probably be less robust and a significant portion of the map class might have to be tweaked to accommodate this.
Array of maps doesn’t sound like the right way to do it. It would have to have all sorts of methods controlling interaction between levels. I think the correct way is to add a third dimension to the map size and refactor the existing map methods controlling submap processing to include processing across the z axis. CIB was putting some work into refactoring the map methods to cross levels, he might have some insights into it.
Please, do not look at vertical_move() for inspiration. It is the nexus of the hacks that make inter-z level interaction work, it is emblematic of what needs to be replaced, not something to copy.
The map class itself needs to be aware of multiple z-levels, wrapping it in something that manipulates multiple separate map instances is going to make things terrible and gnarly once you try and make it do anything.
If you mean a wrapper around the existing map class, same as above. We need one class that has a unified view into everything in the reality bubble.
I’m not sure what you mean, submap loading is one thing that already handles z-levels, and should probably remain mostly unchanged. The change is in which submaps get loaded, since it will need to handle ones above and below the player.
Ya… vertical_move() is a mess, I was more looking at it to see how it sees other z-levels and changes between them.
Ok, I’ll continue on the lines of looking at expanding the map class to see levels in 3D, I wasn’t planning to tackle something as big as z-levels so right now I’m just in the looking at the code to understand what’s going on, and planning stage.
Then best place would be to put the wrappers in the map class?
The change in where submaps are loaded is what I meant
CIB’s outline is what I’m working from, but for my mind to process it, I have to understand why, and to understand why I have to understand what the code is doing. I see that some wrapper functions were merged.
I don’t quite understand what the transparency.cache() is for(something to do with lighting?)
It’s super expensive to calculate whether you can see through a square or not on-demand, so we build a cache of which squares are and are not transparent at the start of each turn, then access that cache instead of the underlying tile data.
One of the biggest users of it turns out to be the dynamic lighting system defined in lightmap.cpp since it also uses it to determine which squares a given light source illuminates.
I started a little bit of work doing some basic conversions from (x,y) logic to (x,y,z) logic, but found it pretty intimidating. I think CIB had made better progress in the same arena.
