[Transparency request] Publish the RNG engine of the lottery system

As an FFXIV player who's based out of an Oceana server (the most heavily populated one) , I can assure you there were mass amounts of players both FC and personal, who had not even questioned that they would not get their plot. Nearly all of us were single entry on our plot, as multiple were not necessary. I 100% think we deserve more explanation. The entirety of Shirogane, both personal and FC wards, has a total of 19 plots that were won, subdivisions included. How is that a story of RNG, or "fairness between entrants", when no other entrants existed?

/blurb

Posting simply because I think there's more validity in the OP than has been expressed by replies.

Quote:

---

Originally Posted by Iscah

If there are five entries and one "zero ticket" (regardless of why it exists) and the lottery is perfectly fair, the "six" tickets all have a one-in-six equal chance of winning.

The fact that in this circumstance the zero can win does not make it a "scam", it makes it a fair contest with a chance that the contest will not have a winner (regardless of the reason for that chance existing, though a big seems far more likely than a deliberate inclusion).

Regardless of this chance of failure, in the circumstance that someone does win the lottery, the lottery was fair between those entrants.

---

Just chipping in because I think you're misunderstanding the poster's request: most "random number generators" on computers are actually pseudo-random. If you go on random.org, which is a pretty common website for drawing randomised results, you can see a blurb about pseudo-randomness on the main page. In some games, this pseudorandomness can be exploited to give you a result you want. An example is RNG manipulation in Pokemon where you use it to get shinies or whatever else you want way more quickly than by pure chance. The mechanics behind pseudorandomness is pretty entrenched in deep mathematics that isn't really suitable for an MMO forum, but basically, what the poster is concerned about is that the method FFXIV use can also be exploited.

Quote:

---

Originally Posted by Timpeni

but basically, what the poster is concerned about is that the method FFXIV use can also be exploited.

---

If that's the concern, then surely having them publicly release the method would be the quickest way for people to learn how to exploit it?

The number 1 should be 100%.

Quote:

---

Originally Posted by MilkieTea

Am I to understand that it is your belief that this bug occurs ONLY to bidders who are the only bidder on a plot, or FC members who all bid on the same plot and are alone in their bid?

Because if so, have I got news for you, buddy

---

Tell me the news then.

Quote:

---

Originally Posted by Iscah

If that's the concern, then surely having them publicly release the method would be the quickest way for people to learn how to exploit it?

---

Even if they publish the RNG code itself, the fault could lie elsewhere. Heck, it could be in code seemingly entirely unrelated to the lottery.

I'm going to pose a hypothetical here; I have no idea if this is what actually happened -- probably not, since it's a stab in the dark -- but it's the type of thing I saw happen more than a few times when I still worked in the games industry. And I suspect that whatever went wrong in the lottery, while probably different in details, was pretty dang similar in terms of failure of process at the very least.

So, let's say you're a developer at SQEX, working on a housing lottery system. You've got it all coded so that people can bid on a house, put down the placeholder money, and then it will pick one of those bidders. Yay!

"But wait," says a co-worker. "What if someone bids on a house and then cancels their account, or moves to another server? If someone who was no longer there to have the house was a lottery winner, people would be out with pitchforks and torches!"

"Oh," you say, "that's true; we'd really better filter the list to remove any invalid bidders when we do the drawing!"

So you look at the codebase and spot some other code calling a utility function like, for instance,

Code:

---

/**
 * Checks if a character lives on a specific world and is currently valid.
 */
static bool PlayerUtilityLibrary::CheckIsValidCharacterWorld(uint64 CharacterID, Servers::WorldGUID World)
{
        // Code stuff
}

---

Great, that looks like just what you need!

So you change the lottery code such that before it draws a winner, it runs through the list of folks bidding and calls this function.

Now it's time to test: you and four other developers log into the test server and head to a house to all bid on it. It says there are five bids. You then have one of the developers log off and delete that test account. You run the lottery, everyone standing there to watch for the results... and it awards the house to someone, saying there were four bids. Great! It filtered to ensure only valid bids. Everything works. You run the lottery a few more times, and it all looks good!

So the lottery code gets checked in and signed off on, checked off the to-do list, and eventually compiled into the patch that's shipped.

But unbeknownst to you, that "CheckIsValidCharacterWorld" function was made specifically to check for things like /tell and social functions (and not documented as such), and thus the definition of 'valid' it operates on actually includes "character must be online". It might not even have been clear in the code of that function; that one might've called some other function that called some other function that said "the character must be online to be valid". So even if you looked in the code of the "CheckIsValidCharacterWorld" function, it might've still looked like exactly what you need.

And, of course, since no one thought someone being online or offline would be relevant to your lottery code, no one thought to check what happened if bidders were offline when it ran; all those test accounts were standing right by the placard during the test to make sure whoever won can then immediately check they can claim the plot. (Just like no one probably would think to check any number of other things like "what if the person was in an instanced duty when the lottery ran" or "what if the player was in the login queue when the lottery ran" or whatever. It's working off of a character record, not a connection session record, after all!)

So the code goes live and everyone bids and it's great. And then the lottery runs, and -- just as you coded it to -- filters to remove 'invalid' players. You just didn't realize that 'invalid' included 'offline' -- so anyone not online when the lottery runs has their bid removed as invalid. Suddenly, huge numbers of houses show as having 0 bids (because no bidder happened to be online when the lottery ran), and people are confused and angry and upset, and you're left to dig frantically through the code to figure out what went wrong.

Thus the RNG code could be perfectly flawless, but the system still breaks badly. And to even demonstrate where the issue was, you'd have to publish not just the RNG code, but the overall lottery code, then the hypothetical CheckIsValidCharacterWorld code and whatever that code called -- like GetCharacterPlayerAccount, GetAccountSubscriptionStatus, GetCharacterWorldState, and whatever other hypothetical functions were called.

Again, this probably isn't what actually specifically happened, but this type of thing happens startlingly often with large and/or long-lived codebases. It's especially true because many software companies take a QA approach -- "take these steps to see if this feature works" (like "go bid on a house with five test accounts, delete one account, then see if the lottery picks from only four accounts and successfully awards to one of them") -- versus a really formal test engineering approach (where you have a comprehensive test plan that tests whether entirely unrelated factors might influence a given bit of functionality).

Ironically, stuff like that is a lot less likely at a "small indie developer", because you probably have 14 people and a more reasonably-sized codebase; there's a decent chance you're familiar with every part of the code, and if you aren't 100% certain on what a part of that codebase does (like "does CheckIsValidCharacterWorld actually do the thing I want"), you can usually just shout across the room to ask the person who wrote it.

The tl;dr form of this near-essay-length post: the failure could be in something entirely different than the actual RNG portion, and based on my own past game industry experience, there's a fairly reasonable chance it was. So even if they did publish the RNG code, that wouldn't do anything to show where the issue was.

I just like to think they coded it to 0-X exclusive instead of 1-X inclusive. Easy mistake.

I think you some of you are getting way too technical and some of the posts are convoluted when they need not be. A lot of people make great points, but regardless of what they did, the RNG code is created by a person, and they inputted 0 as one of the possible choices for output. I have coded in Python and Mathematica before, and if you import random, and then you list the parameters, e.g. list=1,2,3,4,5... It is pretty easy to see, that when they listed their parameters for the housing lottery system, they included 0 (zero) in the list of possible choices that could be rolled. If they did in fact did put zero into their list, as in: listhousing or list1 (whatever you want to call it) = 0,1,2,3,4,5..., when as stated earlier, it should have been list1=1,2,3,4,5...

If what I stated is correct, then in all fairness, they should roll back EVERYONE's bids, because if 0 (zero) was counted as a possible RNG choice, then EVERY roll is invalidated and needs to be done again. I know it sucks for some people, but in all fairness, if zero (0) was included, then redoing it is the most fair solution.

Quote:

---

Originally Posted by Iscah

If there are five entries and one "zero ticket" (regardless of why it exists) and the lottery is perfectly fair, the "six" tickets all have a one-in-six equal chance of winning.

The fact that in this circumstance the zero can win does not make it a "scam", it makes it a fair contest with a chance that the contest will not have a winner (regardless of the reason for that chance existing, though a big seems far more likely than a deliberate inclusion).

Regardless of this chance of failure, in the circumstance that someone does win the lottery, the lottery was fair between those entrants.

---

The lottery was not fair and was rigged.
Assuming there are 4 bidders, each one should have 25% chance of winning.

So when the lottery system rolls from 0 to 100 a 24, the first ticket should have won. However, because there was a 5th "ghost" person, there is now 20% chance of winning for each person.
That means now the winning range of the first ticket is reduced from being 0 to 25 to being 0 to 20.

Henceforth, with a roll at 24, where the first ticket should have won, now the 2nd ticket has won instead.

This is a scam and this is not fair, period.

Quote:

---

Originally Posted by Packetdancer

... snip ...

---

Very interesting insight. I indeed didn't think about those parameters being taken into account!

Hope they will share their investigation with us and allow transparency about this matter.