3-dimensional Z-level support, Core Part 1: extend map class to 3D [$330]

[GlyphGryph]

Master Ticket #6822

This will be a "bounty issue" for the development of z-line track development.

This has following requirements:
Expand the "map" object to encompass alternate z-levels

CiB's estimate of required task components:

• Implement a "SEEZ", that tells us how far up and down the player can look at most(and by extension, how many of the up/down slices should be loaded into map)
• Extend map to store SEEZ times more submaps
• transparency_cache etc. can stay the same for now - visibility calculations will ONLY happen on current z-level
• implement special submap type that is homogeneously one terrain(e.g. only air, or only rock)
• rewrite anything that changes the player's z-level to do map::shift with the new z-level instead
• optional: don't shift the map on every z-level, shift it only on every N z-levels
• expand creature to have zpos()
• expand the creature tracker/mon_at to be fully 3d
• expand the stored traps to be fully 3d
• expand map::i_at, ter_at, furn_at, get_ter, tr_at, etc etc to be fully 3d

Did you help close this issue? Go claim the $330 bounty on Bountysource.

[CIB]

I'll be tackling this, but progress will likely be slow during my semester.

See my current estimate of what needs to be done here:
https://gist.github.com/CIB/9790666

I'll put up a branch, soon.

[GlyphGryph]

Great. Should I update the tickets with those requirements?

Also, I will try and get the bounties up for each of them - How much do you think they are each worth?

[KA101]

implement special submap type that is homogeneously one terrain(e.g. only air, or only rock)

Bear in mind that underground is now Unpredictable since players can dig a downstair wherever they like. Not sure what that'll affect but wanted to make sure it's on the radar.

[CIB]

Bear in mind that underground is now Unpredictable since players can dig a downstair wherever they like. Not sure what that'll affect but wanted to make sure it's on the radar.

Thanks for the reminder. Stuff like this ought to be handled automatically as long as it uses the appropriate accessors to change terrain(set_ter etc).

[CIB]

I was stuck on how to integrate reality bubble with z-levels cleanly so I wrote a document.

https://gist.github.com/CIB/10397620

[kevingranade]

You might be overthinking it, I was envisioning simply having X* vertical
slices loaded at all times, and optimise around avoiding accessing them
when possible. This boils down to one question, how many levels do we
intend to have as a maximum? If that number is significantly lower than
100 or so, we can probably get away with not worrying about shifting around
and simply have all z levels loaded at once.

*X = 21 for a first approximation.
On Apr 10, 2014 9:10 AM, "Christian Bielert" notifications@github.com
wrote:

I was stuck on how to integrate reality bubble with z-levels cleanly so I
wrote a document.

https://gist.github.com/CIB/10397620

Reply to this email directly or view it on GitHubhttps://github.com//issues/6818#issuecomment-40105084
.

[CIB]

Maybe, I just don't really see that being any less effort, but it's definitely less flexible.

[KA101]

I'm gonna throw out that 10 aboveground levels is probably good enough for game purposes. There are 11+ story buildings in New England, granted, but from a gameplay standpoint there isn't much one can do on the 12th floor that one can't do on the 10th floor.

(Flying vehicles might want to go higher, but we could make a designated "airborne" level for folks who want to be assured that they won't crash into anything, at the expense of significant difficulty interacting with stuff on the ground.)

Put it another way: how many different "office building", "hotel/apartment", etc floors can we realistically expect people to explore? After a while they will start running together. If places need more room, I'm thinking skybridge or simply 3x3 skyscraper.

With basements being diggable to z-10, 21 levels should suffice for present purposes and keep things somewhat manageable for older systems.

[CIB]

Mhm.. yeah, I guess all the work that needs doing for z map shifting is optional. But it will NOT make things more managable for old systems, because I was planning on having only 11 z-levels loaded at a time, not 21, whereas z-map-shifting would happen only very rarely, so that's not really an impact on performance at all.

Another concern is configurability. With this max-z-level approach, you can't just go and say "only 1 z-level at a time", and things will magically speed up. You'd still have all that overhead for loading lots of z-levels into the map each time map::shift is called, even if only 1 z-level is used for lightmap calc etc.

[CIB]

Note: My primary concern here isn't old desktop computers, those will probably be fine. But we did at one point have a working android version, and I also plan to port the game to the dingoo I ordered, and here that configurability really matters.

[kevingranade]

The other question is, when can you PROVE that you don't need certain
levels loaded? Horizontally the bubble is defined by max sight range, but
if the number of z levels is lower than 121, we can't use the same thing.
So why is it that you can see a monster 20 tiles away horizontally, but not
20 tiles away vertically?
Finally, if you're optimizing for lower ram usage, it's premature, and I'd
be very against adding vertical map shifting on that basis. We were able
to run just fine on pretty old android devices even when we were keeping
every submap in existence in memory, and we have most of the work to
dynamically page submaps back out at runtime in place. Just having a few
hundred submaps in the immediate vicinity of the player loaded and active
is no big deal, it's mostly a matter of optimizing the hugely dominant
"nothing to see here" case when processing the map, and saving memory
footprint with the special static submaps we discussed.

[CIB]

I'm fine with coding with static z-levels and then adding shifting on demand. Regarding RAM usage, my dingoo has 32 MB of RAM, I will probably ahve to look into other kinds of optimizations for that anyway. But what I was concerned about was having to LOTS of copying for the caches, not the RAM usage itself.

[ClockworkZombie]

So... I've made it at least as far as implementing the changes described in this issue at least four times, and scrapped those changes out of frustration at least as many times after a dozen or a few dozen steps further into overhauling things. Is this really the sort of thing people would be OK with merging?

How functional is this supposed to be? Do callers need to be re-written to actually use the updated 3D functions? The biggest issue I've run into is that there's a rat's nest of bad caller assumptions that have implications when more than one level is active at a time. This can be simplified a bit by making sweeping generalizations such as that character actions can only be performed on the current level (world_Z or g->u.zpos, what have you), but this is the sort of thing that's just going to have to be re-written in the future.

[KA101]

And that's why it's a bounty issue. These would need to be handled at least wit the others in mind, but a clean (and properly documented, so others can pick up on it--avoiding problems if the original coder disappears) implementation of one would likely get merged.

[kevingranade]

Yea, updating the callers is the real pain point here, and is necessary.
An unused 3d api that isn't called might technically meet the criteria, but
that's why the final criteria is, "we agree it fixes the issue and merge
it".

[CIB]

Yeah my progress is slow mostly because I'm trying to do as much groundwork as possible that can be merged without actually doing the 3d transition. As you can see from the issues popping up, even my harmless refactors can create problems, so I'm really wary of doing a large 2d->3d refactor without first having laid the requirements to make the process as simple as possible.

[CIB]

@GlyphGryph: Following the recent discussion, these won't be necessary anymore:

- rewrite anything that changes the player's z-level to do map::shift with the new z-level instead
- optional: don't shift the map on every z-level, shift it only on every N z-levels

Instead we'll simply have all z-levels loaded into the game at all times, and call map::shift only for x/y transitions as we do now.

I might rework the TODO list in general when I have time.