Skitso's Xenonaut noob friends thoughts

[StellarRat]

Doesn't seem passive in the last build.

[Skitso]

Yeah, the AI is pretty great atm! Props to GJ!

[lifehole]

Yeah played new build, balance and ai aggression problems are fixed but it's still too easy imo, on veteran anyways; maybe due to the fact that I have a squadron filled with 100-110 ap colonels by early midgame. Problem is when I increase difficulty I think it would make geoscape too hard for me.

[Commissar Pancakes]

Anyone else notice how if you shut a door, an enemy NPC who saw your solders close it will just walk up to the door and stand there? Kinda easy to clear out UFOs by exploiting this with shields and heavy weapons...

[lifehole]

Yep, that's my go-to tactic for some UFO assaults. Open door, throw in flashbang, shoot (or grenade if you don't care about destruction) stuff then close door. Rinse and repeat until alien life is gone.

[r4m0n]

We don't see anything going wrong, so the only other possible explanation for a bug would be that the RNG isn't working properly....which is pretty much impossible to prove one way or another (and afaik the game uses the default C++ RNG, which I assume is pretty reputable).

I was reading the reports of frequent misses and was wondering about the quality of the RNG, and this confirmed my suspicions.

The default RNG that ships with most C/C++ standard libraries isn't actually all that good, and it's prone to streams of numbers that actually aren't all that random.

There are some tests you can run on a RNG to measure the quality, but I'd just suggest that you get an implementation of a Mersenne Twister and start using that. If the RNG was the source of the problem, it will just go away, and we get a more reliable death distribution for our soldiers

[Gauddlike]

If it isn't too much work then adding a better method to generate random numbers would be worthwhile as the game relies on that random element a lot.

If the rng does generate strings of numbers then that could explain why people see a string of misses but testing the output of the rng shows it working as intended.

[Skitso]

That sounds interesting. I hope Chris reads those Wikipedia links.

[Skitso]

I'll have a new game night next Saturday with a new newbie friend. I'll make similar notes again.

Edited March 26, 2014 by Skitso

[Gijs-Jan]

I was reading the reports of frequent misses and was wondering about the quality of the RNG, and this confirmed my suspicions.

The default RNG that ships with most C/C++ standard libraries isn't actually all that good, and it's prone to streams of numbers that actually aren't all that random.

There are some tests you can run on a RNG to measure the quality, but I'd just suggest that you get an implementation of a Mersenne Twister and start using that. If the RNG was the source of the problem, it will just go away, and we get a more reliable death distribution for our soldiers

This is true for "heavy" (Cryptography, some AI techniques) usecases of psuedo randomness. I myself always roll my own RNG based on Mersenne Twister for any and all non-trivial use, however this really shouldn't be a problem for the accuracy calculation in Xenonauts.

If something is wrong, it will most likely be through the use or transformation of the output of the RNG.

[StellarRat]

I was reading the reports of frequent misses and was wondering about the quality of the RNG, and this confirmed my suspicions.

The default RNG that ships with most C/C++ standard libraries isn't actually all that good, and it's prone to streams of numbers that actually aren't all that random.

There are some tests you can run on a RNG to measure the quality, but I'd just suggest that you get an implementation of a Mersenne Twister and start using that. If the RNG was the source of the problem, it will just go away, and we get a more reliable death distribution for our soldiers

We actually encountered this problem on a game we did. The RNG tended to "roll" low numbers far too often if the RNG spread was multiplied by 100 or more (like 4x too often.) In our game "miracle" rolls were originally very low numbers. Such as a critical hit or lucky shot at extreme range. The solution was too "flip" the required rolls to the high side, so if something was only supposed to happen 1% of the time you had to roll a 99 or higher instead of a 1 or less. It took us a long time to figure this out, but eventually everyone got the sense that "miracles" were simply happening far too often. Things we only expect to see once in 10 games were happening every game, etc... After that a simple study of the output of the RNG confirmed the problem and indicated a solution. It's possible Xenonauts is suffering a similar problem, but the only way to find that is to do something similar to what we did. Edited March 26, 2014 by StellarRat

[Gijs-Jan]

We actually encountered this problem on a game we did. The RNG tended to "roll" low numbers far too often if the RNG spread was multiplied by 100 or more (like 4x too often.) In our game "miracle" rolls were originally very low numbers. Such as a critical hit or lucky shot at extreme range. The solution was too "flip" the required rolls to the high side, so if something was only supposed to happen 1% of the time you had to roll a 99 or higher instead of a 1 or less.

Which is what I tried to express with the transforms remark. :-)

This is due to how some RNGs manipulate the bit representation of the number; which gets distorted if you discard sections of it in the transform. Anyway, if I have some spare time somewhere I'll take a look.

Other than that, our first hunch is still (if it exists) some problem in implementation. The way to showcase this is to present some save where we from our end can see the problem happen. :-)

Btw:

If you encountered this during game development, you should've probably switched your RNG implementation.

(Previous iterations of Java's Random were notorious with skewed random results.)

IMHO; I always use MersenneTwister; making all points moot. (I need "better" RNG for most of my AI implementations, as they are academic)

[StellarRat]

Btw:

If you encountered this during game development, you should've probably switched your RNG implementation.

(Previous iterations of Java's Random were notorious with skewed random results.)

IMHO; I always use MersenneTwister; making all points moot. (I need "better" RNG for most of my AI implementations, as they are academic)

It was a LONG time ago (1991). We were writing in Turbo Pascal 6. At the time, none of us knew anything about "MersenneTwister" or anything else like. We just knew the Turbo Pascal random function wasn't working right. There was no internet to do research and none of us had a math background. It's so much easier to find solutions these days!

[Gijs-Jan]

It was a LONG time ago (1991). We were writing in Turbo Pascal 6. At the time, none of us knew anything about "MersenneTwister" or anything else like. We just knew the Turbo Pascal random function wasn't working right. There was no internet to do research and none of us had a math background. It's so much easier to find solutions these days!

Ah, fair enough!

Forget I said anything :-)

[jeon]

I've used the debug logger for this game several times looking around for other strange behavior and I haven't noticed any problems with the random numbers. I also have not seen any unusual streaks of misses/hits while playing the game.

If there really is something going on, someone needs to capture either a save with reproducible results or they would need to provide a debug log showing a problem with the random numbers.

[StellarRat]

Ah, fair enough!

Forget I said anything :-)

No, actually, I'm glad you said something. Now I know there is a better RNG algorithm out there if I ever need one again. It also enforces my belief that some RNGs suck.

Here is a suspect just posted: http://www.goldhawkinteractive.com/forums/showthread.php/9215-Ground-Combat-Balance-V21-Stable-Candidate?p=103994&viewfull=1#post103994