Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 126 127 [128] 129 130 ... 169

Author Topic: Future of the Fortress  (Read 158184 times)

Another

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #1905 on: August 11, 2007, 01:04:00 pm »

I hope that there actually will be NO bugreports this time due to the absence of bugs  :)

Well, from the realistic point of view I'll try to provide my share of bugreports. So I think just as the previous poster but hope for the contrary then him.

Logged

TheSpaceMan

  • Bay Watcher
    • View Profile
    • http://www.digital-lifeform.com
Re: Future of the Fortress
« Reply #1906 on: August 11, 2007, 01:51:00 pm »

Atleast he won't get some of the funnier bug reports that i have heard of in my time.

From a company that made a port of their game to PS2.
"Your game crashes if there is a golfclub controller connected to controller port 2."

[ August 11, 2007: Message edited by: TheSpaceMan ]

Logged
Poking around with a DFParser.
Bodypart names, creatures names in one easily overviewable place.

Oh my new (old) picture?

Toady One

  • The Great
    • View Profile
    • http://www.bay12games.com
Re: Future of the Fortress
« Reply #1907 on: August 11, 2007, 03:09:00 pm »

Nah, cave-ins are still a nightmare.  There are just some things I know I need to handle, like disconnections and crumbling soil.  People want to make giant statues with arms handling down, and giant domes and so on.  Handling arms hanging down and things like that is aggravating.  I'm still not sure what I'm going to do about that, if anything, this time around.
Logged
The Toad, a Natural Resource:  Preserve yours today!

Zemat

  • Bay Watcher
  • Zemat, programmer, cancels coding: Too insane.
    • View Profile
Re: Future of the Fortress
« Reply #1908 on: August 11, 2007, 03:34:00 pm »

Hey Toady, maybe you should handle cave-ins just like you handle first-time floods in the current version (when miners first reach the cave river or the magma flow). Cave-ins could simply be a function of how weak the material is, and the skill of the miner digging below it. Adding a bonus for the stability of each adjacent tile on the same z-level. So every tile has a associated chance of crumbling down based on the value calculated when a miner dug the tile below it.

Whenever a particular ceiling tile crumbles, every adjacent tile has an increased chance of crumbling along with it.

Also, it would be helpful if the view tool could be used to analyze the stability of a particular ceiling tile (the changes of it crumbling down) so that players get the chance to build some supports below it if they consider the chances of crumbling down too high.

Of course, disconnected blocks of tiles should crumble down always regardless of how "stable" they are.

[ August 11, 2007: Message edited by: Zemat ]

Logged
You too can help bring to life the RogueLife Project!

TheSpaceMan

  • Bay Watcher
    • View Profile
    • http://www.digital-lifeform.com
Re: Future of the Fortress
« Reply #1909 on: August 11, 2007, 03:50:00 pm »

The longer more time and cpu consuming solution to me, would be, since we got materials of stones and metal veins. This would require lots and lots of work.

Each tile would have a connection list keeping track of its neighbors material. When a rock is dug away it will report this to it's neighbors that would recalculate their current stability, stability would be based on the neigbors stability type. Iron ore for instans, might have a higher stabilty value then dirt if connected to other ore. the questions is how big area should effect stability.

What i mean is, to put it simply.

say that the stability of rock is 0+1 per rock tile around it.
It would create something looking like this in stability values if we cut out a one tile wide slice seen from the side.

3333333333333333333333333333333333333
2222222222222222222222222222222222233
___________________________________33
3333333333333333333333333333333333333
3333333333333333333333333333333333333

This wouldnt work well. Probalby some kind of solution where rocks stabilty decrease based on how many neighbours they have that are instable....
or that a rock can't be more stable then it's neighbour, creating a chain reaction that will make large rooms to automaticly turn unstable.

well i should shut up now.
I can realise how this can be a pain in the behind.

[ August 11, 2007: Message edited by: TheSpaceMan ]

[ August 11, 2007: Message edited by: TheSpaceMan ]

Logged
Poking around with a DFParser.
Bodypart names, creatures names in one easily overviewable place.

