The Judgment Hammer (aka Judge) is Mr Game and Watch’s (G&W) Side+B attack in Super Smash Bros. Melee. The Judgment Hammer is mysterious because the attack can be one of nine. Those are judgment-1 through to judgment-9.
A Pseudo-Random Number Generator (PRNG) is used in order to decide what number judgment will come out. The PRNG is updated every frame and is affected by both the user’s and opponent’s actions.
I was interested in finding out the probability and chance of each Judgment Hammer attack. Here is my write up of the experiment along with everything else I found. My main aim was to test if the well-known judgment hammer rules were true.
In this post I will refer to the number as the judgment. Hammer refers to the attack as a whole.
I used a script to repeatedly press Side+B with Mr Game and Watch in training mode. The script records every judgment in the order that it occurred. I ran the script for a short amount of time for NTSC version 1.02, this resulted in 3,285 hammers. I ran the script for 24-hours with NTSC version 1.00 and this led to a massive 79,970 hammers.
I purposely ran high and low tests to see if there would be any significant difference in the probability or spread of each judgment.
The Judgment Hammer data is arranged in a text file consisting of one line for each hammer. Here are the data-sets in text file format:
Feel free to analyse this data in any way. Provide a link back to this page if you do use it.
‘Event’ is the count which increments with each hammer occurrence.This is to make sure that script errors can be accounted for. For example, if the script accidentally recorded the same hammer twice. This would look like two consecutive hammers, however, the ‘Event’ variable would reveal this.
Note for 1.02 data file: It is important to remember that the game counts from 0. So 0, in the text file is equal to judgment-1, 1 is equal to judgment-2, 8 is equal to judgment-9, and so on. The 1.00 data file has been changed so that it reflects the ‘normal’ judgment number; judgment-1 = 1.
Note for 1.00 data file: The ‘event’ variable overflows and resets after 65535 because the memory address is 16 bits. This doesn’t cause any problems. Just remember that you’ll see ‘event: 0’ after ‘event: 65535’.
The Judgment Hammer Queue
The game stores the previous two judgment numbers in memory. We can call the first address Queue-A and the second address Queue-B.
The process resembles a queue: When a new judgment comes in, the number is moved into Queue-A. The number that was previously in Queue-A moves into Queue-B, the number that was previously in Queue-B is thrown-away (technically, overwritten).
The master rule is simple: The next judgment hammer cannot be any of the values in Queue-A or Queue-B.
One or Two special Cases
When a battle is initialised, Queue-A is equal to 1 and Queue-B is equal to 0.
Remember what I said earlier about the game counting from 0?
0 = Judgment-1
1 = Judgment-2
So read the red text above; the first hammer cannot be judgment-1 or judgment-2.
But what about the second attempt?
Let’s see what happens:
[Queue-A = 1] [Queue-B = 0] <– The next judgment hammer can’t be any of these!
First hammer throw = 5
[Queue-A = 5] [Queue-B = 1] <– The next judgment hammer can’t be any of these!
Second hammer throw = 8
[Queue-A = 8] [Queue-B = 5] <– The next judgment hammer can’t be any of these!
Now we can see why judgment-2 cannot be the second hammer. The value 1 (Judgment-2) is sitting in Queue-B on the second hammer throw.
That’s all there is to it. I’ve put all of the judgment hammer rules/laws together below.
Judgment Hammer Laws
We can deduce the following rules of the Judgment Hammer.
- Judgment-1 and Judgment-2 are impossible on the first attempt.
- Judgment-2 is impossible on the second attempt.
- Two consecutive hammers of the same number are impossible.
- The next judgment cannot be equal to either of the last two judgments. The same judgment must minimally be separated by two different judgments. (X, Y, X is impossible. X, Y, Z, X is possible.)
- Apart from the above, the chance of getting each hammer is equal.
Dying resets the queue. The judgment hammer rules may only apply to a Game & Watch who does not die in-between judgment hammer attacks.
Everything is as expected. I have not performed a proper statistical analysis on the data. I’ll leave that for someone else, or I may include it in a follow up post. Let me know your results if you do analyse the data and find something that contradicts anything said here.
I’ll probably reverse-engineer and disassemble the actual code used for the Judgment Hammer mechanics, if I can fully understand it. Then I could explore how attacks influence the randomness. Possible to discover a glitch or bug to increase the occurrence of 9’s! Although that’s not very likely :-p.
I’m new to the PowerPC instruction set, which the GameCube uses, so it may take a long time or never.
I may also do something similar for Random stage select and Peach’s turnips.