definitive proof that animations are a result of computer calculations.

first off, sorry about the long title.

Ok, I don't have screenshots but I do believe that this can be recreated by anyone interested.

I was sieging a village, which has all of those weirdly placed road ways, and I was firing upon the sallying defenders with my Khazaks. While the enemy unit of viking raiders were walking along the road, my HA were firing upwards as if they were directly behind another unit to compensate for the buildings. Nothing new and amazing, until the unit of raiders got to a point where they were no longer behind buildings. The arrows, mid air, changed direction by about forty degrees and shot straight towards the raiders. I repeat, the arrows changed direction mid-air.

The only conclusion that I can draw from this is that the computer generates the attack and then the animations are a result of those generations. If the animation determined the kill, there would be absolutely no reason for the sudden change in direction for the arrows.

I know that I don't have screenshots, but my finger wasn't exactly on the printscreen button since I wasn't expecting it to happen. I'm sure that the scenario can indeed be recreated though.

If I wasn't at my university's lab right now, i'd be testing this.

I've heard of people changing the shield stat into the negative and suddenly, they're seeing animations of people deflecting blows with the shields; which would probably mean longer and mutual destruction melees between equal units.

I never believed that animations determined damage.

I think the animation is relative to the random generation of the attack; whatever. Then, the animation is played out.

For an animation's point of contact to then translate into numbers is just silly and neigh impossible to be done on this scale (so far).

Man, I want me some of them heat-seeking arrows! :laugh4:

I never believed the animations "drove" the combat results either. That would assume the game is doing collision detection for every object, which isn't likely, considering how big the armies can get, and the fact that we don't see more significant CPU crunching when doubling the army size.

Well I remember that there was a bit of a debate on this earlier, and I thought that my "experience" was pretty interesting. Heat seeking arrows are definitely something you share with the community. :P (I guess this is the early precursor to Russian Nikita rockets:laugh4: )

This information might also be of some help to modders who might of been unsure as to how MTW2 calculated casualties on the battlefield.

Now that I think about it, computer generated casualties with graphical reflections of said generations would have to be the way to go anyways, in regards to auto-calcing battles.

I believe the game chooses a target for each arrow, randomly generates target deviation, and then runs the animation. The arrows will curve in mid flight to reach their target point relative to the enemy unit, but it does seem to do collision detection vs soldiers who aren't the intended target but get in the path of the arrow.

The definitive test for this would be to have a unit of archers fire on a unit of infantry, and after the volley is loosed, run a unit of cav into the unit of infantry and see if any of the cavalry get hit. If they do, it's doing collision detection.

Not a bad idea. I think I'll test it.

The order to the cav needs to be issued after the arrows have been fired though so that the computer doesn't generate the cavalry actually being there.

Quote:

---

Originally Posted by Musashi

I believe the game chooses a target for each arrow, randomly generates target deviation, and then runs the animation. The arrows will curve in mid flight to reach their target point relative to the enemy unit, but it does seem to do collision detection vs soldiers who aren't the intended target but get in the path of the arrow.

---

I don't know about "target for each arrow" though. If you look at it from a programming standpoint, wouldn't it be more efficient to have the computer generate casualties on a per unit basis and then have the graphics do their voodoo?

If you consider it in terms of auto-calcing, and how the devs could program the game to also be semi-accurate in the auto-calc, it doesn't seem to add up that each individual arrow is tested for.

Actually, while this is definitive proof of something, it is not definitive proof of what you claim.

What your arrow behavior shows is not that the animation is generated based on the determination of the kill, but that the flight path of the arrow was changed when the higher trajectory was no longer required: i.e. that missile pathing is dynamic as opposed to static, and able to change in mid-flight. This in fact has NO bearing whatsoever on whether or not the missile's path of flight is being dictated by a determined kill or miss, or whether it is determining the kill or miss. So what I'm saying is that the missiles didn't change path because they were predetermined to be kills or misses, they did so because the conditions forcing their higher flight path changed. While this is weird, it has no relevance to whether collision detection is used in combat, or the animations stem from the battle calcs.

It remains as likely that your path-altered missiles are having collision tests run on them as it is that they are simply representing calculations.

PaulTa: It's unlikely that Autocalc is even that in depth. Much more likely that it's a pure numbers game that never even takes into account field position or anything like that.

Quote:

---

Originally Posted by Musashi

I believe the game chooses a target for each arrow, randomly generates target deviation, and then runs the animation. The arrows will curve in mid flight to reach their target point relative to the enemy unit, but it does seem to do collision detection vs soldiers who aren't the intended target but get in the path of the arrow.

