I've been doing large scale distributed systems for a decade, and I still feel like I'm learning especially as I retool for games.

The way that I'm trying to make this simple is by inventing a new platform for "serverless game hosting" using my programming language (Adama : http://www.adama-lang.org/ ).

My focus on board game is the ultimate in server's role on authority since board games are more transactional between players and staggered (I play this card, that card enables another play to react, that reaction enables another play to augment, etc).

I'm looking into what it could mean to escape the board-game pit, and one thing that I'm thinking about is latency. The question that I'm looking at is whether or not I can have a programming model be differentiated such that the client prediction code can be generated.

A trivial way to exploit my language is to bring edge computing into the mix such that the edge compute runs a copy of the entire game, and then ships deltas quickly which will be overwritten from the authoritative server. This will work on updates to existing data (i.e. moving position), but it will fail at creating new items unless I move unique id generate to clients (which, is less than happy for me).

For example, in Fortnite, if you toggle a lagswitch (as in, block Fortnite UDP for some time), then reconnecting to the server will return you to the same position you were at when you disconnected, assuming you were just trying to run on the ground. However, if you toggle a lagswitch in a vehicle, the servers don't want to do expensive, complicated physics server-sided, so your client becomes authoritative to your position and the sanity checks are simply making sure you're not teleporting around large chunks of the map in seconds. If you were to hack your client and give your vehicle moon gravity, the server generally wouldn't care about that.

What really surprises me is how how often I see this mistake in web development. "No, Bob, you should not increase the user's bank account based on that number passed in from the frontend React app."

1. Authoritative server 2. Client accuracy

By 'client accuracy' I mean that was happens on the client actually occured. Ie. If you shoot a player, he actually got shot.

The conundrum is that these goals conflict. They are like Heisenberg uncertainty: you can have position or momentum, but not both. You can have server-side authority, or you can have client side accuracy, or somewhere in the middle.

Just as an example, most shooters have the goal that 'if you shot him on your screen, it was a hit', even if according to server side knowledge the recipient of the shot had already moved. Otherwise when you're shooting you would have to guess where the player is going to be when you're bullet packets reach the server.

So instead, we let the client decide what a hit was. Hopefully the server has some sanity checking.

I shoot at time t, server receives the info at t+s, reporting that I shot at some trajectory at time t.

But the client can erroneously edit history. What if the client sends t-0.1s instead of t? There is no check the server can do to prevent this... I appear like a client which has 150ms of latency even though I really only have 50.

"easy" so you think veterant c++ dev that invented those concepts are dumb or lazy and it's a solved problem?

It's not easy and not solved because those are very complicated issues.

But they didn't really compensate for exploiting this to do things that were actually impossible. (ie speed hacks)

Have a watch of this.

If you play a first-person shooter with 300-400 ms ping and the game uses server side hit detection, you're not going to have much fun.

By moving to client-side detection, players hit what they "should hit" from their perspective.

At least that's how I recall it from when COD and BF moved to client-side hit detection.