Light Style© by Fisana

Jump to content


Photo

Advanced attack features


  • Please log in to reply
28 replies to this topic

#1 quantumstate

quantumstate

    Primus Pilus

  • WFG Retired
  • 1,150 posts

Posted 22 December 2011 - 01:07 PM

I was thinking of working on this, it should be fairly straightforward to do what I suggest here and will bring the attack code up to a decent level of functionality (similar to AoK). Here is what I propose.

Accuracy

Stationary targets

This will have an entry in the entity xml for ranged attacks. The value will be in the range 0 to 1 and will mean the probability of hitting an infantry unit at maxRange.

When a missile is fired it will be placed according to a (2d) normal distribution (approximately). The normal distribution will be scaled linearly according to distance, so a missile fired half the distance has the same chance of hitting as a missile fired at a a target twice as wide (4x surface area). This makes aiming at nearby targets a lot more accurate.

Examples:With a maxRange of 100 and an accuracy of 0.5, the probabilities are (range:probability) 100: 50%, 75: 70%, 50: 93%, 25: 100%, 0: 100%. With a maxRange of 100 and an accuracy of 0.25, the probabilities are (range:probability) 100: 25%, 75: 40%, 50: 67%, 25: 87%, 0: 100%. With a maxRange of 100 and an accuracy of 0.0625, the probabilities are (range:probability) 100: 6.3%, 75: 8.4%, 50: 23%, 25: 64%, 0: 100%.

First, by mistake I calculated the results for a 1d normal distribution, here they are for comparison. With a maxRange of 100 and an accuracy of 0.5, the probabilities are (range:probability) 100: 50%, 75: 63%, 50: 82%, 25: 93%, 0: 100%. With a maxRange of 100 and an accuracy of 0.25, the probabilities are (range:probability) 100: 25%, 75: 29%, 50: 48%, 25: 80%, 0: 100%.

The 2d results should be fairly realistic, but for the game I think 1d would actually be better because it has a less extreme curve. Archers will automatically attack at maxRange and won't walk any closer automatically (at least currently) so having too much advantage for being closer encourages lots of micro.

Of course in dense formations if the arrow might well hit a nearby unit and will cause damage to that unit, this will make spread formations useful. Larger units such as cavalry will be easier to hit if they are stationary.

Moving targets

This is something that I am less sure about how to do properly so consider this a less strong proposal. Units should by default aim at where a unit is going to move to, using its movement vector. On its own this would lead to moving targets being hit with the same chance as still units though which is undesirable. There should be an accuracy decrease according to unit speed, I suggest having accuracy depend on the square of speed, with walking speed cavalry halving the hit probability and everything else worked out from there. This kind of thing is easily adjustable though so we could test and see what feels good. Again if you have a tight group then stray arrows will be likely to hit other units.

Splash Damage

I propose this xml structure for splash damage:
  <Attack>
	<Melee>
  	<Hack>7.0</Hack>
  	<Pierce>17.0</Pierce>
  	<Splash>
    	<Type>Trample</Type>
    	<Dist>5</Dist>
    	<Crush>4.0</Hack>
    	<FriendlyFire>No</FriendlyFire>
  	</Splash>
	</Melee>
  </Attack>

This would work by giving splash damage to units within Dist in addition to the conventional attack, so the conventional attack would have to be decreased to compensate since the primary target would receive both conventional and splash damage.

I would recommend 3 types of splash damage, with this scheme only one would be possible per attack type (this restriction could be lifted if necessary but it would probably make the xml more messy).

Circular

This would damage all units in a circle of radius Dist around the location of the attack hitting (the unit being hit for melee or where the missile landed for ranged). It would have a quadratic damage falloff so units at range Dist (from the location of the hit) would receive 0 damage, units at range Dist/2 would receive 0.75x damage, units at range 0 would receive full damage. e.g. the rock throwing siege.

Linear

This would damage all units in a line aligned with the attack. So for a missile it would damage all units within dist of where the missile hit in the direction away from where the missile was fired from. It seems to be hard to put into words but is a simple idea so I drew a picture. The green blob is your bolt thrower, red are enemy soldiers, blue is the line along which damage is received so three red soldiers get hit. I would suggest quadratic damage falloff again.

Posted Image

Trample

This is identical to circular but the damage is calculated centered around the attacking unit rather than the position where the attack hit.
  • 0

