Color3.random() function

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too hard to create random Color3 values in a clean way.

If Roblox is able to address this issue, it would improve my development experience because it would greatly improve my scripting flow when creating random colors.

Currently to create random colors I must type the following line: Color3.new(math.random(), math.random(), math.random())

This is repetitive and makes things much harder to read when you have lots of code.
I propose that something along the lines of Color3.random([minHue], [maxHue], [minSat], [maxSat], [minVal], [maxVal]) be implemented. This allows full control of the appearance of output colors and makes things much quicker since you now only need to type Color3.random() to create a random color.

This greatly reduces clutter in code that uses random colors and makes things much more readable especially because it’s much less repetitive and isn’t as easily confused with other similar lines.

Example uses:

-- Black and white noise
Color3.random(0, 0, 0, 0, 0, 1) -- 0-0 hue, 0-0 saturation (bw), 0-1 value
-- Fully saturated noise
Color3.random(0, 1, 1, 1, 0, 1)
-- Random shade of green
Color3.random(0.43, 0.43, 1, 1, 0, 1)
14 Likes
#2

There are so many different things you might want to do that I don’t think a built-in random method would actually be that helpful.

Take the following examples:

  • Generate a color between violet and orange excluding green. (Not possible because min/max doesn’t take into account the continuity of hue).
  • Generate the same sequence of colors multiple times. (Not possible because there’s no way to set the seed of the generator/the random object used to generate the color).

For that reason, it would make more sense to write a helper function that suits your own needs. A basic implementation might be as follows:

local rand = Random.new()

local function randomColor()
    return Color3.new(rand:NextNumber(), rand:NextNumber(),
        rand:NextNumber())
end
16 Likes
#3

Random colors are an anti-pattern, if you’re using random colors in this sort of way then you’re probably doing something wrong, or at the very least suboptimally.

For end user facing stuff, color palette matters. You should be carefully choosing a palette of “random” colors to choose from ahead of time so that the colors actually match the aesthetic of your game

For debug info, you don’t want random colors either. You want well distributed colors so that you can differentiate whatever it is you’re tagging with the colors as easily as possible.

6 Likes
#4

This is usually true however I actually use random colors more than you might expect. A basic example would be the static/noise I included in this module here: [POC] Optimized Frame Image Rendering With UIGradients

But I do use random colors in more complex ways. While random colors are generally not useful I do use them quite a bit in specific situations. Ones where I need to make sure contrast, brightness, etc are working as I intend them to, such as above, or when I need to make things look/feel more interesting in a subtle way.

Additionally I specifically suggested the API in my post since it allows for more control of what random colors you get. I actually use mono colored noise in most of my graphics although it’s so subtle sometimes that you wouldn’t know. If you were to compare two of my images, one without noise, the other with, you’d see the difference and you’d probably say that the one with noise looks more interesting even though the texture is so subtle.

So I do think random colors can be used well for sure. For example, if you wanted to add variation to terrain colors in a voxel based game. I can think of a lot of places I’ve used randomness like this for colors in Roblox and I think it is worth it’s own function.

For example, here’s my logo with and without noise (The hues don’t match perfectly but it’s pretty close)
image
image

These are much less subtle compared to some of my images but comparing the top vs the bottom image you can really see the difference.

2 Likes
#5

Noise is still not a good use case for this because all it offers is static, which is about the worst kind of noise you can use in most scenarios.

You can already construct a color from HSV using Color3.fromHSV. Anyone with an advanced use case is probably just going to need to drop back to using that for more control, so I feel all that this API would do is encourage people using random colors where they shouldn’t.

#6

I agree this is still needed in 2025

#7

I actually no longer agree with my own request. The response from @woot3 is pretty much exactly the code that I use in these cases where I occasionally need random colors nowadays, I think a dedicated function on Color3 would actually kind of just be overkill.

There are good arguments for functions that might feel ‘bloaty’ like math.lerp and math.map due to their general usefulness and lack of state, but randomness inherently has some state to it and so its nicer to use a random object because it keeps the state of the randomness isolated, predictable, and user defined. In this case I think a dedicated constructor on Color3 is sort of too niche and specific to make too much sense.

Rather, if I were to request that any function or method be added for random colors it would be through the Random object such as through a Random:NextColor3() or Random:NextColor() method which simply generates a ramdom color.

Something like the following is easy to place into a module somewhere:

local defaultRandom = Random.new()

local function randomColor(random: Random?)
    local rng = random or defaultRandom
    return Color3.new(rng:NextNumber(), rng:NextNumber(), rng:NextNumber())
end

Adapting this to HSV is really easy too, there is, in my opinion, little usefulness in a dedicated function because random colors are relatively niche and can easily have code written for them for the wide potential of different ways of producing random colors that might be needed. A Color3.random would have to fall into some particular niche, when in reality there are lots of ways that games might want to randomly generate colors, and no obvious general case that is useful for them all.

With Rojo & Luau LSP autocompletes for modules are also pretty key to my workflow when working on any Roblox project, which is notable here because its what makes simple utility modules that have single functions a lot more reasonable to type out and organize in my project structure.

Or in short, due to modern tools and further complexities and alternative use cases for randomness I had not considered at the time of making this request, I think that dedicated color random probably isn’t worth implementing.

2 Likes
#8

If you want to use it across multiple scripts I would just make this a module function so you could use it anywhere you want!