Automoderated users, Autopatrolled users, Bureaucrats, Comment administrators, Confirmed users, Forum administrators, Interface administrators, Moderators, Rollbackers, Administrators
116,623
edits
m (Mass update links) |
Looney Toons (talk | contribs) m (added Category:Randomness Index using HotCat) |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1:
{{
In [[Tabletop Games]] (such as [[Dungeons
For example, [[Role
Note that almost all computer systems are incapable of producing truly "random" numbers on their own. Some have [
This works rather well with traditional computer systems, where the time will be different every time you start a program (making it very difficult for the user to predict the seed used, especially if a program re-picks one every time it calls the random number generator), but older video game consoles didn't ''know'' the time of day. So they had to use certain tricks.
Line 10:
One method commonly employed was to start a timer when the console powered up, then grab the current value from that as required. Another method was to modify the current random value by a number based on the controller input each frame. This would appear random to the user. However, through [[Emulation]], one can actually determine the algorithm in question by reverse-engineering and then provide controller input to get whatever random number you want. In tool-assisted speed running, this is known as "luck manipulation".
Some games look to other sources for a seed value. For example, the [[Game Boy Advance|GBA]] game ''[[
Whether a video game using a timer-based random number generator is more "random" than a real set of dice is debatable. In practise, so long as the program is using a fresh seed every time it starts, and the player doesn't know what that seed is ahead of time, there should be no way to consistently predicting the outcome of a decent-coded random number generator. If the seed ''is'' predictable, then the results of the random number generator are, too.
Line 16:
On the other hand, it could be argued that a sufficiently skilled player could roll dice in a manner that would guarantee certain results... It is, after all, simple physics that determines which way up they'll face. Regardless, it's very difficult to determine the outcome of a roll before making one, and so dice rolls are usually assumed to be "truly" random. In practise, which is more "random" usually boils down to how many opportunities there are to cheat. It's also commonly argued that all values are hand-picked by the [[Random Number God]] anyway, hence rendering the mechanics moot.
In any modern well written program, the "random" number is generally random. Only in the case of encryption (where massive computer power can be harnessed to discover and exploit the tiniest flaw) would there be any problem. Programmers who have the knowledge and desire to do so can ensure that any computer game has all the randomness it needs. On the other hand it is trivially easy to [[Idiot Programming
The best known (and most reviled) of them is the infamous IBM-designed RANDU, which failed even the most relaxed definition of the RNG (such as that the number it generates must be spread uniformly over the range, which they weren't). Unfortunately, due to popularity if the [[Mainframes and Minicomputers|IBM hardware]] and software that were supplied with it<ref>RANDU was a part of the FORTRAN scientific library that was bundled with IBM System/360 mainframe, ''the'' most popular, used and cloned computer of the "Big Iron" era.</ref>, it was ''the'' most widespread RNG of [[The Sixties]] and [[The Seventies]], and even now a lot of scientific results in computing are suspect because it was used to get them.
{{reflist}}
[[Category:Useful Notes]]▼
[[Category:How Video Game Specs Work]]
[[Category:
|