Jonathan Waller [ aka quantumstate ]

Wildfire Games Programmer
Contact me: jonathanmarkwaller at gmail dot com


Support Wildfire Games!


#2 Wijitmaker

Wijitmaker

    0 A.D. Old Timer

  • WFG Retired
  • 9,540 posts

Posted 22 December 2011 - 02:04 PM

I think that would be a fantastic addition.

These were features we were planning to include years ago:

http://trac.wildfire....Actions.Attack
http://trac.wildfire...ctions.Move#Run

Trample was intended to be a "damage" aura that was going to be coupled with the stamina (run capability) of the units.

Accuracy was to be a function of unit class, rank, distance, formation, etc. Philip has done some pondering on this in the past: http://www.wildfireg...ndpost&p=204807

Many of these features were implemented in the pre-simulation rewrite in 2009. After the re-write I suspect they haven't been given a priority to be re-implemented.

Another advanced attack features to consider are elevation bonus to the unit that takes the higher ground, also the direction of attack. Face to face combat is best case vs. an attack from behind which would cause considerable more damage.
  • 0

Jason Bishop [ aka Wijitmaker ]

0 A.D. Founder

Contact me: jason@wildfiregames.com


#3 plumo

plumo

    Centurio

  • 0 A.D. Art Team
  • 979 posts

Posted 22 December 2011 - 02:10 PM

Will projectiles have Stopping Power and armour penetrating depending on speed and kind of projectile?

For example: a projectile fired on horseback has more speed I read, or more stopping power.
  • 0
B. Guns [aka Plumo]
0 A.D. Community Liaison
Contact email: plumo@wildfiregames.com

#4 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,921 posts

Posted 22 December 2011 - 02:39 PM

There's some old discussion in a (non-public) thread here (looks like posts #134 to #154 are relevant).

(Edit: Oh, Jason beat me.)

If I remember correctly, my main concern was that trying to do physically realistic projectiles (like aiming at a unit by predicting where it will be at the time when the projectile hits it) makes the gameplay behaviour impossible to predict. If it depends on the target's movement speed, and direction, and footprint size, and density of formation, and whether they're near the edge or center of the formation, and the distance from the attacker, and the attacker's accuracy stats (several numbers determining the shape of the distribution), and the projectile speed, and the number of turns per second, etc, and then playtesters say "Greek archers are overpowered against spearman", how can we tell what to change to make it better without introducing new balance problems?

I think it would probably be better to start from a gameplay basis rather than a physics-simulation basis - have some simple rules like "basic archers hit their target 50% of the time at normal range, elite archers hit 75%; fall off to 25% (basic) / 50% (elite) at maximum range; increase to 75% / 90% for targets flagged as 'Large' (buildings, elephants, ships, etc)" or whatever. That makes it easy to understand what's going on, and easy to adjust the balance. Then implement something that matches the desired behaviour and looks visually alright, like how the current implementation computes the probability in advance and then either fires a heat-seeking missile that is guaranteed to hit its target or fires a dud that will miss and land randomly somewhere nearby. (The current implementation is too simplistic since it always has a probability of 50% and takes no other factors into account, so it certainly needs changing, but I'm not sure how radically it should change.)
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#5 fabio

fabio

    Centurio

  • WFG Programming Team
  • 648 posts

Posted 22 December 2011 - 04:39 PM

There's some old discussion in a (non-public) thread here (looks like posts #134 to #154 are relevant).


Would be possible to enable read only access to these boards to all users?
  • 0

Graphics problems with 0 A.D. under Ubuntu and free drivers? Check out the Updated and Optimized Graphics Drivers Archive: includes updated drivers with fixes and improvements for games, including 0 A.D..


#6 feneur

feneur

    Cartographer of imaginary worlds

  • 0 A.D. Project Leader
  • 7,839 posts

Posted 22 December 2011 - 05:32 PM

Would be possible to enable read only access to these boards to all users?

Not on a general basis no, it would take too much time to go through and make sure there is no sensitive information in them. However, specific threads like this should be possible. Though that thread is 18 pages long, so it seems like a lot to go through I'm afraid. I guess we could copy the posts Philip mentioned though :unsure:
  • 0

Erik Johansson [ aka feneur ]

Wildfire Games
Contact me: feneur@wildfiregames.com



Support Wildfire Games!


#7 iap

iap

    Sesquiplicarius

  • Community Members
  • PipPip
  • 101 posts

