Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Xehon]

I brought this up in the DF general discussion, thought I make it more formal by bringing it up here. I haven't seen something like this before anywhere else, but I haven't been tracking all the suggestions that much either, so if its been mentioned somewhere just else gimme a link, please.

The idea is to slice Z-levels into 7 slices, like water and magma in current versions. This way we could have a lot of issues solved. Like having actual brooks you can walk through, smooth water to land transitions, naturally occurring slopes, realistic freezing for water less than 7/7 and then some. In additions a lot of improvements could be implemented. Different creatures could climb higher height differentials based on their raws and sizes(think of megabeasts climbing over your walls), smaller creatures could fit into smaller spaces(mole(dog) infestations for our fortresses), small water channels, sloped roofs and other architectural niftyness, etc.

The problem of having an inflated terrain data for this can be solved by having most data for only blocks of 7(stuff like material data). So, whaddya think?

[Draco18s]

This is a tile:

There is 1/7 granite, 2/7 sand, 3/7 water, and 1/7 obsidian.  It is damp.

How does that all mix together?

[MagicJuggler]

The chance of minable mineral being recovered would be related to the layer mixture. E.g. the chance of finding a piece of obsidian or granite would both be 1/7 the chance of finding it had either one been in a 7/7 granite/obsidian tile. The water would be revealed as a 3/7 at the bottom, assuming they were allowed to mine below it; otherwise you would have 1/7 granite, 2/7 sand, 3/7 water...The order of appearance determines the layer, so one could in theory have 3/7 water, 1/7 granite, 3/7 water.

Such a variable height would be useful for modeling stuff like vehicle buoyancy as well, that we could have stuff like 3/7 water, 4/7 boat base.

[Neonivek]

splitting it up!

Solid: Rock and stuff
Dirt: Mud
Course Dirt: Sand
Liquid: Water

[Randominality]

yeh this suggestion makes sense especially since it gives natural slopes. and as for digging/channeling, basing what rock comes out of the tile would be dicated by chance based on how many levels of the particular rock there is. as magic juggler said

[Footkerchief]

You do realize you're just proposing a tile system with smaller tiles, right?

[Xehon]

I made a entry to the suggestion-voting-thingy.For easier voting: the title is "Revamp Z-levels into x/7 slices like liquids".

You do realize you're just proposing a tile system with smaller tiles, right?

In a way, yes. Do you realize that you're capable of asking questions in English?

[MagicJuggler]

Not necessarily, as mining will eliminate a tile like normal, as will channeling, and items are generally 7/7 anyway. Such a system would be also useful for determining aspects such as gas/miasma spread (if the total combined depth of gas in an area is 1/7, and the rest is Open Space, that gas will dissolve, similar to water evaporation), or even lack of oxygen in high-mountain areas (where open space is simply 1 or 0/7). Assuming a hermetically sealed area with no access to oxygen (e.g. completely surrounded by water/lava/rock), oxygen would slowly deplete based on the number of breathers in an area, while trying to pump air into a full, otherwise sealed area, would result in 8/7 air or higher, depending on the strength of the surrounding walls and floors; when the area is unsealed, the air will naturally rush out, assuming the tank doesn't explode outright. (Allowing for...e.g. torpedoes).

[Footkerchief]

Not seeing anything wrong with my grammar.

Anyway, this would be ridiculously hard to implement.  You would have to assign a size to every object in the game, unless you want barrels to be able to fit in a 1/7 crevice.  And then, what happens if you have a 6/7 rock surface and a barrel falls on top?  It can't fit into that 1/7 space, so it has to either float in midair or occupy two tiles at once.

[MagicJuggler]

We're currently not allowed to build on ramps or other unstable surfaces, correct? The simple solution would be to make it so the only way one would be allowed to build on an area would be for open-space to be rated at 7/7.

[Footkerchief]

I'm not talking about building, I'm talking about dropped items.

[MagicJuggler]

Yeah...I ended up realizing that...it would end up being complicated in that case. The worst case would be a large object (such as a magma block) on top of an unstable object (such as a series of anthills).

There are other testcases to consider too:

Suppose we want a you can only mine all or nothing. What happens when you have 1/7 rock 6/7 water, and and adjacent 7/7 rock tile. When you channel the 7/7 tile, the water naturally drains out leaving a 1/7. So there's another issue.

As for dropping...I'm lost.

[texmith]

Not necessarily, as mining will eliminate a tile like normal, as will channeling, and items are generally 7/7 anyway. Such a system would be also useful for determining aspects such as gas/miasma spread (if the total combined depth of gas in an area is 1/7, and the rest is Open Space, that gas will dissolve, similar to water evaporation), or even lack of oxygen in high-mountain areas (where open space is simply 1 or 0/7). Assuming a hermetically sealed area with no access to oxygen (e.g. completely surrounded by water/lava/rock), oxygen would slowly deplete based on the number of breathers in an area, while trying to pump air into a full, otherwise sealed area, would result in 8/7 air or higher, depending on the strength of the surrounding walls and floors; when the area is unsealed, the air will naturally rush out, assuming the tank doesn't explode outright. (Allowing for...e.g. torpedoes).

So smaller tiles without smaller digging designations... why have the smaller resolution if you can't even use it? How would it be displayed? I can't imagine any satisfactory way. Everything would look the same and act pretty much the same but be far more fiddly to manage.

Recording air density would be far simpler without any of this. The air would expand to fill the available space quite unlike water which falls in a pool, so there really is no need for depth.

[Mike Mayday]

Without isometric graphics, this would be a real hell. I'm still finding the "3d-space on ascii graphics" difficult to manage sometimes and now you want to make it 7 times worse?

[lucusLoC]

Necromancer!

2 main problems with this:tile display and item handling.

the "robust" solution: this would be to simply expand the z levels to 7 (or whatever realy) times what they are now. creatures would then be x number of tiles tall, and you would be able to dig and build on multeple levels at the same time.

   pros: (ignoring coding requirements) allows for creatures to have a different height, e.g. dorfs are 4 tiles high, and humies are 6. dorfs dig 5 unit high tunnels, and build 5 unit high walls. material usage is made consistent (more or less) as a wall would now need the right amount of material to build (depending on how high it is). floors are now one tile thick, instead of existing between tiles. slops are natural. no more x/7 water, so no more strange flows. a puddle is only on tile deep, and water would only slosh around if there was a tile of water under it. items would also have to be given a height. tables would be 2 units high for example. chairs might be 3. for dorfs that is, for humies it would be different. this would also help to define an exact volume for tiles, as 1 tile would be about 1 foot thick.

   cons: requires multi-tile creature support, as creatures will need to travel through a volume. item definitions just got crazy. display and designations also just got really complicated. the learning curve is no longer  wall, it is an overhang.

   mitigation: many possibilities, but here is my idea: set the default "height view". what i mean by this is set the volume you want to be viewed in one display tile. for dorfs this would be 5. so looking at a tile would also show the contents of that tile and the next 4 tiles up. volume of water wold be conveyed as it is now, with a number, but the number would be a different fraction. volumes of dirt would have to be conveyed as well. in the case of a 7 height standard you would use . , ` ' " : ; and # the standard full tile.

Code: [Select]

. is completely empty, with a floor
, is on unit of rock/dirt/ruble
` is two units
' is three
etc.
# is displayed as a solid wall like we have now.
       you will have to either k over the tile or switch to a finer z level resolution to see the exact distribution of those tiles. i do not think there is any way around that. any item that is contained in a z slice that you are looking at would also have to show up in the tile, even if it also occupies space outside your current view. moving up and down should move you up and down in blocks of whatever your resolution is set to. so for dorfs ever press of > or < would move you up or down 5 tiles. designations would start on the bottom tiles and designate the entire 5 unit volume, including any partial tiles. you could also enter a finer resolution mode to carve out only x tiles high from this location. so you would carve out a 2 tile high crawl space for water, or a 1 tile high shelf in the wall. you would also be able to manually dig out stairs and slopes, though a designation tool for these should also exist (our current stairs would become a carved out ladder). since items would now have volume as well, things could now be on top of other items. a barrel falling onto a table would be supported 2 units above the floor the table was on. if your view only contained the legs of he table you would only see that as occupying the tile, you would have to scroll up to see the barrel. this also solves the quantum stockpile problem, but would be very difficult to code. there would also be the issue of unusual items balancing on top of each other. a "balance" mechanic could be added to prevent a bin on a statue on a table on a chair. items may also have to have a weight limit to prevent other weirdness, but this whole thing is already complex enough, and i thing we can make due without it (and without balance for that matter)

      there is also the problem of multi-tile items. once a volume is more rigidly  defined, and multi-tile creatures are in multi-tile furniture is a must. a 2x2x8 golem race is not going to want to use a 1x1x4 chair to sit on. how do you handle a 3x3 table sitting on a slope? or on the edge of a cliff? at this point a balance mechanic is almost a requirement. also how do you display it? if it were me i would just stretch the table/item/creature character over the required number of tiles. there will also have to be a rotation mechanic of some kine to handle items/creatures who are not square. . .


the "simple" way: this would keep the display more or less the way it is now, but would add the concept of "dirt" volume

as above this volume would be displaye with . , ` ' " : ; and #

Code: [Select]

. is a standard floor
, is one unit of "rubble"
` is two
etc.
# is walls as we currently have them.
slopes would not exist anymore, and transitioning from one z level to another would only be allowed if the volume of the adjacent tile was 4 or more. so

Code: [Select]

. ; # would be considered the same type of slope we have now.

Code: [Select]

. ' # would be a wall. i know the volume math does not add up, but i am trying to keep this very simple. any more complex and you basically run into the above complications. you may be able to get away with "creature cannot traverse x difference in volume" and not run into to many issues though. so a dorf traverseable slope wold be

Code: [Select]

. " # for the steepest, 

Code: [Select]

. ` ; # for the next steepest etc. i would buy that. slope and item handling would be just as it is now, with items falling onto a volume of "rubble" only showing up on that z level. in this version there is not such thing as a crawl space, and rubble is assumed to occupy space from the floor up. material composition its really irrelevant to this solution, but i suppose if the material rework and hauling is ever done, then one unit of stone/dirt/sand would be produced for each volume contained in the tile. the only other issue is water. near as i can figure it the current water display would have to be modified to tell the player how much volume that tile is capable of holding. so water would be displayed as 7/7 or 5/5 to communicate an empty tile and a 2/7 rock tile, respectively. dig and smooth commands should work on a tile with any volume, and reduce tiles to 0 volume and an appropriate number of items. a fill command would also be nice, and would move aggregate to that tile to fill it, where it would become generic " rock rubble". this would allow a large number of other suggestions to be implemented as well. building can either be built only on an empty tile, or would automatically empty the tile. limitations could be placed as needed, for example smooth would only work on tiles less than 3/7, dig would only work on tiles more than 2/7, and building can only be placed on tile 1/7 or less. this solution also leaves the tile volume question ambiguous, so the multi-tile creature/item problem is put off (again).

conclusion:
the "expand the z levels" idea, while very robust, would basically require a rewrite of almost everything. while i like this idea the most, as it adds the most complexity and realism, it would also add a lot of problems, weirdness and inconsistencies. by the time it is fully implemented you may as well just switch the display to the 3rd dimension as well. it would make more sense that way.

the "simple" solution, as the current solution does, simply ignores the problems and makes the gameplay work. i think it does add slightly to the game though, and does solve a few of the more interesting issues, such as the ice volume issues, and allows us to implement a few nice features such as earthen dams and  sea walls, refilling moats for sieges, rubble in mining and other ideas, while at the same time allowing us to preserve the spirit of the game and its ascii based roots. it can (probably) be added with a "simple" addition to the map data, which means that it may actually have a shot at happening.

either way the current slope handling seems just a bit off. we don not really have the ability to have gentile hills, mounds of trash and other niceties. i think some sort of revamp is in order.