about gates, bridges and stairs

[ProvencalLeGaullois]

Hi,

[mylife]

yesterday I took a lot of photos of some castles (in ruins) near my mom house... so I started to think it would be nice to write my own small mod. Castle fight or so...

[/my life]

I would like to have some informations about how the gates are working to let units walking trough them. Is it scripted or hard coded ?

I'm working on a 3D keep tower, I would like to use it as civic center. I would like to have a door at upstairs from where units enter and exit. So I checked how bridges are working. I saw they are not scripted or coded, they are included in the heightmap. So I would know if it would be possible to do some stairs, and if there is some buildings or scripts interesting to study. I thought about gates, because in some way they have a special ability.

[sanderd17]

We don't have walkable meshes for now. The gate simply works by enabling and disabling the middle obstruction of the 3 obstructions defined in the gate. Enabling an obstruction is done for every building anyway when it's build. And disabling is done when it's removed (though through different functions, but the backbone is the same).

Walkable meshes are only planned for Part 2, as they're too much work, and not important enough for gameplay to include in Part 1.

[ProvencalLeGaullois]

ok thx for these informations. Do you have some documentations (web or books) about walkable meshes ?

[sanderd17]

The problem with having them walkable is that it needs to integrate with a other components. Like the pathfinder needs to know where the mesh is connected to the terrain, and what parts of the mesh that can be walked. The position component needs to know at which height the units are, to render them correctly. Both those components are quite big, and very performance sensitive (one added feature can easily multiply your lag).

[ProvencalLeGaullois]

I see... and it's better to let you guys working on IA without adding more problems than you already have to face

[Radagast.]

Couldn't we simply heighten the heightmap at the positions where the walls are located? It has to be steep enough that people can't get ontop without climbing (that is vertical movement only what we have no animation for anyway). A stairs then has to be provied just like being able to add gates to walls.

The stairs will just be that steep so that it's still possible to walk upon. The problem will be that across walls where gates are placed unit won't be able to stand/walk on the wall. This is because then the gates would be untraversable. If a gate is locked, the heightmap could be set there too.

I have no idea how difficult it is to change the heightmap values on the fly ... and it's not as flexible and cool as to have walkable meshes (then we could even have placeable bridges). Where to walk upon could be determined via the steepness, so of course if there is a steep jump in height (as it is for the towers or battlements) it is not possible for a unit to reach those.

The question is if it would be possible to include hollow meshes? That would add to many mesh vertices, would it?

So probably rather take the heightmap adaption way for making walls traversable. Perhaps also add the climbing feature for slowly climbing rocks, but using a attack tower storming a wall should be possible without climbing, so that's optional.

For the constructable bridges we could go the on-the-fly-heightmap-adaption way too ...

1) place the building, get center/origin and extent

2) adapt height to a higher value within the buildings extent.

Unfortunately without walkable and hollow meshes e.g. crossing below a bridge will not be possible as we can only either increase the heightmap value (hence cannot cross below the bridge no matter if we remove the obstruction elements) or we remove the obstruction and keep the heightmap value according to the landscape height (lower in the case of the bridge and the walls).

I am surprised as to how many patches lie arround in trac. We should not be arguing too much about whether brushes are infinite or not but simply use the natural solution as proposed by sanderd and already completely implemented by apha123: constant regrow (perhaps depending on season or weather). People don't like the fact that it's infinite but that's the reality. The problem for the berries if all fruits are harvested all the time in nature is that they can't seed new berry brushes. Once we add that, non-harvested brushes will seed and reproduce while permanently-harvested brushes will never reproduce and could die out finally (after years, what will be within the time scope of city phases).

What do you think?

[sanderd17]

Couldn't we simply heighten the heightmap at the positions where the walls are located? It has to be steep enough that people can't get ontop without climbing (that is vertical movement only what we have no animation for anyway). A stairs then has to be provied just like being able to add gates to walls.

The stairs will just be that steep so that it's still possible to walk upon. The problem will be that across walls where gates are placed unit won't be able to stand/walk on the wall. This is because then the gates would be untraversable. If a gate is locked, the heightmap could be set there too.

I have no idea how difficult it is to change the heightmap values on the fly ... and it's not as flexible and cool as to have walkable meshes (then we could even have placeable bridges). Where to walk upon could be determined via the steepness, so of course if there is a steep jump in height (as it is for the towers or battlements) it is not possible for a unit to reach those.

You can try it yourself: http://trac.wildfiregames.com/ticket/2264

In that ticket, it's used to create celtic slope walls (making the terrain higher after the wall). But there are several problems with using it for walkable walls. First, the terrain rendering is also bound to the heightmap.