---

Have you been able to visually track an arrow in flight, all the way to landing in an individual soldier's chest? The last time I took a close look at this, it seemed like the game just shows a generic hail of arrows that disappear before they actually hit anything. When soldiers are hit but not killed, you get that brief blood spray without actually seeing an arrow landing. When they're killed, an arrow pops out of their chest and they fall down, but I don't actually see it landing there. At least that's what I think I was seeing... and it would be consistent with animations being generated without collision detection. I'll have to take a closer look. Maybe I just wasn't getting a smooth enough frame rate to see the full arrow trajectory, although I think I'm running at about 20fps according to FRAPS. That should be enough.

Artillery file does seem to "carry through" all the way to final impact, and the game does apply an area effect to whatever soldiers are standing there. It's possible the game is handling arrow fire differently, to conserve CPU cycles.

Quote:

---

The definitive test for this would be to have a unit of archers fire on a unit of infantry, and after the volley is loosed, run a unit of cav into the unit of infantry and see if any of the cavalry get hit. If they do, it's doing collision detection.

---

Not necessarily... the game may be calculating area effects instead. In other words, if a unit is standing at the targeted coordinates when the volley arrives, then x number of soldiers will show the "hit by arrow" animation with the blood spray, without actually calculating individual arrow trajectories and collision detection. And this could apply to more than one unit occupying that space. That would be a much less CPU-intensive way to handle it.

I could be wrong... I'd just be shocked if this game is actually doing collision-detection for so many independent objects at once (at huge size setting).

Zenicetus: Yes, I can track an individual arrow from loosing to impact, as long as it's not being fired at high angle (At which point they go higher than the camera can follow). I always see arrows stick in the ground right where they hit.

Heck, I can even see individual musket balls in flight, if I pause the game at the right moment.

ot realy. Get a unit of Musketeer and turn them off Fire at will and then give the enemy 2 units of Swordsmen.

Wait till the rear unit is in range and fire at them and then whatch as not one round hits the rear unit and it's all the front unit that drops dead despite it being miles in front, and thus not subject to the area of effect thing you mentioned.

