Print

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

[Rowanas]

I'm so against the idea of boat designations because it will completely stifle player creativity.

I see Andeerz' point (correct me if I've read this incorrectly), that as it stands, the player will have no way of telling what would float and what wouldn't without actually trying it. Obviously the trial and error method is fine sometimes, but if one little screw up accidentally sinks you leviathan, that's not going to be well received by...anyone. We would need a way to test our ships for sea-worthiness before we dunk them. However, without a designation, the game won't know where the ship ends and the world begins.

I'm not adverse to the idea of being able to select an area and being told the total weight of that area in urists, so that I can go away and add up all the sections of my ship together to get the total weight (and thus, sea-worthiness), but it would be a horrible immersion breaker. Needs more thought.

Andeerz replied while I was typing to say exactly this, but more concisely.

[Andeerz]

That's not what I'm saying, though what you bring up is an extremely important point.  The example you bring up, though, probably wouldn't be that big a deal, since good planning will avoid that, and if you build a huge ship in a dry dock, if the boat floods when the dry dock is opened, just close the dock again, pump the water out and patch up the holes.  :3  I don't think designations would be needed at all to avoid this problem, and wouldn't be a strong reason to have them.

What I am trying to say is that I don't think there is a way for the game to simulate buoyancy without either

A: being able to designate a construction as a single entity (that way the total weight and volume of the construct could be calculated, so could water-tight-ness, as well as buoyancy calculations)

OR

B: have a loosely simulated model of structural strain, load bearing, etc.

These are the only two ways I can see of addressing the problem of the game being able to recognize or treat a multi-tile construction as a coherent, stuck together construct subject to the phenomenon of buoyancy.  Buoyancy is dependent on the density of an object as a whole.

Here's an example to illustrate what the game would have to do to simulate buoyancy given choice B:

Imagine the multi-tiled, multi-z-level bottom of a boat in DF in all its blocky glory.  Let's imagine this boat is made of a single material and let's imagine lowering this boat z-level by z-level into water.  The very bottom edge of the boat touches the water and goes into the water one z-level.  The game needs to then make calculations on whether or not the boat continues sinking (water is displaced), stays submerged at that z-level (water is displaced), or is pushed back up to the surface (no water is displaced).

To do so, the game needs to ask "what is the effective density of each of the tiles of the edge?"  The effective density of each tile is not the density of the material it's made of.  It's the weight of the entire boat divided by the volume of the blocks in the water.  If this effective density of the volume of blocks in the water is greater than that of the water, it continues sinking.  If it's equal, it stays there.  If it's less than that of water, it goes back upward.

I think I'm understanding buoyancy correctly...

Basically, there has to be a way for the weight tiles are bearing to be represented for option B to work.

[Andeerz]

I'm so against the idea of boat designations because it will completely stifle player creativity.

Also, I don't think designations would do much to stifle player creativity.  The reason I'm against them is that they could be subject to exploits and/or allowing really implausible designs.

[ZebioLizard2]

Able to build an entire fortress above the ocean with just one floor tile attached to the mainland right now. Just bringing that up.

Although the ability to build a self propelled, swimming fortress of doom sounds awesome..

[Rowanas]

Andeerz, to answer your point about strain and such, I think what you propose in plan B is the best solution and how I assumed it would work. I hadn't thought of it as a problem, but you are correct, it isn't a feature at the moment and it would need to be. I assumed that things would add their weight to the weight of whatever supports them, but there are issues with that... hmm.. not so easy, this boat stuff.

EDIT:

A thought occurred to me while...unloading my elven caravan. Every building material could have a [MAX_LOAD] tag, much like animals. It would determine how much weight a floor or wall could hold. For the purposes of boats it would... nevermind. this helps in no way, shape or form.

[Andeerz]

Yeah.  It won't be easy... :C

Also, the option B thing doesn't necessitate that we do away with the current ability to support a mountain on a single floor tile.

[Rowanas]

Well... everything is supported by one other thing, right? A wall on a floor tile on another wall tile is still all supported by the bottom-most wall. So everything on a boat must be supported by the bottom-most ship tiles, or, more generally the tiles in contact with the water. Problem solved for weight distribution. It'll take the computer a fraction of a second to work out how much weight is on the water-touching tiles, since it doesn't need to know where exactly the weight is. It just takes the density of everything on board and divides it by the number of water-touching tiles. If it's denser than the water by an arbitrary figure, the ship sinks one z-level and the game recalculates. Ships would only rise in the water if the combined density is less than that of the water by that same arbitrary figure. I add the figure bit on because otherwise ships would be constantly bobbing up and down, causing the computer to recalculate often and increasing the chance of your boat getting flooded.

