A Literally RANDOM Update? - Version 1.2.2
Hello, people out there,
This update corrects some minor bugs but it also addresses a small problem which has been around since version 1.0: Random number generation.
I won't go into all the technical details of pseudorandom number generation (it's not hard to find more info on this subject if you are interested), the important factor to understand here is that computers are not capable of creating random numbers out of nowhere. The best you can do is simulate randomness with algorithms that return streams of bits that are apparently not correlated to each other.
But no matter how complex the algorithm used to generate a sequence of numbers is, it will rely on determistic operations running on a finite set of states, meaning the resulting sequence is not truly random.
Nonetheless, the quality of pseudo RNG algorithms will vary and the best fit for a game will depend on how critical randomness is in its gameplay.
Now, believe it or not, none of the gameplay elements in Quantumleaper rely on pseudo RNG. Despite some of them seeming apparently random (like some enemy projectiles or the AI of some bosses) they are all created using internal counters and modulated trigonometric functions (which is just a fancy way to say they may look messy but they still form a pattern, much like fireworks in real life).
That is not to say that pseudo RNG is not used anywhere, some visual effects do rely on them, and that's where one of the issues addressed in this update was found:
The first picture uses the previous RNG, which didn't generate any randomness for this particular type of particle. The second picture uses a new RNG. It's important to note that, prior to version 1.2, these smoke particles were rendered using a simple static texture. Therefore, the problem wasn't apparent until very recently.
The function I was using up to this point is infamous among C and C++ developers for being a low quality choice. I was aware, but I thought I could get away with it because it was used only for visual effects. Then it broke a visual effect, who'd imagine that? ¯\_(ツ)_/¯
Anyway, this was just one of the modifications, here are the remaining changes and corrections included in version 1.2.2:
If you are wondering about what types of change you should expect in the levels, here is an exemple:
I know what meme is your mind right now and no, they are not the same picture! These changes are subtle, but I intend to add more and more detail to the levels throughout the next round of updates.
As always, feel free to make suggestions, report an issue, give a compliment or just acknowledge my humble existence.
And if you are also a developer, do yourself a favor: stay away from rand()!
This update corrects some minor bugs but it also addresses a small problem which has been around since version 1.0: Random number generation.
I won't go into all the technical details of pseudorandom number generation (it's not hard to find more info on this subject if you are interested), the important factor to understand here is that computers are not capable of creating random numbers out of nowhere. The best you can do is simulate randomness with algorithms that return streams of bits that are apparently not correlated to each other.
But no matter how complex the algorithm used to generate a sequence of numbers is, it will rely on determistic operations running on a finite set of states, meaning the resulting sequence is not truly random.
Nonetheless, the quality of pseudo RNG algorithms will vary and the best fit for a game will depend on how critical randomness is in its gameplay.
Now, believe it or not, none of the gameplay elements in Quantumleaper rely on pseudo RNG. Despite some of them seeming apparently random (like some enemy projectiles or the AI of some bosses) they are all created using internal counters and modulated trigonometric functions (which is just a fancy way to say they may look messy but they still form a pattern, much like fireworks in real life).
That is not to say that pseudo RNG is not used anywhere, some visual effects do rely on them, and that's where one of the issues addressed in this update was found:
The first picture uses the previous RNG, which didn't generate any randomness for this particular type of particle. The second picture uses a new RNG. It's important to note that, prior to version 1.2, these smoke particles were rendered using a simple static texture. Therefore, the problem wasn't apparent until very recently.
The function I was using up to this point is infamous among C and C++ developers for being a low quality choice. I was aware, but I thought I could get away with it because it was used only for visual effects. Then it broke a visual effect, who'd imagine that? ¯\_(ツ)_/¯
Anyway, this was just one of the modifications, here are the remaining changes and corrections included in version 1.2.2:
- The information text for Trigger Strands was corrected (it had the word "described" misspelled as "discribed");
- It was possible to make red lasers cross solid walls by saving and reloading the game in specific locations. This is now corrected;
- Hitting the floor makes slightly less noise now;
- Hitting the floor while underwater makes a distinct sound now;
- The geometry of multiple locations in the game levels has been refined.
If you are wondering about what types of change you should expect in the levels, here is an exemple:
I know what meme is your mind right now and no, they are not the same picture! These changes are subtle, but I intend to add more and more detail to the levels throughout the next round of updates.
As always, feel free to make suggestions, report an issue, give a compliment or just acknowledge my humble existence.
And if you are also a developer, do yourself a favor: stay away from rand()!