Advanced attack features

[quantumstate]

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.

Trample

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

[Wijitmaker]

I think that would be a fantastic addition.

These were features we were planning to include years ago:

http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Attack

http://trac.wildfiregames.com/wiki/XML.Entity.Actions.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.wildfiregames.com/forum/index.php?showtopic=12669&view=findpost&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.

[plumo]

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.

[Ykkrosh]

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.)

[fabio]

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?

[feneur]

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

[iap]

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

[Android_]

^ 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 ).

[feneur]

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

[Mythos_Ruler]

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.

[Android_]

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 December 22, 2011 by Android_

[quantumstate]

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 .

[Mythos_Ruler]

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?

[iap]

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)

[Android_]

^ 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.)

[Ykkrosh]

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...)

[Mythos_Ruler]

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.

[quantumstate]

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.

Thinking about projectiles.

In the old system, it does an actual physics simulation - it moves the projectile according to gravity each simulation turn, finds all the entities whose footprints it crosses (in 2D), then looks for the first one (by entity ID) whose bounding box is tall enough to reach the arrow, and if it finds one then it hits it.

A few problems I see with this (in decreasing importance):

* We get very little gameplay control - we might want to say there's 75% less chance to hit units that are hidden in a forest, or a 25% greater chance to hit friendly units if you fire into the middle of a melee, etc, but it's hard to do that if we're doing turn-by-turn collision detection.

* Bounding boxes are a very rough approximation, and many objects are not shaped like boxes, so things will get hit even if it looks like the arrow is nowhere near a solid part of them.