Posted 22 December 2011 - 05:32 PM

A little OT, I think, but will the splash damage be able to hurt friendly units?
  • 0

#8 Android_

Android_

    Sesquiplicarius

  • Community Members
  • PipPip
  • 128 posts

Posted 22 December 2011 - 07:34 PM

^ I am against that notion; we had it in AoK and it made mangonels etc. very difficult to use.

On trample damage: If you implement it as an aura around the unit it is important to activate it only when the unit is moving, otherwise you'll get weird results (if you remember the monster trucks (cheat units) in AoE3 you know what I mean ;)).
  • 0

#9 feneur

feneur

    Cartographer of imaginary worlds

  • 0 A.D. Project Leader
  • 7,839 posts

Posted 22 December 2011 - 08:23 PM

On trample damage: If you implement it as an aura around the unit it is important to activate it only when the unit is moving, otherwise you'll get weird results (if you remember the monster trucks (cheat units) in AoE3 you know what I mean ;)).

I would think it would only be active when the unit is "running", i.e. moving faster than normal. Slowly driving a chariot towards the enemy shouldn't do nearly as much damage as a chariot at full speed ;)
  • 0

Erik Johansson [ aka feneur ]

Wildfire Games
Contact me: feneur@wildfiregames.com



Support Wildfire Games!


#10 Mythos_Ruler

Mythos_Ruler

    Senator

  • WFG Retired
  • 14,966 posts

Posted 22 December 2011 - 08:42 PM

I would think it would only be active when the unit is "running", i.e. moving faster than normal. Slowly driving a chariot towards the enemy shouldn't do nearly as much damage as a chariot at full speed ;)

Hmm. Perhaps half trample at walking and full trample when running. The blades are still spinning, after all.
  • 0

#11 Android_

Android_

    Sesquiplicarius

  • Community Members
  • PipPip
  • 128 posts

Posted 22 December 2011 - 08:54 PM

I think in the long term the fact that units don't actually knock over their opponents (and stop to fight them instead) will be quite the problem for the concept of trample damage. For the moment some sort of damage aura will be fine as discussed, but eventually we might have to discuss how to implement cavalry/chariot charges that are able to plough through infantry etc.

Edited by Android_, 22 December 2011 - 08:55 PM.

  • 0

#12 quantumstate

quantumstate

    Primus Pilus

  • WFG Retired
  • 1,150 posts

Posted 22 December 2011 - 09:01 PM

Trample was intended to be a "damage" aura that was going to be coupled with the stamina (run capability) of the units.


Maybe trample should be excluded from this then, it does seem to make more sense that even when moving they would cause trample damage.

Accuracy was to be a function of unit class, rank, distance, formation, etc. Philip has done some pondering on this in the past: http://www.wildfireg...ndpost&p=204807


It would be simple enough to have a formula with a template based override, having it automatic would probably save quite a bit of work for most units.

Another advanced attack features to consider are elevation bonus to the unit that takes the higher ground, also the direction of attack. Face to face combat is best case vs. an attack from behind which would cause considerable more damage.


These all sound quite useful to have, I think it is best for now to limit the scope of this proposal though.

Will projectiles have Stopping Power and armour penetrating depending on speed and kind of projectile?

For example: a projectile fired on horseback has more speed I read, or more stopping power.


That sounds like it may be over-complicating things. This is definitely beyond the scope of this.

There's some old discussion in a (non-public) thread here (looks like posts #134 to #154 are relevant).

(Edit: Oh, Jason beat me.)

If I remember correctly, my main concern was that trying to do physically realistic projectiles (like aiming at a unit by predicting where it will be at the time when the projectile hits it) makes the gameplay behaviour impossible to predict. If it depends on the target's movement speed, and direction, and footprint size, and density of formation, and whether they're near the edge or center of the formation, and the distance from the attacker, and the attacker's accuracy stats (several numbers determining the shape of the distribution), and the projectile speed, and the number of turns per second, etc, and then playtesters say "Greek archers are overpowered against spearman", how can we tell what to change to make it better without introducing new balance problems?

