[Solved] Making weapons skillshots

[Isysar]

I remember this site from the WC3 days. I'm glad it's still going strong.

I have a long and complicated problem. I'll try to keep it as brief as possible. I want to make units have more realistic missile pathing, akin to what you'd experience in an FPS game or if you're shooting a gun in real life (you can't stand at the base of a cliff and shoot through it at a 45 degree angle to hit stuff standing on top of it, i.e. you can't shoot "through" 4 allied marines to hit a zergling but you could be in a ball of marines but shoot a collosus or air units from the center of the ball).

I've tried several things to accomplish this, and they'll all long stories that don't end up working (validators to disable a unit's attack is X units of the same height at clumped around them, splitting weapons into 2 with a ground attack and an air/high ground attack. Tried using triggers to determine distance and height of units, but these triggers fail when you use the A-move command).

Is there some sort of discussion we could get going on how on earth to do this? I want to use this system in a traditional SC2 RTS game, rather than for some RPG, FPS or other type of game.

Any advice or thoughts would be helpful. Thanks.

 

[Dr Super Good]

Sounds too complicated for a RTS game and will likely annoy people however it is implemented. However here are some ideas to try.

FPS games manage this by running some kind of tracer simulating a bullet from the unit to its target, if it collides with something then it misses so you cannot shoot stuff through other players or walls etc.

If you make it so all attacks are simulated by throwing out a high speed missile it might work. Your missile could be tested if it falls below ground (using a trigger running every frame (1/16 of a second)) and destroying it if it does. If it hits anything on its way that is not the caster unit (area search) then the projectile dies and deals damage to whatever object it hit. You could even trigger the search so you can test unit height and things in a spherical way.

The problem then becomes an AI one. Since the above implementation will give you exactly the type of gameplay you want and even highly accurately but will be totally unusable as the dumb SC2 default combat AI (if it can even be called that? it is more like a combat reflex units have) will shoot your own troops, try and shoot up cliffs, etc.

This means the problem is a lot more complicated as you do not just was to create attacks with complex interactions, but also a complex AI so the units use them correctly. Due to limitations with the weapon system you will probably need to use weapons as just UI dummies and all the actual attacks are triggered/use effects.

This leads on to another solution. Instead of an accurate physics simulation of all attacks, just do the calculations as part of the combat AI and do not try shooting if there is not at least a chance of hitting.

 

[Isysar]

Thank you very much for your response. I see that you grasp the complexity of my problem. Yes, the problem is as much an AI problem as it is a systems problem.

I don't ever want the scenario where the AI/combat reflexes are hurting the player (marines shooting themselves, etc). As you've suggested, is just want a set of rules that would simply prohibit a unit from attacking if it would hurt an ally.

I've nearly been successful doing this with triggers. I use the "Event -- Any unit starts attacking with any weapon" and essentially step through a large series of logic: what kind of unit is trying to attack; how tall is it; what is it trying to hit and how tall is that; are there any units inbetween the attacker and the target; if friendly, issue order- Stop, if enemy, Issue order attack the picked enemy in the way.

The problem is that apparently the attack move command is NOT considered as "any unit starts attacking". This trigger works if you directly issue an attack order (unit A attack unit B) but it you A move (select any number of units and attack a ground location), the trigger is simply not called. This is stupid ass of course. Everyone A-moves units. I simply can't figure out an event pattern that catches the A-move command. Do you know of a way to catch this? (I've tried the "whenever a unit acquires a target" event and I don't know what the hell triggers this. Nothing from my tests. Doesn't trigger from direct attack, A-move or standing still and noticing an enemy move into attack range)

If not, I might have to trigger 100% of everything as you say since the "combat reflexes"/AI of attacking is so ingrained. Thanks for your ideas

 

[Isysar]

I'm less concerned with an epic physics system. The only thing I don't want is people right beneath a cliff shooting up it, or those on top shooting through a cliff to those beneath it. I'd rather have an AI that disallows those attacks from happening than make a physics system to check for moving bullets through the ground. I haven't found a good way to figure out where two units stand in relation to the edge of a cliff however

 

[Dr Super Good]

