And as explained above, rerollCount is most likely 1 which corresponds to the T shape.
And in case of the reroll it doesn't set a to a random integer number - it sets a to rerollCount instead.
rerollCount is most likely 1 in this branch of the code 2 is the second most common and 5 is already so unlikely that this if statement can be ignored.Īnyway, if the algorithm changes its choice, then it will reroll the piece exactly once. The chance to change the choice is slightly below 1/7 = 14.3 %, and rerollCount is almost geometrically distributed according to this chance. There's a variable called rerollCount and it basically counts how often the algorithm will change its choice in a row. However, there's also some code with the purpose to reduce the likelihood of receiving the same shape twice in a row, and this part is flawed. The algorithm will stick to this choice, if a differs from the last dealt piece. At first, the algorithm rolls a random integer number between 0 and 7, and a becomes that number - except if the random number was 7, then it will chose 0 to 6 according to the total number of dealt pieces. Each shape is represented by an integer number between 0 and 6, as listed in the table above (piece ID). The final choice is noted by the variable a in this pseudo code. Go back to the "generate the piece" comment According to people trying to read the assembly code, the algorithm works roughly like this: A test involving around 10,000 pieces resulted in the following piece distributions:Īlmost every fourth dealt piece is T-shaped. Like in the original GameBoy version, some piece shapes show up more frequently than others - for different reasons though.