I think it would probably be better to start from a gameplay basis rather than a physics-simulation basis - have some simple rules like "basic archers hit their target 50% of the time at normal range, elite archers hit 75%; fall off to 25% (basic) / 50% (elite) at maximum range; increase to 75% / 90% for targets flagged as 'Large' (buildings, elephants, ships, etc)" or whatever. That makes it easy to understand what's going on, and easy to adjust the balance. Then implement something that matches the desired behavior and looks visually alright, like how the current implementation computes the probability in advance and then either fires a heat-seeking missile that is guaranteed to hit its target or fires a dud that will miss and land randomly somewhere nearby. (The current implementation is too simplistic since it always has a probability of 50% and takes no other factors into account, so it certainly needs changing, but I'm not sure how radically it should change.)


From reading that thread, it seems that there are technical issues with determining what the missile hit on impact. The general idea I proposed should work similarly with hit detection on launch. One thing to consider though is, as the attack module mentions big projectiles would be best not done this way and people seem to want missiles they can dodge, is it worth considering doing impact based detection? I would imagine it working by cutting tracking out of the ProjectileManager code and always have it aiming for the hit location, you could detect if there is a unit there for visual effect. Then the attack code would just use a timer as it does now but have a hit detect function. Occasionally there would be a visual mismatch from timing lag, but I don't think it would be more very noticeable.

I disagree somewhat about the complexity. My idea has a very clean implementation (random normally distributed hit position and check for collision of the arrow), but I you disagree about the gameplay complexity. I think having the missile hit whatever it lands on adds significantly to the strategy, making spread formations useful for something. Making things more physically based where possible is good because it makes the game play more intuitively, so the arrows will do what you expect, if my archers hit a little infantryman half the time then a massive great elephant should be hit practically all of the time, using their in game size gives a good visual indicator of what is going to happen.

A little OT, I think, but will the splash damage be able to hurt friendly units?


That is why I added a <FriendlyFire> to the xml proposal. Easier to let someone else decide :P.
  • 0

Jonathan Waller [ aka quantumstate ]

Wildfire Games Programmer
Contact me: jonathanmarkwaller at gmail dot com


Support Wildfire Games!


#13 Mythos_Ruler

Mythos_Ruler

    Senator

  • WFG Retired
  • 14,966 posts

Posted 22 December 2011 - 10:13 PM

Mike's thoughts.

Accuracy

It would be simple to just add an <Accuracy> element to the <Ranged> attack. I'd prefer doing it in the template to using a script. Accuracy distance (a lot less accurate near MaxRange; more accurate at mid range; slightly less accurate near MinRange) could maybe be adjusted in the templates too, but editing this is less important to me. I am fine with distance accuracy decay occurring uniformly for all units. Adjusting the top level accuracy in the template would be more important.

Splash Damage/Friendly Fire

I'd like it to work exactly like Age of Kings: The Conquerors. Splash damage-inducing siege onagers would not fire automatically if it would incur friendly fire casualties. However, the player was able to override this behavior and manually target the enemy, even if it would incur friendly fire casualties. At any rate, I think Siege Engines should only auto-fire on Buildings within range anyway, so this may be a moot point. :) Something like this perhaps:

Catapult (stone thrower; has splash damage)
Auto-fire on buildings, manually fire on units.

Bolt Shooter (shoots bolts, or giant arrows)
Auto-fire on units, manually fire on buildings.

Height Bonuses

Maybe it's just me, but such a thing rarely seems to affect the outcome of battles for me. Perhaps the bonus in other games wasn't steep enough for me to notice. I know Age of Mythology had it in a very simplified way (if you were X tiles above the targets you get Y bonus and that's it; that's my understanding at least). I think the bonus here in real life was because the enemy wore themselves out marching up the incline to get to you, plus marched slower so were then within optimal range of your arrows for a longer time. Perhaps make units march slower up hills and be done with it. Not sure.

Trample Damage

100% trample damage when running, 50% trample damage when walking, 0% trample damage when stationary (fighting, idle, or otherwise).

Stamina

This is needed for charging and running. The Sim1 implementation was pretty decent from a simulation standpoint, so we should start from there.


Where is that spreadsheet were were working on a few months ago to set some priorities?
  • 0

#14 iap

iap

    Sesquiplicarius

  • Community Members
  • PipPip
  • 101 posts

Posted 22 December 2011 - 11:01 PM

My thoughts about height:
When I was building guard towers on a high place, I was surprise to see that they couldn't see farther on the map, and couldn't shoot farther. Actually, when I was shot from below, it seemed like the height is not taken into account when calculating the distance the arrow travels. It's like the map is 2D, and a height is only a minor detail.
To call it "height bonus" is wrong, it should be called "the way it should be on height". (See farther, shoot farther, and forces from below should really get near in order to shoot me)
  • 0

