Positive Z-level Discussion

Frostwood · 2014-06-20T02:25:27.000Z

So… I made a PR about Positive z-levels seen here:https://github.com/CleverRaven/Cataclysm-DDA/pull/7974

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.

Screenies:

3-D version of John’s Motel:

1c3ec896-f764-11e3-80f6-bf91f7163ff8.jpg1366×768

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.

3-D Office tower provided by acidia:
Level 2

26ffab24-f764-11e3-86d9-2afe02e5e628.jpg1168×738

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).

Arek_PL · 2014-06-20T12:48:30.000Z

i like this idea z levels like this are enought for me

stk2008 · 2014-06-20T13:25:42.000Z

awseome finally some Z level work thank you so much

Zireael · 2014-06-20T14:13:40.000Z

I agree with the folks who already posted here

yonsisac · 2014-06-20T14:37:46.000Z

cool z-level i like it

youtoo · 2014-06-20T17:14:53.000Z

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.

FunsizeNinja123 · 2014-06-20T18:09:16.000Z

Well… These are faux z-levels.

Zireael · 2014-06-20T18:59:37.000Z

FunsizeNinja123:

Well… These are faux z-levels.

Yeah, but still, something for us to experience and better testing for people working on real z-levels.

Arek_PL · 2014-06-20T19:38:39.000Z

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

Frostwood · 2014-06-21T03:47:14.000Z

… reading the code to determine where to begin.

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

vache · 2014-06-21T04:48:42.000Z

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.

Frostwood · 2014-06-21T05:11:35.000Z

vache:

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.

vache · 2014-06-21T05:23:27.000Z

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.

kevin.granade · 2014-06-21T05:23:54.000Z

Frostwood:

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),

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.

Frostwood:

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).

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.

Frostwood:

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.

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.

Frostwood:

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.

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.

Frostwood · 2014-06-21T06:50:19.000Z

Kevin Granade:

*snip

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

vache:

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.

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?)

kevin.granade · 2014-06-21T17:37:36.000Z

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.

conductorbosh · 2014-06-23T16:50:39.000Z

Has actual work on implementing proper Z-Levels begun at all?

I’m not shitting on anyone, I just haven’t closely followed development since the kickstarter and I’m curious.

vache · 2014-06-23T17:48:18.000Z

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.

StopSignal · 2014-06-23T23:26:37.000Z

I did not saw this before, it looks pretty badass. Looking forward to it!

detahramet · 2014-06-24T01:04:24.000Z

I shat myself, literally shat myself, when I discovered the dig up and down option in the build menu. Then I came here.

I need to go change my pants.