Page 1 of 4 123 ... LastLast
Results 1 to 10 of 35

Thread: Impossible Dump Rates

  1. #1

    Impossible Dump Rates

    Someone brought to my attention the issue of impossible dump rates by some teams in the GLB. It seems like this is an issue that has been going on for a long time and has resurfaced. Though Playrix may have done a patch at some point to deal with some syncing issues that allowed it - that hasn't fixed the problem.

    Here are my thoughts - I would like to open discussion for brainstorming on how this can be dealt with on a more permanent basis.

    There is no way teams could have such a low number of dumps without cheating - it seems like a no-brainer to program a check for that. Say the normal number of dumps for a 30 member team with perfect scores is around 1000 (seems about right) then a red flag could go up for any teams with under 800 dumps with that total score. Or they could base it on a certain percent of the score - surely there is already an algorithm that determines how many 100 point, 130 point, 135 point, etc tasks we get each week - so if they can take that info to come up with a mathematical formula of what percent of dumps would be reasonable for a certain score, they can tell pretty easily if something is way out of bounds. Not rocket science.

    But.... it doesn't even have to be that complicated.

    Say:
    R = number of racers on a team
    TS = total score
    AS = average score per player (TS/R)
    TD = total dumps per team
    AD = average dumps per player (TD/R)

    There should be a fairly consistent range of the ratio of AD/AS across the board. Teams with higher scores will logically always have higher dumps. With 10s of thousands of teams of data to look at (times the number of weeks in the year and a half that we have been doing this!!!) Playrix developers already have more than enough statistics to know what the standard deviation should be - the acceptable range of dump ratio - to know what is outside of that range.

    It sounds like before they focused on the syncing issue between devices - and while that seemed to work for a while (maybe), that will always be an issue because of things they can't control. So I believe they need to focus instead on the math.

  2. #2
    It’s already obvious just with a ‘naked eye’ peek through the top scores to see who has a massively impossible (statistically highly implausible) dump ratio. But an automated check on that would be a piece of cake to implement, so far so good.

    But let’s say that gets done.. now anybody with an outlandishly improbable dump ratio gets flagged. What happens next? Do you ban them automatically over a certain threshold of implausibility? I’d say yes - that gets rid of the very worst offenders. But then the cheats work out where the detection boundary lies, which they inevitably will, and the fair-play teams still get beaten, just by a smaller margin. And if you tighten the detection threshold up too far, anyone getting legitimately lucky that week gets banned by mistake, with no way to prove they didn’t deserve it.

    And that’s the problem with this cheat. (Without me saying too much and potentially creating more cheaters), Playrix has no possible way to see what the cheaters did, either at the time they do it or in retrospect. I can’t see how they can ever check the borderline cases, manually or otherwise. Which potentially both lets the cautious cheat escape detection and mistakenly bans the innocent.

    Bearing in mind I’ve never synced between 2 devices, either to cheat or not, I still wonder if the actual solution may lie in the sync between devices. Banning the use of more than one device would solve the problem but would be hugely unpopular, so let’s assume that’s off the table. It’s tricky discussing this without letting the cat out of the bag and potentially creating more cheats, but I wonder if forcing those switching between devices to have a wait before logging in again might help.. any thoughts?

  3. #3
    Thanks Bess! Some great thoughts! This is what I am hoping for - a good discussion on how this could work and what other things need to be considered so Playrix can come up with the best possible way to handle this.

    I believe we need an automated check against those with impossibly low dump rates. Easy to do as I described. But as far as people figuring out what the threshold is - I am not sure that is an issue for a number of reasons. 1) I think it would be incredibly hard for them to figure it out as they would not have access to the very large amount of statistics that Playrix does that would be needed to calculate the threshold. 2) Cheaters generally are not going to do the math - most cheaters are just told how to do a cheat by someone else and don't really have a clue as to the coding behind it. 3) Cheaters tend to get very greedy - they usually don't use a cheat to get a tiny advantage, they use it to get a huge advantage. 4) Most importantly - staying right under the threshold (assuming someone did figure it out) would accomplish nothing - the dump rate only affects standing in the GLB and has no effect on a regatta race. These cheaters are using it to get to the top of the GLB - and knocking the obvious cheaters off the top of that would take away the incentive to use this cheat. As I understand it, there's no benefit to using it to lower your dump rate by only a handful of dumps.

    I agree that programming a way to ban borderline cheaters isn't feasible and would punish too many innocent people, as it could happen incidentally to someone without them intending it to. And, there could be, as you said, a week where a team just gets incredibly lucky with the tasks that come up on their board. So any fix would have to be to stop those who are blatantly abusing this with way out of bounds dump rates.

    One problem I thought of here is detecting who in a team is doing this. In my suggestion in the original post, that could easily detect which teams could be using it, but say you have a co-op and only one person is in charge of dumping tasks, and that person uses this cheat to drastically lower the dump rate. The rest of the team might even be oblivious that this is going on (though that seems unlikely). So the one doing the dumping shows a small number of dumps, and the rest of the team has none. If the program to detect cheating flags this team as having impossibly low dumps, who do they ban? The players with zero dumps could have been using it and the player (the real offender) looks innocent because they actually had a handful. Do you ban the whole team? Or just knock them off the GLB?

  4. #4
    Junior Member
    Join Date
    Dec 2017
    Posts
    87
    I can honestly say that your ‘threshold’ of 800 is way off, I can say that a dump total of around 500 for a team of 30 is achievable through honest play, (the very top team did around 330 which I have to admit is hard to fathom, but i’ll stop just short of accusing them of unfair play. A solution to this issue was offered a long time ago to this problem by a co-op member and posted here. Simply put, it effectively goes as like a ticker. You don’t count the number dumped but the number generated, so every team would start with 12, as soon as a task is taken (whether high a low it doesn’t matter) the ‘ticker’ goes up to 13. This way any co-op attempting to take advantage of any double/device, sync issues etc (however you want to describe it) will simply be adding to their score. The end scores can still be calculated in a similar way but instead of having ‘total tasks dumped’ you’d have a ‘total tasks generated’ (those with the least generated would have the lowest penalty points)

  5. #5
    Quote Originally Posted by Deano4England View Post
    I can honestly say that your ‘threshold’ of 800 is way off, I can say that a dump total of around 500 for a team of 30 is achievable through honest play, (the very top team did around 330 which I have to admit is hard to fathom, but i’ll stop just short of accusing them of unfair play. A solution to this issue was offered a long time ago to this problem by a co-op member and posted here. Simply put, it effectively goes as like a ticker. You don’t count the number dumped but the number generated, so every team would start with 12, as soon as a task is taken (whether high a low it doesn’t matter) the ‘ticker’ goes up to 13. This way any co-op attempting to take advantage of any double/device, sync issues etc (however you want to describe it) will simply be adding to their score. The end scores can still be calculated in a similar way but instead of having ‘total tasks dumped’ you’d have a ‘total tasks generated’ (those with the least generated would have the lowest penalty points)
    Thanks Dean! My number of 800 was purely a random number and not meant to be a suggested threshold. That's why Playrix would have to use the data they have to come up with what is an acceptable ratio of dumps. The standard deviation should give them a very good idea, and even then, they'd have to leave a reasonable margin of error for instances where a team just gets very lucky with tasks.

    I am not sure in the scenario you suggested that the sync issue wouldn't also escape the task counter. Wouldn't the same sync problem bypass the task counter of the task taken then dumped the same way it is bypassing the dump counter, since in essence what the sync issue does is basically go back in time a few minutes/seconds to skew that player's game data by that amount of time? I'm trying to envision this. If the server lag doesn't "see" the dumped task to count it as dumped, it makes sense to me that it also wouldn't count it towards a task counter. Correct me if I am missing something here.

  6. #6
    Junior Member
    Join Date
    Dec 2017
    Posts
    87
    Quote Originally Posted by debville View Post
    Thanks Dean! My number of 800 was purely a random number and not meant to be a suggested threshold. That's why Playrix would have to use the data they have to come up with what is an acceptable ratio of dumps. The standard deviation should give them a very good idea, and even then, they'd have to leave a reasonable margin of error for instances where a team just gets very lucky with tasks.

    I am not sure in the scenario you suggested that the sync issue wouldn't also escape the task counter. Wouldn't the same sync problem bypass the task counter of the task taken then dumped the same way it is bypassing the dump counter, since in essence what the sync issue does is basically go back in time a few minutes/seconds to skew that player's game data by that amount of time? I'm trying to envision this. If the server lag doesn't "see" the dumped task to count it as dumped, it makes sense to me that it also wouldn't count it towards a task counter. Correct me if I am missing something here.
    You might be correct. I would’ve though the count (a task has been generated) would’ve been counted instantaneously at playrixs end? If it was at playrix’s end, then the delay wouldn’t matter as it would’ve already ‘ticked’ another task generated even if the player tried to ‘turn back the clock’ it would’ve already counted, or am I missing something? Lol

  7. #7
    Quote Originally Posted by Deano4England View Post
    You might be correct. I would’ve though the count (a task has been generated) would’ve been counted instantaneously at playrixs end? If it was at playrix’s end, then the delay wouldn’t matter as it would’ve already ‘ticked’ another task generated even if the player tried to ‘turn back the clock’ it would’ve already counted, or am I missing something? Lol
    I guess we have no way to know this for sure, but certainly Playrix should know and can test for it.

    My "guess" though is that data like this is stored, at least initially, in the individual player game data which is why the dump counts can be manipulated before it is synced with the server, it is the individual game data that gets erased when switching between devices. I imagine that it would be way too big of a hit on the server to have these individual bits of information automatically update the server in real time, but instead they do it in small batches to balance the load.

  8. #8
    Member Will9455Nikki's Avatar
    Join Date
    Dec 2016
    Location
    London, England
    Posts
    385
    I believe that it was said in the original post about "average score". This is a must for consideration.

    My baby town is in a GLB co-op. We started the week with 30 active racers (though one left after completing only one task). Of the 29 remaining racers, we have completed 446 of 464 tasks. We have a total of 421 dumps thus far.

    That said, we are quite adamant that NO task over 130 is dumped and we work together to complete even those horrid silk and rubber tree plant tasks. We have rules on dumping (of which I will give no trade secrets, sorry. ). And this number is very close to what we have dumped the past couple of weeks.

    My primary town, on the other hand, has 27 active racers and we have dumped just over 900 (though it is a different set of requirements for dumping).

    I agree that 500 is achievable honestly and POSSIBLY as low as 400 on a semi-consistent basis. Much lower than that and I would agree that there is potentially an issue that needs to be addressed.

  9. #9
    I don’t know what causes the “synch issue” to allow someone to avoid the “dump penalty”. Nor do I know how the game communicates with the server nor the number of servers there are for a single game platform. I am assuming there are different servers for Mac and Windows, and Android / iOS / Kindle since those platforms cannot see each other.

    There are multiple ways to approach this problem. One is “prevention”, plugging the hole. One is “detection”, figuring out who is taking advantage of the hole. And one is “correction”, penalizing those who use it to improve their ranking. I’m thinking about the “prevention” problem.

    We have some indication that a few updates ago, Playrix implemented something that detected when someone switched devices, or at least was playing on two devices at the same time and asked that they exit from one device before continuing. There isn’t a lot of information about how they detect that or if there is a “time window” that they use to decide you are on 2 devices at the same time. So this type of detection may have a flaw in that it catches most cases but not all cases.

    I believe that there is a single set of data that contains the “race data” for a particular co-op. The evidence for this is that all members of the co-op see the same task list, each other’s scores, each other’s dump counter, etc. And that this dataset is on Playrix’s servers because they use the information contained to decide the winners of the regatta and the GLB scores, all without an interaction with the player’s device at the end of the race.

    If you think about the process of “dumping a task”, or “finishing a task”, “taking a task”, or anything that affects those things that the co-op has in common, there are a number of items in the database that have to be updated before the resultant record is in a consistent state. The idea of a “synch issue” would imply that there is a way to get the data record in an intermediate state, one where some of the data is up to date and other data is older. For example, if you could convince the server that the old task was dumped and a new one needed but got it to “forget” to update the “dump counter” or other items, you could conceivably end up with a “low dump rate”.

    In database management, there is a concept of an “atomic operation”, that is, when you have to have multiple pieces of data all be updated in some sequence before the new record is “consistent”, you have to wrap these multiple database transactions with a “record lock” that prevents other processes from accessing (or updating) that record. Only when all steps of the data update are completed, that is, the new information is now in a “consistent state”, you can then “commit” the new record to the database and release the “record lock”.

    There are two problems with doing “record locks”, one is that you rarely want the activity to involve a “back and forth” with another application, in this case, the player’s game and the server. Any back and forth activity is subject to internet delays, the player’s game shutdown, etc. This would introduce an unpredictable delay time in holding the “record lock”, preventing other co-op members from doing their task activities.

    One other problem is that you have to have a mechanism to “back out of the transaction”. This is because you want to be able to cancel the update in case there is an inordinate delay in completing all the necessary steps to have the database record end in a “consistent state”. This “back out” would prevent any changes to the record and have it revert to the original state before these updates were attempted.

    So, if you do depend on multiple interactions with the player’s game, a “back and forth”, you have to utilize a “record lock” tagged with an “owner’s id” (the player) and implement a “back out” algorithm for when there is either a delay (“time out”) or when you see the same “owner’s id” attempting to start a new operation on the record (meaning they never completed the old transaction). It is this recognition of a subsequent transaction on the team co-op record by the same player that could be used to identify someone using the “2 device synch loophole”.

    Again, I have no idea how any of this is actually implemented in the game. I do have experience with server databases and what it takes to maintain “data integrity” there. Regardless of how many servers are involved in a single game platform, there is surely a single database record for this regatta information and that a “database record lock” is able to span multiple servers otherwise you could not prevent multiple players in the same co-op from trying to update the common items (e.g., task list) at the same time without causing some form of data corruption.
    Last edited by cdosr; 01-20-2018 at 09:41 PM. Reason: Typo

  10. #10
    Quote Originally Posted by Will9455Nikki View Post
    I believe that it was said in the original post about "average score". This is a must for consideration.

    My baby town is in a GLB co-op. We started the week with 30 active racers (though one left after completing only one task). Of the 29 remaining racers, we have completed 446 of 464 tasks. We have a total of 421 dumps thus far.

    That said, we are quite adamant that NO task over 130 is dumped and we work together to complete even those horrid silk and rubber tree plant tasks. We have rules on dumping (of which I will give no trade secrets, sorry. ). And this number is very close to what we have dumped the past couple of weeks.

    My primary town, on the other hand, has 27 active racers and we have dumped just over 900 (though it is a different set of requirements for dumping).

    I agree that 500 is achievable honestly and POSSIBLY as low as 400 on a semi-consistent basis. Much lower than that and I would agree that there is potentially an issue that needs to be addressed.
    Thanks! I agree there is a certain level that is achievable honestly, and that's why I said Playrix can determine what that is exactly with all the data they have. The standard deviation is a statistical reference to how far off from the average a number can be and still be considered "normal" - so say the average was 600 for a perfect score with a 30/30 team (just throwing a random number out there for this example). Obviously you can't say anyone under 600 has to be cheating, because that could easily be half of the teams! An average doesn't work. Instead, the numbers in the acceptable range form more of a bell curve, where you will have most of the numbers clustered around the middle but with some falling below and some falling above and still be acceptable statistically. With calculations, you can determine how far from that bell curve "middle" is no longer something that can happen under normal circumstances.

    A standard deviation is simply a formula that determines how far off from the average a range of numbers reasonably can be. So in the example above, say the average is 600 dumps (just a random number again) and say the standard deviation is 200 based on the calculation of all the data of teams with that same number of racers & total score, then the reasonable range would be 600 +/-200 or 400-800, so you can rightly be suspicious of any number you see that falls outside of that range, so a number of only 150 would be flagged as highly improbable.

    Of course, to simplify, I would use the dump ratio (average dumps in a co-op divided by the average score per racer in that co-op) rather than a specific number of dumps since smaller co-ops would have less dumps as would ones with lower total scores. But the acceptable range of dump ratios should be fairly consistent across the board.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •