The main reason I don't like the
candy is just tacked onto the reward theory is that we
just don't know how this works, so we can't really say that's how it happens.
The algorithm could have so many different ways it was implemented that we just can't know that.
For example:
- A basic table of pairs (PointGain, ConsumedItem)
- A basic table of pairs (MinPoints, RewardGrade)
- Another table of tuples (RewardGrade, DelayTimeInSeconds, {ListOfValidRewards}, MinRewardPoints, MaxRewardPoints)
- A basic table of pairs (PointCost, RewardItem)
Then Kurito-chan:
- Calculates your donation based on the first table
- Fetches the reward grade based on the donation points
- Checks if she might alter the grade with RNG (Say, roll 16+ in a 1d20)
- If grade alteration is go, adds an extra to the grade (-50%,+50%) based on pure RNG (For all programmers out there: (grade * (rngCalc() - 0.5)))
- Fetches the delay time and list of valid rewards based on the final grade
- Build the reward:
- Randomly add an item, from the list of valid rewards, to the reward-
- Check if the reward point value (points fetched from the 4th table) is above the minimum needed.
- If reward points are lacking, repeat from the first step. Only do this once.
- Apply magic formulae to the difference between MaxRewardPoints and CurrentRewardPoints to calculate how many candes to add.
- Register the reward, and return the delay time.
Of course, that's a ridiculous amount of work for such a functionality.
First of all, it's most probable that whatever we donate will only be used for calculating the reward grade, which will yield the delay time only.
Then, once the time period is over, and we click on the RECIEVE button, only then the server will build a reward based on the grade/delay time.
That would mean that, if a hypothetical grade of 6 were to be between 2k and 5k donation points, we'd get the same possible rewards no matter if we gave 2001pts in donations, or 4999pts.
Also, based on optimized algorithms for this kind of thing, the most probable way this works is:
[LIST=1][*]Calucale the reward grade in only one line of code (and two nested SQL queries):
Code:
fetchRewardGradeFromDataServer(ListOfDonationItems){
Connection = ConnectToDataServer;
QUeryResult = Connection.ExecuteSQLQueryforRewardGrade(ListOfDonationItems, RNG.getRngFactor);
Numeric grade = QueryResult.getRewardGrade;
Numeric delay = QueryResult.getDelayTime;
}
While the SQL code would look something like:
Code:
SELECT reward_grade, delay_time
FROM reward_grade_table,
(SELECT SUM(item_value) donation_value
FROM LOOP list_of_donation_items
(SELECT item_value
FROM donation_items_table
WHERE item_name = donation_item_name)
)
WHERE grade_min_value <= (donation_value + rng_factor)
AND grade_max_value >= (donation_value + rng_factor)
After that, once the time is over and we click on the recieve button,
we'd send the reward grade to the server, and it would:
- Get a random number from RNG
- Ask the Data Server for the rewards for a certain grade and a certain random index
- Return the rewards to us
Once again, such a thing could be done with a simple piece of code and an even simpler SQL query to a table of tuples
(reward_grade, random_offset, list_of_reward_items).
No, I'm not even saying that's how it works. I'm just showing that there are many possibilities we can cook up in our brains, and none of them might even be close to the real thing. As such, we can bandy around theories for how it works internally, but the facts we must present are the tabulated data we gather, and any statistical conclusion we can reach from those alone.
Anything else is just deriving some fun from trying to understand how it
might work.
This is just like my work on the flash code to check if chance time and gacha rewards were calculated pre-choice or post-choice.