Damage Modifiers for Aliens

[Zombie]

The problem for me was that the soldier was modified to be in the air. That's fine.

 

However, both of the soldier's hands were filled: 1 with a Heavy Cannon, 1 with a Stun Rod. To increase the accuracy of the Heavy Cannon beyond the 96%, I needed to get rid of the Stun Rod somehow. Since the backpack was filled, I couldn't place it there. The only option left was to drop the Stun Rod on the ground. As soon as I did this, the soldier was also on the ground! So much for that idea. I ended up leaving the Stun Rod where it was, effectively giving the Heavy Cannon a 4% chance of missing the target.

 

I am now using NKF's most recent modified game where the soldiers have lot o' TU and the ability to fly. So no more problems there.

 

Only thing is that I am battling my second Win32 virus in under 6 months. Last time it was Win32.Pinfi, this time it is Win32/Parite. Hopefully, by tomorrow this virus will be gone so I can start to gather some more numbers. When it rains, it pours!

[Zombie]

Just when I start to think I'm beginning to completely understand HE ammunition, and the mechanics behind the explosion, something comes along which trashes my assumptions and forces me to look at things in a different light.

 

Sectopods have a susceptibility to HE of 80%. That's a fact. A HE shell modified to deal out 50 damage will actually do 50 * 0.8 = 40 average damage to a Quarterpod. The minimum was 20 and the maximum was 60. But how did the game arrive at these numbers since all the other ammo types have a minimum of 0 and a maximum = 2 * listed damage? That question has been bugging me since I started the HE tests.

 

Because I had some problems with too much damage being dealt to a full Sectopod, NKF modified the HE shells to dish out half as much damage as the initial shells (which did 50). Figuring that a change in ammo strength would hamper my ability to understand the more complex Sectopod, I decided to run some tests against the Quarterpod with HE damage = 25. This would be my "control" group. From this, I should be able to link the Sectopod to the Quarterpod, and determine how much more damage a 2x2 unit takes.

 

As I started to run the new trials against the Quarterpod, I noticed that the minimum "air" damage was not 20 like the HE-50 dealt, but rather 9. That threw me a loop as I had somehow convinced myself that 20 would be a constant min for every HE weapon strength. In hindsight, I know this was an invalid conclusion; but at the time I was able to explain it through various means. I also noticed that the maximum damage a HE-25 shell did was 29.

 

With that assumption debunked, I decided to take a closer look at my data. If a HE-50 shell did 20 min, 40 ave, and 60 max; then a HE-25 shell should do half those numbers, or 10 min, 20 ave, and 30 max. But why in the heck was I getting a 9 for a min, and 29 for the max? Where did that 1 extra damage point go? At this point, I calmed myself down and drew upon my knowledge of the game to help explain the confusion. My conclusion: the game is making a calculation error, due to the fact that it can't handle decimal answers very well. It's using that damn INT function again!

 

Now the task-at-hand became how to match the mathematics to my theory that the INT rounding was responsible for the min of 9 and the max of 29. That was the tough part. I worked all afternoon and finally formulated some equations which govern how HE ammo behaves depending upon the susceptibility and the listed damage. Working with the HE-50 ammo, I already knew that the average damage was 40. The equation to find the min would be MIN = AVE / 2, and the MAX = AVE * 1.5. Assuming that the INT round error occurs during divisions, the new equations would be MIN = AVE / 2, and MAX = AVE * 3 / 2. This became the key insight on understanding how the calculations are performed by the game.

 

This is what I came up with. First the key:

AVE = Average

MIN = Minimum

MAX = Maximum

R = Range

N = Listed damage of the HE ammo

S = Susceptibility to HE ammmo. Since the game hates decimals, a susceptibility to HE of 0.8 would be expressed as the whole percentage: 80/100

 

Minimum: MIN[1] = INT(N / 2); MIN = INT( MIN[1] * S)

 

Maximum: MAX[1] = INT(N * 3 / 2); MAX = INT( MAX[1] * S)

 

Range: R = MAX - MIN + 1

 

Average: AVE = MIN + (R / 2)

 

The calculations for the MIN and the MAX are done in the order I listed. If you reverse the order (i.e do the susceptibility to HE ammo first, and the min or max calculation last), the numbers don't come out.

 

Using these equations as a guide, let me calculate the Min, Max, Range and Ave for HE-25 ammo.

First the min: MIN[1] = INT( 25 / 2) = INT(12.5) = 12;

MIN = INT( 12 * 80 / 100) = INT(960 / 100) = INT(9.6) = 9

 

Next the max: Max[1] = INT(25 * 3 / 2) = INT(75 / 2) = INT(37.5) = 37;

MAX = INT(37 * 80 / 100) = INT(2960 / 100) = INT(29.6) = 29

 

Range R = 29 - 9 + 1 = 21

AVE = MIN + (R / 2) = 9 + (21 / 2) = 19.5; If the AVE is indeed used by the game for some reason, it should be stored as a value of 19.

 

Plug in any number for HE damage, and my equations will correctly deduce all the necessary information. So there you go, my final word on how HE damage is calculated by the game for 1x1 units!

 

I have around 200 values for the Quarterpod vs HE-25 ammo completed as of today. Hopefully, these tests will be finished by the mid-end of this week. Along with the damage, I am also going to try and resolve how much stun damage is inflicted by a certain HE shell. Keep your fingers crossed. Now that I know how HE damage is calculated, I am confident that I will determine an equation for stun also! Whew, you guys get all that?

 

- Zombie

[Bomb Bloke]

Always assume that the game is using ints. The game only uses ints, you see; and an int divided by an int, even if there should be a remainder, will produce an int answer. That's just the way program work. If the game could use decimals, it would require a heap more memory... Old systems didn't have that.

[Zombie]

Everyone probably already knows that I used to program a bit "back in the day". It may seem stupid that I used the term "INT function" to describe the data, but it was just easier to convey my theory. I understand that the programmers declared all the variables in the game as "Integer" to save on memory space. However, if I were the programmer, for answers which required multiple calculations, those results should be stored as "Reals". That way, rounding errors will not multiply. Only at the very end of the calculation should the result be turned into a whole integer. And how much extra space would a few "real" variables consume anyways? Not that much in my experience. Ahhh welll. The joys of programming!

 

I should probably reiterate that the equations I gave in my previous post are only for HE detonations in the air. I am still working on the ground-based detonation equations. At this point in time, I think that the ground HE equations are just re-using the air calculations with a multiplier of 80%. I'll know more after I run about 200 trials with the HE-25 shells to verify.

[Zeno]

Integers used 2 bytes in C++ "back in the day", on 16-bit processors running DOS. That gave a range of values from -32,768 to 32,767.

 

Now, most systems (32-bit processors running Windows 9x, 2000, NT, or XP, for example) use 4 byte integers in C++, with a range of values from -2,147,483,648 to 2,147,483,647.

 

Sticking with the C++ example, both old-style and current floating-point numbers (aka real numbers) use 4 bytes, and have up to 7 digits of precision. There are more precise data types that require more bytes.

 

I used C++ as a standard because it's fairly consistent with other languages. Does anyone know what language XCOM was originally programmed in?

 

If we assume XCOM used 2 byte integers, then using real numbers of 4 bytes would have at least doubled the memory required for every variable--and probably would have had an impact on game performance using same-time-period computers.

 

------

 

By the way, I'm still very interested in the ongoing testing-- Zombie, this is really great information! Your dedication over the past few months has been outstanding! I wish I could be more than just a casual observer, but that's all I can offer right now. I do have a few renegade brain cells near the back of my skull thinking about alien AI tests, and hope to participate more on the various game mechanics analyses in the future...

 

--Zeno

[Zombie]

If we assume XCOM used 2 byte integers, then using real numbers of 4 bytes would have at least doubled the memory required for every variable--and probably would have had an impact on game performance using same-time-period computers.

 

Ok, so double the space for a real as opposed to an integer. But all the game would need is a few real variables to handle the "problem" calculations, or those errors which multiply because of an INT truncation. All I meant is that a handful of real variables would not significantly affect overall memory, speed or performance. Unless of course, if you wanted to use reals, you would have to declare all the variables in the game as that type.

 

By the way, I'm still very interested in the ongoing testing--  Zombie, this is really great information!  Your dedication over the past few months has been outstanding!  I wish I could be more than just a casual observer, but that's all I can offer right now.  I do have a few renegade brain cells near the back of my skull thinking about alien AI tests, and hope to participate more on the various game mechanics analyses in the future...

 

