nihilistvoid
Chieftain
- Joined
- Feb 15, 2004
- Messages
- 29
Exactly.
Who hates Civ3's combat system?
- Thread starter Sark6354201
- Start date
Exactly.
akots
Poet
I beg to disagree. It is as random as a long dice game with several sequentially thrown cubes or a long gambling roulette session. And there is no proof it is different in Civ3. At least all combat calculators are working. However, the system is often considered as pRNG, pseudo-RNG due to its complexity when preserve seed option is checked.
Theory of these games was extensively studied including wave-type behavior and predictability as well as seed options and effects of the number of cubes on distribution patterns.
Recommended reading may include for start "Practical Statistics: Simply Explained," by Russell Langley and for more sophisticated math "Principles of Statistics" by MG Bulmer. All our students love this book. There is also an excellent site mathworld.wolfram.com with an excellent chapter on dice statistics: http://mathworld.wolfram.com/Dice.html
Some practical recommendations can be found at craps site:
http://www.crapsrulesstrategies.com/index.html
Commander Bello
Say No 2 Net Validations
To flatten out the effects described above, the interval should be sliced and the slices should be randomly spread as well.
Example:
You attack with your Crusader vs a fortified Pikeman.
A = 5
D = 3*(1+0.25+0.1) = 4.05
The chance for an attackers win is (as per hitpoint):
a/(a+d) => 5/(9.05) = 55.2486...%
So, the interval from 0 to 0.99999999999.... should be sliced into 905 single segments, from which 500 would be allocated to the attacker, and the other 405 would be allocated to the defender.
Say, the range from 0 to 0.0000145894 would be a win, from 0.0000145894 to 0.000029177 would be a loss, the next three segments would be wins again, then 8 losses and so on (the numbers of course are just ficticiuos).
Since that allocation would be given by the RNG as well, the effect of streaks in the resulting numbers should be eliminated.
In principle, by using this method you would just have weighted the results by the RNG.
Example:
You attack with your Crusader vs a fortified Pikeman.
A = 5
D = 3*(1+0.25+0.1) = 4.05
The chance for an attackers win is (as per hitpoint):
a/(a+d) => 5/(9.05) = 55.2486...%
So, the interval from 0 to 0.99999999999.... should be sliced into 905 single segments, from which 500 would be allocated to the attacker, and the other 405 would be allocated to the defender.
Say, the range from 0 to 0.0000145894 would be a win, from 0.0000145894 to 0.000029177 would be a loss, the next three segments would be wins again, then 8 losses and so on (the numbers of course are just ficticiuos).
Since that allocation would be given by the RNG as well, the effect of streaks in the resulting numbers should be eliminated.
In principle, by using this method you would just have weighted the results by the RNG.
superjib
Chieftain
The problem is in the title of this thread : combat system ! Not in the stats number but in the core... A/A+D formula is desperately too basic, I always wondered why attacking hoplites always lose vs hoplites no fortified... and swordsmen always won vs swordsmen... the units are the same !
So firstly, why not install a round system ? A/A+D and D/A+D...
Second problem is HP system... units lose 1 HP per 1 HP... too bad ! Best combat system is very simple (and I love Galactic Civilizations for that !) units should have HP, Attack, Defense, but the combat system is :
Att Unit rolls a die between 1 and his Attack amount, Defense unit do the same between 1 and his Defense amount, result is substract by the Defense HP... and you do the same with Def unit !
In Gal Civ, all combat are very realistic, big ships don't always win and in general 2-3 medium ships can destroy a fresh big one.
Suicide units are very useful because they have a very good attack and a very weak defense and HP so they usually strike one time with hope to kill in one shot, but if the defensive HP are not below 0 after the first attack : goodbye suicider !
For me, Gal Civ is great game due, partly, to his combat system...
If Civ3 had that, I would only play to Civ because I prefer historical games than SF... but I usually play one Civ3 game and one Gal Civ game...
Finally, I hope the combat system will be change in Civ 4 !
So firstly, why not install a round system ? A/A+D and D/A+D...
Second problem is HP system... units lose 1 HP per 1 HP... too bad ! Best combat system is very simple (and I love Galactic Civilizations for that !) units should have HP, Attack, Defense, but the combat system is :
Att Unit rolls a die between 1 and his Attack amount, Defense unit do the same between 1 and his Defense amount, result is substract by the Defense HP... and you do the same with Def unit !
In Gal Civ, all combat are very realistic, big ships don't always win and in general 2-3 medium ships can destroy a fresh big one.
Suicide units are very useful because they have a very good attack and a very weak defense and HP so they usually strike one time with hope to kill in one shot, but if the defensive HP are not below 0 after the first attack : goodbye suicider !
For me, Gal Civ is great game due, partly, to his combat system...
If Civ3 had that, I would only play to Civ because I prefer historical games than SF... but I usually play one Civ3 game and one Gal Civ game...
Finally, I hope the combat system will be change in Civ 4 !
Commander Bello
Say No 2 Net Validations
Sorry, Akots,
but now I have to disagree.
A computer's RNG is just *not* a set of dice. It *simulates* them.
So, you have an algorithm, which is to calculate numbers which equal the outcome of a given (big) number of dice rolls.
Since the common die has 6 integers (1-6) whilst a RNG typically gives back numbers in the interval from 0 to 0.9999999.... , for comparison of the sets of numbers for the RNG you would have to multiply the results with a factor to make them appear as integers. Here the problem of rounding will appear.
But there is another problem. For the die, the interval is inherent, given by the eyes on it's six different surfaces. For the RNG, it has to be set.
Then, a perfect die is expected to give you uniformly distributed numbers (under the assumption of a very large number of rolls, let's say, 10,000 of them). The expectation is that every number of the range from 1 to 6 would appear very closely to 1666 times.
This has to be simulated by the RNG's algorithm. So, you need some mathematical tricks to make the low numbers appear with a certain percentage, the same for the high numbers (and of course, for everything in between).
The quality of the algorithm decides about the statistical relevancy of the numbers. And the quality of the transformation into cpu-code (assembler) decides about the quality of reflecting the results of the algorithm.
So, depending on the level at which the compiler constitutes the rounding to take place, you will face differences between what the algorithm determines and the "real" result of the RNG.
To make these differences appear less often, a good RNG should change the seed for it's calculation quite frequently. But, since the seed is the basic value for the calculation and may differ, it is obvious that some seeds may fit better to the algorithm, than others.
akots
Poet
I don't understand what you are talking about. Either you have to read something to understand the subject, or please make it more understandable in standard terms and may be equations. I don't see any rounding problem or any other problem at all with pRNG. There is no need for rounding. The cube can have as many sides as you want. It is a simulation after all...
Arguing on these subjects without having some background in statistics is like saying to a sick child: "Please, baby, drink this milk. You'll get better if you do." And baby says: "I don't like the taste and will not drink." And the baby dies. Audience bursts with tears. Not so poetic but statistically correct.
Actually, poetry and statistics have many things in common. They are both unpredictable for one.
Commander Bello
Say No 2 Net Validations
Gladly!
Ok, please allow me to start with a general comment.
Combat in Civ is at least to a certain degree a simulation of what has happened or would have happened in the real world. For that reason, units have different unit stats.
If only these unit stats would be taken into account, a swordsman would win every time vs a spearman. As we all agree (at least the vast majority), this doesn't reflect our experience from history and real life. So, there has to be a feature to add unexpected outcomes of a battle between two given units. This is done via making use of the RNG.
Now, we have the combat stats and the RNG number. As we learned in CivI, that would cause annoying effects over and over (the famous battleship - spearman).
To level this, hitpoints have been added. Obviously, the expectation was that hitpoints would cause those "unexpected" results to happen seldom enough.
Nevertheless, at least a significant minority of players still complains, since they feel to observe so-called "streaks".
How may those streaks appear? (Under the assumption, that they are real, and not only a perception problem of the individual player)
That is, where my attempts to explain (see my previous posts) started.
If we were to roll a n-sided die and did this often enough, we would expect any of the numbers to appear 1/n times.
Let us stay with the 6-sided die, for making the understanding easier. With a given (very large) number of rolls, each number of the die is expected to appear 1/6 times of the total of rolls. So far, so good.
Now, this rolling of the die is to be simulated with a RNG.
A RNG will not come back with a value of 1, 2, ...., 6, but with a number in the interval of 0 to 0.9999 (actually, it will be 0.9999999... , depending on the bits reserved for it).
So, the RNG is expected to have 10,000 different values to offer as result, running from 0 to 0.1666 (!) as complement to the die's 1, 0.1667 (!) to 0.3332 as complement to the die's 2 .. and so on.
Now, depending on the calculation of the relation between attack and defense values, we may see that there are rounding problems.
Under the assumption that the attacker has A=4 and the defender has D=2 (no modifiers as fortification, defense value of the terrain, attack across a river are taken into account for the moment), the formula is: A/(A+D) = 4/(4+2) = 4/6.
So, any result of the RNG being in the sub-interval of 0 to 0.6664 would count as a win, everything in the sub-interval of 0.6665 to 0.9999 would be a loss.
As our combat formula tells us, the probability for a loss is 2/6 = 1/3.
If we calculate the probability of a loss as "counter-win", for the RNG it would be 0.9999 - 0.6664 = 0.3335 (!)
This already is a difference of 2/10.000
(Again, please take notice that the figures are very much simplified. Real figures will be much lower)
If we would assume that rounding takes place at the third decimal place (due to transforming integers into floats), the "counter-win" becomes 0.334 (!)
Now, we calculate again: 0.9999 - 0.334 = 0.6659 (upper threshold for a win)
This makes a difference of
0.6659 -0.6664 = 0.0005 => 0.05%
0.05% seem to be very low. Actually, it is very low.
Nevertheless, it is already an inaccuracy.
Now we will add the modifiers into the formula.
We have an attacker with A=4, and a fortified defender with D=2, sitting on the other bank of the river on plains.
The probability for a win would be:
4/(4+(2*(1+(0.25[fortified]+0.25[river]+0.1[plains])) =
4/(4+(2*(1+0.6)) = 4/(4+3.2) = 4/7.2 => 0.5556
Again, this may result in a win to be any number in the sub-interval of 0 to 0.5556 or in the sub-interval of 0 to (1-(0.9999 - 0.5556))=0.5557.
So, depending how the range for a win is calculated, we have already differences. You may look at it "bottom-up" or "upside-down" and will get different results for the probability.
If still the rounding would happen at the third decimal, we would have 0.556 or (1-(0.9999-0.556))=0.5561 or (1-(0.999-0.556))=0.557.
So, the biggest error due to rounding would be between the 0.5556 and the 0.557. It would be 0.0014 => 0,14 %
All this stands true under the assumption, that the divisor in our example is correctly translated into a float. Is it?
If our formula would be:
4/(4+3[3.2 not being a float, but kept as integer]) = 4/7
the range for the win would be: 0 to 0.5714 (of course, at a certain point we will have floats, forced by the use of the RNG)
Now, we would face a difference of
0.5556 - 0.5714 = - 0.0158 => 1.58 % difference.
Without taking into consideration, that the attacker could be an army with pentagon (0.1666 multiplier) under the influence of a radar tower (0.25 multiplier) what really would make for a worst case scenario, we may assume that both units are veterans.
So, the battle could last for 7 internal rounds (wwwlllw or the like). 7*1.58% = 11.06% difference!
Of course, here I assumed that the results of the RNG would always be around 0.5556 +/- 0.0001, just to make for the rounding differences.
Bottom line:
The whole example of course is just to display that the combat results are depending on:
a) when integers are transformed into floats
b) when rounding will occur (that is, how much decimals of the floats will be used)
c) how the interval in which the RNG results will be, is divided up into win and loss
[edit] Ok, since I am not willing to take responsibility for your death, I will give you some time to drink your milk
[second edit] All the above was under the assumption that we will have perfect random numbers. About the random numbers I might continue, if you wish....
nihilistvoid
Chieftain
- Joined
- Feb 15, 2004
- Messages
- 29
Bello is on a roll today! (no pun intended)
Im kind of curious if a PC is actually ever capable of making a truly random decision between two bits of equally valid information; it seems to me that it could only make the decision based on programmed algorithms and the like. It should be clear that I have absolutely no programming experience, so Im really out on a limb making this "observation."
Im kind of curious if a PC is actually ever capable of making a truly random decision between two bits of equally valid information; it seems to me that it could only make the decision based on programmed algorithms and the like. It should be clear that I have absolutely no programming experience, so Im really out on a limb making this "observation."
microbe
Cascaded Mansion
- Joined
- Nov 16, 2003
- Messages
- 4,596
That is why it's called Pseudo RNG.
But so WHAT? It's good enough. We are NOT talking about security of online transaction systems here.
If you WANT to predict the result here, I wish your luck. With "Persistent RNG" options on, you don't need to predict - just try and reload will do. With "Persistent RNG" off, you'd have to have the good timing to reproduct the result, and I don't know why you would bother.
It's JUST A GAME. There is no need for a true random number generator.
microbe
Cascaded Mansion
- Joined
- Nov 16, 2003
- Messages
- 4,596
Yes it could, as long as it has device with random inputs.
Typical sources are keyboard and mouse. More sophisticated sources are network adaptors and hard disks - those are not TRULY random but almost - theoretically, a hacker could feed packets to your network adaptor and predict the events, but he has to know the exact timing and he has to be the only source of network traffic, which makes this nearly impossible. So unless you are a security paranoid, it can be safely considered truly random. The benefit of network traffic as random number generation seed is it's much more adundant than keyboard and mouse (the latter will become exhausted when the human stops inputting).
This is how Linux generates true random numbers.
Commander Bello
Say No 2 Net Validations
Microbe,
nobody is talking about prediction of a certain roll.
The discussion was triggered by some people thinking that they've observed "streaks" in the rolling.
And I tried to explain, that streaks may be forced by the inner settings of the RNG and everything, was is attached to the way in which combat results are calculated.
The funny thing is that as soon as you state that the (p)RNG's numbers are just not random, but calculated in a certain way, you are faced with the allegation of desiring predictability.
The only predictability I am interested in, would be to be sure that the RNG's algorithm is so good, that streaks are as likely to happen as if you would have rolled perfect dice.
Everything else has to be done with the balancing of the combat stats and the hitpoints. That is, what I would call the flavour of the game.
And here we find different approaches. The one likes it when he never knows how a certain battle might end, the other ones likes the "stronger" unit to win more often, and some indeed claim the would like even better chances for the "weaker" units.
After all I think it is just a question of proper balancing, that's all.
This initial assumption not necessarily must be true. Why exacly pRNG must return number in range 0 - 0.99999? Why can't return 1, 2, 3 and so on? In fact, creating such generator is rather simple task. Please read interesting thread about Civ3, pRNGs, streaks and randomness in general:
http://apolyton.net/forums/showthread.php?s=&threadid=60407
Thread author wrote simple yet good random number generator which returns integer numbers in range 0 - 1023. Now consider your example: 6 attack vs 2 defence = 2/3 prob. of attacker wins each battle round. There is no problem in simulating a roll for this scenario: get some high number in range 0 - 1024 divisable by 3, say 900. Assume range 0-899 (counting starts from 0):
pRNG returns 0-599 = attacker wins
pRNG returns 600-899 = defender wins
900 - 1023 = ignore, reroll
Of course rerolling may be not optimal, but that's not the point. Even after factoring defensive bonuses we may easily adjust our 0-899 range.
Note: discussed pRNG probably isn't Civ3 generator (but I suspect it's similar). I was only pointing to fact that pRNGs can return integers and may simulate "perfect" dice rolls, no truncating necessary. And often they do.
microbe
Cascaded Mansion
- Joined
- Nov 16, 2003
- Messages
- 4,596
Sorry I didn't read all the posts, my apologies.
However, the "streaks" is not caused by the pseudo RNG. The difference between pRNG and RNG is not that one is more "fair" than the other (short term or long term), but the predictability of the next result. From the game's point of view, even if we use a true RNG, it will not make a difference when it comes to "streaks" or "bad luck".
Commander Bello
Say No 2 Net Validations
@ Gen:
Thanks for the link to this very good and interesting thread!
Vulture definetively is much more into the details, than I am after being 18 years out of university.
Just one remark: his RNG delivers integers, but they are transformed from a 64 bit value. But this for sure is not important.
The whole thread is very interesting and offers some insights to the work of (p)RNG's.
He explains it much better than I ever could do, so I leave that statement uncommented from my side.
Thanks for the link to this very good and interesting thread!
Vulture definetively is much more into the details, than I am after being 18 years out of university.
Just one remark: his RNG delivers integers, but they are transformed from a 64 bit value. But this for sure is not important.
The whole thread is very interesting and offers some insights to the work of (p)RNG's.
He explains it much better than I ever could do, so I leave that statement uncommented from my side.
akots
Poet
For these and the above conclusions you apparently assume independent dice roll every time during the combat for each hit point which does not happen. The dice are rolled for the whole combat so that the combat between two units is resolved. And it is substantially more complicated in analytical expressions. Good examples of similar calculations can be found in sources which I posted previously. Another combat will be an independent event with a certain seed which is either saved or not depending on the option checked during the start of the game. Apparently you got mixed up with hit points and resolving combat. The calculations that you use are for resolution of combat but you use them for individual hit points. At least this is the way I understood it. Therefore the rounding does not exist. And you cannot subtract probabilities one from another. We learned that in high school.
Edited: There is no point to argue. It is just hopeless. Let the people believe what they want.
Edited again: cross-posted with Bello and Gen. Ya, vulture did some good digging through. His explanation of phenomenology is precise. Though he is not getting much into mechanism which is very-very wise. It is complicated.
I thought you might like it
Edit: oh, and if anybody is interested in what exactly pRNG Civ3 uses, I've finally found the link. Search for hwinkels posts:
http://forums.civfanatics.com/showthread.php?threadid=15208&perpage=20&display=&pagenumber=2
The Last Conformist
Irresistibly Attractive
nihilistvoid isn't a Civ3 programmer or a computer programme, so he can't therefore provide nummerical evidence of his nummerical assertations? Did someone exchange my universe when I wasn't looking?
Rounding errors or not, a virtually certain sign of a non-random orgin of a string of any length is a lack of streaks. We want streaks. They're part of the reason we feel comfortable handling the pRNG as a source of true randomness, and thus feel we can consider CivIII combat to be fair.
Rounding errors or not, a virtually certain sign of a non-random orgin of a string of any length is a lack of streaks. We want streaks. They're part of the reason we feel comfortable handling the pRNG as a source of true randomness, and thus feel we can consider CivIII combat to be fair.
TheNiceOne
Emperor
Now, this has fortunately been extensively tested, and the CIV3 RNG is so good. In fact, it is so good that many players think it delivers too many streaks. Statistical analysis have shown that people expects less streaks than true random numbers produce. So players who observed streaks in the rolling, observed how true random numbers actually will behave. They expect something else (since most humans expect a smoother distribution of numbers), and complains abut the RNG, when its their own expections that are wrong (if true random numbers are the facit).
Gingerbread Man
Dark Magus
Originally posted by Commander Bello
Gladly!
Ok, please allow me to start with a general comment.
Combat in Civ is at least to a certain degree a simulation of what has happened or would have happened in the real world. For that reason, units have different unit stats.
If only these unit stats would be taken into account, a swordsman would win every time vs a spearman. As we all agree (at least the vast majority), this doesn't reflect our experience from history and real life. So, there has to be a feature to add unexpected outcomes of a battle between two given units. This is done via making use of the RNG.
Now, we have the combat stats and the RNG number. As we learned in CivI, that would cause annoying effects over and over (the famous battleship - spearman).
To level this, hitpoints have been added. Obviously, the expectation was that hitpoints would cause those "unexpected" results to happen seldom enough.
Nevertheless, at least a significant minority of players still complains, since they feel to observe so-called "streaks".
How may those streaks appear? (Under the assumption, that they are real, and not only a perception problem of the individual player)
That is, where my attempts to explain (see my previous posts) started.
If we were to roll a n-sided die and did this often enough, we would expect any of the numbers to appear 1/n times.
Let us stay with the 6-sided die, for making the understanding easier. With a given (very large) number of rolls, each number of the die is expected to appear 1/6 times of the total of rolls. So far, so good.
Now, this rolling of the die is to be simulated with a RNG.
A RNG will not come back with a value of 1, 2, ...., 6, but with a number in the interval of 0 to 0.9999 (actually, it will be 0.9999999... , depending on the bits reserved for it).
So, the RNG is expected to have 10,000 different values to offer as result, running from 0 to 0.1666 (!) as complement to the die's 1, 0.1667 (!) to 0.3332 as complement to the die's 2 .. and so on.
Now, depending on the calculation of the relation between attack and defense values, we may see that there are rounding problems.
Under the assumption.... {{{{ETC, ETC, ETC,}}}}
You have no idea how the RNG works. The number of assumptions you have made are astounding. Please, dont base proof on assumptions, base it on evidence.
Here is something from a guy who knows what he is talking about:
(Bold added for emphasis)
I dont want to be offensive. It is just that your view of the Civ3 random system is wrong.
Commander Bello
Say No 2 Net Validations
Now, since this is really going more and more off-topic, I just want to make a last statement.
I've to admit that I didn't debug the program code. Nevertheless, as the combat calculations have to be aligned with the relationof the combat stats of the units involved, the problem on principal stays the same.
For the logic of it, there is no difference whether I have to align a result within the interval from 0 to 0.999999 to a given relation between to different combat stats, or if I have to align a result within the interval from 0 to 1024 to it.
In other words:
In my example I was assuming a A/D ratio of 4/7.2. I will quote myself:
We have an attacker with A=4, and a fortified defender with D=2, sitting on the other bank of the river on plains.
The probability for a win would be:
4/(4+(2*(1+(0.25[fortified]+0.25[river]+0.1[plains])) =
4/(4+(2*(1+0.6)) = 4/(4+3.2) = 4/7.2 => 0.5556
Of course, here I assume the calculation to be A/(A+D), with A being the modified attacker value and D being the modified defense value. As far as I know, this is the formula used. And in all threads regarding this topic, I haven't read something else. As far as I remember, this is emphasized by Tavis' explanation (was in the announcement of the 1.10 patch with the new combat system) that there wouldn't be a roll for the defender. Although, even that wouldn't make much difference, as I see it.
Whatever the RNG will return, it has to be aligned with this ratio. Any interval of possible returns from the RNG will have to "sliced" into 72 slices (slice = interval), from which 40 will be counted as attackers win, and 32 will be counted as defenders win. (Again, I have to assume something: that there are no fractions of "slices" - you either have an interval, or not. But you will not have x.2 intervals)
Since such a slice will constitute an interval within the interval of possible returns of the RNG.
If it is the given ratio we have to divide the interval of possible returns by the divisor. So, if the Civ3 RNG returns with something between 0 and 1023, we have 1024 possibilities of returns and 72 possible intervals for calculating the result of the battle. That means that any of the 72 possible intervals will stretch about 14.222.... numbers (1024/72). Now, what does happen with the 0.2222... ? I still see it as a rounding problem.
And even, if there would be independant rolls for both, the attacker and the defender, then still the interval of 0 to 1024 would have to be aligned with A and D. In the given example, for the attacker it would be easy, since it is 4, but what about D=3.2?
And the last possibility... First, the game determines the probability for a win, then it would calculate 0.5556 for the attacker. Still, 0.5556 * 1023 = 568.3788. Again, we have to face rounding. First, for the probability, second for the calculation p*1023.
Roundings just will occur!
Any other assumption in the consequence would mean that the relation of combat statistics (taking all possible modifications into account, of course) would be at least almost meaningless for the calculation of the battle.
To be honest, I am a little bit surprised, that this obvious fact constantly is neglected by interested parties.
I can only assume, that some of you desperately want to keep the current system. So, any argument against it seems to be just inexistent for some of you.
Very well then. Let's drink our milk.
I've to admit that I didn't debug the program code. Nevertheless, as the combat calculations have to be aligned with the relationof the combat stats of the units involved, the problem on principal stays the same.
For the logic of it, there is no difference whether I have to align a result within the interval from 0 to 0.999999 to a given relation between to different combat stats, or if I have to align a result within the interval from 0 to 1024 to it.
In other words:
In my example I was assuming a A/D ratio of 4/7.2. I will quote myself:
We have an attacker with A=4, and a fortified defender with D=2, sitting on the other bank of the river on plains.
The probability for a win would be:
4/(4+(2*(1+(0.25[fortified]+0.25[river]+0.1[plains])) =
4/(4+(2*(1+0.6)) = 4/(4+3.2) = 4/7.2 => 0.5556
Of course, here I assume the calculation to be A/(A+D), with A being the modified attacker value and D being the modified defense value. As far as I know, this is the formula used. And in all threads regarding this topic, I haven't read something else. As far as I remember, this is emphasized by Tavis' explanation (was in the announcement of the 1.10 patch with the new combat system) that there wouldn't be a roll for the defender. Although, even that wouldn't make much difference, as I see it.
Whatever the RNG will return, it has to be aligned with this ratio. Any interval of possible returns from the RNG will have to "sliced" into 72 slices (slice = interval), from which 40 will be counted as attackers win, and 32 will be counted as defenders win. (Again, I have to assume something: that there are no fractions of "slices" - you either have an interval, or not. But you will not have x.2 intervals)
Since such a slice will constitute an interval within the interval of possible returns of the RNG.
If it is the given ratio we have to divide the interval of possible returns by the divisor. So, if the Civ3 RNG returns with something between 0 and 1023, we have 1024 possibilities of returns and 72 possible intervals for calculating the result of the battle. That means that any of the 72 possible intervals will stretch about 14.222.... numbers (1024/72). Now, what does happen with the 0.2222... ? I still see it as a rounding problem.
And even, if there would be independant rolls for both, the attacker and the defender, then still the interval of 0 to 1024 would have to be aligned with A and D. In the given example, for the attacker it would be easy, since it is 4, but what about D=3.2?
And the last possibility... First, the game determines the probability for a win, then it would calculate 0.5556 for the attacker. Still, 0.5556 * 1023 = 568.3788. Again, we have to face rounding. First, for the probability, second for the calculation p*1023.
Roundings just will occur!
Any other assumption in the consequence would mean that the relation of combat statistics (taking all possible modifications into account, of course) would be at least almost meaningless for the calculation of the battle.
To be honest, I am a little bit surprised, that this obvious fact constantly is neglected by interested parties.
I can only assume, that some of you desperately want to keep the current system. So, any argument against it seems to be just inexistent for some of you.
Very well then. Let's drink our milk.
Similar threads
