It seems more likely to me that they just run the PRNG before the spinning block animation begins, no? Or maybe time isn't a factor in their seed, just game state?
This was my guess, that the 'roll' occured earlier in the sequence and by the time the dice showed up it was set in stone.
There was a very interesting hack in World of Warcraft where the server would not show you the stats on an item unless there was one currently "on" the server, and after a server reboot (every tuesday!) if you were one of the first guilds on, you could step into an dungeon instance and check stats on the rare loot you wanted (warglaives were the big deal as I recall) and if you didn't see it, the boss hadn't spawned with them. So you step out, reset your view of instances and step back in, check, rinse and repeat until they show up. Then you go through and collect your prize at the end. Blizzard patched the loophole once it was discovered but for me the interesting thing was that the loot spawned right at instance creation time, not the time the boss 'died'.
I imagine that was for the benefit of GMs (in-game customer support). Occasionally they'd be responsible for spawning loot for guilds who had just spent some hours fighting to and killing a boss, only to have the server crash afterwards and wipe out their rewards. By making the loot table a property of the instance, and attaching the last instance a player was part of to their character, the GM can just do a lookup to see what items were missing after the server reboot and hand them out. The only thing they have to take the players' word for is that the kill happened, rather than whether or not some ultra-rare reward was part of the missing loot.
Wheter you run it before or after doesn't matter. If the internal PRNG state didn't change (through another roll) the same seed is being used and has the same number of random() calls, so random() returns the same sequence!
Maybe they save the PRNG seed specifically to prevent this particular form of "cheating" (loading a saved game continuously trying to get a difference result?) It's better than the "you can only restore from the beginning of the level" alternative, anyway.
It's a bit of a stretch to believe that the Nintendo 64 developers on boxed cartridge software foresaw a day when someone would try to "cheat" using an emulator and specifically coded against it. You can't use save states like this to play a live game on the original system.
If there was a way to skillfully roll the dice, it would give a massive advantage to dice-practicers (in this particular game).
The OP really objects to the illusion of agency. If his random number were generated seeded by the number of microseconds since the dice roll animation began, he would have no complaints. Even though the dice roll is just as random one way or the other.
More likely they just created a RNG with a seed at the beginning of the game and then use the generated set later on so that the N64 doesn't have to waste resources (albeit a small amount) generating a random number mid-game. I imagine every little bit of CPU power saved adds up with the N64.
Not necessarily. If it simply sets the random seed once as the program starts, then saving the state of the game, and reloading it repeatedly will give the same result from rand(), because the seed hasn't changed and you are rewinding/repeating time.
If I flip a coin in a deterministic universe, it's still "random" (air flow, force exerted, etc), but if I "rewind time" and play it back, I'd get the same result.
You missed the point. Part of the game is that you thought you could control the number with your timing of exactly when you hit the button (it shows the "die" spinning above your head, you hit a button to jump and hit the die, at which point it stops spinning).
Yeah but why should that matter? If you hit it at a random time and it should be random, then why does it matter if the random number is generated at that instant or before? It's all still random in the user's eyes.
Because it's not random in the user's eyes. We thought the number was totally based on our input; we would try so very hard to perfect our timing to get the numbers that we wanted.
So? He was the intended user when a younger version of himself played it on the actual console. Many players thought that their timing alone controlled the value. The author has simply used an emulator to show that that is false.
Well, the problem is, that's different to real dice. And subtlely different to the expectation of how it should work. If you throw a die, you could, with enough fine motor control, throw to get the number you desired. Or, in roulette, you could pick the right number the ball will land in by observing the speed with which the ball is spinning. In theory. Is there a practical difference? No. But, it still feels wrong that the game would work in a way that completely ignores the action of the player.
Perhaps some people thought there was actually a non-random element, whereby hitting the button at a specific timing could cause a specific number to turn up.
It's like Press Your Luck: you could theoretically determine what value you get, but human reflexes are too slow to hit the value you want consistently, so you might as well play randomly for fun.
> They took the time to display a spinning dice over Mario's head, so why couldn't they just add the random function that determines the dice roll AFTER the player head-butts the dice, and not before? Even though the dice roll IS random, the player cannot alter their fate while watching the dice spin above their head.
This reveals a misunderstanding of how the PRNG would work. Whether you compute the random number before or after is irrelevant, provided that nothing else asks the PRNG for output during that time.
What would change it is reseeding the PRNG based on the amount of time waited, or using the PRNG in displaying the animation. However, while this guarantees a causal effect, it doesn't really change the randomness in any measurable way (that is, to anybody playing the game as intended, not through an emulator) and so it would have no effect. So the designers made the right choice in my eyes.
> If I flip a coin in a deterministic universe, it's still "random" (air flow, force exerted, etc), but if I "rewind time" and play it back, I'd get the same result.
I view "rewind and play back" essentially as replaying the exact way the quantum states collapsed. Although quantum mechanics are probabilistic (whether you believe in multiverses, Copenhaguen, etc.), the key here is that you're replaying the same probabilistic results and not "throwing the dies" again.
Or maybe I misunderstood your point?
I'd also argue that this is Mario Party using a PRNG. QM do not apply!
I don't think there are very many quantum effects working on coin tosses. It seems (to my relatively inexperienced eyes) like something handled pretty adequately by classical mechanics.
Most games shape their random events because true random is actually really frustrating to play.. but what it appears to me here is that there's a PRNG here that was seeded before he save-stated.. and since he didn't do anything that called the PRNG before that head-butt, the number didn't changed.
This sort of behavior is famous in Fire Emblem.. but there's also a trick due to how some of the games do pathfinding. Some of the games, if the game can't decide which path to take, calls the PRNG to decide. Since you've induced a call to the PRNG, you can redo a specific battle with a different random number generation.
If you were playing on a console, the fact that the number is chosen ahead of time wouldn't make a difference. The only way you can be disappointed by this predetermination is if you are trying to game the system with an emulator. This doesn't seem like some cardinal sin to me considering you'd never know if you played the game the way the game was meant to be played.
As long as the dice roll is a) statistically fair with equal odds for each possible outcome and b) cannot be determined by the player in advance, it doesn't matter when the dice value is computed. That way, the value can be computed in the background, and there isn't any lag when the player hits the die.
Admittingly, since it is Mario Party, the dice definitely aren't fair.
Coincidently, for many Nintendo games, there's usually a way to control randomness by deliberately seeding the RNG in a certain way. (Pokemon in particular has many RNG/memory manipulation tricks).
One my favorite RPGs, Golden Sun, has an RNG flaw that if you perform an exact sequence of attacks in a certain order, you will ALWAYS get a rare item drop.
If you all aren't familiar with Mario Party, here's what they're talking about: for a number of applications like turn order and movement distance, a Mario-style block that looks like a rolling die appears over your character's head. When you jump and hit the block, it settles on a single number. Apparently, you get the same number regardless of how long you wait to jump. The issue here isn't that the PRNG is reseeded or anything, it's that the appearance of player autonomy is an illusion.
I see a couple of misunderstandings in the comments here.
First: the PRNG state is not stored in the game's save file. It's in a "save state", which is an emulation term for an image of the system's RAM etc., which is a far cry from how the games work on a physical console.
That leads to my next point: if you're seeding the PRNG with the current time every time you need a random number, then you're doing it wrong.
Agreed. This seems to me to be all very simple: Nintendo is using a straightforward pseudorandom number generator. At time t, it has an internal seed. If the guy saves the emulator state then, of course that seed is saved along with everything else. When he restores it, it's still that seed -- why would he expect anything else?
Nintendo did this because it's the correct behavior if you want the die to be statistically random in normal play, that is, not hacked up for cheating in a non-Nintendo game emulator. So what this guy is really complaining about is that he cannot influence or bias the roll of the die by hitting the die when it's displaying a certain number on-screen. He somehow thinks this is "determinism".
I assumed game developers did this for pretty much everything that requires randomness if for no other reason than ease of debugging.
I've written similar non-game code where you generate a random seed and every other random value is derived from that. Makes it much easier to reproduce "random" issues because you just need the build + the seed, not luck.
I am mildly worried by someone who is obviously an experienced and competent coder not understanding how pseudorandom number generators work. As they have an initial state which is often determined at program or level load time saving the state of the game means the state of the srand[1] or the 64's equivalent is stored.
You have missed the point. The point was that it is calculated by an algorithm (presumably a RNG), not by the user. Part of the game is that you thought you could affect the value by timing when you hit jump.
I believe that was fixed in later Mario Party games: the animation was changed to move so quick that the player has no reason to assume they could affect the outcome.
I just played this game two nights ago, and somebody mentioned that it was predetermined. I instantly started thinking of how to figure out if that was true or not. Thanks to the author!
Reminds me of something I witnessed using emulators, you could save the game state at any time, and whatever your actions, the computer would score the same sequence of shoots and/or goals (it was NBA JAM).
Considering that Mario Kart has the rubber-banding effect to give less skilled players a chance, it doesn't seem unreasonable to assume that all their other multiplayer games have similar mechanisms to make the game fair for everyone.
This article is pretty dim, for all the reasons people said. But also - the guy is trying to rewind time on a dice roll. And Nintendo is the one cheating _him_?
could you tell me what web browser & version you were using when this bug happened? sorry this happened, the platform I am developing is still in beta.
This is Opera 12.02. I didn't mention it because it's mostly not relevant (Opera ditching their rendering engine and all). The issue is that the site seems to rely on JavaScript to render anything at all. At least throw the body in a noscript tag or something.
One thing a lot of the posters here complaining about "that's not how PRNGs work!" are missing is that for many traditional NES games, that is how PRNGs work: the game is entirely deterministic and based exclusively on user input, to the extent that exact timings of button presses can be used on real hardware to manipulate luck and get the result you want.
The sub-sub-genre of luck manipulating tool assisted speedruns are all about this, for example: http://tasvideos.org/1596M.html
Wow this is a little disappointing to me. I always thought I was affecting the die by timing my jump (so did all my friends). I understand it's random, but wouldn't a more accurate animation be of a motionless die until you hit it? Then all players would know their jump has no affect on the number rolled.
See, this is a very important topic for me because as a child, I'd sit there and watch the dice and look for patterns and try to get the number I wanted by some kind of luck and timing, heh.
I think the author is missing the point. The point of games is to be fun. And games are made through constant iteration. I'm sure they had the completely random number going and then someone said hey, these poor kids never roll the right numbers, or don't roll them enough, lets make their odds a bit better.
This falls under the same 'PvP' randomness of Mario Kart 64 giving 8th place lightning bolts and stars. These games leverage perceived randomness as an equalizer.
60 comments
[ 3.0 ms ] story [ 87.0 ms ] threadThere was a very interesting hack in World of Warcraft where the server would not show you the stats on an item unless there was one currently "on" the server, and after a server reboot (every tuesday!) if you were one of the first guilds on, you could step into an dungeon instance and check stats on the rare loot you wanted (warglaives were the big deal as I recall) and if you didn't see it, the boss hadn't spawned with them. So you step out, reset your view of instances and step back in, check, rinse and repeat until they show up. Then you go through and collect your prize at the end. Blizzard patched the loophole once it was discovered but for me the interesting thing was that the loot spawned right at instance creation time, not the time the boss 'died'.
If there was a way to skillfully roll the dice, it would give a massive advantage to dice-practicers (in this particular game).
The OP really objects to the illusion of agency. If his random number were generated seeded by the number of microseconds since the dice roll animation began, he would have no complaints. Even though the dice roll is just as random one way or the other.
If I flip a coin in a deterministic universe, it's still "random" (air flow, force exerted, etc), but if I "rewind time" and play it back, I'd get the same result.
http://www.newscientist.com/article/mg21428644.500-roulette-...
Unless you're Michael Larson, of course.
A agree, from a game design standpoint, it doesn't make much sense to make it like slots; but that's the way it appears to the user.
> They took the time to display a spinning dice over Mario's head, so why couldn't they just add the random function that determines the dice roll AFTER the player head-butts the dice, and not before? Even though the dice roll IS random, the player cannot alter their fate while watching the dice spin above their head.
This reveals a misunderstanding of how the PRNG would work. Whether you compute the random number before or after is irrelevant, provided that nothing else asks the PRNG for output during that time.
What would change it is reseeding the PRNG based on the amount of time waited, or using the PRNG in displaying the animation. However, while this guarantees a causal effect, it doesn't really change the randomness in any measurable way (that is, to anybody playing the game as intended, not through an emulator) and so it would have no effect. So the designers made the right choice in my eyes.
The argument by the author is that the game implies that this occurs.
Couldn't quantum mechanics mean this is not true?
I view "rewind and play back" essentially as replaying the exact way the quantum states collapsed. Although quantum mechanics are probabilistic (whether you believe in multiverses, Copenhaguen, etc.), the key here is that you're replaying the same probabilistic results and not "throwing the dies" again.
Or maybe I misunderstood your point?
I'd also argue that this is Mario Party using a PRNG. QM do not apply!
But since time travel is impossible then maybe it makes no sense in general to talk about.
Plus as pointed out the OP does say it was a deterministic universe (but I would have thought that is not what we are in due to QM)
This sort of behavior is famous in Fire Emblem.. but there's also a trick due to how some of the games do pathfinding. Some of the games, if the game can't decide which path to take, calls the PRNG to decide. Since you've induced a call to the PRNG, you can redo a specific battle with a different random number generation.
Admittingly, since it is Mario Party, the dice definitely aren't fair.
Coincidently, for many Nintendo games, there's usually a way to control randomness by deliberately seeding the RNG in a certain way. (Pokemon in particular has many RNG/memory manipulation tricks).
One my favorite RPGs, Golden Sun, has an RNG flaw that if you perform an exact sequence of attacks in a certain order, you will ALWAYS get a rare item drop.
http://minimaxir.com/2013/05/guaranteed-to-be-random/
First: the PRNG state is not stored in the game's save file. It's in a "save state", which is an emulation term for an image of the system's RAM etc., which is a far cry from how the games work on a physical console.
That leads to my next point: if you're seeding the PRNG with the current time every time you need a random number, then you're doing it wrong.
Nintendo did this because it's the correct behavior if you want the die to be statistically random in normal play, that is, not hacked up for cheating in a non-Nintendo game emulator. So what this guy is really complaining about is that he cannot influence or bias the roll of the die by hitting the die when it's displaying a certain number on-screen. He somehow thinks this is "determinism".
The "discovery" is that it uses a RNG at all. The player thought that it wasn't a random number at all; it was based on user input, like slots.
I understand that this would be unnecessary, but does it actually affect the desirable properties of randomness?
Edit: Oops, posted before reading other posts - this appears to be the general sentiment.
I've written similar non-game code where you generate a random seed and every other random value is derived from that. Makes it much easier to reproduce "random" issues because you just need the build + the seed, not luck.
[1] http://www.cplusplus.com/reference/cstdlib/srand/
But until I learned that it was a lot of fun, the AI possibly would have sucked without the cheat.
Too bad there's not a simple protocol to transfer hypertext across the Internet.
The sub-sub-genre of luck manipulating tool assisted speedruns are all about this, for example: http://tasvideos.org/1596M.html
http://xkcd.com/221/
Strangely familiar as well!
(sorry, couldn't resist)