Combat 'hit' system changes
Re: Combat 'hit' system changes
This is a bit more complicated indeed, but I think all scalar values necessary for this are there already. You can get speed with droid->sMove.speed, direction is available too.
Sign Up for Beta-Testing:
?topic=1617.0
?topic=1617.0
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: Combat 'hit' system changes
Dear, is this progressing fastly!
Just some small suggestions by me:
- Using sqrt is slooow... Better try to avoid that.
- Using basic target prediction should be possible and better done using a function instead of storing the units position into a struct each frame. I bet there is somewhere the data for the current unit position, speed and direction (maybe the latter together in one struct). You just need a clean new API to get it.
- Is it possible to let the roll of the dice affect the accuracy of the projectile? Maybe "dice()-accuracy-visibility" and modify the projectiles direction with that? Or "dice(-10,+10)*(accuracy+visibility)" for each axis(x,y,z)? (-10,+10 is the range of the requested result.) Would mean that the hit is not that predetermined...
- How are splashdamage projectiles going to work? They might hit nothing but bare sand and still do damage to near units.
- Not hitting enemies through buildings or other units is really good. Exactly what was suggested by Karma in the other forums! But this should also apply to own units. You shouldn't be able to shoot through own/allied units. Instead the unit shouldn't shoot at all, or if forced to (or the allied unit moved into the projectiles way) hit the allied unit, too.
Just some small suggestions by me:
- Using sqrt is slooow... Better try to avoid that.
- Using basic target prediction should be possible and better done using a function instead of storing the units position into a struct each frame. I bet there is somewhere the data for the current unit position, speed and direction (maybe the latter together in one struct). You just need a clean new API to get it.
- Is it possible to let the roll of the dice affect the accuracy of the projectile? Maybe "dice()-accuracy-visibility" and modify the projectiles direction with that? Or "dice(-10,+10)*(accuracy+visibility)" for each axis(x,y,z)? (-10,+10 is the range of the requested result.) Would mean that the hit is not that predetermined...
- How are splashdamage projectiles going to work? They might hit nothing but bare sand and still do damage to near units.
- Not hitting enemies through buildings or other units is really good. Exactly what was suggested by Karma in the other forums! But this should also apply to own units. You shouldn't be able to shoot through own/allied units. Instead the unit shouldn't shoot at all, or if forced to (or the allied unit moved into the projectiles way) hit the allied unit, too.
Re: Combat 'hit' system changes
There is dirtySqrt() which I hope is faster.DevUrandom wrote: - Using sqrt is slooow... Better try to avoid that.
Sign Up for Beta-Testing:
?topic=1617.0
?topic=1617.0
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: Combat 'hit' system changes
I am not using square root,I am using the actual integer when comparing squared distance.DevUrandom wrote: Dear, is this progressing fastly!
Just some small suggestions by me:
- Using sqrt is slooow... Better try to avoid that.
- Using basic target prediction should be possible and better done using a function instead of storing the units position into a struct each frame. I bet there is somewhere the data for the current unit position, speed and direction (maybe the latter together in one struct). You just need a clean new API to get it.
- Is it possible to let the roll of the dice affect the accuracy of the projectile? Maybe "dice()-accuracy-visibility" and modify the projectiles direction with that? Or "dice(-10,+10)*(accuracy+visibility)" for each axis(x,y,z)? (-10,+10 is the range of the requested result.) Would mean that the hit is not that predetermined...
- How are splashdamage projectiles going to work? They might hit nothing but bare sand and still do damage to near units.
- Not hitting enemies through buildings or other units is really good. Exactly what was suggested by Karma in the other forums! But this should also apply to own units. You shouldn't be able to shoot through own/allied units. Instead the unit shouldn't shoot at all, or if forced to (or the allied unit moved into the projectiles way) hit the allied unit, too.
maybe you can get the velocity from sMove.speed + direction
the projectile's miss direction is already random,no need to do that imo.
add the ability to hit allies/own unit is easy,not sure if it's a good idea or no though.
tasks postponed until the trunk is relatively stable again.
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: Combat 'hit' system changes
As I said, I don't know the code. So it is definitely possible that I suggest something which is allready done. (Just to clarify this.)
And as I said also I think that blindly shooting will create problems if you suddenly make those projectiles hit friendly units as well, when the droids are not aware of that fact.
So my idea was that first make a unit not shoot if the line between it and the e is occupied by other (friendly or not) units. 2nd step woould be to make the AI try to walk around that obstacle and shoot from another position. 3rd step would be to make units which are forced to shoot (ctrl+click is the button I think?) shoot no matter what, even if the units are friendly.
Eg:
Remember: This is just a draft...
And as I said also I think that blindly shooting will create problems if you suddenly make those projectiles hit friendly units as well, when the droids are not aware of that fact.
So my idea was that first make a unit not shoot if the line between it and the e is occupied by other (friendly or not) units. 2nd step woould be to make the AI try to walk around that obstacle and shoot from another position. 3rd step would be to make units which are forced to shoot (ctrl+click is the button I think?) shoot no matter what, even if the units are friendly.
Eg:
Code: Select all
function shoot(enemy)
{
if( !self.forced_attack && obstacle_in_the_way(self.position, enemy.position) )
{
self.move_around_obstacle_to_free_line_of_sight(enemy.position);
return DIDNT_SHOOT;
}
else
{
self.fire_projectile( vector.add( enemy.position, randomness(self.accuracy) ) );
return DID_SHOOT;
}
}
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: Combat 'hit' system changes
doing line of sight test against all non-wall objects on every 'fire event' is too expansive for a RTS,at least I dont know of an effective way to do such tests,and you would probably need to rewrite raycast,visibleObject and other line of sight test function to implement such features.DevUrandom wrote: As I said, I don't know the code. So it is definitely possible that I suggest something which is allready done. (Just to clarify this.)
And as I said also I think that blindly shooting will create problems if you suddenly make those projectiles hit friendly units as well, when the droids are not aware of that fact.
So my idea was that first make a unit not shoot if the line between it and the e is occupied by other (friendly or not) units. 2nd step woould be to make the AI try to walk around that obstacle and shoot from another position. 3rd step would be to make units which are forced to shoot (ctrl+click is the button I think?) shoot no matter what, even if the units are friendly.
Eg:
Remember: This is just a draft...Code: Select all
function shoot(enemy) { if( !self.forced_attack && obstacle_in_the_way(self.position, enemy.position) ) { self.move_around_obstacle_to_free_line_of_sight(enemy.position); return DIDNT_SHOOT; } else { self.fire_projectile( vector.add( enemy.position, randomness(self.accuracy) ) ); return DID_SHOOT; } }
tasks postponed until the trunk is relatively stable again.