Closed thoraxe closed 1 year ago
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: https://developers.google.com/protocol-buffers/docs/style
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: https://console.redhat.com/application-services/service-registry/t/825ab4b1-e40f-40bd-aa5e-ade5511e9142
Note: after discussion 7/28
Just noticed we are using syntax = "proto2";
vs proto3
is that an intentional choice @thoraxe @RoddieKieley ? If so, can I get a rationale for the ADR? Thanks!
@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 box2d.PbBody
which has an optional UUID. We could do something like the following in the short-term:
message DualStickRawInputCommandBuffer
{
required box2d.PbVec2 pbv2Move = 1; // TODO move to Body2D.Vector
required box2d.PbVec2 pbv2Shoot = 2; // TODO move to Body2D.Vector
optional box2d.PbBody pbbShoot = 3;
}
Then you could set DualStickRawInputCommandBuffer.pbbShoot.UUID
when the client generates the shoot command. The server could then use that submitted UUID. Although I don't think the entire PbBody
is required. It could just be optional string missileUUID
.
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.
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