Open World Players Position Matchmaking Service

Purpose

The purpose was to brainstorm on the specific of the online service used to matchmake players based on their open world position. It focuses on identifying any area that warrant further investigations that will be outlined in Axis of Investigations where different developers will take the lead on.

Area of Investigation

Topic	Description	Interrogation
Responsibilities	Define the responsibilities of the service	Better name than “Matchmaking Service” or “Open World Players’ Position Matchmaking Service” Criteria to move players between dedicated game servers Population rebalancing Consolidate players population for scaling down dedicated game server Authoritative Is the decision of the service final? Can the dedicated game server overrule the decision?
Architecture and Design	Define the architecture and the design of service Define the topology of the components	Multiple process for the “service” 1 process that execute the request for players’ migration 1 process for filtering the data for analysis 1 process for processing the data for matchmaking etc. Master Agent Workers Architecture Will We Allow Players to Change Matchmaking Service? Topology Service and dedicated game server kept on same data center Versioning Match service with game version Version of service itself
Communication Technologies	Look into the different technologies for proper and efficient communications Possibility of enormous amount of information between dedicated game server and this service Possibility of large quantity of connections between dedicated game server and this service	Protocols TCP vs. Websockets vs. RUDP vs. Others Different protocol for different use cases Serialization / Deserialization Protobuf vs. custom binary vs. others
Data Management	Look into how the data from the dedicated game server is managed / saved in the service	Historical data Grouping info of the past 5-10 minutes Storage Same process vs. redis
Implementation Technologies	Default language choice C# / .NET Core Possibility of enormous “processing” power requirement	Performance Native compilation
Implementation Strategies	Look into the different strategies / algorithms for efficient processing of data and decision making	Filter / throttle by dedicated game server No point of sending information when players are in specific situation (i.e. outpost) Service can ask dedicated game server to reduce load Service’s Data Scalability Partition Filter Share Bucket
Fault Tolerance	Look into how to make the service robust	Crash recovery Automated Self healing Kubernetes / cluster management