Combat 'hit' system changes

Discuss the future of Warzone 2100 with us.
Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: Combat 'hit' system changes

Post by Troman »

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
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Combat 'hit' system changes

Post by DevUrandom »

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.
Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: Combat 'hit' system changes

Post by Troman »

DevUrandom wrote: - Using sqrt is slooow... Better try to avoid that.
There is dirtySqrt() which I hope is faster.
Sign Up for Beta-Testing:
?topic=1617.0
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Combat 'hit' system changes

Post by Watermelon »

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.
I am not using square root,I am using the actual integer when comparing squared distance.

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.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Combat 'hit' system changes

Post by DevUrandom »

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:

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;
  }
}
Remember: This is just a draft...
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Combat 'hit' system changes

Post by Watermelon »

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:

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;
  }
}
Remember: This is just a draft...
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.
tasks postponed until the trunk is relatively stable again.
Post Reply