3 ms·

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

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.

jpgleeson 5y ago
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?
- jay_kyburz 5y ago
  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.
hypertele-Xii 5y ago
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?
- initplus 5y ago
  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.

jpgleeson 5y ago

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?

jay_kyburz 5y ago
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.

hypertele-Xii 5y ago

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?

initplus 5y ago
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.