Shooting through walls - how do I stop this?

[LordStark]

I just noticed that enemy units are able to shoot there arrows through my walls - how do I stop this? They were able to destroy the houses and my Lord that was supposed to be protected...

[Grapjas]

Report them for wallhacking.

[Stan`]

2 hours ago, LordStark said:

I just noticed that enemy units are able to shoot there arrows through my walls - how do I stop this? They were able to destroy the houses and my Lord that was supposed to be protected...

The engine doesn't support blocking arrows, spears or any long range unit through walls.

[Darkcity]

9 minutes ago, Stan` said:

The engine doesn't support blocking arrows, spears or any long range unit through walls.

Its understandable. But I think there are few possible solution which can be configured and probably will help with this issue.

Reducing the range of the unit based on the height of the wall.

Example: Archers with range 60 meters. Wall height : 15 meters. 

Follwoing use cases are possible

1. Archer is standing near the wall, in that case his range on horizontal will be 45. That means he can attach a unit stabding <=45 meter other side of the wall.
2. Archer standing x (<=45) meters away from the wall. In that case he can attack any units standing 45-x  meters away from the wall.
3. Archer standing x (>45) meters away from the wall can't attack unit inside the wall.

These are the core features that can be implemented.

Enhancement feature: The archers visibiity range will also be modified accordingly. Example,

• Current scenario: any archer standing x (<=60) meters can see inside the wall.
• Expected Scenario: Any archer standing x (<=45) can only see inside the wall.

Note: all ranges here are vision ranges, the deducation of 15 is applied to see accross the wall.

Exiciting feature: The projectile to go above the wall. This is somehwat exist already. For example units attacking enemy units garsioned on wall. Similar fashion the projetiles for all ranged units will go above the wall.

@Stan` @LordStark, and @Grapjas Let me know what do you think about feasibility of the solution with current supported mechanism we have in place. 

[Stan`]

Projectile are purely visual they do not take whatever is betwen them. So they don't know about height or other units.

Tracking all the buildings around you might have a hit on performance. Silier once attempted that for terrain

https://code.wildfiregames.com/D1905

[Grapjas]

I have bent my head over this before too. IIRC projectiles do have an entity ID, just not sure what you can do with it other than visually delete them. But if i understand @Stan` correctly, even if you got them to visually delete before it hits the intended unit, the engine will still register it as a hit.

Best way i think would be to check for any entity between the unit and the target along the fly path and if true, stop checking and deal the damage to that unit/building instead. But Stan is probably right and will be costly in performance. 

[Darkcity]

Hmm, I see. So the only possibility is to totally block the attacks from either side of the wall untill wall is destroyed, but attack from garrisoned units can be allowed and they can also be attacked. 

It can be tested  in a mode if this is a good game play or not. (Prone to many bugs)

[smiley]

Projectiles are a pure visual element. The simulation engine is agnostic of the actual arrow or stone. Ranged attacks are simply a velocity and the damage code just run a calculation, there is no physics simulation going on. The visual projectile is also a local entity, which can be considered to not be part of the game, is not serialized, does not affect the game state and is there purely to be seen by the local player.

Unlike FPS games where bullet physics are actually simulated, for RTS games with thousands of units, its not going to be feasible. Have to do ray casts over several entity meshes per turn per projectile. There is a potential optimization if only buildings are considered, which do not move, and are also reduced to cuboids. In which case, it might be potentially okay. However, projectile paths are not rays, there is some ballistics going on. A ray will not have a curved trajectory going over a wall. So I assume a more expensive form of collision detection needs to be done.

This will be a complete overhaul of how ranged attacks are currently implemented.

[LordStark]

Wow, I wasn't expecting there to be so much to this.

Can I ask, does anyone know how other games do it like Age of Empires?

Or maybe these games don't do it and I just never noticed...

[Stan`]

Needs to be checked but I don't think they do.

[Freagarach]

8 hours ago, smiley said:

This will be a complete overhaul of how ranged attacks are currently implemented.

And would be awesome.

[Grapjas]

What if there would be another function added called ExecuteLinearQueryPos(startPos, endPos) to Rangemanager? Returning true immediately and stop searching if it found anything. Much alike the ExecuteQueryAroundPos we already have but that one is checking in radius. To get the positions you can simply use the positions that are already calculated in the PerformAttack function. And while at it, you can probably redirect the damage to the unit/building in the way instead there too.

[Stan`]

3 minutes ago, Grapjas said:

What if there would be another function added called ExecuteLinearQueryPos(startPos, endPos) to Rangemanager? Returning true immediately and stop searching if it found anything. Much alike the ExecuteQueryAroundPos we already have but that one is checking in radius. To get the positions you can simply use the positions that are already calculated in the PerformAttack function. And while at it, you can probably redirect the damage to the unit/building in the way instead there too.

There could be but if would probably be still expensive

[smiley]

51 minutes ago, Grapjas said:

What if there would be another function added called ExecuteLinearQueryPos(startPos, endPos) to Rangemanager?

This would be the ray cast I mentioned, or maybe not a ray since it's a segment now, more accurately line segment to polyhedron intersection I suppose.

It's in the realm of possibility that we can make buildings block projectiles, but units are out of the question as they won't have the same position each turn and would need repeated ray casts unlike a static building which can be done just once, with the caveat that buildings placed and constructed after the projectile was launched would not block.

Somewhat interesting, and I believe I have had this discussion on IRC sometime back in 2018.

6 hours ago, LordStark said:

these games don't do it

Indeed they don't. AoE4 have even more simplified ranged attacks by making them always hit. Essentially delayed damage, instead of delayed hit testing we have.

[Grapjas]

30 minutes ago, smiley said:

with the caveat that buildings placed and constructed after the projectile was launched would not block.

I'd take that caveat gladly opposed to no blocking at all. It would be interesting to see and test what the performance hit would actually be instead of theorising about it. But i don't know C++ so i need someone to join me on that journey.

30 minutes ago, smiley said:

AoE4 have even more simplified ranged attacks by making them always hit

Yup, and theres a decent amount of shooters who do HitReg instead of ballistic hits.

Edited June 30, 2022 by Grapjas

[Freagarach]

3 hours ago, smiley said:

repeated ray casts

I'm not sure about the terminology, but is what you mean that at every turn the former and current position of both entities is used to calculate whether an intersection occurs? Ignoring any entity dimensions here. ^^'

[smiley]

4 hours ago, Freagarach said:

at every turn the former and current position of both entities is used to calculate whether an intersection occurs?

The projectile would be reduced to a velocity. (launch pos + time * direction == unit bounding box). In the case of moving units, this has to be evaluated at every turn since unit positions vary over time, and we can't simply assume that the projectile would not hit any unit until after the fact.

In the case of buildings, they do not move over turns, and if a building bounding box intersects with the velocity at any time value, they can be assumed to do that at the future turns as well. (launch pos + x * direction == building bounding box). Building constructions and destruction would have to be taken into account.

Edited June 30, 2022 by smiley