Casual observers are always welcome to post their thoughts here. In fact, there were times when I wish there were more people adding their insight, as two heads are better than one. I'm just one guy doing the actual testing, so sometimes a fresh opinion is helpful. Zeno: I look forward to seeing you around more often!

 

----------

 

Well, back to the damage modifier section. I finished the secondary trials for the Quarterpod vs HE-25 ammo today. In addition to damage, I collected the stun information for each alien to see how much stun gets added for an explosion. The amount of stun is not proportional to the amount of damage that is inflicted. That is definately a fact. So if a HE shell damaged a unit for 20 points, the amount of stun would be random.

 

For HE-25 shells and a damage modifier of 80%, the amount of stun added to a 1x1 unit is a number between 0 and 7 (inclusive). I have yet to determine an equation linking explosive strength, the damage modifier and stun with the values I have. I think some more tests with a different damage will help, as well as an alien with a damage modifier of 100%. Luckily the Reaper is up next, so determining an equation will be soon.

 

I'm still working on crunching the data I have for the HE-25/stun trial just completed. Those results should be done by the end of this week, or even tomorrow if time permits.

 

Up next: some trials for HE-25 ammo when the Quarterpod is standing on the ground (including the soldier). This will hopefully shed some light on a general ground HE equation. Also, some additional trials with the HE-50 ammo should provide some stun numbers to compare against the HE-25. There just might be a link between the amount of damage and the amount of stun inflicted.

[Bomb Bloke]

In some cases, an integral number divided by an integral number will produce an integral answer, regardless of what you mght it expect it to. It's a trait of some languages, notably the more primitive ones. That is to say, the programmers would have had to use float values (or reals) for the starting values, in order to generate float answers - the answer types were equal to the original types.

 

I had great fun programming a GameBoy game a while back. The primitive compiler ouldn't even warn you of such problems. The worst case was when you tried to perform a calculation with a type that was signed, and another type that was not. The thing decided both types were unsigned and calculated accordingly. The results were novel, and as the compiler gave me no warning (and programming debug information into a GameBoy rom is painful), it took me ages to work out what was going on.

 

I believe UFO was written in C, from my explorations. This message is hidden in the game code:

 

WATCOM C Run-Time system code is provided on an "as is" basis and is © Copyright by WATCOM International Corp. 1988-1993. All rights reserved.

 

I don't know enough to say what type of C, mind.

[Zombie]

Sorry for the delay in this post, but the data I was investigating needed quite a bit of "crunching" to decipher. Really messy. Arrgh!

 

Anyhow, if you all remember from my previous post that HE explosions not only inflict health damage but also a small amount of stun. Since I determined a general equation to find the Min and Max damage from a certain damage level, I was hoping that I could link that formula to the amount of stun inflicted too. So far, I have been unable to do this with only one HE damage level used. I need more data, so that means I need to reload a bunch more times with the HE-50 ammo. Oh, well.

 

These are the stats for the health damage inflicted on a Quarterpod using HE-25 ammo:

 

Quarterpod vs. HE-25 ammo

            Damage=25
Minimum:        9
Maximum:       29
Median:        20
Ant. Ave:      19
Act. Ave:    19.649

As you can see, the anticipated average is right on target with the actual average. The range of values is between 9 and 29 points of damage which equates to a continuous range of 21. Now for the associated stun stats with HE-25 ammo:

 

Quarterpod Stun Damage with HE-25 ammo

            Damage=25
Minimum:        0
Maximum:        7
Median:         2
Ant. Ave:      3.5
Act. Ave:      2.342

Let's take an example: The HE-25 ammo damages the Quarterpod's health by the minimum of 9 points. How much stun will be inflicted? Answer: anywhere between 0 and 7 points. Now let's assume a HE-25 shell does 29 health damage. How much stun is inflicted at this level? Answer: between 0 and 7 points. So there is no correlation between the damage inflicted and amount of stun added (both are random rolls).

 

Look at the anticipated and actual averages. They aren't even close to matching. But why is that? I did a distribution tally to see what the problem was:

 

Stun       0      1      2      3      4      5      6      7
Count     201    187    207    172    124    77     52     17

