4 ms·

There are lots of interesting (and challenging) topics in this area and those tend to be a great source of complexity. For instance, do we want to replicate the

There are lots of interesting (and challenging) topics in this area and those tend to be a great source of complexity. For instance, do we want to replicate the full world? Or each client will keep only partial world state? This decision will impacts literally every other aspects such as programming model, security model, game play, etc. I see a good potential for better formalization in this area. At its heart, this is literally distributed streaming system engineering with extremely wide, fluctuating variety of requirements in the name of game play first. You don't need to be 100% accurate on physics simulation but the result shouldn't diverge too much on every clients within a very limited bandwidth. You want to depict character movement as accurate as possible across every player, but their detailed status should be shared to their allies, not their opponents. Synchronization of continuous and discrete states are fundamentally different. How can we build a single, general networking model to unify those kinds of requirements without resorting to some ad hoc solution?

kllrnohj 4y ago
Honestly this is all largely a completely solved problem space. The article is just way out in left field seemingly fully oblivious to how game netcode currently works, which certainly isn't with AI prediction. Look at actual game engine docs like this one from Valve https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... or this one from Halo https://www.halowaypoint.com/news/closer-look-halo-infinite-online-experience https://www.halowaypoint.com/news/closer-look-halo-infinite-... But tldr is the only thing a client ever predicts is their own inputs, which of course can't really ever end up wrong later on. There's no other prediction happening (eg, the position of other players is not predicted) And then for anti-cheat/optimization purposes the server also only sends positions for enemies that could be visible soon, which is done by taping into the same map chunking logic that would be used for asset streaming. There's a ton of other great resources on this topic here https://github.com/ThusWroteNomad/GameNetworkingResources https://github.com/ThusWroteNomad/GameNetworkingResources But you'll find they all largely do the same basic thing. There's nuance in some of the rules and what state is replicated and what isn't (such as server side or client side ragdolls), but the general architecture tends to be the same. And without a fundamental shift in connectivity, seems pretty unlikely to change.
- summerlight 4y ago
  I had worked on a number of commercial MMO games' server and I don't necessarily agree on your opinion on "a completely solved problem space". Have you worked with your game designers and artist to find a sweet spot across latency, bandwidth, security, hit box and effect synchronization etc... just for one type of action skill? I had. It ended up with a very customized protocol which was nearly unusable on any other stuffs. It might seem simple to do such things for one or two features, but it's actually death by thousand cuts; it doesn't take that long till all those state synchronization and replication codes invade through game-play and presentation layers and all the logic and you got hundreds of them now. And I am not very sure if you had a good look through the resources that you posted... Many of them are pretty explicit on their use of own ad-hoc solutions and the trade off that had to be made, which really supports my arguments. (Yeah, I think I already have read and watched more than half of them over the last decade) And this is not surprising if you have a good theoretical ground on distributed systems which have literally hundreds of impossibility theorems and real time games usually have quite tight latency constraints.

kllrnohj 4y ago

Honestly this is all largely a completely solved problem space. The article is just way out in left field seemingly fully oblivious to how game netcode currently works, which certainly isn't with AI prediction. Look at actual game engine docs like this one from Valve https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... or this one from Halo https://www.halowaypoint.com/news/closer-look-halo-infinite-online-experience https://www.halowaypoint.com/news/closer-look-halo-infinite-... But tldr is the only thing a client ever predicts is their own inputs, which of course can't really ever end up wrong later on. There's no other prediction happening (eg, the position of other players is not predicted) And then for anti-cheat/optimization purposes the server also only sends positions for enemies that could be visible soon, which is done by taping into the same map chunking logic that would be used for asset streaming. There's a ton of other great resources on this topic here https://github.com/ThusWroteNomad/GameNetworkingResources https://github.com/ThusWroteNomad/GameNetworkingResources But you'll find they all largely do the same basic thing. There's nuance in some of the rules and what state is replicated and what isn't (such as server side or client side ragdolls), but the general architecture tends to be the same. And without a fundamental shift in connectivity, seems pretty unlikely to change.

summerlight 4y ago
I had worked on a number of commercial MMO games' server and I don't necessarily agree on your opinion on "a completely solved problem space". Have you worked with your game designers and artist to find a sweet spot across latency, bandwidth, security, hit box and effect synchronization etc... just for one type of action skill? I had. It ended up with a very customized protocol which was nearly unusable on any other stuffs. It might seem simple to do such things for one or two features, but it's actually death by thousand cuts; it doesn't take that long till all those state synchronization and replication codes invade through game-play and presentation layers and all the logic and you got hundreds of them now. And I am not very sure if you had a good look through the resources that you posted... Many of them are pretty explicit on their use of own ad-hoc solutions and the trade off that had to be made, which really supports my arguments. (Yeah, I think I already have read and watched more than half of them over the last decade) And this is not surprising if you have a good theoretical ground on distributed systems which have literally hundreds of impossibility theorems and real time games usually have quite tight latency constraints.