Secondly, the height map is very imprecise, one tile is 4x4m. So the terrain would stick though parts of the wall, unless it's massively thick. Even for those slope walls (which only need one unwalkable side), I had to make them twice as thick as the regular walls. For general walls, that would mean they should be something like 6x as wide as currently, to have a walkable part, and to hide the steep edges with models. For water bridges, this could be viable, as the edges are already hidden a bit by the water.

[Radagast.]

I get the point. Thank you for your time. I didn't know of the implications, 6x as wide as currently you say ... oh dear that's a shocker.

So as this is only really useful for bridges I fear walkable meshes are the way to go. I will try to acquire some knowledge and read some papers once I finished (or failed) my engineering studies.

The resolution of 4 m x 4 meters is fixed is it ? No possible workaround ? What if we omit the battlements in a different height and just somehow assure the units walk in the middle so to avoid unrealistic walking in the battlements. Is obstruction resolution 1m x 1m? Then we could make the battlements 1m deep and put obstruction onto it to avoid units standing in there?

The fences make me think 1x1 is the obstruction resolution but your comment in trac makes me wonder about how the fences work:

There are certain engine limitations that require obstructions (and obstruction holes) to be of a certain minimum size. [Context: Comparison of one-piece-building obstructions or composite buildings.]

If fences have very narrow obstruction shouldn't then the minimum obstruction width that is possible be small enough even for the battlements?

As you said the terrain rendering is tied to the heightmap. So that means it is not possible to have a very steep slope, 100% to say? Height is being interpolated? And would walls stay at ground leven if we heighten the middle of the walls (which are 10meter deep since your recent TerrainModifier changes I think). So if we lift the height in the middle of the wall, will the building float ontop or stay on the height it was once placed at?

Good work in the TerrainModifier patch! Sounds promising.

And your changes for making repairng units follow the object to repair once it receives new order is brilliant!

Edited January 10, 2014 by Hephaestion

[sanderd17]

The obstructions can be less, but it cause bigger obstructions sizes (or nothing). You can try it with the fence. If you enable the pathfinder overlay in Atlas, you can place a fence so it makes no single tile "unpassable". If you place a row fences like this, you'll see strange results. The long range pathfinder will think everything is passable, and will just path your units through the fences, but when you come close, the short range pathfinder kicks in (which is more precise), and finds no short path through or around it. This results in the long-range pathfinder kicking in, and returning the same path (as there are no obstructions as far as it can see). This goes into a few loops, until the pathfinders finally give up.

Now, with fences placeable in Atlas, the map designer has some power over it. He can make sure it marks some tiles as "unpassable", or he can make sure the row of fences isn't too long (so the short range one finds a way around it). But when you allow these types of objects as buildable in game, certainly when they're used because of their obstruction, it can cause real problems.

The same with gates. If the gap of the gate is too small, the sides could trigger two adjacent tiles to be marked as unpassable. That would make it impossible to open the gate decently.

For the resolution of the height map, a tile is a 4x4 square when projected along the (upward - in this game) y axis. It's a grid, where every point can be given a different y coordinate. So no, you can't have terrains going straight up. As for changing the resolution to 1x1, that shouldn't be too hard to do if the code is made a bit decently, but you have to think about the pathfinder implications again. Currently, a Tiny map is 128 patches (a patch is something like 8x8 tiles), and a Giant map is 512 patches. So setting the tile size to 1x1 instead of 4x4 would make the pathfinder on Tiny maps just as slow as it is now on Giant maps, and I don't want to imagine what it would lag it would cause on new Giant maps. It's understandable, as for most operations, it will have to check 16x as many tiles to create a path.

That being said, Philip is working on a new pathfinder, the main purpose of his work is to give the long and the short range pathfinder the same behaviour (so you don't get that strange fence issue). To do that, he has to work with a more precise grid of 1x1, so in that case, smaller obstructions, more precise heightmaps, and all those things could work.

[Radagast.]

That being said, Philip is working on a new pathfinder, the main purpose of his work is to give the long and the short range pathfinder the same behaviour (so you don't get that strange fence issue). To do that, he has to work with a more precise grid of 1x1, so in that case, smaller obstructions, more precise heightmaps, and all those things could work.

That's good news!

I had to think a bit about it and now I think I understood the implications you talked about. Very interesting insights. The long and short pathfinder giving different results, never really thought of this.

Though for bridges and walls I might give it a try. Especially if we really get around to include the pathfinder rewrite.

This would allow us to place eye-candy objects too I guess. And fences then could be used for captives/corralling/herding.

@AI News: It's taking shape. I hope to be able to test it soon once I have the military front line math ready (I use vectors to calculate it... so another useful information you posted was that the y-Axis is pointing up! Thx.).