(I've tried the "whenever a unit acquires a target" event and I don't know what the hell triggers this.

It is triggered when the units attack target matches the weapons attack target. Units attack target only matches the weapons attack target when the unit is stopped and has an actively queued attack order.

There is no way to get the current target of a weapon.

I'm less concerned with an epic physics system. The only thing I don't want is people right beneath a cliff shooting up it, or those on top shooting through a cliff to those beneath it. I'd rather have an AI that disallows those attacks from happening than make a physics system to check for moving bullets through the ground. I haven't found a good way to figure out where two units stand in relation to the edge of a cliff however

You need to perform an iterative test on the height of the terrain at every node between the two units and then see if the resulting interpolated height for the actual path of fire will result in an intersection with the ground. Alternatively you just need to sample iteratively on a line from the one unit to the other testing the height of all terrain edges to check for an intersection with the ground.

As you can see, this is very expensive and I would not recommend doing it too much. Your AI may need to stop and "think" for considerable time before computing a valid action in order to not introduce performance constraints.

Also please avoid interfering with the order stack. It annoys players heavily when they queue up attack move orders just to find the game discards all orders in order to do something else.

 

[Isysar]

(sorry I don't know how to quote)

You said: "There is no way to get the current target of a weapon."

^ That is disappointing. I'll need to rethink how to do this.

You said: <stuff about iterative tests on ground differences>

^ Yes, that kind of solution would be very CPU intensive and not ideal. I was actually thinking of making 2 invisible untargetable units that each emit an aura that applies an invisible behavior to units. One of these units I'd place around the bottom of cliffs--it applies a behavior and I'd just add a validator to my air/attacking up a cliff ranged weapons -- must target air or greater cliff level AND cannot have this behavior. The second unit type I'd place at the top of a ridge, but somewhat further in (units standing at the edge of a ridge can fire down at targets, but units 15-20 back from the cliff edge can't shoot straight projectiles down). Same thing-- make their shooting down weapon have a validator for cliff level is less than AND they cannot have this behavior present. Probably a fairly ghetto solution but I think it accomplishes what I want. We'll have to see if it actually works.

Finally, you said: "Also please avoid interfering with the order stack. It annoys players heavily when they queue up attack move orders just to find the game discards all orders in order to do something else."

Yah, fuck. I completely forgot about that. That would be infuriating. Do you know if there's a way to selectively remove just a single action from the action queue without scrapping all of it?

I really appreciate bouncing these ideas of you. Thank you for your time Dr Super Good. You're helping me a lot.

 

[Isysar]

So, in the trigger Order <unit> to <action>, there's 3 options. "Replace Existing Orders" (this would dick up the queue as you mentioned and I shouldn't do this), "After Existing Orders" (this wouldn't do anything useful for me) and "Before Existing Orders." This wouldn't really fix anything b/c a unit would start to attack, then stop, then start, then stop and just sit there hanging. If the player tries to tell the unit to attack something I don't want it to, the AI should have the unit attack something it can hit, or would hit should it try to attack in that direction. I guess this would work, I'd just need to make sure to always provide an adequete acceptable target for the unit to attack instead and issue an attack order to another nearby unit "Before Existing Orders". Bah, but that'd call this trigger again wouldn't it? Because then the unit would try to start attacking and be ordered to stop again. . . .I could give them an invisible temporary behavior says "you're good to attack without the trigger checking." But how long should that behavior last? Too long and you'd have less trigger calls, but weird scenarios where, based on unit movement, units are attacking stuff they shouldn't be able to.

Perhaps you're right about using dummy weapons and moving 100% of everything attack related into triggers or effects.

 

[Dr Super Good]

Yes, that kind of solution would be very CPU intensive and not ideal. I was actually thinking of making 2 invisible untargetable units that each emit an aura that applies an invisible behavior to units. One of these units I'd place around the bottom of cliffs--it applies a behavior and I'd just add a validator to my air/attacking up a cliff ranged weapons -- must target air or greater cliff level AND cannot have this behavior. The second unit type I'd place at the top of a ridge, but somewhat further in (units standing at the edge of a ridge can fire down at targets, but units 15-20 back from the cliff edge can't shoot straight projectiles down). Same thing-- make their shooting down weapon have a validator for cliff level is less than AND they cannot have this behavior present. Probably a fairly ghetto solution but I think it accomplishes what I want. We'll have to see if it actually works.

