Online Multiplayer: Building a Virtual Playground
Updated: Feb 19, 2019
Effective and efficient network communication is crucial to popular multiplayer games today.
When making a game people can play against each other online, you have to keep track of what the players see on the screen, what the players can do, the game’s win conditions, and a host of other things.
This bookkeeping can be done in several different ways, and while I won’t go too deep into the nuts and bolts of how that’s done save for a couple examples, I hope this article gives you a better appreciation for everything necessary for an enjoyable gaming experience online.
I will be illustrating what needs to be considered when building an online tic-tac-toe game by writing a server that talks with clients (programs that send out data for games). The client-server model may be slightly overkill for this example and could be done with a peer-to-peer model. However, using the former will better explain the concepts I want to discuss, and peer-to-peer networking is a topic that truthfully merits its own article anyway.
Also, the code snippets from this toy server example will be written in C# so refer to its documentation if you have specific questions while following along.
An online multiplayer game needs some way to send data over a network to other players in the game, and the first task needed to do this is building a server to which the clients can connect. This is done by the server program running a lobby.
Next, we want to get data sent out from the client to use it to send info to other clients. In our tic- tac-toe game, this means recording squares on the board that a player wants to mark with their symbol and sending it to the server. Once the client has sent Player One’s move to the server, we want to make sure the requested move can actually be made.
Here, the server does that by keeping track of the board with a Board() object. If the square Player One wants to claim has already been taken, we don’t want them either erasing Player Two’s move with their own or wasting their turn marking a square they already claimed.
If the move is valid, the server will record Player One’s move in the Board() object, and back in the Lobby() class we will send a response code that tells the rest of the server code whether the move was valid and whether or not to send a new board state to Player Two.
It’s good practice to send a response back to the client whether or not the server validates a move such that Player One can have feedback on whether their action was actually recognized and how to make a valid action. Many people know how annoying it is to sit around waiting to do something in a game and not know whether they actually did something in the game or their connection to the server was cut.
Note that in this example our game performed three major functions per player turn: sending requested moves across the network, checking the validity of that move, and responding to one or both players’ clients depending on whether the move is valid. Our tic-tac-toe example showed only one lobby running, but the server obviously gets more of a workload as it handles multiple lobbies at a time.
Additionally, if we allow the player to do more things over the network, such as in a game of chess, our server has to perform several more functions to check for validity, and displaying information to the client like the valid moves of a selected chess piece, a turn timer, and warnings against putting the player’s king in check take even more functions.
You can imagine the scale of the data being passed from client to server in a game that updates in real time rather than being turn based, such as a first-person shooter; then the server likely has to check player locations, projectile speed, player velocity for calculating fall damage, hit detection notifications, environment detection so players aren’t walking through walls, and an exhaustive list of other variables. In short, making an online gameplay experience fun and fair takes a lot of work on the game’s part, clever information handling by the programmers, and in many cases a lot of processing power running the server.
I hope this article helps you keep that in mind when you build a game yourself or simply the next time you get domed from across the map while playing PUBG even though you were clearly inside a kitchen. Maybe an understanding of the daunting task of game networking will make you reconsider storming Bluehole Studio’s front door with torches and pitchforks.
Tell Us What You Think
Leave a comment or tag us in a social media share.
Join our mailing list and be one of the first to Planet Rise.