It's so obvious and easy that I know i've fucked up somewhere.

[thijser]

Maybe we should be able to construct ship parts. These would stay together in case of cave ins and would start floating calculations.
One problem is that our seas are not very deep. Most seas are only 2/3 z-levels deep. This is probably to save a bit of fps. However adding somehow somewhat deeper oceans could lead to more interesting seas in general.

[Andeerz]

Thinking about this some more, I think that the best option IF implementing a structural strain model sort of thing universally would kill the game (think about having to make structural calculations for every tile everywhere, probably constantly, or at least any time there is a change, which would be frequent ;_; ) would be a novel construction designation feature; the kind me and Rowanas were not too keen on.

Thinking about the feature more makes it make more sense to me and I am convinced that such a feature would not be bad in the way I think Rowanas and I were thinking it would be.

Here's what I suggest:

A separate screen could be opened up where a construction can be designed tile by tile.  The construction could be of unlimited size, material use, whatever.  The only limits would be the memory of the computer, time, and player creativity.  After designing the construct tile by tile, the game can then do all the structural calculations regarding strain and stuff, weight distribution, as well as calculate buoyancy (as in how deep in water or any other liquid in the game it would sink and stay at, and how additions or subtractions to its mass would affect its level of buoyancym etc.) among other physical phenomenon before actually constructing it.  That way, all the physics simulation for the object could be done largely before hand without a bunch of physics having to be simulated in real-time for not only the boat (or whatever the hell the construct would be... this would NOT be limited to boats) but the entire damned map.  Any construct designed in this would be subject to the same calculations, regardless of whether it is intended to be a boat, a wagon, a static object, dwarven cruise missile, different-shaped trade-depot, whatever.

Again, this would NOT be limited to boats.  This design mechanic could be used for any custom player-designed (or even non-player-designed) construct.  This would be best for constructs intended to be treated as non-static objects (like vehicles) or for things designated as constructs (like workshops, trade depots, etc.).

Basically, this suggestion is a way to "compartmentalize" physics of the game in such a way as to not have physics implementation break the game (if that is indeed what would happen by implementing a model of structural strain and stuff).

There are undoubtedly some problems with having this, to be sure.  It seems to be a bit clunky and would sort of interrupt immersion by bringing attention to a big limitation of the game, among other things... even in the way I suggest it, there still is something in my gut that says this kind of system isn't really in keeping with what I think Toady's vision is... then again, in DF Talk #8, Toady didn't sound like he was against having vehicles like boats being separately designated objects...