* To make things look nice, the projectile ought to be launched from an appropriate prop point on the actor (currently it's just launched from 2.5 units above the ground), but we don't want the simulation to depend on the actor mesh data (because of floating-point inaccuracies, and because it's good to keep them independent).

* The collision detection sounds fairly expensive - it won't be much fun when you build a hundred archers and tell them to aim across the entire enemy army, and it has to check every arrow against every unit every turn, even if we have some optimised spatial data structures.

* It's lots of floating-point code, which is annoying to translate into fixed-point.

So I'm tempted to do something more like:

* Calculate a target point on the ground (based on what the user aimed at).

* Apply some randomness based on distance, archer skill, etc, to make things as inaccurate as desired.

* Compute who is going to get hit, based on their footprint and distance from the target point.

* Do some extra checks so that trees and walls can protect the target.

* Work out the time until the target will be hit (assuming it's going to hit somebody).

* Choose the visual 3D target point (typically the center of the target's bounding box, so that you'll never kill somebody by hitting them in an invisible corner; or a point on the ground if it misses everyone), and visual source point (based on the actor), and set up the projectile as a purely graphical effect so it moves in a nice arc between those two points.

* If the target unit moves in the future, adjust the arc so it's still going to hit it. (This is physically unrealistic but if projectiles move fast then nobody will really notice, and if they do notice then they won't really care. (I'm sure I've seen a few tank shells do 45-degree mid-air turns in Company of Heroes to hit their target, but never worried much about it.))

* After the previously-determined time interval, hurt the target.

That means all the work is done once, when the projectile is first released, where it will pick the target and do any special calculations to adjust probabilities of hitting, which helps with performance and control. The apparent motion of the projectile is purely a graphical effect, with no effect on the simulation itself, so it's simple and fast and can be tweaked to line up nicely with the actors.

This won't be great if we have big slow long-range projectiles (like catapults that launch burning cows) but we can extend it later and I think it should work okay for the common cases (arrows and javelins). Hopefully.

So, if I read you right - any projectile fired will always find it's mark? (like a homing missile?)

Meh.

I think they're needed (in a basic form) because otherwise people will build archers and javelinists and get quite confused by why they can't attack anyone and just sit there like lemons . (I originally marked it as needed on this page for that reason.)

Yes - it will decide what its mark is when it is first launched (it might miss the unit you targeted and hit somebody else, depending on accuracy), but then it will always hit that mark. (Unless the target dies before, or hides in a building, in which case I guess it'll just hit the ground). I don't like that, but I can't think of any alternatives I dislike less.

I'm not sure I like that idea, but I'm not the one that has to impliment it. So take this for what it is worth...

This was a while ago, so perhaps things have changed. But years ago the idea behind the game design of ranged attack simulate real world warfare. Such as:

* Pierce Damage inflicts high HP lost vs units that don't have the correct armor (like shields, plate armor, chain mail armor)

* Accuracy diminishes with distance of the shot

* Accuracy increases with training

* Ranged units typically have lighter armor themselves and higher mobility

* Accuracy improves if they have time to take a good shot, decreases with movement

* Speed of the shot increases with strength/experience

So, that being said... If you have heat seaking missles that lock on targets, you are ignoring some of the gameplay and strategy that could be devised with ranged units. Not saying this is required feature right now, or perhaps ever... if it is overly complex to work some of these ideas into the gameplay.

So, I say all of this to say - that I think it would be best that if an entity marks a target, and fires - that shot should go to the target it picks the instant it fires, it shouldn't deviate to follow the target.

If it misses the mark, it would be because the unit moved. Now, I could see that a good archer could "lead" his target to guess where the target might be when the arrow reaches the target's distance. Perhaps that could be a tech that would 'lock' and allow some deviation by a small margin?

So, in summary... greater the distance, slower the speed of the shot, and movement by the target - the less likely it would be to find it's mark. And, that isn't always a bad thing - it happened, probably often

I think all of the things in your list can still be done, because they can be computed when the projectile is launched rather than when it reaches its target - the approximate distance to the target is known, and all the characteristics of the attacker are known, so accuracy can still be simulated. The accuracy computation could also be based on the speed of the target at the time of launching, if we want moving units to be harder to hit.

The only thing that couldn't have an effect is any movement of the target after the launching - once the projectile has decided to hit the target and has then been launched, it's definitely going to hit the target. So you can't wait until the enemy fires at your units then quickly pull your units back so that the arrows harmlessly hit the ground in front of them, and you can't make a group of tall bodyguards run in front of your hero to protect him after the enemy has fired.

I've only ever done archery with modern bows and over short distances and I'm far from an expert (and far from really knowing anything at all about this), but I'm not sure that getting shot at and then quickly running away is a historically viable strategy. Apparently most bows get somewhere around 90mph, and apparently Roman archers got a maximum range of around 200m, which gives at most five seconds to run away, so I don't think that's a tactic you'd want to rely on.

I think the reason I'm worried about not deviating is that it's hard to make the graphics match the decision of whether the unit gets hit. We can't do precise tests against the target unit's mesh polygons, so we have to approximate using a bounding box (or bounding cylinder), and then it's likely to unexpectedly hit what the player sees as empty space around a unit. Making the bounding boxes tighter would reduce the chance of anyone ever getting hit, so we can't simply do that. (I doubt it would be much fun if you fired a few dozen arrows into the middle of an enemy concentration and only one got a hit).

Units should always appear to get hit somewhere near their center (where they're nice and solid), but we need more control than is possible by adjusting bounding boxes, so the graphics needs to be separate from the gameplay decisions about accuracy and probabilities of hits. And the only way I see to keep those things separate but consistent is to make the arrows deviate so they hit the chosen spot. (They should never deviate much, because they're fast and the target is slow, and we can say it's wind if anyone notices.)

(I'm certainly not convinced that I'm correct here, so this is a useful discussion . I think it's a tradeoff between various groups of problems, and it's good to have as much information as possible.)

I see your dilemna better now. You mentioned adjusting the bounding box, is it possible to shrink the bounding boxes on the fly and make the 'core' of the unit the target, rather than the entire bounding box that define the extents of the mesh?

Would you be able to control the amount/degree of deviation?

That is classic. I think it should go in an FAQ eventually.

I thought about that too, but it seems that might still be too much computation to do for each shot (considering how many arrows could be shot at once)? I'm glad you started this very interesting discussion, Jason.

That's technically possible - but if the boxes used for projectile collision detection are small, it'll be unlikely that an arrow will hit anybody, because a group of units will mostly consist of empty space between their little boxes.

It would probably be 'realistic' for most arrows to miss everybody, but our game isn't a realistic scale: we have tens of units instead of hundreds or thousands, units are metres apart rather than packed shoulder-to-shoulder, battles take minutes rather than hours, we build cities hundreds of metres apart from each other, and so I think we need independent control over the scale of arrow-hitting-target probabilities in order to balance it.

Not quite sure what you mean here. Once a target unit is picked (taking account of accuracy and hit probabilities) it would have to deviate as much as is necessary so that it will continue to move towards that target.

I was curious if you could specify (for example) the arrow can adjust it's course by 10 degrees to find it's target while in flight. If it exceeds that, it would miss. But, it sounds like the arrow will do whatever it takes to get the job done. Like you say, if the arrows are flying fast enough, I doubt anybody will notice. Only way to find out for sure is to program it, and play it I'll leave that in your capable hands

Oh, another factor to throw in the archer mix to consider is the rate of attack. As you have probably experienced - if you have time to take a good steady shot, your likely to have higher accuracy.

Hmm, what about this.

When the projectile is thrown at a target the "target" is actual any random area within a small radius of the spot on the grid where the target was when the projectile is launched. Adds some accuracy realism (maybe this circle becomes smaller for Advances and Elite units). If it hits the target, then great.

Side note: Why can't the bouncing boxes be manually adjusted for uber excellence in the entity?

Second Note: why not just do it exactly how they do it in Age of Mythology or Age of Kings? Maybe you'd need to see the source code though for that.

I think that's what I'm already thinking of (but probably not explaining well ) - the player picks a specific point to aim at, then the game does some calculations based on accuracy and range etc to choose where it'll really hit, which will either be a unit that's close to the targeted point (though not necessarily the one the player clicked on) or a point on the ground (if it misses everyone). With more skilled units, the chosen target will be closer to the point the player selected (and more likely to hit a unit rather than empty ground).

Because the bounding boxes affect both the probability that a unit will be hit, and a how a unit will be sheltered by those nearby (especially trees and buildings), and how close an arrow appears to come when it hits the unit. I'm not sure it's possible to choose a bounding box size that is good enough for all of those things simultaneously.

Hmm, that's a good idea. So I looked at AoM, and arrows diverge from their normal path in order to track their target unit. (It's much easier to see if you reduce the velocity of arrows, and then make a guy run around while being shot at - the arrows move really weirdly to make sure they land on him.)

AoM actually has a "TrackRating" in proto.xml which affects this - if it's high (which it is by default) then the arrows try hard to follow their target, and if it's low then they lag behind and are more likely to hit the ground behind a running unit. It's got some values for accuracy and spread too. I'm not sure exactly what it's doing (there's a lot of variables and it's hard to test), though I can see it's not the same as what I'm thinking of, but it does the same trick with making in-flight arrows track their target instead of doing a realistic physics simulation.

One thing I notice in AoM is that's hard to see exactly where a unit gets hit, which suggests it doesn't actually matter if we don't make it precisely match the solid body of the unit because nobody will notice. But I expect that's partly due to AoM's arrows being fast and frequent (toxotes seem to fire once per second) and about twelve inches thick - AoM feels stupid and cartoony with these Gatling-gun archery units firing a continuous stream of arrows at my unit that is zipping backwards and forwards, so I'm assuming we want something slower-paced where each individual arrow has a much greater significance. (The strongest memory I have of playing the AoM demo is how rubbish and insubstantial the archers seemed, so that's not something I want to completely emulate )

Good call on suggesting to review AOM, Michael Interesting findings Philip.

Whatever you end up with will be great - looking forward to seeing it in action!

I agree that the AoM archers were nigh worthless - IIRC only the Atlanteans (from the expansion) and a Greek mythical unit that fired volleys of arrows were worth their salt.

That aside, it seems reasonable to roll the dice and choose the landing point when the arrow is launched. To avoid the problem of deducting HP due to an arrow that lands next to the unit, tracking the unit sounds good. However, my recollection of CoH games is that people often noticed and commented upon the extremely visible projectile path changes. (In WW2, there were antitank guns with v0 of 1000 m/s, and any deviation at all is just laughable and annoying.) In fact, the gameplay element of moving away to dodge a volley of projectiles seems worth keeping, it'd be a shame to lose that in 0ad. Consider micromanaging a hero unit - it'd be a shame if his destiny were pre-determined, rather than at least partially dependent on skillful dodging/weaving.

Here's a simple potential solution: when firing, determine the hit position and the unit currently standing there. If the unit manages to move far enough away from that position, forget that it was the target. Otherwise, make slight adjustments to the rendered projectile position so that it'll appear to hit the unit.

Those extra checks you mentioned are a bit tricky, but probably also important for gameplay. Trees could be modeled by a single probability of not hitting anything, but those walls should stop everything to be convincing. We might get away with only checking a small fixed neighborhood of tiles around the firing and target position, and marking that as the new 'stop' position if there's a wall there (assuming trajectories aren't flat, which seems reasonable if trying to achieve ranges > 100m).

Here's what I think arrows (and javelins) should be like:

- High Attack (jevelins higher attack than arrows because javelins have more mass, but consequently have shorter range)

- Infrequent Attack (archers should take a few seconds to nock their bows properly and aim)

- Quasi-synchronization (archers in a group tend to fire in volleys)

- Distance accuracy (projectiles are less accuracy at long range)

- Accuracy > Attack (Accuracy is more important than the attack value; accuracy adjusts from basic to advanced to elite; higher levels don't get higher attack, but rather greater accuracy)

And here's the tricky one:

- Ranged Units Anticipate their targets (archers and javelinists will lead their target in order to hit it; if the target changes direction then the projectile is avoided; this rewards micromanagement)

That all sounds reasonable

One additional bonus for the elite might be firing frequency - is that desirable? It would prevent mixed-experience formations from firing synchronized volleys. To achieve that effect, is it sufficient to just order your units to stop/move, then attack something, and rely on them all reacting to the order at the same time, i.e. synchronized for that first volley?

I agree about micromanaging and the benefits of avoiding arrows (especially when considering single units). However, Philip is planning on first implementing the simple solution (just working out hit/miss before shooting and following the target unit), but attempting to keep open the possibility of the more complicated but interesting solution later. (We talked about this in the meeting. To achieve both square-on hits and allow dodging, we'd have to have the arrow re-acquire a target if the previous unit got far enough away from the intended intercept position, which is possible but a tiny bit more complicated.)

BTW, leading the target seems to be a freebie since we'd do the 'follow target unit' thing.

Sounds reasonable to me too

An extra issue I encountered: For performance reasons, the simulation 'turns' are fairly slow (currently about 3 turns per second; could be increased to maybe 5 per second to reduce player input latency) and unit positions are simply interpolated when rendered between turns. Projectiles travel at a constant speed, so it might take e.g. 2.5 turns to reach the target. To make it look good, they need to be rendered so that they hit whatever unit they hit at its interpolated position between turns 2 and 3, but the actual simulation computations have to occur in either turn 2 or 3, and the unit could move by half a tile in that time. So just doing a test for "what unit is currently at the point where the projectile landed?" is not going to match what it looks like it hit. So I still think we need to cheat in order to make it look correct.

But it sounds like people really want to be able to dodge arrows, and I have approximately no RTS-playing experience so I can't justifiably disagree strongly . Seems like maybe the reasonable approach is to do this tracking thing, so it looks okay in the common case and so we can easily control the probabilities of hitting a target, but if the target moves too far away from its expected position (where 'expected' is possibly based on leading the target) then the projectile will 'detach' and always harmlessly hit the ground (or (as Jan suggests) pick a new target).

In the interests of not taking forever to get an initial rough version working, and because this is becoming more complex than I expected, I think I'm going to give up trying to get it just right and will stick with my current implementation for now, and add lots of comments about how it should be modified (hopefully soon) to be better. (Currently there's a (ugly, hardcoded) 50% chance of hitting the unit you targeted, and the projectile locks onto that unit and always hits it (which is a reasonably subtle effect with the standard archer speeds); and 50% of hitting a random point on the ground nearby. (Arrows that hit the ground stay there forever, because it's nice to see where they landed). This isn't acceptable from a gameplay perspective, but it generally looks okay to me.)

Yes! That may fix more than just arrow issues; I always thought the response time for unit tasking was noticeably slow.

About the dodging arrows, I remember doing that with heroes in AoK, so it's likely that we'll want it here too eventually.

[quantumstate]

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

[ribez]

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?

[quantumstate]

great!

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

No, this makes arrows get fired at a random spot near the target. Then, when the arrow lands, it tests whether it hit the target and if so causes damage, it is possible for the arrow to hit a different unit than the one it was fired at. Also it provides the option of splash damage so now siege units can cause damage to all units near where the projectile lands.

[Enrique]

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

Awesome Jonathan! I want to test it immediately!

[Thorfinn the Shallow Minded]

By the way, perhaps height and terrain like water and snow would not only affect the speed, but could make the stamina drain more quickly.

[Pedro Falcão]

I agree with Jonathan and Michael, except for the catapult things. Let's analyze the Onagers of AoK:

- High damage is good.

- Splash damage is good... when not mixed with an incredibly slow projetile speed and a slow recharging time (contrasting to the first AoE, where it really worthed to have a catapult army, even though it worthed too much), making it easy to avoid the incoming missiles (except, of course, with the tech of more accuracy).

- Low range made it an easy target against buildings like castles and towers, as they could easily destroy the poor onagers.

- Very Slow moving speed made it an incredibly easy target for cavalry, even better to micro-manage when you have a huge army trying to defend the catapul, and micro-managing is very bad.

With all these things in mind, players prefered to use trebuchets against buildings (as it had the best range ever) and bombard cannons to splash damage units (they were more accurate, faster fire rate, faster move speed, faster recharging time, faster projectile speed and less area of effect, while almost the same cost). Do we really want that to be repeated here? I think we want to see catapults playing a better role than that. Greeks, by the way, used catapults over some walls (principally against invading ships).

[Sonarpulse]

Hmm, I don't think you guys should scrap the slow, physics & collisions method of calculating trajectories and damage. Ideally I would make it so players can select that method, or the proposed speedier one before a match.

Also I think that height really should be taken into account for ranged projectiles, and that it wouldn't be too hard either:

1. Imagine all the other parabolas
2. Take the union of them all
3. Make a function that describes the border of the region, f(y)=x. I bet it might be a simple polynomial too, or a hyperbola.

Now when checking if a target in range, there is two more steps: get the height difference between the target and archer, and plug that in. If the function is too slow/complicated, make a table. Using a table also means that drag, etc, can be accounted for with no performance penalty.

Doubt this is any faster, but the shape can be spun around the z axis to create a 3d shape which can be placed over the archer (not rendered of course), and then intersected with the hieghtmap to create a bordered region. Game then checks if unit is within that region.

---------------------------------

On an somewhat unrelated note, I was thinking if a bunch of ranged units are selected and told to attack (maybe just attack ground), the mouse wheel (with a hotkey I guess) could be used to adjust how much spread they should aim for. the area to be targeted could either correspond to the formation of the archers, or simply be a circle or rectangle. That way if the enemy is a swarm of units you can just rain down arrows, but if the enemy is some big powerful unit that moves slowly (the king in), you can have them all target the same spot