Oh my new (old) picture?

Toady One

  • The Great
    • View Profile
    • http://www.bay12games.com
Re: Future of the Fortress
« Reply #1910 on: August 11, 2007, 03:53:00 pm »

I don't quite understand it, but it sounds like too local of a solution to allow for some of the grander constructions people wanted.  It's really the specifics of exactly how it calculates the stability of larger structures that is the annoying part.
Logged
The Toad, a Natural Resource:  Preserve yours today!

Zaratustra

  • Bay Watcher
    • View Profile
    • http://zarat.us/
Re: Future of the Fortress
« Reply #1911 on: August 11, 2007, 04:34:00 pm »

Thoughts on the problem:

* Either a tile is supported from below (in case there's a supported tile below or around it) or it isn't. If it isn't, its weight has to be supported by tiles around it, closer or farther away.

* So, basically you'd have a 3d directed graph where each tile supports N other tiles and the weight of those tiles is divided between all of its supporters.

* This is horribly complicated.

* Possibly a force distribution could be simulated with a 3d cell automaton?

* The connectivity of tiles is only changed when you mine or rewall, so you can work only the six (or 18 for diagonally or 26 for triagonally) adjacent tiles outwards.

TheSpaceMan

  • Bay Watcher
    • View Profile
    • http://www.digital-lifeform.com
Re: Future of the Fortress
« Reply #1912 on: August 11, 2007, 04:59:00 pm »

I understand your problem toady, the more i think about it and the more i try to explain it the more complex it becomes, maybe this version should use the old 6x6 secure rule, to make it work. Feels like good and cool caveins would require it's entirely own revision. For instans my mind shows me a picture where there is a cave in but things arn't just destroyed, rather a part of the fortress is lowerd 1->n levels based on the cave in, some areas would require new stairs to work, some parts colaps completely. But i don't know how this would be simulated acordingly if not by one calculation where everything is moved and just lots of smokes that hides everything for a while. I don't envy your task, it's a thine line between performance and cool effects. Still i belive materials of stone should have a inpact, where rewalling can be used as a way to build a "statue", "dome" of stable materials. All i can do is to wish you luck and be glad that i am not curently in your shoes. Think i am leaning to hard on my wish for the realistic physical side of a cave in. Make it in 3 revisions. Make it work, make it nice, make it fast.

Good luck.  :)

Logged
Poking around with a DFParser.
Bodypart names, creatures names in one easily overviewable place.

Oh my new (old) picture?

Zemat

  • Bay Watcher
  • Zemat, programmer, cancels coding: Too insane.
    • View Profile
Re: Future of the Fortress
« Reply #1913 on: August 11, 2007, 06:54:00 pm »

