For a long time, I’ve been dissatisfied with the quality of Roblox’s pseudo-random number generation. As a result, I’ve decided to take matters into my own hands by developing a true random number generator module. This module is extremely performant, lightweight, and easy to use. Here’s an example of how it works:
local TrueRandom = require(game:GetService("ServerScriptService").TrueRandom)
local RNG = TrueRandom.new(1, 100) -- Minimum and maximum values for number generation.
print(RNG:Next()) -- Prints a number between 1 and 100.
This module works by wrapping random.org’s true randomness API in an easy-to-use package for developers. It solves the issue of pseudo-random numbers making games too predictable and less fun to play.
Entirely, the difference between Random.new and my module is that Random.new, albeit higher quality, still uses pseudo-random number generation. By contrast, my module uses atmospheric noise through the random.org API for generating random numbers.
(To be fair though I did take a small amount of inspiration from Random.new with the :Next() function).
RateLimits will hinder the use of this module for any consistent load and by using this, you’re relying on an external API for a rather commonly used algorithm: Random.new, that can be used without a single drop of bandwidth allocated on the server, this seems like a roundabout method for something that is not worth this extra resource usage.
PS: Random objects can also be further scrambled (in theory) by creating a new Random with Random.new() and using the old random to get a seed, or if you want some better results, use Random:NextNumber(min,max) a couple times, 2-8 should be okay; and add each result to a number variable, as well as count to another.
Next, simply average it with A/B (sum / count, respectively) to get the seed avg + os.clock() + tick().
After this, replace the old Random with the new Random and clear any references to the old one so it may be considered weak and garbage collected.
These are just my thoughts and criticisms, I’m awfully tired.
While it may be true that using my module may take up more bandwidth than if you were to just use Random.new, the bandwidth used is insignificantly small.
What this module is basically doing is sending a GET request to a server, and retrieving the body of a page. Both of these things combined are way too small to even be considered bandwidth usage. A single player joining your game and moving around is likely using way more bandwidth than this module will ever use.
Also, HTTP requests are only made when you create a new RNG object or when the RNG object runs out of cached numbers and generates more. Requests are not made every time you call the :Next() function.
Also Also, you can change the amount of numbers generated per request to make it that RNG objects will have to use less bandwidth if you need to generate large amounts of numbers.
Edit: And to adress the ratelimit issue; I’ve personally never experienced any issues with HTTP or ratelimiting, but I guess your mileage may vary.
Yes. I wanted to make this module similar to Random.new and very easy to use.
I really don’t see why you need true random generation. Most if not all games use the built-in ways of random generation and they work just fine. This one also takes a longer time to randomize because it sends a http request.
I’m not sure what the case for you might be, but I’ve personally been discontented by the quality of pseudorandom number generation on Roblox.
An example of this was when, a while back; I was making a Plates of Fate type game. Basically, events were chosen at random, but because of the repetitiveness of pseudorandom numbers, the same events were consistently chosen multiple times in a row. Even after I tried Random.new and math.random, it was only when I used the random.org API did the events stop being chosen multiple times over.
Again with the raitlimiting concerns -
I’ve already stated that this module uses a very insignificant amount of bandwidth (less bandwidth than a single player joining your game).
You can raise the amount of numbers generated per request, meaning that it would be extremely difficult to reach this limit (also this limit applies to developers with API Keys, not people just sending anonymous requests).
If somehow, every 3 seconds a player opens a crate, it would take around 8 hours before you would even have to submit another HTTP request.
If you had several RNG objects, each of them would only submit one HTTP request (every couple hours or so depending on your circumstances).
My point is that because of its low bandwidth usage and ease of use, this module would be an ideal choice in games that require real random numbers (such as dice or chance games that must be genuinely random to be fair).
It’s still gonna ratelimit the actual server, it does not matter if you have multiple ““objects”” sorry lua oop lovers its not actual oop, it’s still gonna be the same server sending the request and if that server gets ratelimited, all of them will fail to get a “real” number
It doesn’t generate truly random numbers, it generates pseudorandom numbers. This means it has issues such as picking the same numbers multiple times and/or picking numbers in a predictable manner.
If you don’t want to deal with HTTP requests or possible (emphasis on possible since I’ve never personally experienced it) rate-limiting, then stick with Random.new. Otherwise, if you need true randomly generated numbers; use this module.
Please at least read the the thread before replying to it.
the bigger the game, the more likely it will run into problems and rate limiting will become a big thing
also the repeating of the same number is such an easy fix and you can implement that yourself
Random.new() is good enough and it doesn’t risk rate limits
