TrueRandom - A Solution to Pseudo-random Numbers

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 =, 100) -- Minimum and maximum values for number generation.

print(RNG:Next()) -- Prints a number between 1 and 100.

This module works by wrapping’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.

With all that said and done, here’s the module:

Example place:
TrueRandom Example.rbxl (30.4 KB)


Are you aware of
Does this have any benefits compared to

Entirely, the difference between and my module is that, albeit higher quality, still uses pseudo-random number generation. By contrast, my module uses atmospheric noise through the API for generating random numbers.

(To be fair though I did take a small amount of inspiration from with the :Next() function).


Was it really needed to make this an OOP module? You could have just made it return a function with min and max as arguments.


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:, 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.

Random objects can also be further scrambled (in theory) by creating a new Random with 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.

CantBeBothered [ IDoLua ]

1 Like

While it may be true that using my module may take up more bandwidth than if you were to just use, 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 and very easy to use.

1 Like

this is great and all but I honestly rather use instead of a whole module to replace it

That’s fine, but if you ever need some true random numbers, you know where to look.

1 Like

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.


doesn’t this module run the risk of rate limits

wouldn’t just be better overall

If you integrate the module into a popular simulator game, you probably would run into a ratelimit.
(taken from

1 Like

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 and math.random, it was only when I used the 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).

You can easily avoid this by checking if the next event isn’t the same as the previous event

Still wouldn’t help if you have multiple players constantly opening things like crates for example. You would hit that ratelimit eventually.

Even so, suppose you’ve cached 10,000 numbers.

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

1 Like

But my point still stands, in games that require real random numbers (dice and chance games), this module would be a good choice.

Phantom Forces doesn’t use ““real”” random numbers and its crate system works just fine. You don’t need ““real”” random numbers for it.

I doubt anyone would make a casino game in Roblox anyway.

What’s the problem with math.random?

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 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 is good enough and it doesn’t risk rate limits