ADR - Restructuring of proto messages

[thoraxe]

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

• Position (x,y coords)
• Angle
• Velocity
• uuid
• owner uuid (where relevant)

Additionally, we should tell the clients a little bit more about the bodies than we already do:

• maximum potential velocity (allows client to display speed as a percentage of max)
• remaining hit points (allows client to display some more information about the health of a body)

Rationale

There are two primary reasons for the change:

• Reducing the complexity of the body proto object
• Reducing the size of the entire message sent, which may have a minimal performance improving impact

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

• Reduced complexity
• Improved client experience
• Potential performance improvement

Authors

@thoraxe

[dudash]

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

[dudash]

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

[dudash]

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

[dudash]

Note: after discussion 7/28

• we will create srt-protos repo
• github actions to build
• update the client and server repos to pull in external proto repo code

[dudash]

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!

[thoraxe]

@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.

[thoraxe]

Closed by:
redhat-gamedev/srt-protobufs#7