I have seen these numbers before. It is roughly half of a Gaussian (bell shaped) distribution curve! Makes sense because two random values are being rolled at the same time (like rolling two dice instead of one). If anyone is interested in viewing a graphical result, I have prepared a table below with a smoothed count to show the distribution better:

 

Stun       0      1      2      3      4      5      6      7
Count     201    187    207    172    124    77     52     17
Smooth    194    198    189    168    124    84     49     34

Note: plot the "Count" as a column and the "Smooth" as a line for the best results.

I also calculated a percentage for each stun number happening:

 

Stun        0       1       2       3       4       5       6       7
Percent   19.38   18.03   19.96   16.59   11.96   7.43    5.01    1.64

Interesting results to say the least. The maximum stun damage is infliced only 1.64% of the time. That's why the two averages didn't jive; I was expecting a linear distribution, instead of a skewed Gaussian curve. Well, I'm off to do some more trials with HE-50 ammo (as usual).

 

- Zombie

[Bomb Bloke]

Excuse my laziness in not examining the stats myself, but does the curve have any relation to the damage inflicted at all? That is, is there a scale involved?

[Zombie]

If you would have taken the time to actually read my post, you would know the answer.

 

In short, the Gaussian curve represents the frequency of a certain stun number happening. The amount of stun added to a unit is completely separate from the amount of damage inflicted. Say a unit takes 10 points of health damage (from HE ammo which pumps out a max of 29). The amount of stun added is a random number between 0 and 7. Now, say the unit is damaged for 20 points of health damage. The amount of stun added is again a random number between 0 and 7. Double the damage inflicted and one would expect the stun to double also, right? Nope, not in this case.

 

There might be a correlation between weapon strength and the amount of stun added. I am beginning the tests with HE-50 ammo to see if an equation can be formulated linking the two. So as of now, we will have to wait and see.

[Bomb Bloke]

I see, so there's no link between the amount of damage dealt and the stun dealt, but you're not as yet sure whether there's a link between the maximum damage that could be dealt and the maximum stun that could be dealt.

 

I would read through all the figures, but I'm really pressed for time these days. It's past midnight as I type this now...

[Zombie]

I gathered some values for the amount of stun added to a Quarterpod with HE-50 ammo. The maximum stun value I reached after 200 trials is 15. If you remember, HE-25 ammo managed half that number, or 7. So there definately is a link between stun and the maximum/normal damage from HE ammo. If you double the ammo strength, you double the stun inflicted.

 

I'm thinking that the maximum damage possible (including the damage modifier) is used for calculating the maximum amount of stun.

For HE-25, max damage is 29. 7 points of stun / 29 max damage = roughly 1/4 or 25%.

For HE-50, max damage is 60. 15 points of stun / 60 max damage = 1/4 or 25%.

 

To put it another way, the maximum amount of stun added is equal to 1/4 of the maximum amount of damage inflicted by HE ammo. Since the minimum for the amount of stun added is 0, the stun range is 1/4 max damage + 1.

 

I'll have to try this with the Quarterpod standing on the ground to verify this, but I am almost positive that my determination is correct.

 

- Zombie

[Stun Grenade]

All I can say is this:

 

Does this information make my gaming experience better? Or is it an attempt to proove the makers of this game wrong for making the game imbalanced?

 

Either way, Zombie, you are pretty close to the line

[NKF]

It's not about proving any imbalance or anyone wrong. It's just a way of trying to understand why the game does what it does. The whole thread's been about testing how susceptible an alien is towards damage of a certain type - then taking into account a variety of other factors that may influence the damage, and then comparing it against the damage notes that were published in the official strategy guide. Trying to understand how much stun damage is dealt is just an offshoot of this very same experiment. I mean, I too would like to know how much stun damage is dealt after any attack.

 

You don't have to understand any of this to enjoy the game - but some of it can be useful to you in one way or another.

 

- NKF

[Bomb Bloke]

Since the minimum for the amount of stun added is 0, the stun range is 1/4 max damage + 1.

 

Er, what?

 

Wouldn't stun merely be 1/4 of max weapon damage?

 

If you also had to add 1, then it would be impossible for there to be a minimum stun damage of 0.

[Zombie]

----------Disclaimer----------

