Question about

@medievu , your question was not on-topic in the Game Design and Theory forum (programming is not game design), so this thread has been moved to the For Beginners forum (a mostly programming-related forum), where you previously posted about your coding problem. If you were not welcomed before, welcome to gamedev.net. Hope somebody helps you with your problem!

Well, it happens that the computer does something you don't expect. Somewhere in the entire dice process something unexpected happens and you have to find where and how.

This activity is known as debugging.

First of all make sure your current code is copied to a safe place, so you can hack it in any way you need to, without losing the code.

To move forward with solving the problem, there are 3 paths that you walk. You'll want to do them all a bit.

The first path is reducing the thing you examine to a minimal reproducing example. Basically, make the code and the number of results smaller without losing the error. The smaller example makes less steps, which means you have likely have less work before you find the exact spot where the error is. For example here, does it need 6 dice? Is 1 enough maybe?

The second path is to output more information in what it is doing. You have the displayed dice and you have numbers on the console, but can you pinpoint which of the dice is wrong at the console? You could add colour to the dice and have the console also output the colour ("green dice is 4"). Another option is to temporarily switch to 2 digit numbers on the dice (eg first has 1-6, second 10-16, third 20-26, and so on). The console can then print "35". In that way you can find exactly which of the dice is not giving the correct number. No guarantees that it will give you useful information, but you don't know until you try it.

The third path is output of internal information. You want to know every decision that the computer does, so you can verify that it makes the correct decisions everywhere (given the above findings, it must make a wrong step somewhere there). You can do that by logging all decisions (printing each decision to the screen or writing to a file). Alternatively, you can use a debugger where you can literally step through the code one statement at a time and see all the input and output data.

In other words, look at what happens in more and more detail, until you hit a point where it makes a wrong move. When you find it, think how to change it, fix it, and try again.

Good luck digging!