Question about random seed test

[zapperio]

I got an interesting result, just now, as I was trying to answer Excelsior question about effects on queue from units from different stacks and a/d dependency.

this time, I had two stacks of horsemen vs two stacks of one(1)pikemen. As the test variables are quite limited I followed up each combination with 2 more attacks by a swordman vs hm and warrior vs hm so that if there were changes in the queue I'd have more variables to help me pick up on it.

An example of an attack:

1st attack Horseman (1st stack) vs pikeman (1st stack)
2nd attack Horseman (1st stack) vs pikeman (2nd stack)
3d attack Horseman (2nd stack) vs pikeman (1st stack)

(My first two attacks were rebuked and therefore I was able to make a third attack against one of the pikemen with my final horsey.)

I followed these with 2 attacks elsewhere to pick up on changes in queue.

When I changed the stacking order i.e. attacked 2nd stack first with 2nd stack horsey followed by 1st stack vs 1st stack there were no changes in the queue. Neither did it matter whether the final attack was made against 1st or 2nd stack. The 2 following combats always came out the same.

This pointed towards a a/d dependency independent of stacks.

However, and this is the interesting bit, when I attacked the same pikeman stack (with one pikeman only) in the first two attacks it changed the queue!

I.e.

1st attack Horseman (1st stack) vs pikeman (1st stack) (pm survives)
2nd attack Horseman (1st stack) vs pikeman (1nd stack)
or
2nd attack Horseman (2nd stack) vs pikeman (1nd stack)

So there is not an a/d dependency either!

Right now I'd give my right hand to find out how the branching system really works, but my testing seems to raise more questions then answers.

Zap

[zapperio]

shameless bump

[Excelsior]

Originally posted by zapperio
This pointed towards a a/d dependency independent of stacks.

However, and this is the interesting bit, when I attacked the same pikeman stack (with one pikeman only) in the first two attacks it changed the queue!

I.e.

1st attack Horseman (1st stack) vs pikeman (1st stack) (pm survives)
2nd attack Horseman (1st stack) vs pikeman (1nd stack)
or
2nd attack Horseman (2nd stack) vs pikeman (1nd stack)

So there is not an a/d dependency either!

Did the pikeman survive the second attack or not? Perhaps the survival of the combatants affects the queue?

Example:

1st Attack: Horseman (1st Stack) vs. pikeman (1st stack) (pm survives)
2nd Attack: Horseman (2nd Stack) vs. pikeman (2nd stack)

If you change the first attack to:

1st Attack: Horseman (2nd Stack) vs. pikeman (1st stack) (pikeman dies)

is the 2nd attack changed?

Also, you say that it doesn't matter which of these you do first:

Horseman (1st stack) vs. pikeman (1st stack)
or
Horseman (2nd stack) vs. pikeman (2nd stack)
, right?

Does it change the queue if you change it to

Horseman (1st stack) vs. pikeman (2nd stack)
Horseman (2ndstack) vs. pikeman (1st stack)
?

[Admiral PJ]

I'm a programmer, and it seems pretty clear that the game uses random number seeds so that no matter if you save a game, the results will always be the same (if you follow the same moves you did each time) as it saves the random seed each time.

It is strange that you'd expect a pattern if similar units were in combat, so like the 3rd unit would always win, but they might change the random seed for the units number or something so it always goes the same way.

WHAT THIS MEANS FOR RELOADS:
if you want to reload a game and chance the outcome in your favour, do like is said in this forum , change the order which you attack/move, I'm not sure what actions change the random seed, it could be it changes the random number depending on what movement number your on..

Often i've got fed up playing seriously, and mucked around for a few turns and suddenly got a Leader!
There may be some luck mechanism programed in, where if you lose or do worse then it helps you giving you more resources or a leader or more unit rank promotions.

[FuManchu]

Hope this might shed some light on things. Situation is probably a lot simpler than it looks (despite the fact the length of this post might suggest otherwise!)

Random number generators generally produce a difficult-to-predict-by-observation sequence of numbers, but they do that by feeding a value (the "seed") through a complex equation and storing the result to be used as the seed next time round. So it's completely deterministic - in other words, if the seed is initially value A, it'll always become B on the first call, C on the second etc etc (not that the numbers themselves would fit such an obvious pattern).

The pseudo-random number generated is also very unlikely to be the seed itself. Usually the seeds are great big numbers and the return value would be something more useful - like a percentage for instance - derived from specific bits of the seed. But this is just applying more maths, so a specific seed value will always produce a specific random number and we've still got a pre-determined (though still hard to predict) sequence of numbers.