Absolutely none of the data I present in this thread is intended to improve or enhance anyone's gaming experience. The fact is, if a person feels as though this information is excessive or obstructive to enjoying the game properly, they are under no obligation whatsoever to use it. This forum is a free society in which none of the members are forced into doing anything beyond their will. Everyone has the right to apply or disregard these facts and figures as they see fit.

----------End Disclaimer----------

(Maybe I should have made this stipulation in my first post)!

 

Most players are completely oblivious to what goes on behind the scenes of a game such as this. Truth be told, a good majority of people aren't very interested. That's fine, because it creates an atmosphere of mystique, and probably makes the game more exciting. However, to gamers such as me, this information is vital. Knowledge is power, and the more I know, the better I play.

 

Wouldn't stun merely be 1/4 of max weapon damage?

 

If you also had to add 1, then it would be impossible for there to be a minimum stun damage of 0.

The stun range is 1/4 max damage +1. It's not simply 1/4 weapon damage as this would suggest you could directly calculate a stun number based solely on damage. The only thing that can be determined is the range of stun values possible. The rest is up to the game via a random roll. For the game to accomplish this, it needs a range. Since the stun range always starts at 0, this number has to be included - hence the "+1".

[Stun Grenade]

hehe sorry guys, maybe if i had played the game longer, i would appreciate the 'tests'.

 

My logic is this: Weapon A is good against Alien Z = Excellent end result

thats all i need to know!

[Zombie]

My logic is this: Weapon A is good against Alien Z = Excellent end result

thats all i need to know!

Incidentally, that is exactly what these tests will accomplish. For the Sectopod, it seems that your best choices for killing it are Lasers and High Explosives. Lasers because they can potentially deal 3 times the listed damage, and High Explosives because they will always damage the unit for something, and they are area effect weapons on 2x2 units. Use them in conjunction (like firing off some laser bursts first, and tossing a grenade or HE pack afterwards) and you will probably see some excellent results.

 

----------

 

I think I have some bad news to report regarding the damage modifier tests. Not terrible, but definately not good either. If you remember, a HE-50 shell will damage a Quarterpod on the ground for between 16 and 48 points of damage. If the Quarterpod is in the air, the same HE-50 shell deals a range between 20 and 60. Reduce the HE strength by half to 25, and the damage dealt for the ground and air are exactly the same! This shouldn't be the case.

 

There are a few possibilities to consider:

1) My initial HE-50 ground trial was wrong, or

2) My current saved game is corrupted, or

3) There is a minimum HE charge where the air will be more than the ground.

 

As of this point, I am unsure. I still have my original game saved to a floppy somewhere, so I can recheck this this scenario quite easily. I also have the newer game on my HDD, I'll just have to copy that over to the game file to double check. In any case, just be patient with me while I sort this mess out.

[Bomb Bloke]

The stun range is 1/4 max damage +1. It's not simply 1/4 weapon damage as this would suggest you could directly calculate a stun number based solely on damage. The only thing that can be determined is the range of stun values possible. The rest is up to the game via a random roll. For the game to accomplish this, it needs a range. Since the stun range always starts at 0, this number has to be included - hence the "+1".

 

I realise stun is a random number derived from the maximum damage a weapon can deal, but if 0 is a possible stun value, then 1/4maxdamage + 1 cannot be correct, as all stun values would be 1 or more. That is, adding 1 removes 0 from the range.

 

Or am I missing something here...?

[NKF]

Hmm. You could probably look at it this way Bomb Bloke:

 

Range = 0 to ((Max Damage * 0.25) + 1)

 

- NKF

[Zombie]

You two are mixing up the meaning of "Range". My meaning of range is this:

Statistics. The difference or interval between the smallest and largest values in a frequency distribution.

I do not mean the range of numbers.

 

For instance, say you have a min of 20 and a max of 60. The range is 60-20+1 = 41. The range of values is between 20 and 60. Get it?

 

So to tie this in with High Explosives, Stun and Damage - Say the maximum damage a HE shell can deal is calculated to be 60. In order to figure out the amount of stun to add, the game needs an actual range. It can't do it with the range of damage numbers because there is no correlation linking the mins from the maxes.

Range of damage numbers: between 20 and 60.

Range of stun numbers: between 0 and 15.

