Patch: Wilder Randomness

The science of statistic is interesting, but i don't know if it is practical. We can use a debugger to get a sample from a sequence of the random numbers generated. We can then use statistic to determinate the average number, variance, minimum value, maximum value and alike variables to evaluate the random numbers generated.

Perhaps it is because i played this game a lot, but i prefer a wilder randomness instead of a controlled one based on average, variance or alike. In my opinion, it raises the replay value of the game. It is true that it can be unbalanced, but it is fair because it can favor both a good and a bad outcome. If you have a bad outcome in a specific period of time and a good outcome in another period of time, in the end you have a balanced outcome. Bad luck plus good luck is equal to average luck in the long run. In my opinion, It may be better than average luck every time.

Well, the reason why you want a balanced random number generator is because you want to ensure that every outcome is possible. If you have a situation where certain patterns of numbers never appear, or appear very infrequently, you risk locking out game content.

For example, one thing I was concerned about in randomizing the RNG table is the Auction House. The chance of getting Espers in the Auction House is very low, and the RNG depends on the movement of NPCs outside. Since there are many NPCs in Jidoor, the RNG skips over several values at once, and there is a very slight possibility that it might skip over every value where you are able to buy an esper, essentially making it impossible to get Golem and Zoneseek.

Of course, if you're just making a static mod, you can easily test whether the Espers are obtainable. It's more of a concern if you're making a randomizer where the random number generator is randomly randomized.

I kinda got lucky in my auction shuffling and it just happen to come out with an practical timeframe of seeing every auction, course I also made a point to give the espers at least a 25% chance every time. Then another slim chance later down the rotation if they still had not been sold.