I know my solution is too local but the less local a solution is, the more exponentially time consuming the algorithm is gonna be. I'm a researcher/programmer myself and I deal mainly with simulations so I have experience with slow algorithms which for the most part I can't get rid of    :(

The idea goes like this:

code:

#########################
########a###b##c###e#####
###########     d # ##### Z
             @      #### ^
######################### |

# : is a rock tile
a, b, c, d, e : are also rock tiles named for reference
@ : the dorf that dug this

to overall formula to calculate the stability factor would be:
S(#) = min(1.0, K * T + Q * sum(Sa))

S(#) is the current stability of the tile #.
K is the (normalized) mining skill of the dwarf that dug below it.
T is the inherent strength of the material.
Q is a constant (preferably a value between 0.0 and 1.0)
sum(Sa(#)) is the sum of the calculated stability of all adjacent cells (without taking into account those cells adjacent to them).

if no dwarf has dug below the tile then S = 1.0.
if S >= 1.0 then there's no chance that tile while crumble.
the lower S is the more chance there is that the tile will eventually crumble.

suppose tiles in the example have a material strength value if 0.5, the dwarf has a normalized skill of 0.8, and use a Q of 0.5 Then:

S(a) = 1.0 since no dwarf has dug down below it.
S(b) = min(1.0, 0.5*0.8 + 0.5*(0.5*0.8 + 0.5*0.8)) = 0.8.
S(c) = min(1.0, 0.5*0.8 + 0.5*(0.5*0.8 + 1.0)) = 1.0.
S(d) = min(1.0, 0.5*0.8 + 0.5*(0.0)) = 0.4.
S(e) = min(1.0, 0.5*0.8 + 0.5*(1.0 + 1.0)) = 1.0.

This value has to be calculated just once when any dwarf digs below it and needs to be recalculated when a dwarf digs below any of the adjacent cells. So the value for each cell would have to be calculated at most 5 times if there's no cave-in. Also you would have to recalculate if any of the adjacent cells crumbles. In this case you could simply multiply S(#) for a value less than 1.0 to make it more probable to crumble along with the rest of the cave-in.

If you want to make the algorithm less local you can just make the sum of the stability of adjacent cells take into account even farther cells. This way you can make the overall behavior of the cave-in be as similar as possible to the previous version when the circumstances are similar. If you make the legendary dwarves have normalized skill value above 1.0 (which would no longer be normalized) then you can create stalactite like structures (like hanging arms for statues) without fear of them crumbling down.

Edit:

Just one more thing, if you want to allow players build complex structures like big Buddha-like statues give them a slight bonus to the stability value if they do it via rewalling instead of just digging out the statue. Ancient civilizations mostly choose carefully which rocks they would choose when creating a statue or when digging them out they choose carefully the rock wall where they were going to do it. Also they choose carefully the most skilled masons for that. That's why my equation takes into account both the material strength and the skills of the dwarf.

[ August 11, 2007: Message edited by: Zemat ]

Logged
You too can help bring to life the RogueLife Project!

Zengief

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #1914 on: August 11, 2007, 07:22:00 pm »

Zemat-  That is all fine and dandy, but it doesn't cover cases where there is a hanging arm like Toady mentioned.
Consider this side view
code:

####c###
#   b  #
#   #  #
# ##a  #
#      #
########


Where should this break? a? b? c? somewhere else? Your formula is too local even with the sum of the surrounding stabilities in there.
Logged

TheSpaceMan

  • Bay Watcher
    • View Profile
    • http://www.digital-lifeform.com
Re: Future of the Fortress
« Reply #1915 on: August 11, 2007, 07:33:00 pm »

And using a physics engine or calculating it per tile would be like what? 8 milion tiles or so. That would require lots of juice as well if not alla actors where dormant untill activated, aka a diggning from belove, still to much work i belive...
Logged
Poking around with a DFParser.
Bodypart names, creatures names in one easily overviewable place.

Oh my new (old) picture?

Zemat

  • Bay Watcher
  • Zemat, programmer, cancels coding: Too insane.
    • View Profile
Re: Future of the Fortress
« Reply #1916 on: August 11, 2007, 08:18:00 pm »

quote:
Originally posted by TheSpaceMan:
<STRONG>And using a physics engine or calculating it per tile would be like what? 8 milion tiles or so. That would require lots of juice as well if not alla actors where dormant untill activated, aka a diggning from belove, still to much work i belive...</STRONG>

I have been evading the particular mechanics that trigger a cave-in since I have no idea how it works. Unless Toady uses a random-picker to evaluate cells he must evaluate every cell, every certain amount of time to see if it will cave-in. That OR he actually stores a signal for a future triggering of a cave-in whenever a dwarf digs a room bigger than 6x6. Which is more workable.

 

quote:
Originally posted by Zengief:
<STRONG>Where should this break? a? b? c? somewhere else? Your formula is too local even with the sum of the surrounding stabilities in there.</STRONG>

You have a point. Like I said I have no idea how Toady checks for a possible cave-in. Here I was thinking that maybe local activity is what would trigger the cave-in, instead of it happening by itself. A random-picker could choose a random tile in a certain range near dwarves or creatures and check if the stability factor is below the threshold. If it is, it triggers the cave-in. The random-picker activates whenever a dwarf or creature performs an activity. The farther the chosen tile is from the creature. The less chance it has of cave-in.

Dunno, I surrender   :p

[ August 11, 2007: Message edited by: Zemat ]

Logged
You too can help bring to life the RogueLife Project!

Tacit_Exit

  • Bay Watcher
    • View Profile
Re: Future of the Fortress
« Reply #1917 on: August 11, 2007, 08:59:00 pm »

I think if the cave in logic becomes too complex for the average player to work out while designing rooms it might as well be totally random.

These suggestions don't sound fun at all.

I can understand adding more 'adapt to local conditions/geology' requirements when digging a new room, but please KISS!

Maybe we could have a dwarf skill in assessing rooms, both pre and post designation, such as geology. The little guy could go check out the planned room, and nod his head or run screaming depending on his conclusions on the proposed extension.

Maybe he could also suggest placement of supports in current areas if they are unstable and last long enough (in the updated DF).

I don't think theres too much reason to deal with probabilities in cave ins. Most people imo will want to know the 0% probability for cave in point and design fortresses based on not exceeding that limit. I'm not gonna design a fortress with even 1% probability of cave in rooms since in a long game I'm probably going to have to deal with a collapse eventually.

This makes scaling cave-in probabilities a little redundant, except perhaps to give you time to correct mistakes, which would only be relevant when you are still learning collapse rules.

[ August 11, 2007: Message edited by: Tacit_Exit ]

Logged

Zemat

  • Bay Watcher
  • Zemat, programmer, cancels coding: Too insane.
    • View Profile
Re: Future of the Fortress
« Reply #1918 on: August 11, 2007, 09:32:00 pm »

The point of making rules complex enough yet not totally random is to make it appear totally random to the average player. Yet leaving the possibility for some hardcore players to figure it out so they eventually amaze us all with their constructions.

The problem with the KISS philosophy in game design is that it lends itself to abuse more easily than in other kind of software. Case in point, bunny-hopping and wall-running in FPSs. Also diagonal walking being faster than straight walking in roguelikes. You need to add certain level of complexity to avoid those pitfalls.

Also, if something differentiates DF from other games in my opinion is it's total disregard for simplicity.

[ August 11, 2007: Message edited by: Zemat ]

Logged
You too can help bring to life the RogueLife Project!

gloogorshkin

  • Bay Watcher
    • View Profile
    • http://www.vine-gar.tk
Re: Future of the Fortress
« Reply #1919 on: August 11, 2007, 11:44:00 pm »

quote:
Originally posted by Tacit_Exit:
<STRONG>
I don't think theres too much reason to deal with probabilities in cave ins. Most people imo will want to know the 0% probability for cave in point and design fortresses based on not exceeding that limit. I'm not gonna design a fortress with even 1% probability of cave in rooms since in a long game I'm probably going to have to deal with a collapse eventually.

This makes scaling cave-in probabilities a little redundant, except perhaps to give you time to correct mistakes, which would only be relevant when you are still learning collapse rules.
</STRONG>


Yes, this does make sense for when people are building up their fortresses.  But what about this: At some point in the future, you will be able to send out armies of your own to besiege your enemies.  Now, how do you think dwarves would prefer to attack those humans/goblins/treehuggers? Dwarves are pretty smart guys--they wouldn't all just rush in.  The way I see it, while on the offensive, the real attack force is your miners.

Once you start to get close, your miners begin to dig down a few levels beneath the surface.  Once they reach a good depth, they work their way to the be directly under the enemy's barracks, or perhaps the lodgings of their leader in the area.  They quickly get to work, hollowing out the area below their target, until they have the optimum situation.  At this point, the mines are cleared and the single support that was holding everything up is brought down (this can be an actual support, or a pillar that you leave standing) and everybody gets out.

Once your other military guys know that you've successfully undermined the enemy's operations, they go in to clean up and do whatever you need them to do.

Basically, you want to know how to do this while keeping your miners alive--apart from being cleanup the entire purpose of the guys with spears and maces is to be an escort.

Logged
Pages: 1 ... 126 127 [128] 129 130 ... 169