In the Prediction documentation it’s noted that one can use Anticipation rather than Prediction to mask latency associated with game actions. It then links to the Netcode for GameObjects documentation for the explanation and examples. There we find there is an AnticipatedNetworkVariable struct defined specifically to help implement this functionality. Is there a similar struct available in Netcode for Entities? Alternatively, is there much difference between using a helper struct vs. simply defining two fields with suffixes like Anticipated and Authoritative, marking the Authoritative field as a GhostComponent, and then running your presentation layer off of what’s in Anticipated rather than Authoritative?
Hi devook,
Can you link me the docs you are referring to I don’t seem to be able to find them. I will check the info in them and get back to you but I’m pretty sure you would just use prediction in Netcode for Entities. Anticipation in this case gives you some of the features of the client side prediction built into Netcode for Entities, so it should be unnecessary.
Thanks,
Sam
Under Possible Mitigations here the docs suggest using client anticipation instead of prediction, and then links to a Netcode for GameObjects document on the subject. On the new page, you can click on client anticipation again to read a doc about AnticipatedNetworkVariable which may not have an equivalent in Netcode for ECS.
I don’t think prediction solves the problem here. Say I have a Predicted Ghost called InstigatorEntity. InstigatorEntity often needs to interact with other Ghost Entities in the scene that are not guaranteed to re-simulate at the same time InstigatorEntity does. Imagine InstigatorEntity modifies the [GhostField] Color of all [GhostComponent] ColorChangingComponent attached to Interpolated, non-player Ghosts around them. Those changes will immediately be clobbered by the server snapshot, resulting in no visual change on the Client side when the conditions are met to change the color. Several ticks later, when the Server simulation has caught up and those Entities have changed color, we’ll be able to see that change reflected in the client, but it would not have been Predicted, because the prediction was clobbered.
There are thousands of these ColorChangingComponents, and they move/path around my Scene, so changing all of them to Predicted isn’t really feasible. It seems like what I’d want is to Anticipate the specific field I’m modifying so that the player can see they are affecting the state of their environment without waiting for the Server simulation to validate the state change.
Thanks for providing that link.
I think in this case these should be predicted if you want those color changes to react immediately to user input (I assume its the local player somehow moving, directly or indirectly these instigator entities). You can try using a second non GhostField colour and updating that yourself then correcting it when the GhostField colour changes but that’s basically what the prediction loop is doing for you.
If you do use prediction and the performance isn’t where you need it prediction switching should help.
Thanks,
Sam