Add prediction guide #580
Add prediction guide #580
Conversation
|
Very cool job! |
VerinSenpai
left a comment
VerinSenpai
left a comment
There was a problem hiding this comment.
Partial review. Just some minor wording and grammar nitpicks. Its beautiful 🥺
|
Occurs to me that I reviewed this like a 500 word english essay that's due in 3 weeks. 😅 |
SlamBamActionman
left a comment
SlamBamActionman
left a comment
There was a problem hiding this comment.
Baller guide. You're the GOAT.
|
|
||
| With prediction each client runs its own game simulation of the game according to the local player's inputs and they will immediately see the results without having to wait for the server, hiding any latency. The server holds the authoritative game state, which is what all clients consider to be the "truth" in case they disagree on something. | ||
|
|
||
| During prediction the client will constantly time travel, reverting the game state repeatedly to the last known authoritative state sent by the server, and then reapplies the player's inputs, resimulating the game until the next server state comes in. This usually happens about 12 times per game tick. |
There was a problem hiding this comment.
"Time travel" is a correct description but it kinda comes in out of nowhere, and for a beginner may seem out of left field.
I think the entire line should be reworded. It explains the process but the process isn't intuitive enough on its own. What does it mean that the client is repeatedly reverting and resimulating, and why does it do it?
| ``` | ||
| Don't forget the client-side system, even if it's empty. Otherwise the client won't be able to instanciate the system class and it will remain unpredicted. | ||
|
|
||
| Avoid shared abstract components. Some ancient code is still doing this, but nowadays we just instead put the entire component into `Content.Shared`, even if some datafields are only used on the server or client. This is minimally worse for performance, but makes the code much more readable, simplifies any API methods and makes it easier to use `TryComp` and `Resolve`. |
There was a problem hiding this comment.
Good place to re-mention netSync and serverOnly here!
There was a problem hiding this comment.
Wait is serverOnly even mentioned? I think the only thing related to server-only datafields is when you imply not adding AutoNetworkedField to fields that shouldn't be networked.
There was a problem hiding this comment.
To be honest I never used serverOnly so far, so no clue. Usually most components just keep the datafield on the client, even if it's only used on the server. Probably because it's just a microoptimization.
Tayrtahn
left a comment
Tayrtahn
left a comment
There was a problem hiding this comment.
Looking great! Thanks for writing all of this up!
|
|
||
| During prediction the client will constantly time travel, reverting the game state repeatedly to the last known authoritative state sent by the server, and then reapplies the player's inputs, resimulating the game until the next server state comes in. This usually happens about 12 times per game tick. | ||
|
|
||
| Once the authoritative server state arrives at the client it will be applied to the client's simulation, overwriting and correcting any disagreements the client may have in their predicted simulation (for example someone else killed you while you tried to interact with something, but you did not know about that yet due to latency). |
There was a problem hiding this comment.
This and the previous sentence should perhaps be reworked to make it clear that the server state is applied to the client before resimulation. That might help explain the purpose of resimulation - redoing the prediction based on the new "true" state from the server. You might extend the example to say that, now that your client knows that you died before interacting, it needs to rewind back to before you died and resimulate the predicted state - but this time your character is dead, so your interaction fails.
|
|
||
| Without prediction any input from the client (like keyboard presses or mouse clicks) will be networked to the server, which then simulates the game according to all players' inputs and networks the resulting game state back to each client. The client will only see the results with a noticable delay depending on their ping, which makes the game feel unresponsive and will cause a visual delay for UI elements. | ||
|
|
||
| With prediction each client runs its own game simulation of the game according to the local player's inputs and they will immediately see the results without having to wait for the server, hiding any latency. The server holds the authoritative game state, which is what all clients consider to be the "truth" in case they disagree on something. |
There was a problem hiding this comment.
It might be worth adding something here about how the idea is to predict what the game state will be on the server by the time the player's input arrives there. In that sense, the player's game actually runs slightly ahead of the server.
5 participants
Adds a guide to prediction, along with a few code examples and gifs showcasing the results.
I tried writing down everything that needs to be known, let me know if anything is wrong or unclear.
Draft until I had a few contributors and maintainers proofreading this and give feedback.
Especially the section on ApplyingState seems like it could be explained a little better, but it's a complicated topic.
ToDo in a future PR: Update the
Basic Networking and youdoc to include sections on field deltas,NetSerializableAttributeand howEntityUidsare converted intoNetEntitiesby the source generator.