We need a way for Game Clients to communicate with the game engine. There are a great number of considerations here, many of which I hope we can ignore and address at a later stage. As such, I'll try to define the bounds of this work item.
The abstractions should allow for the following implementations (note, the implementations of each of these are not necessary, we simply need the abstractions to be as ambiguous and extensible enough as necessary given these potential implementations):
The implementation will create a very broad/ambiguous context, and use the Component Manager from #5 to populate enough information to allow it to respond with a client
The request context will be fed onto an internal bus allowing for one-to-many handlers
There will be a mechanism in place to allow the game engine to respond
This could be done in a similar way to OWIN whereby the request context contains a response stream, though not sure if that'll play well in all cases?
Alternatively (and perhaps preferably?), a mechanism can be put in place that allows the client to subscribe for certain events, to which the communications abstractions can subscribe to the internal bus and feed back events to the client (eventual consistency asynchrony)
Implementations must be fully tested (integration tests)
Serialization methods must be interchangeable
Components (from #5) must be retrieved for the outbound context and included in the message
Components (from #5) must be associated using the mechanisms in place to the context as part of the inbound context
At least one implementation (from the list above) is necessary, not including in-memory / mock which is assumed.
It may be worth considering extending Test Attributes or defining a new mechanism allowing us to stress/load the implementations. I don't think this should fall under Integration tests, but remain open to recourse.
Intentionally out of scope for now is any security, encryption, compression, etc. However, please bear these in mind for extensibility points!
We need a way for Game Clients to communicate with the game engine. There are a great number of considerations here, many of which I hope we can ignore and address at a later stage. As such, I'll try to define the bounds of this work item.
It may be worth considering extending Test Attributes or defining a new mechanism allowing us to stress/load the implementations. I don't think this should fall under Integration tests, but remain open to recourse.
Intentionally out of scope for now is any security, encryption, compression, etc. However, please bear these in mind for extensibility points!