Anyway (if you're still with me)...

This more than likely explains the phenomenon mentioned, that if you repeatedly reload a game and try the exact same sequence of attacks you get exactly the same results. I've been tinkering around with it, and battles do appear to have identical outcomes - even down to when individual hit points are lost - as long as you always carry out your attacks in the same order as before. If you change the order of attacks the outcome of the battles may change, but that's explicable too.

For all this to add up, I'm making two (reasonably big) assumptions...

1) The current seed value is saved along with the rest of the game data and restored when the game is reloaded (as mentioned in other posts).

2) The random number generator is only ever called when it's needed - e.g. for combat.

This is kind of interesting. It doesn't really prevent people cheating as attacking in a different order can yield more favourable results and if you're bothered enough you could go through all your options to find something better by continuously reloading and trying again. The thing is, this effect could be avoided if the program called the RNG every so often in the background to bump the random number sequence along - IOW made it not completely relative to what the player does (and also the seed wouldn't need to be saved at all).

So why are they doing it? Best guess - it might be some kind of multiplayer synchronization thing. If the seeds on different machines are set the same to begin with then communications are a bit simpler - you just need to give the other machine a list of battles between specific units and it can figure out the identical outcomes on it's own, round-by-round, battle-by-battle. You don't need to chuck so much data back and forth.

As to why you can get different outcomes by trying battles in a different order: we've got a fixed sequence of random numbers so if you change the order you fight battles in, each battle is going to hit the sequence in a new place, get a different set of numbers and so maybe have a different outcome.

I really don't think there's anything sinister involved and I don't think there's anything here that ties in with other combat weirdness, as in "unrealistic" results. Which is whole other topic...

[zapperio]

The replies that this thread gets seem to suggest that we are puzzling over why re-loading doesn't work. That is absurd and can only be a result from not reading the thread or not understanding it.

I'm a programmer myself, and call me anal, but I actually would like to know how the combat RNG queue system works. I'm interested as it relates to my field and I do think it may help the re-occurring discussion on the combat system in this forum.

Originally posted by FuManchu
I really don't think there's anything sinister involved

Neither do I.

and I don't think there's anything here that ties in with other combat weirdness, as in "unrealistic" results. Which is whole other topic...

I agree with your explanation on how the RN is used but what I'm interested in is what kind of action, when, under what circumstance, changes the order of results. Hence the testing.

Zap

I don't agree. If you know how a system works you may find it easier to know how and if it fails.

[Dev]

Good observations zap.

Now I wonder if messing with the queue can change the whole AI path. i.e. if you can make the AI move unit X from A to C instead of A to B simply by reloading and do whatever you're doing in a different order.

/dev

[zapperio]

Originally posted by Excelsior


Did the pikeman survive the second attack or not? Perhaps the survival of the combatants affects the queue?

No, he succumbed to his numerous wounds, alas. What changed the queue in this case was either that he was attacked twice in a row or, and I need to test this, he was attacked while wounded (he'd lost 1 hp in previous attack).

Example:

1st Attack: Horseman (1st Stack) vs. pikeman (1st stack) (pm survives)
2nd Attack: Horseman (2nd Stack) vs. pikeman (2nd stack)

If you change the first attack to:

1st Attack: Horseman (2nd Stack) vs. pikeman (1st stack) (pikeman dies)

is the 2nd attack changed?

Hard to test, that as he will either die or he will not die when attacked, in the 1st attack, by a horseman. Nothing I can do will change that except if we had a reg pikeman that survived against reg horseman but died fighting elite horseman. I still haven't seen that happen though. Saaay....

Also, you say that it doesn't matter which of these you do first:

Horseman (1st stack) vs. pikeman (1st stack)
or
Horseman (2nd stack) vs. pikeman (2nd stack)
, right?

Does it change the queue if you change it to

Horseman (1st stack) vs. pikeman (2nd stack)
Horseman (2ndstack) vs. pikeman (1st stack)
?

No it doesn't.

I tried all combinations and there was no change until I attacked the same stack twice in a row.

Zap

[quinalla]

Excellent thread, zapperio, I haven't done any testing myself, but it what you have done so far is very interesting. I might have to try something myself.

-quinalla

[FuManchu]

zap: you said "The replies that this thread gets seem to suggest that we are puzzling over why re-loading doesn't work"

Sorry, that wasn't my intention. I was mainly offering a suggestion as to why they bother to store the RNG seed
in the save file at all. It's probably there for a reason. Also: if it weren't there, we wouldn't be able to enjoy this entertaining discussion

Anyway, you want suggestions as to how the RNGs are picked up by the combat routines. Here's my hypothesis...

Let's assume we've got an RNG producing a series of random percentages. As I said in my previous post, the series is generated to a fixed pattern determined by the current value of the seed and the formula applied to it. So call the RNG a dozen times for a specific initial value of the seed and you'll always get the same set of a dozen numbers in the exact same order.

You fight two battles. First time it's A vs B, second time it's C vs D. If the first battle requires 3 rounds to resolve and it only needs one random value per round then A vs B will use the 1st, 2nd and 3rd numbers from the sequence, C vs D will use the 4th onwards.

Reload, seed gets reset, repeat battles, same numbers, same results.

However, if you reload and reverse the order of the battles then C vs D gets the numbers at the start of the sequence, A vs B picks up the sequence wherever C vs D finished off. So by reversing the battles you plug them into a different set of random numbers, which could well effect their outcomes.

Make sense? I'd be interested to hear if you've seen anything that might contradict this.

[Hurry]

Sorry, that wasn't my intention. I was mainly offering a suggestion as to why they bother to store the RNG seed

The most probable reason for saving the random seed is to make reload-cheating harder. As you have shown, this can easily be bypassed when you have several stacks of units, but especially early in the game, cheating is hard. For example, reloading won´t help you if you find a horde of barbarians in a village instead of something useful.

And yes, it seems quite clear that the random seed is only called for when it is needed.

[AHO]

I've also noticed that battle results will change by doing something that would appear to be completely unrelated but that uses a random outcome, such as, entering a goodie hut (or not entering the hut, whichever way you did it the first time). Conversely, you can change the outcome of the goodie hut by altering your battle plan (which, again would seem unrelated, but is tied to the RNG)

[Nero Would]

Originally posted by zapperio

No, he succumbed to his numerous wounds, alas. What changed the queue in this case was either that he was attacked twice in a row or, and I need to test this, he was attacked while wounded (he'd lost 1 hp in previous attack).

Zap

Surely that must be it. I may be missing something, but you seem to be assuming that one random number is used to resolve the combat between a pair of units. That does not fit the explanations of combat that I have seen. It seems more likely that one random number is used to resolve each round of combat, that is the loss of a hit point by one unit or the other. Any time you do something that changes the number of rounds it takes to resolve a given combat, the following combat will no longer get the same random numbers.

So if you change the attack/defense/experience values of any unit, or if you substitute a wounded unit (i.e. few hit points) for an otherwise identical unit, you potentially change the number of rounds (and therefore random numbers) required to resolve the combat. If the number of rounds is changed, the next combat starts at a different point in the string of random numbers.

[Hurry]

I hade the chance to make a little test in my current game, which in my opinion proves that the "die" is rolled in advance.

I had five Knights of different experience and damage levels (and in different tiles, as well), and I attacked a single regular Longbowman at full strength (3 hit points). After attacking with one of the knights, I reloaded and tried with another of the knights. These are the results (H=hit to enemy, W=wounded):

Attack with Elite Knight w/ 3 Hit points left: HWHH, Leader produced
Attack with Veteran Knight w/ 4 Hit points left: HWHH, upgraded to Elite
Attack with Regular Knight w/ 3 Hit points left: HWHH, upgraded to Veteran
Attack with Regular Knight w/ 2 Hit points left: HW, withdrew from battle
Attack with Veteran Knight w/ 1 Hit point left: HW, lost battle.

I think this clearly shows that the queue of random numbers is fixed, and also that is may be used as much in your favor as against you if you love reload-cheating.

Hurry

[Hurry]

I continued my testing a little bit.

As I showed in the above post, my unit got a hit during the second round of combat (after inflicting one hit on the enemy). This meant that I lost the battle if my unit had only one or two hit points left (since Knights retreat when wounded to one hit point). Now, I let this happen, and continued attacking with a second knight.

If my theory was right, I would always win this battle with no damage. This was the case. I always won, even if I attacked with a one-strength Knight. Also, I was also upgraded after the battle, and the Elite Knight always produced the leader.

Imagine the random generator is a die with 100 sides. It has always made the next 100 die rolls or so. Now, in this example, the die rolls could for example be 40, 96, 9, 67 and 1 (low number in favour of the player).

Since I had around 80% chance of winning (attack str 4 against def str 1), the die rolls 1, 3 and 4 was in my favour, while die roll 2 was in the enemys favour. The last die was in this case used to check whether my unit was upgraded after the battle. As you have seen, the elite can´t be upgraded, but instead produced a leader. The probability of gaining a leader is less than being upgraded, but can still use the same die roll.

Hurry