In addittion theirs the point of non-working animations. iof it was pure calculation then a non-working animation would have no effect. the kill would still happen regardless of weather or not the animation played out, (trust me i've seen it with Necron in DoW:DC where some firing animations are out of sequance with the calculations that determine kills). Since their is never a kill if the animation dosen't play out and actually hit some collission detection has to be taking place their.

If your going to use collission detection of the suffictication that missile units would likliy require to get the observed efects you might as well outright dispence with calculation and use collission detection.

Likewise collission detection dosen't need massive processer power as both HW1 and HW2 used it. Indeed HW1 used nothing else, it's accurracy really WAS determined by weather or nmot a projectile hit. You could edit things in the files (track rates and fire cones), to produce more acurrate results but the end effect was the same. And HW1 was made in 1999, they where still on P3 back then I think.

Quote:

---

Originally Posted by Musashi

PaulTa: It's unlikely that Autocalc is even that in depth. Much more likely that it's a pure numbers game that never even takes into account field position or anything like that.

---

Battlefield calculations and autocalc are entirely separate entities. You can see this because bugged and weird-acting units on the battlefied like 2H axe guys and pikes work just fine in autocalc even before you patch anything.

Quote:

---

Originally Posted by Zenicetus

Have you been able to visually track an arrow in flight, all the way to landing in an individual soldier's chest? The last time I took a close look at this, it seemed like the game just shows a generic hail of arrows that disappear before they actually hit anything.

...

I could be wrong... I'd just be shocked if this game is actually doing collision-detection for so many independent objects at once (at huge size setting).

---

Watch your archers at work some more. Often one or two will fall behind the group in firing, and you can distinctly see the arrow come off of that one guy's bow and make it's entire flight. I don't think there's any question that arrows are being drawn and tracked independently of each other in the game.

As for collision detection being horribly processor intensive, I don't think it's the case. As we can see arrows being drawn in the scene already, distinct and independent of one another, there's no question that the mechanism to track and draw them is already in place. Adding to that some simple collision detection is a very miniscule amount of calculation when compared to how much has to be done to draw even one man onto the battlefield and calculate his battle AI. In fact, collision detection for all arrows in the air at once in a huge battle may not be as processor-intensive as everything involved with making one man be on the battlefield in this game. It's just some simple number crunching, nothing complicated to a computer, and compared to the absolutely enormous number of MFLOPS current processors are capable of, is honestly not even a minor annoyance to the processor.

Quote:

---

Originally Posted by Musashi

Zenicetus: Yes, I can track an individual arrow from loosing to impact, as long as it's not being fired at high angle (At which point they go higher than the camera can follow). I always see arrows stick in the ground right where they hit.

Heck, I can even see individual musket balls in flight, if I pause the game at the right moment.

---

This has been my experience too.

I simply think it is wrong. Or, if not, then the game is really deep!

Why? You can grab a unit of Horse Archers, makes another Archers unit fire at it. By simply, running with the Horse Archers a certain direction when the Archers release their volley, you will evade most of their arrows (You won't see any arrows heat seeking your folks). And, when as soon as the second volley is released, you run the opposite way, you will evade most if not all of the arrows again.. Explain that!

(If what you say is proven true, the simple answer would be that the game's engine calculations are deep. Which contradicts what a lot of vets say about it)

Quote:

---

Originally Posted by the_foz_4

Watch your archers at work some more. Often one or two will fall behind the group in firing, and you can distinctly see the arrow come off of that one guy's bow and make it's entire flight. I don't think there's any question that arrows are being drawn and tracked independently of each other in the game.

---

Right, I see the firing of the arrows and I see them in flight. It's the final point of impact in a soldier from an arrow in flight (i.e. not magically appearing in their chest out of nowhere) that I'm not seeing, and that I think the computer may be "faking". I'll run some tests later tonight, and see if I can see what y'all are seeing on the impact side.

Quote:

---

As for collision detection being horribly processor intensive, I don't think it's the case. As we can see arrows being drawn in the scene already, distinct and independent of one another, there's no question that the mechanism to track and draw them is already in place.

---

Hmmm... maybe, but I think I remember reading a post here from someone quoting CA to the effect that the game doesn't do full collision detection. I'll see if I can dig it up.

I doubt that the game calculate by the real time position of the arrow except for animation purposes and impact. There's no need to since medieval men didn't use Zepplins, you just need to know where and when it will land and a few other things, More likely, when an arrow impacts, it calls a command that checks if a unit's hitbox is over spot and then applies the arrow's angle and the unit's direction to figure out what defense values to apply. That's a simple version of what I would do. Even then, you could calculate the point of impact and time of impact, with parabolic arcs so you don't even need the arrow to return where it will hit.

Guy.ShootArrow() creates an instance of arrow.
If (Arrow.ImpactsGround()) then check BigArrayOfUnitsInZone[] and then check if BigArrayOfUnitsInZone[].ArrayOfIndividualMen[] is .
If it is, then call ApplyArrowDamage(Arrow, BigArrayOfUnitsInZone[].ArrayOfIndividualMen[])

Or something.

Heres a vid of a poor guy getting shot by about a hundred arrows at once: http://vids.myspace.com/index.cfm?fu...oID=1717879354

Quote:

---

Originally Posted by Blademun

Heres a vid of a poor guy getting shot by about a hundred arrows at once: http://vids.myspace.com/index.cfm?fu...oID=1717879354

---

HOLY COW THAT WAS AMAZING!

little question here, what the hell difference does it make if arrows have individual flight paths calculated or not?

proving that arrows do something by no means prove that melee attacks do the same thing.

@video: I remember making them one with the force in MTW except it took whole quivers of half a stack and a crap unit pinning the bastards.

@pat: Well it is calculated for the animation. I'm guessing you're asking about checking along the arrow's flight path for collision. The main thing is efficiency. If you checked whether an arrow hits a man then it would take however many checks performed a second and multiply it with the flight time and the amount of arrows to get roughly the total amount of checks. This is inefficient since the only time you care about the arrow is if it hits a person or the ground. Its faster to just figure out when and where the arrow will end up at rather than seeing if it has hit anything yet. It's a few dozen calculations rather than hundreds or thousands of checks per second from a cloud of arrows.

Quote:

---

Originally Posted by antisocialmunky

I doubt that the game calculate by the real time position of the arrow except for animation purposes and impact. There's no need to since medieval men didn't use Zepplins, you just need to know where and when it will land and a few other things, More likely, when an arrow impacts, it calls a command that checks if a unit's hitbox is over spot and then applies the arrow's angle and the unit's direction to figure out what defense values to apply. That's a simple version of what I would do. Even then, you could calculate the point of impact and time of impact, with parabolic arcs so you don't even need the arrow to return where it will hit.

Guy.ShootArrow() creates an instance of arrow.
If (Arrow.ImpactsGround()) then check BigArrayOfUnitsInZone[] and then check if BigArrayOfUnitsInZone[].ArrayOfIndividualMen[] is .
If it is, then call ApplyArrowDamage(Arrow, BigArrayOfUnitsInZone[].ArrayOfIndividualMen[])

Or something.

---

This sounds like it's along the correct lines. It can't actually be using the test for when the arrow hits the ground, as some line-drive arrow trajectories would be calculated as hitting the ground way behind the man that ought to be getting hit. However if no unit is taller than say 10 feet, checking above that height can be entirely avoided, which helps a lot.

We also already know that the game calculates a firing trajectory based on what is in the way, so we can assume that if a man's hitbox is intersecting the arrow flight path, the game already knows about it since that level of collision detection (with the flight path, since it has to be preplotted) is already necessary to path the arrows correctly (avoiding the FF kills of RTW due to archers shooting their front row in the back of the head, as well as walls and trees and all manner of other things). That is to say, the game can see everything that intersects the flight path since it must to plot an unobstructed arrow path, and it will just choose to ignore men that do so on the downward portion of flight as they are targets. That being the case, all that remains is to see if something (it can only be a man at this point since the game plots around everything else) intersects the flight path during flight. If not, the arrow obviously falls harmlessly to the ground. If so, then you could check to see if the man still obstructs the flight path when his position is reached by the arrow, at which point he'd be hit. It should likewise be easy to tell when something closer gets in the way, at which point you'd track that man until he is no longer in the way, or the arrow reaches his position and he is hit.

Note that I'm not saying this is what the game is doing, or even speculating that, I'm just laying down a framework so people can have a better idea what could be going on, as few people probably have much knowledge about hit detection or what it might entail.

Melee and missile might be two separate systems. Melee might play animations based on combat results, as this makes more sense. Projectiles, on the other hand, might use a realistic physics engine to determine hits. If this is not the case, then why were there so many friendly fire issues in RTW? Archers could shoot their own front rankers in the back if the angle was too low. Onagers could demolish their own siege towers if they got in the way.

I find it difficult to believe that each arrow is individually targeted and tracked to its victim. It seems over-complicated and unnecessary.

Carls scenario using musketeers is interesting. Since these weapons are very inaccurate it is likely that when the bullets reach the first unit, at lest half of them would miss. If they were individually tracked they would then go on to there intended target, the second unit. But he saw no casualties in the second unit.
If the first unit was targeted, what is to stop the “missed” bullets continuing on to cause casualties in the second unit? Or third or forth until they reached there range limit.

If a group of archers was firing from behind a castellated wall then every other archer would have to use a high trajectory whilst the rest could fire low through the gaps.

Isn’t it more likely that the developers compromised and only tracked / targeted one projectile, but displayed the graphic of “one flock of arrows” in flight? This could explain why, when its trajectory is blocked by another enemy unit, that one takes the damage and none of the projectiles gets through to the intended target.

A few points:
There still seems to be friendly fire on your side of the battlefield. While archers and crossbowmen never seem to shoot their fellow unit members in the back, they still sometimes hit friendly units deployed in front of their own unit or standing mixed up with them in the same spot. Try sticking some spearmen into some crossbowmen: You will take a few casualties, if not as many as in Rome. So the trajectory of projectiles has to be followed by the CPU from the start.

As long as you have to plot the whole trajectory for the animations anyway (and yes, I can see arrows impacting quite clearly - I also have a rather high end machine here and all details on full. Unit size is large, btw, so there are a lot of arrows from my English Longbowmen in flight at most times), you can also put in the rather simple collision detection. It's simple math: The intersection of a curve with a plane. A complicated plane, in that it has holes where no people are, but still a plane. It wouldn't be too difficult to do a planar projection of every soldier on the field for the PC - it has to do that and much more for real time shadows anyway (if you turn them off, this doesn't compromise my argument: the mechanics are there).

The issue of enfilade fire that was raised makes it very clear to me that collision detection has to take place somewhere. I think it must have been there even as early as M:TW (dunno if Shogun had enfilade, never played it).

That the second unit didn't take any casualties in the musketeer test can have many reasons: At max range, accuracy decreases massively, and the power of the projectiles does, too. Many bullets were probably stopped by men in the first regiment fired upon, even if they didn't produce a kill because the sword unit was heavily armored. So I don't think there have to be some mechanics that don't let the bullets fly farther. Most people here will have experience of low-trajectory fire like bullets or crossbow bolts hitting two units in a row, and this can easily be confirmed by more tests, I'm sure.

Actually if you bother to whatch the impacts, it's pretty rare for muskets to wipe out all 3 ranks anyway, so theirs no way the muskets COULD pass through the first unit. accurracy or not as they have to go through a solid wall of men r or more ranks deep to do it.

To calculate arc, you need trigonometric operations and those cost sometimes too much to use. Ok, you can use predefined tables for those and so on. However I think they have done something different in mtw2. Archers just shoot to direction where enemy is and they use some predefined angle. When arrow is on the top of arc it calculates rest of the arc. When arrow is close enough to really hit something game applies collision detection for em. I am not sure when does it really do the calculations about the collision point on the ground. Maybe when it is on the top of arc? You could test this by screwing you horse unit that it is scattered around the game area. Then just stop them and wait for enemy archers. If arrows change their way vertically, its on the top of arc if not then it is after they release arrows.

'One point' collision detection doesn't cost too much to use even on bigger scale. I have done this one by myself. Its easy and fast to do with Gauss-Jordan method. Barycentric is a bit harder to do, but its even faster. Next thing to do is console and collision detection for pill shaped object... Oh, forget those last lines. I was just babbling about my 3D engine. ^^

Btw, theres also one bug with ranged units. When they have taken their target and start animation they will shoot that target even if it would be out of their range. If you wish to replicate this, use fast horse unit.

I have in the past have experienced anomalies with ballistic units, convincing me that the actual animations arent really bona fide in casualty occurances. On one occasion I had an archer unit stationed on a small mound, with some of the unit behind a building. Not only is this a LOS issue and technically half my unit shouldnt have even fired, but when my unit did fire the flight of the volley did actually deviate in flight. I noticed that the volley sharply changed trajectory to avoid hitting the building, and that individual targets in the unit that were killed didnt always have an arrow hitting the victim. This leads me to believe that the animations and casualties inflicted on the targetted unit are two seperate animations related only by behind the scenes "dice rolling" type calculations. If that makes sense at all?

"Likewise collission detection dosen't need massive processer power as both HW1 and HW2 used it. Indeed HW1 used nothing else, it's accurracy really WAS determined by weather or nmot a projectile hit. You could edit things in the files (track rates and fire cones), to produce more acurrate results but the end effect was the same. And HW1 was made in 1999, they where still on P3 back then I think."

But for collision detection to be soley effective wouldnt the game then need to genuinely compute trajectories for each individual missle?. Take into the account the sheer amount of projectiles that could potentially be launched at one time. And it would be that mass computations that would eat up the cpu.

For homeworld 1 though, the collision detection was only necessary for a max maybe 200 ships on screen while in a large battle on m2tw, there would easily be 300-400 arrows flying around every few seconds.

Even elite muskets rarely kill more than the first rank of the target unit. You will see plenty of impacts as the men soak up all the shots but not fall. Muskets are almost 100% accurate so they rarely miss their intended target. Not a good test weapon for your purposes.

Quote:

---

Originally Posted by Xdeathfire

For homeworld 1 though, the collision detection was only necessary for a max maybe 200 ships on screen while in a large battle on m2tw, there would easily be 300-400 arrows flying around every few seconds.

---

To be fair, most of those ships had multiple turrets, and their projectiles were all being tracked for collision.

Thanks, I was going to say the same Musashi. Plus the game had full collission detection on every ship, (you could even accidently kill a ship if it ran into another one), and spacing between ships and other stuff seems to be controlled by it and the formation/stance selected. The stuff was also often moving at high speed.

hell in HW2 a large custom battle could have 30 bomber squadrons running round along with 30 gunship corvettes, and 30 frigates and a similar number of BC.

That totals well over 2000 pojectiles and a hundred ships on EACH side out of a possible 6 sides, and I don't think anyone ever expirianced slowdown on a modern spec system.

Oh and Drone Frigates had something on the order of 50 gun drones each... and the drones themselves were checked for collision as well as their projectiles.

Yeah, 24 drones actually, but they each had a gun and both the guns, the drones and the frigate where all checked for collission.

I'd say collission detection isn't THAT big of a drain based on that myself.

The fact that MTW2 on occasions due to cpu capabilities wont alow all participants in a battle to be on screen at the same time, i.e reinfocements being "delayed". would suggest to me that to add collision detection on a mass scale also would futher reduce the games already stretched resources. Of course thats only in my experience as I have an intel pent 940D.

Wtf is up with this typing intereface! I cant even go back and retype stuff without typing over the words ive just typed.

I remember shogun getting funky in missle battles when alot of things would land all at the same time. This was on a 600 Celeron BTW so... yeah.


Keep in mind however that all games have different calculation loads to run through. Homeworld might have had alot of power dedicated to collision but it didn't have or need a great pathfinding AI. Infact, I still remember losing frigates in the Garden of Kadesh and the asteroid belt. They weren't very smart. Plus, you didn't run that many shading operations and other stuff to boot as well as calculate combat between 1000+ individual units.

TW on the other hand, has to calculate that...

@stey - Hit your insert key, it toggles between insert and overwrite.

I tried the insert key but it hasnt made a difference, cheers anyway.

@antisocialmunky: true enough about HW1 doing less, but this is less so with HW2, and they both had to run on much worse systems than TW does. So even though the other requierments have gone up with regards M2TW vs. HW1. So too has the processing power. i think they where still on P3's back then wern't they? (1999 was HW1's first release according to the re-release box cover).

So too is the processing power that is needed.

Weren't we talking about hit detection and not efficiency a page ago?

Well I think the point everyone is trying to make is that given the immense power of current processors, you cannot simply assume hit detection doesn't exist due to the processing power you assume it would require. The analogy is drawn to an older game that is known to employ hit detection on a very large scale, in order to demonstrate the feasibility of applying hit detection in M2TW after advances have been made in computing. So essentially it's in debate to prove that hit detection would indeed be possible, and so the discussion of hit detection versus simpler calculations is in fact non-trivial, as both are feasible options.

Quote:

---

Originally Posted by the_foz_4

Well I think the point everyone is trying to make is that given the immense power of current processors, you cannot simply assume hit detection doesn't exist due to the processing power you assume it would require.

---

This is true, however if you double the size of the armies (easy to do, with this game) and don't see a significant slowdown in frame rate, then it means one of two things:

1) Either the game is doing full 3D collision detection for all models, including projectiles, and it's just a super-efficient algorithm where you can't see a slowdown by doubling the army size. Or...

2) The game engine is cheating. And by this, I mean "cheating" like a WWII combat flight sim (or maybe Homeworld) that calculates bullet streams instead of individual projectiles.

I think it's #2... but it would be nice to hear from the CA devs about this. I'm no game dev, but I've been involved in enough coding projects (as a front-end GUI designer) to know that efficiency of CPU cycles is something that coders care about.

1) Hits seem to be checked against bouncing boxes not the meshes. This speeds it up considerably. So its like lines and boxes only.
2) You don't need to check collision when arrow is higher in the air than tallest unit in battle.

Don't know about 2) ,but at least they have done 1). Don't want to test a thing with this game. Actually I deleted it completely and I am going to wait for atleast half a year to get rid of those blood boiling bugs.

I could make a demo about 'single-point' collision detection in work, if I just get enough time from my studies.

They most likely use bezier splines (curves) for archers. And every archer has the same arc (sometimes two different types). You could do something like have a "central" imaginery arrow that has its arc pre-determined from the squad to the current target. Then work out the position of all the arrows determined by that imaginery arc (offsets).

You have like a couple of hundred arrows (MAX at once) flying in the air; it sounds alot but im sure they could optimize it. Then checking hitboxes isnt a big deal at all.

I was just saying that Option A was better than Option B because A is more efficient.

Quote:

---

Originally Posted by antisocialmunky

I was just saying that Option A was better than Option B because A is more efficient.

---

Better from a programming standpoint, of course. And while I'll heartily agree that efficiency is a primary concern of developers, gaming also requires that developers do everything possible to make the game seamless and natural to the players. In this case, it is obvious that hit detection is a far more realistic and natural representation of combat than would be arbitrary kill animations generated strictly from a mathematical engine. As CA has gone to such great lengths to model things so realistically in the various other aspects of the battlefield (Jerome recently commented that in RTW already they had implemented situational flanking bonuses to account for the field of vision of a character, and armor being weaker in side and rear areas than in the front), I am inclined to conclude that if collision detection was at all feasible (which it seems it is), then CA would choose to implement it in their quest to achieve a more true-to-life experience of battle.

Quote:

---

Originally Posted by PaulTa

The arrows, mid air, changed direction by about forty degrees and shot straight towards the raiders. I repeat, the arrows changed direction mid-air.

The only conclusion that I can draw from this is that...

---

... it was windy? :smash:

:laugh4:
Thank you. I'll be here all week. :clown: