-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADR - Restructuring of proto messages #10
Comments
As part of this, I'm thinking we should do a little design on the data model to identify anticipated frequency updates and QoS characteristics. Then group messages around the QoS and data parameters - frequent updates, required guaranteed delivery, etc. I'll can draft up thoughts on that basic design - maybe in a spreadsheet first, but I'll get it back over here in github too Agree on reducing the complexity of the body proto and size of message |
Another thing I'd like to discuss related to this is how to break up the data across .proto files. I'm not sure the best practices we want to follow, but here is the style guide for reference: |
We could also (at some point) leverage the Service Registry to do versioning and validity/compatibility... I imported the current .proto files into there to see how they look: |
Note: after discussion 7/28
|
Just noticed we are using |
@dudash the original protos were built with proto2. we could probably upgrade to proto3 as part of this overhaul. As part of #11 I realize that we probably need some way for the client to request/suggest a UUID for a missile when the client fires. This is so the client can begin tracking its own missile as soon as the user fires, and then the server can begin to track it. The client can then dead reckon the missile between itself and the server. There is
Then you could set The only gotcha here, which is a really low probability, is a UUID collision where the client generates and requests a missile with a UUID but that UUID already exists. |
Closed by: |
ADR Context / Overview
The current proto structure was based on a previous dependency on Box2D. Almost the entirety of the space of Box2D physics is pulled in as part of the
EntityGameEventBuffer
. This is mostly unused at this point.Decision
The additional object associated with the proto should probably be dramatically reduced in scope. Instead of a Box2D object, we should just have a "physics" or "body" object that has the minimum information required at this time.
Body
Additionally, we should tell the clients a little bit more about the bodies than we already do:
Rationale
There are two primary reasons for the change:
The secondary reason would be to improve some of the capabilities of the client to display additional information about what's going on in the game.
Status
<[Proposed | Accepted | Deprecated | Superseded]
If deprecated, indicate why. If superseded, include a link to the new ADR. >
Consequences
Authors
@thoraxe
The text was updated successfully, but these errors were encountered: