Bay 12 Games Forum
Dwarf Fortress => DF Dwarf Mode Discussion => Topic started by: Brent Not Broken on July 23, 2009, 01:13:41 pm
-
Because I do. Old habits are hard to break, I guess, and I got comfortable with some shapes back in the 2D version that I still use a lot. Even though I could dig out enormous caverns without supporting pillars and (probably) suffer no consequences (most of the time) for it, I still go out of my way to avoid it.
So, how about you? Do you embrace the new capabilities of dwarven mountain-architects and ignore the old 7x7 rule, or do you hold fast to tradition, in memory of all the lives of dwarven ancestors lost to cave-ins in previous versions?
-
Personally, I can't wait for the confusion when it gets added back in
-
I'm relatively new to DF (been playing since March) and with the warning of my friends, my first few fortresses took cave-ins into consideration. I guess they didn't realize this version took the feature out. I still build wall supports or don't dig out parts of rock to support a room, but because I like the aesthetic, and I don't restrict myself to 7x7 between supports.
Why was the feature removed anyway?
-
-
-
Yeah, that. I think he also wanted to make the cave-ins more realistic, which would mean a more complex system, which will be worked on later. Hence, only a placeholder is present now.
Personally, I'd like to see something where if you were to build a bridge, you would need period supports, etc. maybe add something in for structures that emulate arches- anyway, the possibilities are pretty much endless and on the 'to do' list.
-
Sometimes the rooms may be a little large, but I'm assuming arched ceilings. I still leave pillars in the middle of rooms that are particularly large.
-
I also started to play the game actively just recently, althought I must say that I think 7*7 is quite small. Esspecially when digging through solid rock.
-
I started playing in 3d, and though I don't follow the 7x7 rule, I do leave columns for very large rooms, especially if they're stacked over z-levels, as in a building, and more so in soil layers, especially the layer just beneath the surface.
It just looks wrong without any support.
-
Well, when I'm doing something dwarfy, namely, mining out entire levels of a mountain to drop it on a siege, I find that large clefts appear that I didn't dig.
(Which reminds me. I need to try this in d13)
I wonder if that's part of 'oversized cave in' code, or just DF trying to simplify the task.
-
I'm another relative newbie, and whack out chambers with wild abandon. I actually wouldn't mind seeing the cave-in threat added back, if the danger size was upped a little higher than 7x7.
-
Eh, if only there were not any 5x5 workshops; I'd be fine with him implementing 4x4 cavein trigger size.
Sure, stockpiles would lose a fraction of their storage size (1 square per ~16?)
-
I use a 7x7 to house my Trade Depot.
And my stockpile floor usually has one massive room taking an entire z level mined out.
-
heh, I'm a newbie with the 3D version and have still been digging out 6x6 areas. so no limit now eh? good to know.
-
Well, I'm boned if that's reintroduced, given my propensity to make huge areas for my stockpiles.
-
Well, luckily that 7x7 rule isn't implemented for my game, I have a 40x40x2 dug out without any supports. It's my main dining hall that I made.
-
Personally, I can't wait for the confusion when it gets added back in
Seriously, you can dig out HUGE CAVERNs in actual rock and have no problems.... Assuming that dwarves know how to make arched cielings, which I bet they do.
Now, caveins in the dirt layers, that i would like to see. It would also be much easier to implement, as you wouldn't need to figure out what to do with the 15+ layers of rock above the fall.
Also, I really really hope he makes it so constructions don't break when they fall a few zlevels. Dwarven diving rigs will no longer require magma!
-
All of my non-residential rooms are 7x7 or larger.
Yeah, only playing since 3d.
-
I still play old school and leave walls unmined to support the roof. No area 7x7 or larger. Occasionally I go for multiple z-levels though.
My favorite design is this:
(http://i48.photobucket.com/albums/f239/s4079856/Design1.jpg)
After smoothing and with a central stockpile it looks like this:
(http://i48.photobucket.com/albums/f239/s4079856/Design2.jpg)
You can place workshops around the central stockpile for quick access. I use this design for almost all my fortresses.
-
I sometimes leave some supports just because I think it looks better that way. But lately I've started digging out some pretty big caverns while hunting for ore, and I'm pretty sure I'd gone way over the 7x7 threshold even before that.
-
I can't wait until they're re-implemented. ;D
I normally stick to under 7x7 - close quarters and cramped tunnels feels more dwarfy to me - but there've been times I've gone oversized. I'd love to load up some of my older forts and see what fun results...
Hmmm... which suggests a couple of possible future improvements.
How about a random time delay on oversized sections? The bigger the amount over size, the quicker the collapse? Then you may not realise you've made an Oops until a season or three afterwards...
Or, to fix the potential "hole in the ground at z=0 because X z-levels have collapsed" problem, how about introducing a new rock "type" of rubble? Which takes up 10% more space than a standard wall tile?
Maybe something like this: a 7x7 section collapses, so a 7x7 section of the level above moves down, right? Let's say that 90% of those tiles become rubble with 10% staying as solid rock. That means that of the 49 tiles falling down, some 44 (rounded up) become rubble, taking up an extra 4 (4.4 rounded down) tile space. That means that there's no room on the collapsed level for 4 of these "rubble" tiles, so they stay in the ceiling level, preventing the next z-level above from collapsing.
Let's say that you have a level entirely made of rubble. That's not as stable as solid tiles, so then the limit should be reduced from 7x7 to, say 3x3. So, when digging out underneath a collapsed area (ie. it has a rubble ceiling) you'd need to use supports to prevent further disaster.
Perhaps I should move this to the suggestions forum?
Nar... I doubt it'd be implemented. So I'll just have another Bourbon instead and see what other fun items I can come up with... :P
-
I use lots of 8x8 squares. It gives you 4 workshops with a 2 wide path between all of them, and I put a 2x2 up/down stairwell in the middle. Plus, and 8x8 dining room as the corner of a 17x17 square of living quarters (4 8x8 squares the the dividing walls) works out well.
Ironically, I started playing in 3d but still thought anything over 5 stood a chance of collapse, with 6 wide being only a little dangerous. I used to make 11x11 stockpile rooms with a single pillar in the middle.
Should be FUN when the Toadster Scamps adds collapses back in.
-
I don't see what the problem with 7x7 areas are, I create areas larger than that all the time.
I agree with the proper collapses though, as we will be seeing the usage of supports more often.
-
Cave ins are removed? :(:(:(:(:(:( BAD dwarf architect, he didnt tell me that i could make giant halls with no fear!
-
Hah, I read the topic title and was like "what? I already dig that way." I had no idea that 2D had this stipulation, about automatic cave-ins with areas larger than 7x7, but my standardized architecture has ended up specified exactly like that: everything is on a grid of 7x7 rooms separated by 1 tile walls. Some standard ways of fancying up those squares lead to a variety of modular rooms.
I agree with the many who have stated that they dig with supports anyway for the aesthetic. For gigantic halls Moria style, I always carve out circular 5x5 columns centered on the 7x7 square's corners. Especially with a tileset (like mine), it just looks too nice not to.
Also, support-based architecture is functional for the neat-freaks out there: most of the city-like blocks my designs are based around end up with columnar supports on the corners that are large enough to house utility functions. Right now I have a large central receiving hall that is 23x23 on the entry-level portion of my fortress. The way it interacts with the surrounding architecture, there are four areas large enough on the corners to house pump stacks and full maintenance stairways for the cistern above. When I get to implementing the fortress's grand fountain, I can covertly pump the water without any dedicated architectural feature apparent and use hydrostatic water pressure to ensure a good spray. Another example was two forts ago, in which a Moria hall was to be dug out right under some small ponds. Rather than ruin the natural walls and forgo engraving, I dug out one of the supports into a drainage column and seamlessly drained the ponds into my cistern.
-
Note: on my side, I like the fact that I'm able to somehow support an entire structure on one tile. :D
-
One advantage of the current system is that it's possible to build bridges out of constructed floors instead of using retractable bridges or drawbridges. When I built a long aquifer I gave it supports, but a proper bridge over a major river would never be possible if this was re-implemented without some changes.
-
I don't know how hard it would be to upgrade the physics here. Would the DF system support material raws for shear strength, tensile strength and mass? I'm guessing it wouldn't take much.
-
I don't know how hard it would be to upgrade the physics here. Would the DF system support material raws for shear strength, tensile strength and mass? I'm guessing it wouldn't take much.
Ha... ha... ha. "Not much work", indeed!
Okay, let me restate that. It would be easy as pie to add those stats to the raws. It would be one of the hardest and most processor-draining tasks ever to actually make them work.
Take a look at real-life physics simulators. Even on small-scale projects (like the ten thousand bridge-building Flash games out there), where everything is tightly controlled (one or two materials, fixed to a pretty low-resolution 2D grid), having a few dozen or so objects on-screen starts to cause problems.
Now, consider DF, where you've got absolutely enormous areas in 3D space. An accurate physics simulator for any kind of realistic construct would probably be more work than a speech system that passes the Turing test.
Imagine, if you will, your entire fortress being constructed of 3 flows. Whereas water has to update pressure throughout the system, the physics system would have 3 inter-related stats to update for all of the solid tiles throughout the map. Notice that most maps have a whole lot of solid tiles. Notice that transmitting just one variable, pressure, through a relatively small number of water tiles has a massive effect on FPS. Now imagine that for 3 variables spread through the entire map.
This would make a full-fledged catsplosion look like a tiny hindrance. ;)
-
I like leaving pillars of stone (Or constructing some) for aesthetic reasons. However, I tend to leave them in the middle of 10x10 spaces.
-
I think some of the strain of a physics system could be taken off by prioritizing stress-prone areas, or even keeping track of only which objects exceeded a certain stress threshold. Then objects could update and transmit those stress variables as needed and adjust the list. While this wouldn't be 100% realistic it would be pretty decent, and CPU stress would be highest only in times of collapse or near collapse. However this is not only non-trivial to implement, but it probably would still have fairly detrimental effects on FPS. Another way to handle this is to bundle several connected structures together that have similar stress readings, so that stress is transmitted between macro units before being distributed on the micro level.
I'd be surprised if water doesn't already have some kind of optimization in place for grouping bodies of water into major units, but if it doesn't then there's actually room for significant improvement in the framerate.
-
[CAVEINS:OFF]
Next topic. :D
-
[CAVEINS:OFF]
Next topic. :D
You missed the topic. This is about having to dig smaller than 7x7 areas in the 2d version and still not digging them out, regardless of the differences of the 2d version and 3d version.
-
What happened in the 2D version if you tried to dig out an area bigger than 7x7 a cave in I guess?
Sometimes I do put supports (the constructed kind) under big hanging ledges as it seems like they wouldn't stay up under it's own weight.
I was also putting pylons under the dock for a lake that ended up failing since it just made sense.
-
I think some of the strain of a physics system could be taken off by prioritizing stress-prone areas, or even keeping track of only which objects exceeded a certain stress threshold. Then objects could update and transmit those stress variables as needed and adjust the list. While this wouldn't be 100% realistic it would be pretty decent, and CPU stress would be highest only in times of collapse or near collapse. However this is not only non-trivial to implement, but it probably would still have fairly detrimental effects on FPS. Another way to handle this is to bundle several connected structures together that have similar stress readings, so that stress is transmitted between macro units before being distributed on the micro level.
I'd be surprised if water doesn't already have some kind of optimization in place for grouping bodies of water into major units, but if it doesn't then there's actually room for significant improvement in the framerate.
Except it's basically a huge math and map rewrite for the benefit of 'Caveins', so the cost/benefit isn't quite there. I imagine it's on the pile of things that will happen the next time the map code gets hit (and I don't think even UD involved that)
-
Except it's basically a huge math and map rewrite for the benefit of 'Caveins', so the cost/benefit isn't quite there. I imagine it's on the pile of things that will happen the next time the map code gets hit (and I don't think even UD involved that)
Yeah, definitely; I don't think this is really that practical at all. It seems in theory like it'd be possible to do and do it at a decent framerate with some thoughtful design, but I don't see it happening anytime soon. I think a lot higher benefit will be achieved from many other new features on the drawing board.
-
Too much cost, both in terms of coding time (do you really want Toady to spend 4 months on this?) as well as CPU cycles and too little of a benefit.
Often times you can abstract away complex things and get a good enough result. Its not perfect, but its good enough. And the abstraction saves tons of manhours of programming/testing time as well as system resources which will be better put to use on other things.
-
What happened in the 2D version if you tried to dig out an area bigger than 7x7 a cave in I guess?
You'd get a warning message a few times, then it would cave in, leaving a few times of wall that was similar to half-mined stone (i.e. not smoothable).
-
One advantage of the current system is that it's possible to build bridges out of constructed floors instead of using retractable bridges or drawbridges. When I built a long aquifer I gave it supports, but a proper bridge over a major river would never be possible if this was re-implemented without some changes.
wait.... so nothing like this?
(http://pix.sparky-s.ie/images/3vzltc6fz7bltg864oa.jpg)
(http://pix.sparky-s.ie/images/wqhcijlp3jc4eoveuu.jpg)
-
It'd make more sense to only re-calculate cave-in physics whenever the structure changes (e.g. during mining, construction, etc.) instead of every frame like water, as water moves while stone doesn't (unless there's a cave-in).
-
I think the main problem with applying real physics (shear/tensile strength and compressive stresses) to DF is that it would need to check every single tile against a minimum of 26 others, but in 99.99% of cases, it would need to check against a whole lot more.
It would be lovely to see, and it could be quite simplified so that the stresses are only recalculated any time there is a big change, and that large areas are treated as a single unit - or Toady could go down the Red Faction Guerrilla route and apply the physics to constructions only, and maybe soil/aquifer/wet rock layers.
Example from real life: When digging tunnels if the excavation crews encounter softer rock or water they are forced to slow right down because of the number of extra precautions they have to take to prevent cave-ins.
This could be represented by your miners slowing down, with the structural integrity being implicitly based on the knowledge of your miners.
Dabbling or Novice miners might go at full speed and cause (potentially delayed, but with the old creaking ceiling warnings) cave-ins in these circumstances, but other more experienced miners could have an Inspecting Excavation job and would then be involved in shoring up shonky excavations that they have found on their inspection tours.
-
I think it would greatly slow down FPS while mining, in theory the game could calculate stress every time something changes, in practice since things change VERY fast when mining the game would be making constant, heavy calculations. I expect Toady will come up with something elegant to deal with this, but I doubt it's high on the priority queue.
-
I think the main problem with applying real physics (shear/tensile strength and compressive stresses) to DF is that it would need to check every single tile against a minimum of 26 others, but in 99.99% of cases, it would need to check against a whole lot more.
It would be lovely to see, and it could be quite simplified so that the stresses are only recalculated any time there is a big change, and that large areas are treated as a single unit - or Toady could go down the Red Faction Guerrilla route and apply the physics to constructions only, and maybe soil/aquifer/wet rock layers.
Example from real life: When digging tunnels if the excavation crews encounter softer rock or water they are forced to slow right down because of the number of extra precautions they have to take to prevent cave-ins.
This could be represented by your miners slowing down, with the structural integrity being implicitly based on the knowledge of your miners.
Dabbling or Novice miners might go at full speed and cause (potentially delayed, but with the old creaking ceiling warnings) cave-ins in these circumstances, but other more experienced miners could have an Inspecting Excavation job and would then be involved in shoring up shonky excavations that they have found on their inspection tours.
Oooooh.
A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.
That would be a reason to start with proficient miners instead of a team of novice ones...
-
Oooooh.
A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.
That would be a reason to start with proficient miners instead of a team of novice ones...
No, that sounds horrid.
Let say you start your fort. Your dwarves are rookies at what they do because you're just starting up.
A 3x3 underground space isn't enough room to store much of anything from the wag. Even corridors should really be 4 tiles wide to accomodate future growth for mature forts. You can't even reliably put a workshop into a 3x3 room, as this depends on where the blocked tiles of the workshop are.
So your newbie miners are digging, and you get a cave-in. The miner is killed by the collapse, and now your mining pick is lost under the rubble.
Also there could be no planning for future constructions. You'd essentially have to have your miners practice until legendary, and then start digging out the fortress. Expanding from small tunnels to decent traffic paths can be quite difficult to do, particularly if you're planning on engraving. Constructed walls cannot be engraved.
-
A legendary miner could easily "support" a 10x10 ceiling room, where a dabbling could collapse something like a 3x3... That sounds absolutely great.
That would be a reason to start with proficient miners instead of a team of novice ones...
I like that.
I think it would greatly slow down FPS while mining, in theory the game could calculate stress every time something changes, in practice since things change VERY fast when mining the game would be making constant, heavy calculations. I expect Toady will come up with something elegant to deal with this, but I doubt it's high on the priority queue.
Given the reasonable way flows are working now, it shouldn't be too bad, although I wouldn't mind if mining slowed down a good bit to begin with. You wouldn't want to calculate from scratch everytime, just know enough to know what depends on that block. Any pressure on it would need to be redistributed. If it couldn't THEN you hit the cave-in code.
Bonus points for adding 'capacity' so that a dwarf could cause a cavein by standing in the wrong place without checking everything again.
-
Well, the game already tracks the accessibility of locations to each other. This means it must run the pathing algorithm, at least when accessibility matters, to see if you can path to a location. Also, Dwarves check if they can path to a specific job before they take it on, or at least before they move.
This means that there is a crap-ton of information being produced all the time about where there is open walkable space. If this information could be saved and culled only for areas considered "inside," then the engine has a way of checking only a subset of the map area where cave-ins would matter, as 1: if a dwarf can mine or build something, then it must be able to path to it and 2: only mining or building something can lead to a location that can cave-in, assuming world gen can take such things into account either explicitly or implicitly.
Since your fortress likely only includes no more than 10% of the total volume of the map (in standard play), and if the pathing information is compressed enough, this should give the CPU enough hints to check only a small subset of the total map for cave-ins. Ideally, you'd set up a really dump algorithm that can determine, with very few operations, if a given tile cannot support itself. Something like IF (solid density * volume constant) > (shear strain max), THEN COLLAPSE. If you normalize shear strain in by dividing by a volume constant at load time, then it is a simple comparison. That pushes the collapsed tile onto a stack of collapsing tiles, which cause the engine to check surrounding tiles next frame (with higher priority than the rest of the check list). A "has changed" flag on the check list also speeds this up and is easy to determine. You'd still get some lag with mining, but with some tweaks this could be minimized (check only every fifth frame, etc., or maybe a dynamic check spacing).
-
Well, the upcoming problem is that in the new version Toady has these massive underground caverns. That just made the situation a lot harder to reintroduce cave-ins.
And on the discussions of how to model it properly, remember that the more rock you have over the excavation, the larger you can safely mine. So far from the surface you could make larger rooms than close to the surface.
But the problem with these isn't math or computing power but the ability for a player to actually work out what will and won't collapse. Some miners can make 10x10 but others only 3x3? How would anyone keep track of that? How would anyone work out how big a room they could make by how many z-layers of rock were over their heads? Seems like it'd make the game rather unfun for many people.
-
Hmmm, true. If the sidebar thingy that changes with the z-level (I've never looked into how it is supposed to work) was made to graphically represent how deep the cursor is relative to the whole map, that might help make the cave-ins be more easy to deal with. Perhaps it already conveys this information ???
Besides, we're batting a thousand when it comes to scaring newbies off; what's one, or ten, more ridiculously complex gameplay elements? :)
I hadn't thought of how the new release's undergrounds would affect this...still, using the pathing information which is provided for free just by how the game already works would effectively speed up the cave-in search, though the lag introduced may still be noticeable. But yeah, the real question is if it can be implemented in a user-friendly way.
One could solve this with yet another cave-in option, bringing the total to three: no cave-ins, simple cave-ins (like now), and simulated cave-ins (fancy kill-your-comp). The level of complexity of the full featured version of the game is so high that it probably warrants a whole host of game play options like that to make it even barely playable for a complete newb or the casual gamer.
-
The level of complexity of the full featured version of the game is so high that it probably warrants a whole host of game play options like that to make it even barely playable for a complete newb or the casual gamer.
Well, we seem to rally around that anyway.
"Urist, here's a pigtail bag full of dimple dye seeds, two pregnant cats, a barrel of lye and a map full of skeletal carp and hippos. 100 orcs will be here in 3 months. Good luck."
"Wait, don't I get a pick or axe or anything?"
"Why do you demand everything to be so easy? See ya. Don't forget to write!"
-
I would like to see its comeback - provided it had a little section in the init file.
[CAVE_INS:YES]
[CAVE_IN_SIZE:7]
And so on. Just don't put [CAVE_IN_SIZE:1] in there...
-
Well, the game already tracks the accessibility of locations to each other. This means it must run the pathing algorithm, at least when accessibility matters, to see if you can path to a location.
Actually, it uses floodfill, not pathfinding, but that doesn't change your statement
But the problem with these isn't math or computing power but the ability for a player to actually work out what will and won't collapse. Some miners can make 10x10 but others only 3x3? How would anyone keep track of that? How would anyone work out how big a room they could make by how many z-layers of rock were over their heads? Seems like it'd make the game rather unfun for many people.
Sound fun (http://www.dwarffortresswiki.net/index.php/Fun) to me
Hmmm, true. If the sidebar thingy that changes with the z-level (I've never looked into how it is supposed to work) was made to graphically represent how deep the cursor is relative to the whole map, that might help make the cave-ins be more easy to deal with. Perhaps it already conveys this information ???
Sidebar is distance from the cursor to the surface... It will change as you move it around a single Z-level
-
Just don't put [CAVE_IN_SIZE:1] in there...
Rookie.
-
I really want it to come back, mainly cause i heard awesome stories involving cave-ins from my friends before i started playing, and the new version doesn't have them :(
I even carefully carve/build my rooms with a few pillars in them for the sake of realism.
-
The old 6x6 or 6x7 was a good method for me, but I always dug out my fortresses in the same way. I don't usually dig that way anymore, but I will leave support and pillars for very large rooms usually. Also I would like it for cave-ins to be back in. They bring such fond memories
-
I've got an idea that might work, check this for me.
Everything gets two more tags, a true/false "solid" and scalar "danger", and every tile understands it it's "supported".
When a square first finds it has been mined under, or somehow has empty space under it (cave in) it makes a pathing check. Each step SUBTRACTS "danger" from the steps left in the pathing attempt of (X) tiles. IF it CAN"T path to a tile marked "solid" it caves in. Once it HAS pathed, it gets a number under "supported" indicating what it had left. This might even allow tiles next to it to know if THEY are supported without a full test, forcing a full one only when it apperas to tail once.
solid rock is "support" walls are... other things... *shrug*
It's abusable, but it's also minimal demand.
-
I think cave-ins should have a randomness aspect to them. In the 2d version, every 7x7 open space was guaranteed to have a cave-in eventually. Perhaps a good algorithm would be to periodically pick a random underground location and "expand" a hemispherical volume upwards. The larger the hemisphere gets before being constrained by walls/supports, the greater a chance a cave-in is triggered at that spot. So... the center of even a 5x5 room would have a (very) small chance of having stone fall out of the ceiling on an unsuspecting dwarfy head. Start making 12x12 rooms and you seriously court having the ceiling cave in.