#15 Android_

Android_

    Sesquiplicarius

  • Community Members
  • PipPip
  • 128 posts

Posted 22 December 2011 - 11:18 PM

^ Good idea. I agree with Michael that a height bonus as in AoM doesn't really make any difference; but a LOS bonus could be visible and nice.

Apart from that I agree with everything that's been said except for the idea of having AoK-like friendly fire. In the end it may be a matter of taste but in any case I'd urge you to check out AoK again. I happened to do so a few days ago and I remember noticing how difficult it was to manage an army with five mangonels in it. You are lucky to get off one volley before your melee units go in, so they are pretty useless in field combat. Against buildings there are stronger siege weapons available obviously. Anyway, whatever you do I suggest you throw in a couple of AoK matches and play around with mangonels first. (Also note that these units were the only friendly fire units in any Age game iirc - scorpions, trebuchets, catapults etc. never caused friendly fire.)
  • 0

#16 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,921 posts

Posted 22 December 2011 - 11:29 PM

I would imagine it working by cutting tracking out of the ProjectileManager code and always have it aiming for the hit location, you could detect if there is a unit there for visual effect. Then the attack code would just use a timer as it does now but have a hit detect function. Occasionally there would be a visual mismatch from timing lag, but I don't think it would be more very noticeable.

The simulation timestep is often something like 500msec, so there's likely to be a fairly huge gap between their quantised simulation position and their interpolated graphical position, so I'd guess it would be very noticeable. (I am just guessing, though; don't know how well it'd work in reality.)

It's like the map is 2D, and a height is only a minor detail

It is :). Height is a purely graphical effect and has no effect on gameplay. (It's tricky with line-of-sight in particular - that's fairly performance-critical code when you have lots of moving units, and doing height-dependent computation is more expensive, so it would be nice not to make it worse than it currently is. Although I suppose it'd be fine performance-wise to do fancy computation for buildings (so you can e.g. build them on the edge of a cliff and see a long way) as long as units remain simple...)
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#17 Mythos_Ruler

Mythos_Ruler

    Senator

  • WFG Retired
  • 14,966 posts

Posted 22 December 2011 - 11:29 PM

You are lucky to get off one volley before your melee units go in, so they are pretty useless in field combat.


That's okay with me, since siege weaponry of our era were rarely used in field combat. They're meant in our game to bring down buildings. Attacking units would be secondary to that purpose. :)
  • 0

#18 quantumstate

quantumstate

    Primus Pilus

  • WFG Retired
  • 1,150 posts

Posted 23 December 2011 - 11:38 AM

The simulation timestep is often something like 500msec, so there's likely to be a fairly huge gap between their quantised simulation position and their interpolated graphical position, so I'd guess it would be very noticeable. (I am just guessing, though; don't know how well it'd work in reality.)


500msec is longer than I had been thinking, the might well cause problems. I was thinking though that it would be possible to interpolate backwards from the current simulation step to get the position at the time of impact. It shouldn't add much complexity, and it makes the code significantly simpler for the ProjectileManager especially if we start adding maximum deviation edge cases, and unifies the case with slow moving siege weapon projectiles.

Also I have put the relevant posts from the private thread in the spoiler below.

Spoiler

  • 0

Jonathan Waller [ aka quantumstate ]

Wildfire Games Programmer
Contact me: jonathanmarkwaller at gmail dot com


Support Wildfire Games!


#19 quantumstate

quantumstate

    Primus Pilus

  • WFG Retired
  • 1,150 posts

Posted 17 February 2012 - 12:18 AM

I have made a patch for this functionality and attached it to the ticket at http://trac.wildfire...s.com/ticket/18
  • 0

Jonathan Waller [ aka quantumstate ]

Wildfire Games Programmer
Contact me: jonathanmarkwaller at gmail dot com


Support Wildfire Games!


#20 ribez

ribez

    Duplicarius

  • Community Members
  • PipPipPip
  • 282 posts

Posted 17 February 2012 - 12:44 AM

I have made a patch for this functionality and attached it to the ticket at http://trac.wildfire...s.com/ticket/18


great!

this patch affects the behaviour of archers to keep a certain distance to the target?
  • 0