Originally Posted by chillinfar

I understand. Due to low quantity of objets to permute (6 on PPS), that random system can place answers in common positions. The only what is possible to calculate with current data is the frequency of some results on certain timelapse. And it isn't ensure that the next answer will be the correct.

We can't know how PPS is managing this (i saw your demo decompiling main program), if is pure random or has a pattern (or mix both to make the shape that has a pattern, fooling the player as you guess). Results are the only data available to work and may be different for each player.

I'll try to see pos of gachas later. I was seeing this many times, but i never wrote this to a text file.

I agree we can't accurately know how they do this. However, we can put more weight in the more logical or common solutions for a game such as this.
The main point to remember is that the server behind this isn't made to handle your game, but a couple million JP players, sending service requests at least every couple of seconds.

That means the server needs to be able to balance a load of possibly hundreds of thousands (or even millions) of requests per second.
In such kind of architecture, you tend to try and minimize any superfluous bit of logic that is pretty much useless to you...

As such, why add some weird rotating pattern to your code, when just randomizing crap works the same?
Applying a pattern requires keeping the pattern stored somewhere (either hardcoded or in database), fetching it, mapping the input data into something that can be put through the pattern, applying the pattern, mapping the results to the required response, and only then returning the value.

Just to make a comparisson:

The simple randomizer works like this:
[LIST = 1][*]Fetch six RND decimals between 0% and 100%.[*]Apply step-ups.[*]Map the 6 results to the "Rarity Table".[*]Fetch a new RND decimal for each mapped range.[*]Fetch data from the IDed cards.[*]Build and return JSON object.[/LIST]

Against a pattern:
[LIST = 1][*]Fetch the pattern list.[*]Fetch a RND decimal to choose pattern.[*]Fetch the chosen pattern.[*]Fetch six RND decimals based on the pattern.[*]Map the 6 results to the "Reward Patterns Table".[*]Fetch a new RND decimal for each mapped range.[*]Fetch data from the IDed cards.[*]Build and return JSON object.[/LIST]

As you can see, patterning is a more complex process.
Also, all fetches and mapings that aren't for RND values imply a call to a database, which can take up to 10k times more to process that a logical process. That's 2 for RND vs 4 for Patterns. So, not only is it more complex (meaning more processing times, more RAM needed, more caching calculated, etc) it actually has twice the delay times corresponding to DB accesses.

All that for something that just having a good randomizer will do equally as good? For no apparent reason besides we wanted a pattern in there?
That's just no good for implementation times, manteinance costs, server costs, etc.