58 lines
2.6 KiB
Plaintext
58 lines
2.6 KiB
Plaintext
Annotation on fields
|
|
Annotation has param to not generate callbacks eg if we want to handle that manually but still label a field as synchronized
|
|
Annotation will have a parameter that specifies a class which the corresponding field is in. Ie server field will have param pointing to client file
|
|
|
|
Callback object to handle initial sync packet
|
|
Specifically, a callback for sending the data and one for receiving the data, each for client and server
|
|
All four callback skeletons are generated for each field annotated
|
|
|
|
A fifth function is generated to attach the callbacks to a given entity, this is used to enforce it being properly attached every time
|
|
|
|
A getter and setter are each generated
|
|
The setter has logic that will distribute the new value every time it is called, alternatively a parameter on the Annotation can throttle how often the value is updated
|
|
Use engine specific functions within setter to actually send packet
|
|
Because the logic to send packet is different on server and client, will need to annotate behaviortree with either server or client annotation
|
|
Should have validation in cli that verifies the field is never manually set outside the setter
|
|
|
|
|
|
Service with map of entity to list of callbacks to synchronize
|
|
The service is generated in a folder specified by a json config
|
|
Service receives packets with its given packet category each frame
|
|
These packets contain entity ID, field id, and new value
|
|
Loops through all packets at start of frame and sets values on entities accordingly
|
|
|
|
|
|
When a scene is being synchronized, loop through every entity in the scene cross referencing the service and firing callbacks to generate packets
|
|
Callback job is to grab current value and send over net
|
|
Attribute data could theoretically change if changing things like player hair are implemented, so that should be stored as dynamic data
|
|
|
|
|
|
|
|
For non entity fields (think weather status of a region, number of players logged in, etc), the flow works mostly the same
|
|
Annotation still has a link to related client field
|
|
Callbacks still generated
|
|
When value is set, call chunk independent function to submit packet
|
|
When packets are being looped through, there's a different class of packet that has field id and value, but no entity ID
|
|
|
|
|
|
|
|
|
|
|
|
Cases to consider
|
|
A chat log
|
|
A character playing an instrument
|
|
Creating a particle
|
|
Playing a sound
|
|
Creating an effect generally (ie fire)
|
|
Creating a speech bubble over a character
|
|
Playing an animation
|
|
Writing a book on the client side
|
|
Fetching book contents from server(lazy load?)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Generally want synchronized fields as well at the ability to call a function on server and client simultaneously (ie 'create fire here') |