[HN Gopher] Implementing secure leaderboards for my game
       ___________________________________________________________________
        
       Implementing secure leaderboards for my game
        
       Author : jsnell
       Score  : 76 points
       Date   : 2021-11-07 07:30 UTC (1 days ago)
        
 (HTM) web link (vittorioromeo.info)
 (TXT) w3m dump (vittorioromeo.info)
        
       | jaimehrubiks wrote:
       | I was super fan of the Super Hexagon Android game a bunch of
       | years ago. Excited to try this one :)
        
       | lowbloodsugar wrote:
       | The page is more ads than text, the ads appear to be
       | inappropriate / phishing schemes and even the links to the game
       | pops up ads before redirecting.
       | 
       | Avoid.
        
         | danielhlockard wrote:
         | A) use a dang ad blocker. It's 2021.
         | 
         | B) I loaded the page without an adblocker and didn't see
         | anything phish-y or inappropriate.
        
       | schemescape wrote:
       | I did something similar to this for a falling block game (for
       | PICO-8). One fun bonus of uploading replays for validation is
       | that you can let other people download and watch replays to see
       | how players achieved their top scores.
       | 
       | In my case, I whipped up a quick-and-dirty replay viewer for my
       | game that runs in the browser (no sound or textures or anything):
       | https://fbg-db.netlify.app/
       | 
       | For the record: no one ever even attempted to cheat at my game :)
        
         | nomel wrote:
         | Couldn't someone make an AI that just plays the game?
        
           | MauranKilom wrote:
           | But even in that case it might be very easy to tell the AI
           | run (i.e. a TAS) from human play. The cheater can then of
           | course go out of their way to make TAS inputs resemble human
           | inputs, at which point it's a battle of statistical tools.
        
           | shhsshs wrote:
           | Yes, though that is theoretically true of ANY game.
        
       | josephcsible wrote:
       | 2 seems easy to defeat. If you know you're going to slow down 30
       | seconds to 5 minutes, you could just send the start packet 4
       | minutes and 30 seconds in, instead of at the beginning.
       | 
       | 3 seems easy to defeat too. Just add a duplicate set of fields,
       | which default to the same values as the original ones, and have
       | the first set control the RNG and the second set control the
       | display. Then you can change the second set all you want.
        
         | SethTro wrote:
         | The start packet should contain something from the server like
         | the level seed, so you can't "start" without it.
        
         | paraknight wrote:
         | For 2, the server can send back a random number (let's call it
         | a nonce) for that attempt session. This nonce can be used to
         | seed the prng such that you couldn't have started the attempt
         | before telling the server that you're starting, only after.
         | 
         | 3 is not fully solvable I think, it's the same class of hacks
         | as x-raying. You can only make it really difficult. At the end
         | of the day, you can't control what's being rendered client-
         | side, short of cloud gaming. I have seen ML approaches to
         | detecting behaviour server-side for things that shouldn't be
         | humanly possible (like seeing through a wall) but it's an arms
         | race.
        
       | capitainenemo wrote:
       | Hedgewars, Spring RTS and 0AD also had issues with deterministic
       | lockstep and floating point. It wasn't as simple as just tweaking
       | compiler flags either, unless you could control all compilers and
       | environments which is tricky to pull off in cross-platform open
       | source.
       | 
       | Hedgewars uses fixed point math. I believe Spring uses streflop
       | now. I don't know too much about the 0AD situation.
       | 
       | https://m8y.org/hw/fp.html A chart of floating point variations.
       | In time idling in the Spring and 0AD channels I picked up similar
       | desync matrices from them.
        
       | Scramblejams wrote:
       | Fun, thanks for sharing. ProtonDB says[0] this runs great on
       | Linux so I'll give it a shot. (If your game is on Steam, runs on
       | Linux, is highly reviewed or otherwise interesting to me, and
       | costs in the single digits, I'm probably gonna buy it.)
       | 
       | [0] https://www.protondb.com/app/1358090/ Okay it's one person, a
       | year ago, but for $4.49 I'll take the risk.
       | 
       | Edit: Running it on Mint 20, works perfectly so far.
        
         | Toadtoad wrote:
         | I've only played for a couple minutes, but from my experience
         | it works perfectly on Linux.
        
       | OskarS wrote:
       | Interesting article, but one point:
       | 
       | > Sadly, the C++11 <random> library is not portable, but the
       | excellent PCG Random library is, so I used the latter.
       | 
       | Yes it is. std::random_device will not give you a deterministic
       | sequence (obviously!), but the standard PRNGs absolutely will.
       | Check, for instance, std::mt19937, which specifies exactly what
       | the 10,000th value has to be [1].
       | 
       | That's not to say that you shouldn't go with PCG. PCG is a
       | fantastic PRNG. But claiming that the <random> PRNGs are not
       | portable is just FUD.
       | 
       | [1]:
       | https://en.cppreference.com/w/cpp/numeric/random/mersenne_tw...
        
         | jepler wrote:
         | The indirectly linked stackoverflow
         | https://stackoverflow.com/questions/14840901/is-the-random-l...
         | goes into more detail: mt19937 is, but distributions
         | (particularly, based on my experience a few years ago, floating
         | point ones) are not. If you have to build your own distribution
         | functions, you may as well base them on a better PRNG than is
         | in the C++ standard.
        
           | OskarS wrote:
           | In the context of that sentence though, it doesn't make any
           | sense. PCG is a PRNG, not a library for generating
           | distributions. In fact, the PCG documentation uses the
           | distributions from <random>: [1].
           | 
           | If people want to use PCG, that's perfectly fine, it's a
           | great library. My point is, there's nothing wrong with the
           | PRNGs in <random>, they work great. Mersenne Twister is not
           | state of the art anymore, but I guarantee you that unless
           | you're doing something truly insane, neither the throughput
           | nor the statistical properties of MT is gonna be your
           | bottleneck.
           | 
           | [1]: https://www.pcg-random.org/using-pcg-cpp.html
        
       ___________________________________________________________________
       (page generated 2021-11-08 23:01 UTC)