The Devs Listen to Us

[Katish]

It's not about booleans but about how normally-working code can be inefficient on a large scale (like an MMO) and create a bottleneck.

That's the thing, this should be a simple check and shouldn't be done on another server that they query that's a spaghetti way of doing things...If the characters are objects you can relate the house object to the player object, doing it any way but than that seems very inefficient to me...I mean you can query SQL server data and have it read/ store it there but that's very inefficient for something that should be simple in practice...a lottery should be a boolean no matter how I look at it or at least baked into the server logic[so returning it is compatible rather then left unresolved]. You either win or you don't rather than take the time to query a server from...1..2..3..4..5..6..7..8..9...to how many total players, you see how inefficient that would be, of course they ran into the query stalling...(?) [That should already have been a concerning issue]. Assuming they are using IDs representing players to store information which again...they really shouldn't for something so simple. It's like if I asked you to keep picking specific socks out a plethora of cloths draws from the next door room with tons of different: socks, clothing, ties, suits, etc...[now imagine that expanded], but what should be happening is: the sock draw is already opened on the start and the person using the draw is you. (Understand the logic?) Of course big data takes forever to increment through. But, they shouldn't be querying data for something simple as a returned yes or no [true or false]. (There should be zero bottlenecking dbs, especially dbs on separate hardware that might have other information needed to be read in, for something that can resolved be relatively easily by relating objects). Normal programming would be fine because we already know the player exists and the house exists...You just make the connection, this doesn't query players but connects the action to the player or in this case the house to the player by functionality of the house thus being relatively instantaneous. <--- This is how many other games handle it. Assign function...pass character doing said function...Storing a bid might have some usage in a database but where it's just winners being randomized and bids fixed, bids do not need to be stored leaving the logic all binary in nature. I've seen games assign players an item that relates to that house indicating they have bid (This might be a better solution given if the server crashes or goes down for maintenance the bid remains...)

I work with game data and server code and big data is used when it needs to be, a good usage of an SQL database on separate hardware for example might be for messages, maybe even item information(?), save states, etc Note---> [Things that are checked once rather than constantly checked]. If you query big data continuously for the heck of it, it might freeze table information. Although, I suspect I know what reason they did it this way...and it's not a good one, the Japanese developers/businesses like their spreadsheets so I would fathom a guess that they keep that formatting as close as possible by making or loading an existing id database revolving around those spreads(Which would account for bottle-necking a return value from big data) [Which is terrifying tbh]. Some good advice from my coworkers: If I'm waiting for your answer, your answer was not worth waiting for. <--- not exactly for coding or data querying but works hilariously enough for the answer to that but yeah....I'll finish my thought here. xD