Point being, if your dealing with stuff that shouldn't be impossible to obtain (such as espers from the auction house) no matter how random, or consistantly random your numbers are, you should work in a little extra chance for it to lean toward taking that route before the average player gives up. Didn't say to just hand it over, but extra chances. Other things (for instance the tail drops in FF4 which I've never seen without a level of cheating) sure, should be rare, again regardless of where your RNG goes, and doesn't really have a required second chance of hitting the perfect RNG.

I have to agree with HatZen though, if you have times where the RNG is never in your favor, and other times where it is always perfect... in the end you still come out with a respectable average in the end. Even if today just isn't your day.

I see that alot now that I think about it, some times 80% miss rate, 2 hours later ever single hit is a crit and every drop is a rare. Kinda extreme but even the RNG in real life works that way, so what chance do any of us have to create better than reality RNGs?

How about adding a randomizer to the RNG? Randomly runs a different RNG code at random?

Well, the reason why you want a balanced random number generator is because you want to ensure that every outcome is possible. If you have a situation where certain patterns of numbers never appear, or appear very infrequently, you risk locking out game content.

It can be true, but i doubt about the risk of locking out something permanently.

The patch can affect both the good and bad outcomes. If it can lock something, it can unlock something as well. Even if the outcome is bad, quantity is a important factor. You can repeat the event until you have a good outcome.

If in a sample of 100 numbers, a number is infrequently or never appears, it will not necessarily lock an outcome. As example, consider the algorithm, which calculates two outcomes by a 50% chance:

Code:

JSR get_random_number       ;get a random number between [0, 255]
CMP #$80                    ;is it higher or lower than 128?
BCS option1                 ;do something if higher or equal than 128
BRA option2                 ;do another thing if lower than 128

If there is at least one number which is lower than 128, the option 2 will be triggered. If in the sample sequence of 100 numbers the number 20 doesn't appear but the number 68 appears 50 times, the option 2 will still be triggered. To lock the option 2, all 100 numbers must be higher or equal than 128.

Technically, random numbers will be generated as long as the player plays the game. All numbers will be generated soon or later. There are only 256 random numbers in the C0/FD00 table and, from the start of the game until the end of the game, the number of generated random numbers must be astronomical.

The question is how the functions use the random numbers generated to determine a specific outcome. As example, C0/062E is a random number generator called by many functions, many of them without documentation. The same generated number will have different effects based on the function which called it. In my opinion, the functions which calls the random number generators are more important than the generated numbers. A irregular number called by a specific function can have more effect than a regular number in another function.

I suppose the scope of random generated numbers is more complex than the generated number themselves. How the game uses them is of relevance.

For example, one thing I was concerned about in randomizing the RNG table is the Auction House. The chance of getting Espers in the Auction House is very low, and the RNG depends on the movement of NPCs outside. Since there are many NPCs in Jidoor, the RNG skips over several values at once, and there is a very slight possibility that it might skip over every value where you are able to buy an esper, essentially making it impossible to get Golem and Zoneseek.

If i remember correctly, the Auction House is a event. As long I know, no event opcode reads the coordinates of another NPCs. Please, can you give more information about how the NPCs movement interfere with the Auction House?

If i understood the script, it use flags to determinate if an item/esper is available. If the item is available, its uses the BD opcode to determinate if the item will be used in the auction. It is a 50% chance to skip the item for another one. I don't see where the NPCs movement/coordinates are used.

Of course, if you're just making a static mod, you can easily test whether the Espers are obtainable. It's more of a concern if you're making a randomizer where the random number generator is randomly randomized.

I will test the Auction House when i have free time.

Many players have different tastes. They may like unpredictable games where they must adapt their strategy. Others may enjoy a more predictable and balancead game. No one is right or wrong. In the same way, this patch is more inclined to players who like unpredictable things. I suppose it is a question of personal preference.

If i remember correctly, the Auction House is a event. As long I know, no event opcode reads the coordinates of another NPCs. Please, can you give more information about how the NPCs movement interfere with the Auction House?

If i understood the script, it use flags to determinate if an item/esper is available. If the item is available, its uses the BD opcode to determinate if the item will be used in the auction. It is a 50% chance to skip the item for another one. I don't see where the NPCs movement/coordinates are used.

You are correct. The random number generator doesn't use NPCs to determine random numbers. What I'm saying is that the NPCs use the same random number generator as the Auction House to determine how they move. Thus, the NPCs in Jidoor affect the state of the RNG. For this reason, speedrunners are able to predict the items in the Auction House by looking at the NPCs in Jidoor.

The issue I was concerned about is, there are about 9 NPCs that walk around randomly in Jidoor, and they all take steps at approximately the same time. That means the RNG will get called approximately 9 times per step (more if an NPC walks into an obstacle) and will skip over many values. When players are searching for espers, they won't spend much time on the main Jidoor map... they'll probably re-enter the auction house as soon as they leave it. Thus, the state changes in the RNG are very predictable, and are likely to get trapped in a loop. If you advance the RNG 9 times every attempt and there are only 256 possible RNG states, then the shortest loop might be only 29 RNG states long. Since there's a 12.5% chance of getting an esper in the worst case scenario, if you randomize the RNG table, there's a 2% chance that the esper won't appear anywhere in that 29-state loop.

I know it sounds crazy but you actually encounter these kinds of patterns when you try to do RNG manipulation for a speedrun. Another example is the Lete River. For certain NPC RNG values, you can get only 2 battles on the river and save a lot of time. But for many of those RNG values, they're impossible or very difficult to get because the way the NPCs move, the generator will skip right over them.

I will test the Auction House when i have free time.

Don't worry about it, it was just an example of why you would want a balanced random number generator. FF6 isn't that complicated it's pretty unlikely that something like that would happen. Even if your RNG isn't perfectly random, it can't be worse than the RNG that FF6 already uses.

I'd like to use this patch, but it seems to disable in-game saving. After applying this patch to a clean rom, when you try to save in-game, it just wipes out whatever was there & doesn't save. Tried it with various emulators 'n stuff, same problem. Just letting you know in case you decide to edit it further. Thanks!

I confirm the bug. Probably, it is related to the save file checksum. I will verify it.

what do you mean with "save in-game"? savestates?

Save in-game, meaning a save point I'd imagine. .srm data - not a save-state.

The issue was the save file checksum. I removed the verification of the checksum and it solved the problem.

I updated the wiki with the updated patch: Wilder Randomness .