It depends on the results they are trying to obtain. 5% chance of something happening is different than wanting something to happen 5% of the time.
Computers can’t roll dice or flip coins so despite appearances there truly isn’t anything random in a computer program. When we used to write scripts we would use a seeded Random function to generate a “random” number. Since seeding the function with the same number would always return the same results we had to use a source that was constantly changing so the internal timer of the computer would be used to seed the function. Since the timer returned time in fractions of seconds it was very fast and a person couldn’t predict what the results would be since there were thousands of results each second.
Now with a 5% chance of something happening, each time the rng is checked it would be checking is the number 1 to 50 on a roll that can be 1 to 1000. This is the method that should be used but judging from many of the returns it doesn’t seem like it.
For something to happen 5% of the time also means it won’t happen 95% of the time. If something is going to happen 5% of the time then the computer has to keep track of all previous rolls until all 1000 rolls have happened. So on the first roll maybe it was a 46. The next rolls the number 46 would no longer be a viable return so if 46 was rolled the rng would roll again until it found a viable result. Each time a viable result was found, that result would be added to the non viable results. Obviously, it would take longer each time as the list of viable results got shorter, but it still happens very fast. I also used similar routines to shuffle a deck of cards.
Another type is also a chance that something will happen but guaranteeing it will happen if it hasn’t happened yet. But this type is flawed and misleading because it would actually happen more often than stated. In this method it counts the number of rolls that have been made and when a positive result happens the roll count is reset. So say for 5%, 1 out of 20 rolls must be positive. If the positive result hasn’t happened after 19 of 20 rolls this method guarantees that roll 20 will be positive. It’s almost feels like something like this method is being used since 5% events seem to happen much more often than 5% of the time. Also the number of total rolls required has a major impact on this method. A 50% event may only require 2 rolls to determine 50% but with only 2 rolls if something doesn’t happen on the first roll then it is going to happen on the 2nd roll. So it could happen multiple times on the first roll before it misses and goes to the 2nd roll. But if the count is 1000 rolls then it’s improbable but there could be up to 500 failures before you got the guaranteed positive roll.
I don’t reverse engineer software so couldn’t tell anything about how this game is coded or works, but somebody mentioned once that the game uses a list of pregenerated numbers for the random events. It’s possible that when a Battle is started that a list of random numbers could be generated (or lists are already made and you receive one of the lists randomly) instead of calling for a random number each time a random number is needed.