I do not see this being less CPU intensive in the longer term. Remember that area searches and area validators all have a cost associated with them.

So, in the trigger Order <unit> to <action>, there's 3 options. "Replace Existing Orders" (this would dick up the queue as you mentioned and I shouldn't do this), "After Existing Orders" (this wouldn't do anything useful for me) and "Before Existing Orders." This wouldn't really fix anything b/c a unit would start to attack, then stop, then start, then stop and just sit there hanging. If the player tries to tell the unit to attack something I don't want it to, the AI should have the unit attack something it can hit, or would hit should it try to attack in that direction. I guess this would work, I'd just need to make sure to always provide an adequete acceptable target for the unit to attack instead and issue an attack order to another nearby unit "Before Existing Orders". Bah, but that'd call this trigger again wouldn't it? Because then the unit would try to start attacking and be ordered to stop again. . . .I could give them an invisible temporary behavior says "you're good to attack without the trigger checking." But how long should that behavior last? Too long and you'd have less trigger calls, but weird scenarios where, based on unit movement, units are attacking stuff they shouldn't be able to.

You can technically rebuild order stacks to remove specific orders. You could also use a unit group to keep track of units you have processed and do not want the trigger to fire again for (the group you clean every frame).

 

[Isysar]

I do not see this being less CPU intensive in the longer term. Remember that area searches and area validators all have a cost associated with them.

Hmm.....perhaps having trigger based projectiles is the solution after all. Do you know how "expensive" validators check are? If I wanted to run like, 7 validator checks per unit each time it attacked is that more expensive than setting up all the rules in triggers?

You can technically rebuild order stacks to remove specific orders. You could also use a unit group to keep track of units you have processed and do not want the trigger to fire again for (the group you clean every frame).

I do like the unit group idea. That's a good solution for giving units a buffer time to fire before rescanning for acceptable targets.

 

[Isysar]

By "7 validators" what I really mean is a Validator Function, with a variety of nested conditions within it. Validator functions are what the SC2 AI uses to cast spells/use burrow/etc semi-intelligently.

 

[Dr Super Good]

Validator functions are what the SC2 AI uses to cast spells/use burrow/etc semi-intelligently.

They use tactical AI functions to do that most of the time. These have no GUI finger print and have to be manually extracted from the MPQs. At least that is what I have made of it so far. Maybe some abilities are driven by validator functions but all the combat AI such as for Thor and Ghost so that they choose targets to cast their abilities on is run by tactical AI functions.

 

[Eagle XI]

FPS games do it via hit-scan or actual ballistics. However dont ask me how to port over the idea to an RTS. CoH was a success in detecting projectile collision properly in real-time, however thats completely another engine.

 

[Dr Super Good]

FPS games do it via hit-scan or actual ballistics. However dont ask me how to port over the idea to an RTS. CoH was a success in detecting projectile collision properly in real-time, however thats completely another engine.

Supreme commander 1/2 also have real time ballistics.
Surprisingly Empire Earth and Empires Dawn of the Modern World (from 2000ish period) also had real time ballistics to some extent (the number of times my towers intercepted my AA missiles with atomic consequences was depressing).

 

[Isysar]

They use tactical AI functions to do that most of the time. These have no GUI finger print and have to be manually extracted from the MPQs. At least that is what I have made of it so far. Maybe some abilities are driven by validator functions but all the combat AI such as for Thor and Ghost so that they choose targets to cast their abilities on is run by tactical AI functions.

You seem to be right, though it seems that Blink and Burrow are done via Validator functions. I'm still thinking about the best way to do this. Thanks for your help guys.

 

[Isysar]

FPS games do it via hit-scan or actual ballistics. However dont ask me how to port over the idea to an RTS. CoH was a success in detecting projectile collision properly in real-time, however thats completely another engine.

Never heard of Company of Heroes. Thanks for mentioning it. Something like that but not quite as complicated is what I'm looking for. Thanks for giving me some material to chew on.