Mission percentages bugged

[HoreTore]

Public order is not a probability. The probability of an event occuring can't be more than 100%. This is inherent inthe definition of probability.

The game may calculate whether a gate opens however it wants, but it's nonsensical to say something has a probability outside the range 0 to 100%.

In the real world, yes, in a computer program, no, it is not nonsensical.

[Whacker]

In the real world, yes, in a computer program, no, it is not nonsensical.

He's right HoreTore. A game may do the math on a certain mechanic so that the outcome is guaranteed to happen given the inputs, but the probability of something happening cannot exceed 100% by definition. For example, say that spy skill is cumulative for opening a gate, and you have 3 spys that each have a 50% chance of opening the gate on assault. You add that up and get 150%, but in reality the probability is 100% because it cannot be more than this. Make sense? Good.

Also public order isn't a probablity function, it's a cumulative statistical percentage. Your 80% garrison + your charming 20% commander + your 20% fun buildings will all add up to 120% order.

[HoreTore]

He's right HoreTore. A game may do the math on a certain mechanic so that the outcome is guaranteed to happen given the inputs, but the probability of something happening cannot exceed 100% by definition. For example, say that spy skill is cumulative for opening a gate, and you have 3 spys that each have a 50% chance of opening the gate on assault. You add that up and get 150%, but in reality the probability is 100% because it cannot be more than this. Make sense? Good.

Also public order isn't a probablity function, it's a cumulative statistical percentage. Your 80% garrison + your charming 20% commander + your 20% fun buildings will all add up to 120% order.

Yup, if the game handles probability like the real world, then it's true. However, that might not be the case. Consider a board game rpg, say D&D. Now, you have a 20 sided dice, and you have make the thing you attempt on any outcome. However, a rule says that a roll of a one is always a failure. Now, even if you have 100% chance of success, you can still fail it. However, if you have say 150% chance of success, then you are entitled another roll if you roll a 1, and will have to roll more than 10 on that roll.

I have no idea if that's the case in this game, however, it COULD be, and thus you will see 150% "probability".

And yes, I know that PO isn't a probability, it was just representing the game stacking percentages.

[JCoyote]

Public order is mechanically different. It isn't stacking. It simply stats a point at which no disorder can happen as 100%, and how far above that you are is the margin you have against things like spies, etc. It is a probability issue below 100%, but above it it isn't anymore because the events it is measuring against can't happen anymore. 130% public order is 0% chance of riots/rebellion with a 30% safety margin that has to drop before it can happen.

[HoreTore]

Yes yes, I know that, but that was quite besides my point...

A bad example, nothing more.

[Foz]

Yup, if the game handles probability like the real world, then it's true. However, that might not be the case. Consider a board game rpg, say D&D. Now, you have a 20 sided dice, and you have make the thing you attempt on any outcome. However, a rule says that a roll of a one is always a failure. Now, even if you have 100% chance of success, you can still fail it. However, if you have say 150% chance of success, then you are entitled another roll if you roll a 1, and will have to roll more than 10 on that roll.

I have no idea if that's the case in this game, however, it COULD be, and thus you will see 150% "probability".

I think the point is that the game should be clear that the number it is displaying is not an actual probability in any case where it is not. If they want to use percentages to mean something other than the actual chance that the event happens, they could do so, but it requires very clear explanation, as percentages as commonly used by anyone always indicate the chance of an event happening with 100% being absolutely will happen no question and 0% never ever cannot possibly happen.

Even in the situation you point out above, the probability of your success is still not above 100%. You actually have a (0.05)(0.5) = 0.025 chance to fail, and thus a 97.5% success rate...

I think the biggest issue here is that probability and statistics are very well defined things with absolutely clear meanings, and the developers should not be using statistical terms if they do not intend to invoke their statistical meanings as a result.

[Whacker]

I think the point is that the game should be clear that the number it is displaying is not an actual probability in any case where it is not. If they want to use percentages to mean something other than the actual chance that the event happens, they could do so, but it requires very clear explanation, as percentages as commonly used by anyone always indicate the chance of an event happening with 100% being absolutely will happen no question and 0% never ever cannot possibly happen.

Even in the situation you point out above, the probability of your success is still not above 100%. You actually have a (0.05)(0.5) = 0.025 chance to fail, and thus a 97.5% success rate...

I think the biggest issue here is that probability and statistics are very well defined things with absolutely clear meanings, and the developers should not be using statistical terms if they do not intend to invoke their statistical meanings as a result.

I'm still not convinced that there's always a 5% pad on the high and low end of the mechanics here. I'm also not convinced that there's a random "seed" that's generated each turn for events, it'd be much easier and less memory intensive to generate a random number and just calculate the result when the action is performed. And as for my testing, it's the best we can do given what we've got to work with, it's as close to a "control" in test as is possible. Someone just playing the game normally and recording results would be possibly useful information provided they recorded actual skill and target strength (command skill, merchant skill, etc depending on target), as well as probability given for success. There's still too many variables introduced when you do this, and you're still assuming that the game actually does a random seed.

The bottom line is we all can't know what's going on for certain what's going on and how this game handles the mechanics, the best we can do is guess. CA is the only source that can give us a definitive answer.

All I know is that what's displayed to me in the game does not remotely reflect what my actual chances are in practice.

[Foz]

I'm also not convinced that there's a random "seed" that's generated each turn for events, it'd be much easier and less memory intensive to generate a random number and just calculate the result when the action is performed.

