Hacker News Reader

Comment by bob1029 | Hacker News Reader

In my experience, most of the pain boils down to synchronization of state between participants. This is also your principal vector for cheating.

If you are willing and able to make a very extreme sacrifice regarding client-server architecture, it is feasible to consolidate all state to 1 synchronous domain while serving an arbitrary number of participants.

The sacrifice is basically to build your game as a native take on the Google Stadia model. I.e. inputs are raw player events, output is a low latency A/V stream back to player.

Keep in mind you don't have to always serve an x264 stream to all clients. Depending on your objectives and type of game, you can serve an intermediate view model that instructs the client on how to draw its view using local assets and resources (textures, models, gpus, etc). This would be more like how Blazor server-side model operates.

View on HN

What you said is kind of complicated way of saying what I do.

Player client sends simple commands to the server. Server validates the command and updates game state.

The server then just simply listens for other clients to request the state of the world, at which point it sends a compete blob of data that includes everything that client can see!

The player can then interpret that data and send new commands as required.

My games are basically turn based so I don't need to poll the server constantly, just at the start of your turn and after every action.

There's a problem with this approach. If the client thinks it's in state X, and sends a command that's only valid in state X, but it turns out that the client was lagging and was actually in state Y, the server has to reconcile this discrepancy somehow.

For example, in an FPS you turn a corner, see an enemy and shoot them. But unbeknownst to the client a grenade exploded just beyond the corner killing the player before the shot got off.

Now we have to deal with the mess of the client thinking you just shot somebody while you were actually already dead. While it's true that this is "simply" a client-side issue, you'll hear endless complaints from players who, from their perspective, turned a corner and shot the enemy and then died to a grenade, but for some reason their shot didn't connect and to them it seems unfair.

Another scenario: An enemy client is approaching a corner. The server sends you their position because it estimates they'll continue moving beyond the corner. You see the enemy and shoot them. But then the enemy client's lagging input comes in and they actually stopped short of turning the corner! How do we reconcile the fact that you've seen and shot an enemy you shouldn't have been able to?

Sure, but these concerns do not apply so much to turn based games. In a turn based design all clients move in lockstep by virtue of the core game mechanics. Clients that send invalid commands will have them ignored by the server, and the client view will be updated to the current valid state when the client catches up.

Speak of the devil. I was just talking with someone about Neptune's Pride a few weeks ago and looked it up to see if it was still going. I really enjoyed that when it came out.

Have you ever written about the architecture of that and Blight anywhere?

I haven't because I really have no idea if any of it is any good. I just sort of muddled through it all.

I've been slugging through a re-write of the server from python to JavaScript because the Python code base is all out of support now and I expect Google to pull the plug on the 10 year old App Engine tools that its built on.

Reply on news.ycombinator.com