A potential solution to (finally) have bridges

[RemiDav]

Hello all,

I have been reading several posts about having bridges and it mentions several problems that do not seem to have been solved so far.
If there is a way to have a place on a map where both water units and ground units can go, just let me know (and sorry for the post).

There are 2 types of problems that seem to forbid the creation of bridges so far: map making and path-finding
I thought about solutions for both problems, you can let me know if they sound silly.

Map making
The main problem is that we only have a 2d layer with height.
The solution would be to have another layer called bridges.png to show where the bridges are.
The bridges would connect to the highest altitude they touch.

For instance, consider this very simple height map:


Then consider this bridge map:


The result would be this, with the parts where the bridge connects to the land in light red:


We can add a bridge texture map to make it better, etc...

Pathfinding
To my understanding, the pathfinding algorithm does not need to be changer itself, the only modification needed is how to define a neighboring cell.
We would just need to put some cells on the bridge and connect the light red bridge cells to the neighboring land cells.

Problems with that system: the bridges have to be flat, and connect land parts at exactly the same altitude.
An alternative would be to draw the bridge with a heightmap, and to make it fall on the ground "tetris-like". This would allow for bridges connecting different altitudes.

Second problem: To my understanding, it seems that the damage system would allow to do damage at the same time on top of a bridge and under it. I do not know if considering the top of the bridge and the bottom as different path-finding cells would solve that.

Thoughts ?

Note: I have experience in C / C++ / CUDA programming if needed.

[tzaeru]

I guess these also need some kind of a way to determine the bridge thickness (another texture map?) and bridge material. Bridge diffuse texture can't really use a similar, direct mapping as the general terrain, since the surface of the bridge doesn't map easily to 2D anymore. But it could use a repeating texture and build procedural texture coordinates or use a specifically made texture that is laid out in some weird-ass way to achieve mapping to the procedurally generated texture coordinates. Though then it'd be difficult to make close, accurate details to the bridge, like road marks or similar. These would either repeat unnecessarily on the sides of the bridge or be hard to lay out accurately in the diffuse texture. Additionally, the navmesh generator has to take the bridge into account when handling the terrain under it, to determine if units can fit under the bridge. So as can be seen, this gets very complicated very fast!

The end result is that there's a whole bunch of diffuse, heightmap, thickness, specular, normal maps more and some quite complicated ways to get things look and work exactly like you want. It might be more realistic to introduce bridges as wholly separate models that have to be created and imported in the appropriate 3D model authoring tools. But, I suspect, this as well would be extremely difficult to incorporate to the current navmesh generation system?

Still, even bad bridges would be super cool to have.. But I can see that it's a lot, a lot of work.

[Anarchid]

I fail to see how bridges.png is capable of deciding which heightmap pixels are gateways into the bridge dimension in this exact proposal.

That's trivial to solve on its own, but then the next problems start piling up:
- how do you determine the altitude of the bridge?
- if you define altitude in a config file while defining entrances and surfaces in bridges.png, does that mean you can only have all bridges on one altitude level?
- if you infer altitude from gateway pixels, what if some have different altitudes?
- what if the bridge surface goes underground?

As for selecting visuals, i think the only thing that would ever make sense here would be to somehow provide 3d models.

[tzaeru]

While I've never contributed directly into Spring and only have superficial knowledge of its structure and codebase, I would likewise imagine that handling bridges as plain 3D meshes, that are created separately and introduced as environment objects into the game, would be much easier an approach.

It'd still need accommodations to the nav mesh generation and pathfinding, but layered heightmaps (which the OP's proposed bridge solution really is about) risk multiplying the amount of data and complexity that is involved in map creation, unless a lot of shortcuts are taken like the bridges always having same thickness and texture coordinates and stuff like that.

In principle, it's a good idea, but also a bit complicated one.

[Kloot]

The only acceptable (clean, hack-free) implementations of bridges require voxel or mesh terrain.

It ain't happening.

[tzaeru]

Out of naive curiousity, how realistic would the implementation of collidable, navigable, general-use environmental 3D meshes be with the currently used navigation mesh format and pathfinder?

This wouldn't necessarily be only bridges, but also say, a huge 3-floor spaceship interior or whatever.

[hokomoko]

I'll explain Kloot a bit, since his time is too precious to waste.

There are 2 types of problems that seem to forbid the creation of bridges so far...

Your approach has more issues than the ones you have listed:

• Projectiles and collisions - instead of just checking for intersection with ground, you now need to check intersection with both bridge and ground.
• Move types - Units can be launched in the air, and know if they can propel themselves by checking their position relative to ground height. Again, same as before
• Game Lua code - Jumping was implemented on many games, guess what it checks and will now need to be changed?
• More stuff

Searching spring's source for GetHeightReal got me 44 results.
Searching spring's source for GetHeightAboveWater got me 34 results.
Searching spring's source for GetApproximateHeight got me 20 results.

Searching Zero-K's source for GetGroundHeight got me 99 results

Most if not all of this will break by bridges.