There in lies the problem. You cannot simply "generate" a random number. Where would it come from? Computers deal in rules, 1s and 0s, and calculations - random is anything but that. Thus the process of generating numbers that are seemingly random yet dispersed uniformly throughout the range [0, 1] is not a trivial task on a computer. The way it's typically done is to define a process that gives the general uniform dispersal you want, with a suitable period (since it's all function-based, the sequences always repeat at some point - the idea is to make that a LONG time). Then you use the seed to set the starting state of the system - you start at a state that isn't ever the same, in order to avoid giving the same set of numbers every time from the generator. So the seed doesn't really determine the result, it only mixes up the result some so that the generator does not become predictable, while still being able to generate numbers to the given specs. Outside of using a physical random number generator, the pseudo-random number generator I've attempted to describe is the only way I know of to get "random" numbers for computing purposes. Coincidentally a generator does calculate the next result on demand, it's only the internal state of the process that is needed to do so, which typically does not take up much ram at all (could easily be ~100 bits, and would never need to be much larger). It's this internal state I've suggested is saved in the savegame, thus giving the duplicated results some people have noted when loading to attempt something again.

I realize that may not be the easiest thing to digest... so for the moment I guess I'll let people try to do that, and see what if any remarks follow as a result.

[Whacker]

There in lies the problem. You cannot simply "generate" a random number. Where would it come from? Computers deal in rules, 1s and 0s, and calculations - random is anything but that. Thus the process of generating numbers that are seemingly random yet dispersed uniformly throughout the range [0, 1] is not a trivial task on a computer. The way it's typically done is to define a process that gives the general uniform dispersal you want, with a suitable period (since it's all function-based, the sequences always repeat at some point - the idea is to make that a LONG time). Then you use the seed to set the starting state of the system - you start at a state that isn't ever the same, in order to avoid giving the same set of numbers every time from the generator. So the seed doesn't really determine the result, it only mixes up the result some so that the generator does not become predictable, while still being able to generate numbers to the given specs. Outside of using a physical random number generator, the pseudo-random number generator I've attempted to describe is the only way I know of to get "random" numbers for computing purposes. Coincidentally a generator does calculate the next result on demand, it's only the internal state of the process that is needed to do so, which typically does not take up much ram at all (could easily be ~100 bits, and would never need to be much larger). It's this internal state I've suggested is saved in the savegame, thus giving the duplicated results some people have noted when loading to attempt something again.

I realize that may not be the easiest thing to digest... so for the moment I guess I'll let people try to do that, and see what if any remarks follow as a result.

I just realized I was misunderstanding what I *think* people were meaning by the 'random seed' in terms of how these events are calculated. Perhaps I am wrong and I did understand, but I'll elaborate. Before I get into this, I did check with two codemonkey friends before I posted this just to make sure some of my understandings were still correct. It's been a long time since I've banged out code for a living.

First in terms of random number generation, the C/C++ rand() and srand() functions will work absolutely fine, with the srand() seed simply being the system time in most all cases. Some software shops, I think Bioware being one, have made it publically known that they've improved on these base functions to get "better" results/"rolls" for their various D20 based games. As you pointed out it's only pseudorandom, esp. if one goes with the base C/C++ reference functions, but it's still been found to be sufficient in most cases. Someone on my floor in my dorm back in the day had to write a paper on this subject for a 200 level course, the overall observation (which is in line with the general viewpoint) is that it's not perfect and can vary somewhat by platform, but generally does give a good, consistent, full spread of results given a particular range set to work with.

The point where I was both misunderstanding and making an assumption was; as a matter of good programming practice, one should ALWAYS reinitialize the srand() seed before running a rand() to ensure that a new random number is generated. Thus in my thoughts, reload or no reload, the game should be performing the srand() first immediately by the actual rand() to decide of the event is a success or not. In my view (and in buddy's views) running reseeding only at the start of the campaign map turn or on reloading the game is "bad programming". This is of course subjective and depending on the particular needs, reseeding once may be a legitimate strategy to use, but again * can only guess and assume based on my limited previous experiences, education, and input from more knowledgeable sources. In terms of modern pc power and even the minimum specs required to run this game, running a simple srand() to reseed would require a minimum of cycles and should quite honestly be absolutely zero performance hit whatsoever on the cpu. In terms of memory again this is going to be minimal, seeing how much is required simply to run the game, much less good ol' Windows. Storing a 'seed' of some kind in a savegame in my view would be completely pointless based on the above. Given how frequently this needs to run, what maybe 10, 20, 40 times per turn towards the start of a campaign?, it's not like this is something that needs to be constantly recalculated and would put more strain on the system resources.

Now I don't know how CA is doing this, they could be doing something completely different for all we know. /shrug Just some thoughts, and it's late and I'm really tired. Good discussion though.

[HoreTore]

I think the point is that the game should be clear that the number it is displaying is not an actual probability in any case where it is not. If they want to use percentages to mean something other than the actual chance that the event happens, they could do so, but it requires very clear explanation, as percentages as commonly used by anyone always indicate the chance of an event happening with 100% being absolutely will happen no question and 0% never ever cannot possibly happen.

Even in the situation you point out above, the probability of your success is still not above 100%. You actually have a (0.05)(0.5) = 0.025 chance to fail, and thus a 97.5% success rate...

I think the biggest issue here is that probability and statistics are very well defined things with absolutely clear meanings, and the developers should not be using statistical terms if they do not intend to invoke their statistical meanings as a result.

I know of course that something cannot have over 100% chance of happening. My argument, is that in a GAME, you CAN see those odds represented, event though you still don't have over 100% probability. It might be an explanation as to why you see spies having over 100% to open the gates. Statistics may be clear, but you have a lot of games representing stuff in ways that break it.