-
Notifications
You must be signed in to change notification settings - Fork 1
Description
ADR Context / Overview
Scaling the game server is a core architecture design needed to allow us to maintain a large player base. We need to identify the rules around how scaling works, what limitations we have, and where we expect to encounter any challenges or degradation of server capabilities. There will likely be multiple server side microservices that make up all the features of the game. But for this ADR we are limited to talking about services necessary to the gameplay state and physics management of the game.
Decision
The universe is split into an infinite hexagonal grid. The physics is processed by a core server. As a core server begins to near it's threshold it will scale out (aka +1 itself). This scale action triggers allows the game servers set to rebalance ownership of portions of the hex grid. Whichever server owns the a hex tile is responsible for physics and game state updates for that hex.
All communication is brokered via a separate component called the data bus. This removes the need for client <> direct connections. Instead we have client <> data bus ... and server(1)<>data bus ... server(2)<>databus... server(n)<>databus
Rationale
Status
Proposed
Consequences
- There might be some delay in rebalancing scale activities as hex tile ownership changes
- TBD more?