Seeding random without a clock

Simple, don't seed the randomizer until the user has actually entered the game. The time (in clock cycles) between when the game was turned on and when the player has finished navigating the menus should be enough to a get random seed.

well... they could have also saved the seed to re-use when you load the game again

I think its definately a combination of things like the actual user input, time between inputs, et cetera. Some consoles also "cleared" their memory to garbage on power-up so maybe they read the garbage from a couple addresses.

I think that JUST the time between boot-up and game start isn't enough.

If you look at tool-assisted speed runs, such as those at this site, you can read about how they often use controller input to manipulate the randomness in the game.

seeding with a vcount / vblank-count, on an event like when the game is started

Yeah. A lot of this was recommended when I was doing GBA dev. Rumor was a lot of "read from this period to this period in clock cycles" was used to seed random.

The time taken for first user input (or the time spent in the front end) can be a good seed due to the human-console interaction being very random.

However there can be a flaw with this method if you're not careful: if you don't debounce your button presses properly, a player can hold down the action button when booting your game and always get the same random seed - thus ensuring predictability in game (great for cheaters, bad for replayability).


A PS1 product I worked on had the awkward requirement that a random choice of intro movie was played before any user input had taken place; we thought it wouldn't be possible - until I had a 'eureka' moment:

1) Almost all platforms have some form of timer which represents some amount of time (CPU clocks, miliseconds, vsyncs etc) since the machine was powered up/(re)booted.

2) If you know when the machine itself was (re)booted, and your game ships on CD/DVD rather than cartridge, then as well as the controller buttons/sticks there's an additional human-console interaction which is almost always guaranteed to be random:
The angle the user puts the CD/DVD onto the spindle/into the tray will be subtly different every time, and so will the time it takes them to close the lid/shut the drawer - this means the time it takes the read head/laser to find the start of the first track will differ, and so the amount of time between the last reboot and the point where your code starts running is actually a decent seed [smile].



For handheld platforms with cartridge based media, battery life (and signal strength etc) sensors tend not to be very reliable or precise, sometimes to the point of only giving one of 3 distinct values, so user input based random seeds are the most practical starting point. It's worth bearing in mind that unless your game is linked/networked, there's nothing stopping you from re-seeding during gameplay itself when the input is very likely to be very random.

Seending is not that important.
This has became very apparent when I realized, just a few weeks ago, that we were not seeding our random number generator on the EL server!
Actually, we were seeding it, but on BSD (where the server is run) we are using random(); while on my machines I am using rnd();
So I was seeding it with srand(), but it should have been seeded with srandom() on the BSD machine.
Of course, in a MMO the entropy from the users it's enough, that is they do different things so the random number generator is seeded implicitly.
In a game, unless very linear, it can be seeded by the entrpy generated by the user, unless he does the same thing every single time, in the exact same order.

The Z80 CPU has a built-in memory refresh register which increments (clipped to 7-bit) after every instruction. You then use this in a function to generate your random number. I'm sure other CPUs are similar, or you could read hardware ports (current video scanline or dot clock, for example).

Spookily enough I was thinking about this very same problem on the bus the other day.

I was thinking in terms of the ZX Speccy, and I didn't think about using a timer. My solution was just to read a chunk of memory and make a table out of the values.