Designing a Distributed System for an Online Multiplayer Game — Requirements (Part 2)
This is part number two of the Garage series, you can access all parts at the end of this post.
In the previous part, I talked about the basics of the Garage, and now we are going to inspect the engineering and architecture in this part.
So, what do we need?
In the big picture, we need a server and a client, but in the details, we need a lot of things:
Game Client
The game client renders the graphics and communicates with the server. I choose Unity3D to develop the game client.
Game Server
The game server manages connections, data calculations, and simulations. It must be authoritative, why? because you must always consider the players as cheaters. In single-player games, cheating is not important, every cheat that a player applies to the game is not harmful to anyone, but in multiplayer games, the cheats change the result, making the cheater achieve a prize that does not deserve.
Authentication service
This service handles user registration, authentication, and authorization.
Matchmaking service
The matchmaking service matches players based on skills or car class.
Game server manager service
This service manages games. When the matchmaking service matches the players, the game manager creates a new instance of the game server and returns its IP and port for the game client to connect.
Inventory service
This service stores and manages items, user items, and car customizations.
Gateway
The gateway exposes the services APIs to the end-user
Admin panel
An admin panel is needed to manage and monitor users and items.
Merging Services
Developing, managing, and maintaining all of these services is hard work to do, therefore, I merged the Game Manager service with the gateway, matchmaking, inventory, and admin services and used Firebase as the authentication service.
Event Broker
An event broker is needed to transfer the events between services.
Deployment
Finally, the delivery part is also important and we should consider it too. we need to deploy all these applications into the servers and maintain them.
Pipeline
Let’s start with a scenario, the player opens the game client and clicks on the “Start Matchmaking” button in the main menu. Next, the matchmaking service adds the player to the queue. After a while, another player repeats this request, and the matchmaking service matches these two players. Then the game manager runs a new instance of the game server and returns the IP and Port of it, so the clients can connect to the game server directly and start playing.
By now we have three main applications, the game client to render the graphics and communicate with the server, an authoritative game server to calculate the client inputs and run the mathematics simulations, and finally, a game manager application to manage game sessions, and handle matchmaking, and so on.
In the next part, we’ll check out the design and architecture of the whole system.
All posts:
