Print

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

[NEANDERTHAL]

What it says on the tin. Making it possible to make curved minecart tracks (via buildings>constructions>curved track>place 2-3 points and interpolate spline) would allow the construction of faster and safer minecart systems, and the abaikity to take full advantage of minecart physics.

[Reelya]

Yeah, there's no way that's going to work on a tile/grid based system. Mine-cart positions along a spline are not representable in the game-logic / visualization system, and would in fact break compatibility with the game's physics completely.

EDIT: The game is optimized on a grid-based system, and to make another physics system which uses e.g. splines that have a route that doesn't 100% adhere to tiles would be an immense physics calculation problem, along with not being possible to represent correctly in an ASCII art style. The best you're going to get is to assume corner pieces are curved, which is what the current game does.

[voliol]

Yeah, there's no way that's going to work on a tile/grid based system. Mine-cart positions along a spline are not representable in the game-logic / visualization system, and would in fact break compatibility with the game's physics completely.

EDIT: The game is optimized on a grid-based system, and to make another physics system which uses e.g. splines that have a route that doesn't 100% adhere to tiles would be an immense physics calculation problem, along with not being possible to represent correctly in an ASCII art style. The best you're going to get is to assume corner pieces are curved, which is what the current game does.

There is already a separate non-tile system for calculating projectile arcs, so one for mine carts would probably not be too much of an issue. The problem would be how to display the curves, due to the aforementioned visual grid system.

[KittyTac]

Yeah, there's no way that's going to work on a tile/grid based system. Mine-cart positions along a spline are not representable in the game-logic / visualization system, and would in fact break compatibility with the game's physics completely.

EDIT: The game is optimized on a grid-based system, and to make another physics system which uses e.g. splines that have a route that doesn't 100% adhere to tiles would be an immense physics calculation problem, along with not being possible to represent correctly in an ASCII art style. The best you're going to get is to assume corner pieces are curved, which is what the current game does.

There is already a separate non-tile system for calculating projectile arcs, so one for mine carts would probably not be too much of an issue. The problem would be how to display the curves, due to the aforementioned visual grid system.

You could solve it like the projectiles do. Snap to the grid.

[Fleeting Frames]

Minecarts already have separate components for each axis of movement, so the movement itself seems doable - currently, corners override sideways velocity, but they don't necessarily have to transfrom it on exit like that. A clever management of ramps can already give a minecart desired angle of horizontal movement.

Bit bigger issue is the lack of diagonal tiles - though no need to represent every line, can represent like arrows flight paths are done with only |/-\, assuming one can define the whole spline at once.

The bigger issue is that it would inevitably take more tiles total (only a perfect 45° angle could potentially save a tile, and that's not a spline) and thus usually wouldn't be built by players.

[Egan_BW]

[Warning! Tangentially related suggestion incoming!]

Sometimes I think the game should do away with tiles altogether. You can still use zero-effort ascii graphics without aligning to a grid.
Probably still want to use z-levels and a grid for convenience when building or digging, but the grid simply seems VERY ill-fitting for things like boats, moving fortress pieces, and multi-tile creatures.

It simply seems like an unnecessary restriction that EVERYTHING in the game needs to align with one grid. That rule is already kinda broken by projectile physics.

[Reelya]

The problem is that would bring 3D physics into the game, and doing 3D physics calculations and movement would eat up all the FPS.

At the very least, asking for that would mean virtually a full rewrite which would probably lead to a three-year gap in which no actual new gameplay/worldgen features can be worked on.

[Egan_BW]

Projectiles already use 3d physics.

[Reelya]

No, they use a cheap type of physics using simple ballistics formulas. That's hard-coded and not the same as a proper 3D physics engine.

to model a point-projectile in 3D in a grid-based game you just use a 2D line-algorithm for the XY direction, and clip it against walls, with a random roll where it passes through a tile with a creature. For the 3rd dimension, the path is a parabola, so you can use the Quadratic Equation to work out what times from 0-to-1 in it's flight it passes into different z-levels. This is the smart way to do it, because projectile motion under gravity is high-school maths. You don't need things like gravity calculations, mass and momentum and to model the object at distinct time-points. You just say "oh it's moving on a parabola - so where does it hit the static stuff?"

EDIT: And to be even smarter, you just assume it's moving too fast for gravity to matter so have it move on a straight line between z-levels (if the target is on another z-level to the shooter) while also moving in the XY direction. I don't know if Toady does that rather than do the calculation for a parabola, but it would in fact be a lot smarter to just do that. The way to tell would be to try shooting down corridors. If you can shoot the same distance in a corridor vs in an open space, then it's not actually modeling 3D flight, or otherwise projectiles would hit the ceiling and range would be limited. I don't play with troops that much, maybe you can tell me which one is a thing.

[KittyTac]

[Warning! Tangentially related suggestion incoming!]

Sometimes I think the game should do away with tiles altogether. You can still use zero-effort ascii graphics without aligning to a grid.
Probably still want to use z-levels and a grid for convenience when building or digging, but the grid simply seems VERY ill-fitting for things like boats, moving fortress pieces, and multi-tile creatures.

It simply seems like an unnecessary restriction that EVERYTHING in the game needs to align with one grid. That rule is already kinda broken by projectile physics.

It would take a complete rewrite, and boats and multi-tile creatures aren't problematic with a grid. Just have 8 orientations and let those orientations have any movement vector.

[Reelya]

Diagonals rotations can be a bit funny if you use 3x3 creatures. However, if you limit objects to this template then you can rotate 8 ways no problem. Imagine a "dragon" (H = Head, T = Tail, W = Wing, X = Body, where a rider would sit). Smaller multi-tile creatures could lose one or more sections:

Code: [Select]

_H_
WXW
_T_


Code: [Select]

W_H
_X_
T_W

Then the head, tail and wing parts are free to rotate around the body (X), and the body moves only when the head moves to a tile that's not adjacent to the current body. The rest of the body parts are always dragged along with the X. The great thing about this is that things like dragons would be able to squeeze themselves down a 2-wide corridor, but not able to unfurl their wings properly. And that's not something you could easily model using standard 3D game physics. A nice touch with the scenario as I've described it is that a dragon in a 2-wide trench could move one wing up onto another z-level, then use that to drag their body up to that level. Effectively, this whole system would be a tile-based ragdoll "physics" system, but really cheap to implement in terms of processing power.

Now, if you want bigger creatures we can just add more sections but keep the same linkane system:

Code: [Select]

_H_
LXL
LXL
_T_
Imagine this is a giant-sized quadruped, the X's are two joined body-sections, the L's are limbs, T is a tail. The core body is the chain HXXT, and the L's are hanging off each body section. Angle between sections can be anything as long as they're still in adjacent tiles. The point here is that there's plenty you can do for interesting multi-tile creature physics without needing a 3D engine at all.

[KittyTac]

This:

OXO
OOO
OVO

Would diagonally rotate into:

XOO
OOO
OOV

I don't see the fuss.

[Fleeting Frames]

That's because you're rotating spherical creatures. A creature that's a line segment would be 42% longer when moving diagonally.

There's also that if you have creature like this:

_X
OOO
_V

rotating into

X_O
_O_
O_V

a dwarf could walk between it's arms diagonally.

Boats have same issue, 10x1 wall is water-tight in a line, but lets water though when rotated by 45°.

@Reelya: It uses ballastic formulas, as shown by tracing flying minecarts.

If it used a linear formula, then minecart sent even slightly airborne would never come back down until it hits something, which would have some novel applications but overall simulate things worse.

Also, it doesn't use a random roll. The moment a minecart tries to move into a tile where a dwarf stands there's a collision check, and dwarf has chance to dodge based on whether they're a dwarf and their dodging skill, and if collision succeeds the cart  loses consistent amount of velocity, depending on what it hits.



I agree with @Egan_BW that at the very least other things could also have subtile positions kept to the hundreth thousand, like minecarts do, but I don't strongly see the need. It certainly wouldn't be very visible in gameplay, and would require rewriting and testing current movement code. I don't think this would have much of an impact in fps; creatures already count down when they've crossed over to next tile when walking.


I suspect that they meant something lot less complicated than wind (which isn't modeled beyond 10k speed reduction at too high speed in medium), or even subatomic scale simulation, though.

Making landforms into vectors internally, similarly to vector fonts, could also provide fps gains, I imagine, as one would have to check only the entire landform not its each individual tile.

[KittyTac]

That's because you're rotating spherical creatures. A creature that's a line segment would be 42% longer when moving diagonally.

There's also that if you have creature like this:

_X
OOO
_V

rotating into

X_O
_O_
O_V

a dwarf could walk between it's arms diagonally.

Boats have same issue, 10x1 wall is water-tight in a line, but lets water though when rotated by 45°.

Just don't pay attention to the longer line-segment creatures. It's not like it matters, it's just visual, because the number of tiles is the same.

Add a special case for diagonal segments of boats and creatures.

[Putnam]

No, they use a cheap type of physics using simple ballistics formulas. That's hard-coded and not the same as a proper 3D physics engine.

to model a point-projectile in 3D in a grid-based game you just use a 2D line-algorithm for the XY direction, and clip it against walls, with a random roll where it passes through a tile with a creature. For the 3rd dimension, the path is a parabola, so you can use the Quadratic Equation to work out what times from 0-to-1 in it's flight it passes into different z-levels. This is the smart way to do it, because projectile motion under gravity is high-school maths. You don't need things like gravity calculations, mass and momentum and to model the object at distinct time-points. You just say "oh it's moving on a parabola - so where does it hit the static stuff?"

EDIT: And to be even smarter, you just assume it's moving too fast for gravity to matter so have it move on a straight line between z-levels (if the target is on another z-level to the shooter) while also moving in the XY direction. I don't know if Toady does that rather than do the calculation for a parabola, but it would in fact be a lot smarter to just do that. The way to tell would be to try shooting down corridors. If you can shoot the same distance in a corridor vs in an open space, then it's not actually modeling 3D flight, or otherwise projectiles would hit the ceiling and range would be limited. I don't play with troops that much, maybe you can tell me which one is a thing.

He does parabolas.