So Im designing a game that is fast paced, (fps) and I would like to use "chance" in many areas of the game. This game should support 10 - 12 players Im hoping, and/or slots MAY be filled by bots. Many things rest on chance, and obviously that takes me to random numbers. Would it be efficient for a server to be running so many random calcs inbetween the action? What would be the best way to make sure it is efficient? I will be using .Net for programming. Specifically VB Thanks

Quote:

Original post by HumanoidTyphoon So Im designing a game that is fast paced, (fps) and I would like to use "chance" in many areas of the game. This game should support 10 - 12 players Im hoping, and/or slots MAY be filled by bots. Many things rest on chance, and obviously that takes me to random numbers. Would it be efficient for a server to be running so many random calcs inbetween the action?

You didn't actually say how many random calcs you're talking about.

However, can you think of an alternative? Show me a game that does not rely on random chance for anything.

When you need something to seem random or be unpredictable, you don't have that many options.

And of course, you could just test it.
Make an application that simply generates random numbers, let it run for, say, 10 million iterations, and see how long it takes. Then you can make an informed decision on what to do in your game.

Games are rarely programmed to make random numbers. Normally they use a pre-generated and agreed list, I believe (at least RTS I work with do - it helps with syncing), although they could I guess if you really wanted to have that plus a hash with the exact game time. The first is just an array look up and incrementing the index on the long but looping list, the second is the same with some form of hash. Neither are taxing. Obviously you then need some modulus to get it down to the number scale you want, but that too is very quick.

Really, so long as you aren't running hundreds of thousands per second, it should be fine, particularly given the speed of even older CPUs these days.

any method of effectively handling "chance" that cannot be predicated would be perfectly fine. I will fool around with varies ideas and do some testing to find the most efficient/pleasing method.

I haven't used random numbers on a very large scale, thats why I was asking, and I too heard that there are work arounds people use to make things more efficient. I was simply assuming they are quite processor intensive in large numbers, but my little game would not be running hundreds of thousands of random calcs a second. Perhaps up to 1000 - 2000 random calcs in a busy second ^_~

Thanks

Captain Griffen:
I think you're confused a little. Just because PRNG (Psuedo-Random Number Generator) have reproducible outcomes, doesn't mean that it's some "pre-generated and agreed list". All PRNGs that I know of use a "seed" value. If the same seed is given to the same PRNG, it will generate the same output.

I highly doubt that random number generation is a bottleneck in any game. Look up "Mersenne Twister." It's a well-regarded, fast, and highly random PRNG.

1000 random numbers per second sounds like more than any game could actually use, to me. As a quickie test, I saw how long 1000 random numbers took to generate using Python's random module. It took .091 seconds, including some minor overhead from the profiler. I believe that random uses Mersenne Twister in its implementation.

Edit: I'm sorry, but that profiling data is actually very wrong. At least .086 of the .091 seconds was all profiler stuff. 1000 random number calls took an incredibly tiny .002 seconds. I really doubt that will be a problem at all. Note that these numbers held up on further tests (eg: 100x the number of calls took 100x the time).

Thanks for the info. That is very good news =)

For multiplayer random number generation I have this system I planned out. Basically for each player on the server (forgot that's for mmo) you hold a queue of random numbers and group them with an encryption key (like groups of 10 with a single key). Send the queue to all players. Then when you need them instead of spamming out random numbers for players you just give the players the keys to them. You can use a 4 bit or 8 bit XOR key. When the games not under pressure just refill the player's random number queues. In a real game a player shoots a gun and fires 8 bullets from a position and you want those bullets to have random accuracy then the player gets the key they can unlock a set of 10 random numbers. They use the 8 numbers and throw away the last 2. This lowers the bandwidth and prevents the players from cheating by knowing the random numbers before time. Might be too complex though for a 10-12 player game. Just sending the random numbers would be better. Also if you want to use a slow random number generator it doesn't matter since you could generate and queue random numbers in a thread for use on the server.

The main thing though is that queuing random numbers works well.

Just one comment, if you want the chance of something happening to be less than 1 in 20, you get more player-satisfying results by faking the randomness because real randomness is too random.

I'll probably be smited for saying this, but you could just use the millisecond digits of the real world clock. It really depends on what the randomness is for, but for many actions that are occasionally triggered in the game by a human, a value such as [MillisecondTimer % 10] would be impossible to guess, time, or predict by humans, so it is essentially random to them.

Example: User clicks a button: if MillisecondTimer % 10 is less than 7, do something. That would cause the button to do something 70% of the time.

The concept probably wouldn't work so well for AI or other mechanical elements, because their timing has a habbit of being precise.

It's unlikely to work well at all, since the typical timer function doesn't provide millisecond resolution.