Checking Line of effect - theory discussion
by Ian Wilson · in RTS Starter Kit · 03/16/2009 (12:27 pm) · 8 replies
Here's an interesting puzzle I'm working on. I have many models on a board, in a turn based game. I can check LOS from the models, but checking line of effect LOE, is a completely different challenge. I'm looking for any advise on how to implement this.
The current solution (still in concept only):
Add several mount points to each model during export from 3DS MAX. On mission load, attach small LOE checker objects to the mount points. These would be invisible to the player.
Next we take the cam point where the player checked LOS from, and draw a line to each of the LOE objects. We test collision for those lines. If any of the lines are successfully, drawn, the unit has LOE and can fire normally. depending on the colliding object, cover values can be taken into account.
Problems:
The more accuracy desired = more LOE objects required.
Drawing the "line" to test collision. We could scale a dts shape up until it reaches destination, and check collision as normal. I wish TGE had polysoup.
The line needs to be rotated so that the scaled object ends up at the mounted LOE object.
There might be some more issues, I haven't foreseen yet.
Hopefully someone has a much better idea for this problem.
Thanks,
Reed
The current solution (still in concept only):
Add several mount points to each model during export from 3DS MAX. On mission load, attach small LOE checker objects to the mount points. These would be invisible to the player.
Next we take the cam point where the player checked LOS from, and draw a line to each of the LOE objects. We test collision for those lines. If any of the lines are successfully, drawn, the unit has LOE and can fire normally. depending on the colliding object, cover values can be taken into account.
Problems:
The more accuracy desired = more LOE objects required.
Drawing the "line" to test collision. We could scale a dts shape up until it reaches destination, and check collision as normal. I wish TGE had polysoup.
The line needs to be rotated so that the scaled object ends up at the mounted LOE object.
There might be some more issues, I haven't foreseen yet.
Hopefully someone has a much better idea for this problem.
Thanks,
Reed
About the author
#2
Do your LOE objects represent the locations of weapons? If so, then wouldn't you care only about the line from the LOE to the target? Why is the eye-to-LOE line also important?
03/16/2009 (3:08 pm)
Sounds interesting but I'm not really understanding either. What exactly is Line Of Effect?Do your LOE objects represent the locations of weapons? If so, then wouldn't you care only about the line from the LOE to the target? Why is the eye-to-LOE line also important?
#3
Most models are humanoid (legs, arms, head) The player checks his own line of sight. The camera becomes mounted to the eye node of the model whose LOS he is checking. If the player can see the target or a part of the target, then he is fairly certain he can shoot it. If there is something in the way, he will anticipate poorer accuracy due to interference from the cover (the obscuring object)
Line Of Sight (LOS) is the player's own eyes checking for interference.
Line of Effect (LOE) is the collision operation that the game performs to see if there are modifiers to the shots success rate.
That part works fine, but the game needs to know whether the player's shot will be influenced by cover. So the mount points (with mounted LOE objects) represent the other end of the line of effect. The beginning of the line is always the eye node of the attacker, since that is the point that the player used to check LOS.
Maybe an example will help?
UnitA is the attacker, and unitB is the target. The player selects unitA and clicks "check line of sight". The free camera in isometric mode jumps to the fixed position of the eye node of unitA. The player can rotate the camera, but not translate it. Target B is partially obscured by a large rock, but targetB's right arm and leg is visible. The player leaves "Check LOS mode" and selects unitB as the target for unitA's shot. The game now calculates the LOE. An invisible line is drawn from the eye node of unitA to each of the LOE nodes of unitB (LeftHand, LeftArm, Torso, Head, RightArm, RightHand, LeftLeg, RightLeg, LeftFoot, RightFoot) Collision is detected for all the lines except RightHand, RightArm, RightLeg, and RightFoot) The colliding object is found to be genericLargeRock. So a 10% modifier is attached to the success rate of the shot's chance to hit unitB.
Hopefully this is clearing things up, not confusing you further.
Reed
03/16/2009 (3:54 pm)
Thanks for all of your interest. Let me try and clarify:Most models are humanoid (legs, arms, head) The player checks his own line of sight. The camera becomes mounted to the eye node of the model whose LOS he is checking. If the player can see the target or a part of the target, then he is fairly certain he can shoot it. If there is something in the way, he will anticipate poorer accuracy due to interference from the cover (the obscuring object)
Line Of Sight (LOS) is the player's own eyes checking for interference.
Line of Effect (LOE) is the collision operation that the game performs to see if there are modifiers to the shots success rate.
That part works fine, but the game needs to know whether the player's shot will be influenced by cover. So the mount points (with mounted LOE objects) represent the other end of the line of effect. The beginning of the line is always the eye node of the attacker, since that is the point that the player used to check LOS.
Maybe an example will help?
UnitA is the attacker, and unitB is the target. The player selects unitA and clicks "check line of sight". The free camera in isometric mode jumps to the fixed position of the eye node of unitA. The player can rotate the camera, but not translate it. Target B is partially obscured by a large rock, but targetB's right arm and leg is visible. The player leaves "Check LOS mode" and selects unitB as the target for unitA's shot. The game now calculates the LOE. An invisible line is drawn from the eye node of unitA to each of the LOE nodes of unitB (LeftHand, LeftArm, Torso, Head, RightArm, RightHand, LeftLeg, RightLeg, LeftFoot, RightFoot) Collision is detected for all the lines except RightHand, RightArm, RightLeg, and RightFoot) The colliding object is found to be genericLargeRock. So a 10% modifier is attached to the success rate of the shot's chance to hit unitB.
Hopefully this is clearing things up, not confusing you further.
Reed
#4
> The game now calculates the LOE. An invisible line is drawn from the eye node of unitA to each of the LOE nodes of unitB
wouldn't you want to draw a line from the weapon node of unitA rather than the eye node ?
03/16/2009 (4:22 pm)
i see, i think.> The game now calculates the LOE. An invisible line is drawn from the eye node of unitA to each of the LOE nodes of unitB
wouldn't you want to draw a line from the weapon node of unitA rather than the eye node ?
#5
So you're saying, cover unitB with (to pick a number) 20 LOE objects. Do a raycast from unitA to each of unitB's LOEs. If only 2 rays hit unitA, you say there's a 2/20=10% chance to hit (or 10% damage, or whatever).
The idea being to calculate the approximate percentage of unitB exposed to unitA... right?
The implementation you described sounds reasonable to me; I think that's the way I'd tackle it too.
There might be a simplification--you might be able to do the raycasts directly from unitA to nodes on unitB, without mounting any actual LOE objects to the nodes. But I'm not sure if TorqueScript gives you access to the locations of those.
It would depend on how the engine's torqueScript API exposes that stuff.
03/16/2009 (6:22 pm)
Ok, I think I get it too.So you're saying, cover unitB with (to pick a number) 20 LOE objects. Do a raycast from unitA to each of unitB's LOEs. If only 2 rays hit unitA, you say there's a 2/20=10% chance to hit (or 10% damage, or whatever).
The idea being to calculate the approximate percentage of unitB exposed to unitA... right?
The implementation you described sounds reasonable to me; I think that's the way I'd tackle it too.
There might be a simplification--you might be able to do the raycasts directly from unitA to nodes on unitB, without mounting any actual LOE objects to the nodes. But I'm not sure if TorqueScript gives you access to the locations of those.
It would depend on how the engine's torqueScript API exposes that stuff.
#6
03/16/2009 (7:56 pm)
Initially, that's what I thought, but the LOE is based on the player's conclusion, which is based on the LOS from the eye node.
#7
Technically, I just need to know if any part of unitB is exposed. Although basing the percentage to hit off of the percenage exposed is an attractive idea.
03/16/2009 (7:59 pm)
Geom, this sounds very helpful. I will investigate raycasts more. Thanks.Technically, I just need to know if any part of unitB is exposed. Although basing the percentage to hit off of the percenage exposed is an attractive idea.
#8
After that, only rests to randomize which of the raycasts will finally be the actual shot, eliminating any extra stats (the hit probabilities are simply the number of raycasts that reach the target's boundingBox, against those that not).
Honestly though, all this ideas are wide too much for an RTS, afaik, this is not made like this even in Company of Heroes (the most advanced in this areas).
03/16/2009 (8:40 pm)
Another simplification could be to aim raycasts to the sectors of an imaginary grid in the side of the targets boundingBox.After that, only rests to randomize which of the raycasts will finally be the actual shot, eliminating any extra stats (the hit probabilities are simply the number of raycasts that reach the target's boundingBox, against those that not).
Honestly though, all this ideas are wide too much for an RTS, afaik, this is not made like this even in Company of Heroes (the most advanced in this areas).
Associate Orion Elenzil
Real Life Plus
this sounds interesting, but i'm not sure i follow the situation.
do you have a drawing or something that illustrates it ?