1. Use an update loop that will call your GetRandom() function a random* number of times before the first time you need it

2. Try to introduce multiple layers of randomness (i.e. a random distance at a random angle from a random point)**

3. Call GetRandom() a random number of times in between uses and only choose one random solution at a time

(and only choose it right before it is needed) instead of determining all of them at the same time using iteration

*

*the amount of times this function is called*

__cannot be dependant on the seed__but could use the current time as input to make a regular or irregular update interval or be procedurally generated by taking the timing of specific player actions as input**

*If multiple layers are impossible because you are selecting from three objects that must be ordered randomly for a total of three events, try to introduce a fourth or fifth random object to provide more variation. These new objects can be functionally the same as the already existing objects but should at least be visually different - bigger or smaller and/or a different colour.*

**l33t section (tl;dr):**

WHY? Why would anyone put themselves in this situation in the first place? It could have been accidental, or in some cases it could be desired to maintain the seed in between different play sessions. Procedurally generated levels, as seen in Minecraft, rely on using the same seed during level loading to get the same level composition. The level always reads a set number of characters at the beginning of the seed, but that means all future GetRandom() calls start at the same place each time the level is done loading. As mentioned above, there are better solutions but not everyone is able to implement them.

**n00b section (full explanation):**

WHAT IS A SEED? It is a pseudorandom string of numbers that are used to generate behaviour that appears random. Having the same seed means having the exact same set of numbers, which leads to the same results even if the designer expects them to be random. Here is an example that explains why the above method works:

THE PROBLEM

**Flipping coin simulator with original seed:**

010001101001111 = heads, tails, heads, heads, heads, tails, tails, heads, tails, tails, heads, heads, heads, heads

**Flipping coin simulation with a new seed:**

101010001101001 = tails, heads, tails, heads, tails, heads, heads, heads, tails, tails, heads, tails, heads, heads, tails

**Flipping coin simulator which loads the original seed again:**

010001101001111 = heads, tails, heads, heads, heads, tails, tails, heads, tails, tails, heads, heads, heads, heads

…now we have a pattern that does not seem random at all. If the player wrote down the order of results from the original seed then they could use that to predict the next "random" coin flip which would definitely make the game feel less random!

THE SOLUTION

We solve this problem by calling our GetRandom() function a random number of times and not printing a result

The results that are printed now appear random, even with the same seed:

**Flipping coin simulator with original seed:**

010001101001111 = heads, heads, tails, tails

**Flipping coin simulator which loads the original seed again:**

010001101001111 = heads, tails, tails, tails

Notice that you are now using a lot more of your seed if you want the same number of printed results. That's OK, seeds are very long and you can pretend that they are of infinite length.

Some people might call this solution "hacky" and it is. I adapted it from a happy coincidence that seemed to be violating my expectations, given that I was quite sure the same seed was being loaded each time I replayed the same level again.

So, while it is "hacky," it is "happy" too. And if it makes you happy and doesn't ruin anyone else's code then just do it.