I''m making a tetris-style game played as a competition between 2 people: the last player to lose is the winner. To make things fair, both sides should get the same blocks, but the blocks should not be predictable. The Problem: I need to generate Psuedo-Random numbers, and I would prefer to have them generated fairly quickly. I can start both sides with a seed based on the time the program was started, but I need a good function for the Psuedo-Random numbers. My current one isn''t random enough: return (Seed & 0x001FFFFF) * 997 + 1; Any ideas or links to random number generators? Theory of random number generation would be most helpful. ----------------------------- C++ is great, but when is B- coming out?

Why not just get one machine to generate 100% random numbers (no pseduoness) and then just send this block to the other machine and say "this is the next block"

This way, you can create pieces as random as you like, and they will be the same on both PCs.

Maybe i''m just misunderstanding the problem...

Why not just use rand()? rand returns a pseudorandom number. As long as you use the same seed value on both computers, you will get the same number for each call to rand(). If I remember right, just call srand(seedval) to set the seed number.

i just write this to point out to freshya that there is no way a computer can generate "real" random numbers. A lot of research has been done about this topic, and i must say that is not as simple as it seems.

freshya,
what if one player drops all the blocks quickly and the other one lets them fall slowly? That could take quite an array to hold the values in advance. (This game is not quite like tetris, and I''ve seen similar games to this go on for more than an hour.)

The rand() idea is nice, but I would like to know some more about random number creation, and a faster function would be nice.


-----------------------------
C++ is great, but when is B-
coming out?

- there is a plethora of random number generation data out there. Most of it is graduate math level or above. Good luck.

- I can''t imagine what you could possibly be doing in a tetris game that would require a routine faster than rand. I fear you are being lead by a newbie''s "rand is too slow" post. If you''re using the single-threaded libraries, rand is just:
return(((holdrand = holdrand * 214013L + 2531011L) >> 16) & 0x7fff);

This comes down to 5 instructions. Feel free to speed that up all you want.

- There are basically two ways to go about synchronizing your game. Either have both games give all the information to each other each game turn/tick/whatever, or communicate the seed at the beginning of the game and have each computer run its own simulation.

This latter method causes the least network traffic, which for a tetris game shouldn''t be that great. However, it can be the major bottleneck for other types of games (Starcraft lag, anyone?).

There''s a really great article that goes into this on Gamasutra from the Age of Kings people. I think they win for best title too:
http://www.gamasutra.com/features/20010322/terrano_01.htm
"1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond"

Anon: yeah I know there is no True random number generator (are there even such things as "random" numbers? ) but the rand() function is pretty damn close.

Also... how can you predict tetris blocks? If you mean that they start to form a pattern ie long, corner, square, steps, long corner square steps, etc then okay... but I''m not sure how that could happen if you used rand (it works pretty damn well for all of my applications).

BB256: yeah I see the problem now... but... with Rand, aren''t the numbers "orderly" anyway? I mean, if you printed out a list of 25000 rand() numbers (from the same seed) aren''t they always going to be the same? oh well....

That last post shows why they are called pseudo-random numbers. Every generator you can use behaves the same way: given a seed (meaning some sort of initialization) they always give you the same sequence of numbers every time you use that seed. You can call them pseudo-ramdom because they follow a "uniform distribution" (or other type of distribution, but unirform is the most common and useful), meaning that after taking a large amount of numbers they are equally distributed in the range in use. But, and that''s the important point, they are proper functions in the mathematical sense: given an input, the result is unique, not random. You can - simulate - randomness this way, but the results are - always - predictable. You can make it harder to note using, for example, the system clock to seed the generator, but that''s another issue...

Sorry, not registered

Danielillo
m.arteaga.000@recol.es

If anyone is interested in info about "random" number generation, just e-mail me. I''ll handle out some papers about the subject, and a very good and quite fast random number generator.

Danielillo
m.arteaga.000@recol.es

Actually Intel 810 chipset has a hardware random number generator based upon thermal noise from a resistor. I suppose one could argue there is no pure random numbers, but that would be ignoring all of quantum physics. Here is a link to MS CryptoAPI. Seperately my testing with the rand under Borland showed the time taken to be not quite as trivial as you would think. I have the source to the rtl and the routine doesn''t do much so I''m not sure why. I think it might have been the dynamic link to the rtl, but I haven''t spent any time tracking it down.