Greetings! Welcome to Part 1 of Building a Multiplayer Gaming System. Throughout this series we are going to design a system that supports a turn-based 1v1 multiplayer gaming experience from separate devices. We will examine different design decisions and their tradeoffs.
Let’s start by answering the question… What is a multiplayer gaming system?
Components of a Multiplayer Gaming System
A multiplayer gaming system allows players in different locations to play games together. The basic idea is that I can open it up on my computer or phone or whatever device, and start playing a game against someone else. Multiplayer gaming systems can be built in different ways. Your system could allow players to host their own games. These games could be public, and displayed in a game lobby, for anyone to join. Or they could be private, and require an invitation or code to get in. Or your system could control all matchmaking itself. Players must enter the queue for a match, and your system decides who plays against who. Here are some of the major components we will be discussing:
- Game Client
- Game Lobby
- Matchmaker
- Game Server
- Game History
The Game Client
The Game Client runs on an end user’s device. It communicates with the Game Server to get the current game state, and renders the state to the screen. It may include other features, such as highlighting possible moves, displaying the history of moves made in the game so far, or suggesting a ‘best move’.
The Game Client also includes the interfaces to start new games, play existing games, and otherwise navigate the game lobby or matchmaking system. If game history is stored and accessible, the game client provides an interface to that as well.
Game Lobby
The game lobby allows players to decide who they play against. Players could host public games and decide whether to accept a challenge from another player. Players could host private games so they can just play against their friends or favorite opponents.
Matchmaker
A matchmaker pairs up players to create games. Players queue up in the matchmaking system, and the matchmaker decides who should play who. This could be a first-come-first-served system, where you play whoever queued up most recently. Or the system could take into account player characteristics like skill rating or play style to try to make ‘good’ matches. Every approach here has tradeoffs which we will discuss more later.
Game Server
The Game Server holds the current game state for active games. It knows the game rules and it knows whose turn it is. The Game Server enforces correct game state and rejects invalid moves. Clients send their moves to the server, and the server updates the game state. If server-side push messaging is being used, the server updates other clients with the new game state. If client-side pull messaging is being used, clients periodically poll the server to get the new game state. If the system supports viewing the history of past games, the Game Server is responsible for committing game history to long term storage as moves are made or when the game has completed.
Game History
Game History is a record of past games and the moves that were made. You can view all your past games and replay them to analyze mistakes and find better moves. This could also allow you to view other players games, depending on what kinds of privacy policies you want to use. You could take the approach that all games are a matter of public record, as if everyone was just playing their game in a public park where anyone can come and watch. You could take the approach that games are private, and only the participants have a right to view it. Or you could land somewhere in the middle, where certain kinds of games (such as tournaments) are public, and everything else is private. Or give players control over whether to share their game history.
System Considerations
We will have a client application, a server application, and persistence. This means we will need to represent and synchronize state in three locations.
We will need to establish a messaging protocol between the client and server. We will need to decide which messages to send, who sends what and when, appropriate responses for various situations, including errors, and so on. We will need to decide whether to use push or pull messaging, or some mixture of the two.
The decisions we make will influence what patterns, languages, and technologies we will choose to build the system.
Design Workflow
There are many different ways to build a complex system. We are going to proceed with a user interface driven approach. The system we are building is for people. People interact with the system through the interface. Our goal is to make a good interface that users love. Everything else in the system is in support of that. The interface drives the decision process for technical decisions and guides the order in which we implement various features.
Conclusion
Now that we have a basic idea of what we’re doing, we are ready to start designing. In Part 2, we will discuss the design process in greater depth.