Basically, this suggestion only really matters IF (and that's a bit IF!!!) simulating real-time physics of static structures (which could translate to moving static structures like boats) would be such an immense burden on CPU that it would kill the game.  I am in no way qualified to say whether or not this would be true: for all I know these kinds of calculations would be so trivial a burden, that they would hardly affect performance at all.  Any thoughts?
 

[Rowanas]

I like it, but either

1: All things are designated this way (or with a previously designed template, perhaps), in which case the game is making and storing a huge number of useless calculations for every thing you build. Depending on the number and complexity of these calculations, having the computer actually use the collected data could kill the frame rate anyway.

or

2: Some things use this system and some things use the old (current) system, in which case things designated under the old system would either do the calculations if and when they are required, which would essentially be back down to the structural strain model.

It's a nice idea, but I'm not sure if there would be any frame rate improvement over structural strain, simplified or otherwise.

P.S. I'd like to know what I've done wrong in my simplified structural strain idea about three comments above. PM or post if you fancy telling me.

[aepurniet]

However, without a designation, the game won't know where the ship ends and the world begins.

how does the game know what should collapse? it uses the same rules to figure out what is weighed. its just a list of cells that are unconnected to the rest of the world.

ideally this whole system could be cocked up to reuse as much code as possible.  making DF a full 3d physics simulator would be quite an undertaking. i think the only way it could be done is if it uses a video card for all the calculations (ala physx). it would also not be pretty when things can tilt and lean given that the DF is cell based.

[lampyridae]

I absolutely agree with aepurniet. It's doubtful that a full-blown physics simulation would look good in a DF tile world and DF is already quite process intensive, namely with path finding. As long as a collapsing structure remains a structure and doesn't degrade into a bunch of unconnected falling tiles until it hits a hard surface, then it becomes a question of what happens when the structure touches water/magma.

For a start, a simplistic approach could make a reasonably coherent and certainly usable feature. Let's say if the structure has more floor tiles touching water underneath than it has total wall tiles, it's considered as having support from water, otherwise let it continue it's merry way downward.

Yes this would mean that wooden structures could sink, but the spirit of building a floating structure is there: flat hollow structures float, thin long structures sink and bowl like structures sink a little before floating.

[thijser]

I think the system should be like this:
1 designate ship hull: a ship hull behaves much like normal wall except it doesn't collapse but falls down as a whole. As a trade off it would require a lot of working from your dwarfs. This depends on the material but it would be quite an undertaking as it would mean that first a part is made from glass metal or wood then the design is made by an architect and then someone with a new skill would spent a lot of time actually making it.
2 The game which has chanced a bit is now able to see the ship. It would have to be build on supports which are removed by lever once consruction has finished. Before this happens the area is flooded so that the ship does not get "damaged" from hitting the botton.
3 The game now has a ship that is completly surounded by water. A simple calculation can see how much it weighs and how much water it deplaces.
4 The ship would be able to get pushed by moving water and/or moved by a special task for moving a ship.
5 sail away!!!

An alternative good start would be to simply take the density of a object and look if it is more or less then water and or magma. If it is it will float otherwise it will sink. It seems quite simple. This would not allow for boats but it could make wood transportation systems. 

[Rowanas]

thijser, further back in the conversation there were thoughts on this, you might want to go and check them out to see if anything is missing.

[Andeerz]

P.S. I'd like to know what I've done wrong in my simplified structural strain idea about three comments above. PM or post if you fancy telling me.

Gladly!  :3

Well... everything is supported by one other thing, right? A wall on a floor tile on another wall tile is still all supported by the bottom-most wall. So everything on a boat must be supported by the bottom-most ship tiles, or, more generally the tiles in contact with the water. Problem solved for weight distribution. It'll take the computer a fraction of a second to work out how much weight is on the water-touching tiles, since it doesn't need to know where exactly the weight is. It just takes the density of everything on board and divides it by the number of water-touching tiles. If it's denser than the water by an arbitrary figure, the ship sinks one z-level and the game recalculates. Ships would only rise in the water if the combined density is less than that of the water by that same arbitrary figure. I add the figure bit on because otherwise ships would be constantly bobbing up and down, causing the computer to recalculate often and increasing the chance of your boat getting flooded.

It's so obvious and easy that I know i've fucked up somewhere.

What I think you missed in your suggestion is how the computer will know exactly what is "everything on board".

I don't think the game has a way of doing this, but I think I have an idea of how it could, which would make what you said work!

I will preface my explanation on how to address this with an acknowledgement that because I have never seen the code of DF, I could very well be wrong with my following speculations.  But, it seems to me that the way the game works right now, each tile at some point (when the map is initialized?) makes a simple check to see if its current state satisfies the following condition:

The tile has at least one facet connected to another solid tile that is defined as stationary.

If this condition is satisfied, the tile that made the check then becomes defined as stationary.

It makes this check again if an adjacent tile somehow changes its stationary state (like if the adjacent tile gets mined out or is touching a tile that has a change in its stationary state or something).  If the condition is not satisfied after this check, its status is no longer defined as stationary and it starts to collapse, which then starts a chain reaction to all adjacent tiles.

Just sort of imagine an invisible "access to trade depot" overlay thing, but instead of indicating accessibility, it's indicating stationary-ness.  A change in the accessibility of a single tile at a bottleneck makes all the tiles beyond it turn into non-accessible.  This would be the same way I think this game determines how things collapse.  Which makes me think... if this is the way the game does it, then, holy crap!  I can totally see how your suggestion would work Rowanas!!!  !!!! 

The game could make an additional check in the instance the above situation isn't satisfied after the check.  When the tile becomes no-longer-stationary instead of simply collapsing, it gets flagged as "movable object x", where "x" is any positive integer that hasn't been used before in this map for any other "movable object" flag.  Any tile touching this tile then gets the same flag, which causes them to make the same additional check.  After this happens, and there are no more tiles in this instance that can get this flag, no other tile can ever get this flag of this integer if it contacts a tile of this flag. 

This creates a way for the game to define a multi-tiled, multi-z-level, not-previously defined object in real-time and recognize it.  After this, the game can treat it in any way it is programmed to.  This would make it possible for the game to make buoyancy calculations since it would then be able to recognize that all the tiles that make up the object are part of that object!  Of course, this is all ignoring any possible cost on CPU, but I think this is how it could work with what Rowanas said!  It basically amounts to a system for on-the-fly designation by the game!  And it doesn't require a reworking of the current way structures are handled other than introducing this new check!

I wonder if anyone else has suggested a similar idea... probably...

EDIT:  Wait... this is pretty much what lampyridae said sorta.