You can get the max stun by dividing the max damage by 4. But if the same ratio were used to find the min stun, you would divide 20 by the same factor of 4. This returns 5, which is obviously not right.

 

What the game does is take the max damage that HE shell can deal. In this example, it's 60. To figure out the stun range (not range of stun values) the game takes the number 60, divides it by 4, and then adds 1. Result: 16.

 

To find the range of possible stun values, the game uses the number 16.

Possible Stun Value (or PSV) is found by this generalized equation:

PSV = Min + INT(Range * rand#)

Since the min is always 0, that factor can be dropped. The range is 1/4 MaxDamage +1.

PSV = INT( [1/4 MaxDamage +1] * rand#)

PSV = INT( [15 + 1] * rand#)

PSV = INT(16 * rand#)

 

Substitute 0.0001 in for the random number, and the stun value is INT(0.0016) = 0.

Substitute 0.9999 in for the random number, and the stun value is INT(15.9984) = 15.

 

Do you see why we needed the "+1" for the range? That factor is necessary to neutralize the darn INT rounding error. If we just used 1/4 max damage, the range would be 15. Sure, the min would remain the same at 0, but the max would be INT(15*0.9999) = INT(14.9985) = 14. My results do not suggest a PSV range of 0 to 14, but rather 0 to 15.

 

----------

As a side note, if the game could handle real numbers, it could use the Round function instead of the INT. The equation could then use 15 (instead of 16) for the range, because the game would round to the nearest whole number instead of dropping or ignoring those digits.

PSV = Round(1/4 MaxDamage * rand#)

PSV = Round(15 * rand#)

PSV (when random number is 0.0001) = Round(15*0.0001) = Round(0.0015) = 0

PSV (when random number is 0.9999) = Round(15*0.9999) = Round(14.9985) = 15

It's the same way of representing a range of values between 0 and 15 inclusive.

----------

 

Does that make sense now?

[Bomb Bloke]

I think you'll find NKF got it right, at least. I actually sat down yesterday and wrote a bit of code for my mapviewer which randomly created an icon for the taskbar whenever you ran it, and clicked as to what you were on about when I did that. I thought the brackets were being placed in a different position, so to speak...

 

You see, RND * 1/4maxdamage + 1 would not work.

 

However, RND * (1/4maxdamage + 1) would work, and that's what you were referring to.

[Zombie]

I think you'll find NKF got it right, at least.

Here is NKF's equation:

 

Range = 0 to ((Max Damage * 0.25) + 1)

The equation should be:

Range of stun values is between 0 and (MaxDamage * 0.25) inclusive

 

See, that "+1" isn't necessary when showing the interval of the range. A range interval is always defined as the space between the Max and the Min inclusive. The "+1" is only necessary when calculating a Possible Stun Value. That's because that equation requires a "Range", and a Range is defined as Max-Min+1.

 

Example:

Stun Interval: 0 to 1/4 MaxDamage -or- 0 to 15

Range: Max-Min+1 -or- (1/4 MaxDamage)-(0) + 1 -or- 1/4 MaxDamage +1= 16

PSV=Min + INT(rand# * Range)

Since Min is always 0, that factor can be dropped.

Substitute 1/4 MaxDamage +1 in for Range. Final equation is:

PSV=INT(rand# * [1/4 MaxDamage +1])

 

You need the brackets to preserve the order of operations. If you didn't have them, the game would multiply a random number by MaxDamage, divide by 4, then add 1. Whenever you substitute an equation for a variable, you must verify that the order of operations is preserved. If not, brackets (or parenthesis) are needed to segregate the two from illegally combining. And since addition and subtraction are the lowest on the pecking order, that "+1" will get done last if the equation is set up wrong.

[NKF]

Eh what?

 

Of course, I realise now that I shouldn't have called it 'range' and the '0 to' should've just been 'rand# *', but I was only trying to illustrate the bracket placement.

 

- NKF

[Bomb Bloke]

Meh, we all knew the correct formula, in my case I was just trying to work out how what you'd written applied to it, and NKF was just demonstrating.

 

...

 

Would you believe some of my most complex conversations use the word 'thingo' for just about every key word? I can talk via context, not meaning.

 

...

 

Don't mind me.

 

...

 

All these stats may be put to use soon. My mapviewer is nearly ready to become a game engine.