(The 3d map approaches suggested by Kloot, but that's a different discussion)

tl;dr: Life sucks.

[RemiDav]

Thanks for all the answers,

Yes, the suggestion was basically a bunch of heightmaps with elements being dropped on each other like in tetris (that solves the bridge altitude problem and the risk of having a bridge going underground).
The cells connecting are the cells colliding with each others (aka an "pixel" of the bridge having the same x/y position as a land "pixel" and the same altitude);
the bridge cell whose the colliding pixel belongs to takes over the underlying ground cell and takes its connections too.

for the thickness, it could be implemented in the same png as the bridge heightmap (ex: red=altitude of the top of the bridge, green=thickness), or with a very small thickness applied uniformly.

Most of the problems mentioned seem to be "solvable" with some code checks or constraints for map designers. (or a lot of code for the weapon system if we do not want the units to shoot through the bridges).

Indeed the original solution proposed is very simple and would create weird things as-is (ex: tall units going through bridges) but strategically and in terms of gameplay, it would expand the game a lot !

For the jumps, my first impression is indeed that the solution might not work. I do not know how the jumps are implemented; I thought units just had a "max slope" they could climb. Is the jump just a very high max-slope value ?

----
Another very simple solution would be to define the only type of possible bridge as a force field over water on which land units can walk and water units can go through. The bridge altitude is then the water altitude, the connected cells for the path finding mesh are the ones where the surface of the map goes over water level. The thickness is almost 0, and the bridge is half transparent like the plasma shield in BA.

Or if you want something compatible with non-futuristic context, just define the bridges as frozen surface/icebergs and consider all ships as icebreakers.




The problem I wanted to solve when I looked for a solution for a bridge was that now, if we want a land access between 2 islands, we need to cut the water path. I wanted to have a map where units could go between islands, or cross a river, without cutting boat access.

[AF]

Spring is a 3D not a 2D engine. Maps are already 3D, not 2D, and just because they're based on a heightmap doesn't mean they lack depth.

My first question is, in your example, how high is the bridge? Could a commander fit underneath the bridge? What about a Krogoth? If I built a buzzsaw under the bridge would it be able to fire? How thick is the bridge? If I place a bridge model I need to define its depth to prevent major clipping if I want depth. What happens if a bridge between 2 cliffs has a join pixel in the middle to the bottom of a canyon? Do the units walk up through thin air? How do you place features on a bridge? If you place a bridge on a metal spot will extractors built on the bridge be able to extract metal? What happens when you define a bridge between 2 points, and both points are underwater? Would a sub pass between the two?

If we ever figure out how to make spherical maps, how would maps work?

[raaar]

maybe one solution is this. Units having a height profile that's taken into account as valid path sectors for other units.

Pathfinding would have to be changed to take into account layers for units over each other, ex:
- ground surface below river
- water surface
- bridge surface
- surface of cube feature standing on bridge surface

In a way, water surface for floating units already kind of works like an extra ground layer.

We could have a building feature (or unit) that allows dropping units or building defenses on top of it.

This approach would reuse the collision handling units already have.

[Anarchid]

Or if you want something compatible with non-futuristic context, just define the bridges as frozen surface/icebergs and consider all ships as icebreakers.

This is a game design decision and is possible to implement:

1) Have ships have minDepth = N;
2) Have ground units have maxDepth = N;
3) Tune your movedefs such that ground units have 100% speed at depth N;
4) Make a map with passages of exactly height N.

There you go! A map with "bridges" where land and sea units are equal.

Here's a proof of concept that basically does this for ZK, in which N=6. It is imperfect in that regard as i was not allowed to completely subvert ZK depth speed malus for ground units, so ground units still suffer ~50% speed malus on "fords".

This approach would reuse the collision handling units already have.

I would strongly advise against this. Spring's current collision handling is very simplistic, and simply cannot do what you aim for. And you *still* will need navmeshes.

[RemiDav]

This is a game design decision and is possible to implement:

1) Have ships have minDepth = N;
2) Have ground units have maxDepth = N;
3) Tune your movedefs such that ground units have 100% speed at depth N;
4) Make a map with passages of exactly height N.

There you go! A map with "bridges" where land and sea units are equal.

Exactly what I needed ! Thanks.
So now I just have to mod BA :)

[Silentwings]

There's no need to change BA to make areas passable by both land & sea units. Just set the height to -18 (and a couple each side iirc) and it will be passable by ~all.

See e.g. this http://springfiles.com/spring/spring-maps/barbary-coves map

[RemiDav]

There's no need to change BA to make areas passable by both land & sea units. Just set the height to -18 (and a couple each side iirc) and it will be passable by ~all.

See e.g. this http://springfiles.com/spring/spring-maps/barbary-coves map

Great, thanks a lot !
Love you guys !

[Super Mario]

I'm with kloot on this, it would be much reasonable and cleaner to implement true 3d maps instead of hackish solution.

[PicassoCT]

The only acceptable (clean, hack-free) implementations of bridges require voxel or mesh terrain.

It ain't happening.

There is another sollution.. dont know if you can consider it hackish.. if advanced unit physics exist, you could create a "infectious" object, meaning a physic entity (the bridge) that gives every unit that touches extended physics for contact time .. and this would give the whole thing at low perf cost realistic collission

That was why AUP had this ridiculous "forcefield" property.. to allow such nonsense as mountainlakes (which are essentially nothing but one huge bridge where ships drive upon..

NO!