Spanish version: Introducción al desarrollo de juegos multiplayer en Unreal Engine 4
THANK YOU VERY MUCH @COLMS19 FOR THE ENGLISH TRANSLATION.
Several people have written to me with many questions about the development of multiplayer games using Unreal Engine so I thought it’d be a good idea to start a series of tutorials that help understand how to develop multiplayer games with this magnificent engine. As there is no better way to learn than practicing, that’s what we’ll do. We will begin by developing a simple “Third Person Shooter Multiplayer” in Unreal Engine. This will allow us to learn many new things we have not seen in previous tutorials, and after that, we’ll look at more advanced multiplayer development concepts.
As this matter is not simple, let’s go slowly. We will leave this first tutorial with only an introduction to the more complex multiplayer concepts.
Note : This tutorial has been developed with Unreal Engine 4.8 . If you are working with another version, you may find some differences since the engine is constantly updating. If so, leave me your comments at the end of the post and we’ll look for a solution together.
A multiplayer game is a game that is played by more than one player at the same time. At this point we have two main variants. The first, where the players share the same station, each with a controller, and the screen split into parts. Talking about this kind of multiplayer game always reminds me of when I played GoldenEye 007 on N64 with all the neighborhood kids as a boy
Another example of multiplayer games where players can play at the same station are fighting games, except that in this case the screen isn’t split because both players are always in the same level. Like the previous mode, each player has a controller to control his or her own character. No doubt the best example of this style of game is the recently released Mortal Kombat X , which by the way, is one of the major titles developed with Unreal Engine.
The two multiplayer game variants mentioned above can be said to be the beginning of multiplayer games. The development of computer networks and increasing speed of data transmission allowed for the creation of another variant of multiplayer game where several players could play the same game even when kilometers away.
In this tutorial, we will focus on this latter type of multiplayer game variant. We will start discussing the client / server architecture of the game.
Client / Server Architecture
In the client / server architecture, each of the players are the clients and are connected to a computer that will be the server. The server is responsible for all major decisions of the game, keeping the game state and transmitting data to each client so that all players are synchronized.
In this architecture, the server can run in two different modes:
Listen Server : The server also functions as a client. A player’s computer could be the server while the player is participating in the game on that same computer.
Dedicated Server : The only purpose of the computer is to act as the server for games. There is no person sitting at the server and participating in the game. This server type is typically used to run production servers.
Importantly, a player whose computer is acting as a Listen Server has no special privileges by acting as the server. All of the rules of architecture apply to this player even though his computer is the server.
Unreal Engine 4 uses the client / server architecture to support multiplayer games. This is a super important point to always clear: Full control of the game will taken by the server. The server will be responsible for updating the status of all clients. Don’t worry. You’ll understand better what we mean by this later when we start to practice, but for now, just remember that this is the golden rule.
Let’s take a simple example to help clarify the matter.
Suppose you are developing a game where four players participate. Each player will have their own station, i.e. each player is a client. Players can equip weapons that are scattered around the stage with the goal of wiping out the other players. The player who survives is the winner.
As we begin to implement this game we have our first problem. When the game starts, suppose that player 1 begins to move. What should happen is that in the other three computers, the player character 1 also moves, right ?? Well, for this we need to have a server.
What the computer of player 1 will do is “tell” the server that the character is moving in x direction. This will make the server send a position vector and rotation to the clients by updating these values for the player 1 character on all clients. This includes the validation of player movement 1, which was conducted by the action of walking. The end result is that when the player 1 tells his character to move on his own client computer character, the player 1 character also moves on all the client computers, so all clients will see the same thing.
This happens in any action that affects the state of any player controlled character changes. For example, if a player shoots, the server is notified which then updated the world state of each client by adding the position and rotation etc. of the projectile. In short, the task of the server is to maintain a synchronized game state across all clients so that each player experiences the same game world.
Of course, this process involves several contentious issues. For example, sometimes the movement of the characters can appear jumpy. If player 1 begins moving and the server is on a congested network, some packets will not reach the server. This could mean that clients wouldn’t see the character move smoothly from one location to another, but instead jump instantaneously between positions as some packets containing position data were lost or arrived too late to be useful. If you’ve played multiplayer games in the past, especially in overloaded and slow networks, you may have experiences this.
In such cases, we must further complicate the solution to avoid these problems. Motion interpolation solutions are generally used to “predict” the character’s position with respect to time, and prevent these jumps. This is easy to say, but the implementation is not trivial. . . luckily we are developing with Unreal Engine :).
The best we have to use EU4 in the development of our games, is that often we do not have to worry about these “low level” problems. You’ll see how easy it is to accomplish this with Unreal engine. Actually, this has been one of the things that surprised me when I started working with Unreal, especially because I had the experience of a multiplayer project developed in Unity3D and SmartFoxServer . . . and in which I almost went crazy taking care of all these details
Testing the multiplayer mode from the Editor
After having taken a little tour of the theory behind the Unreal multiplayer games, we will go on to develop a simple example that allows us to put all these concepts into practice.
For our example, we will create a project from the Third Person from C++ template I the editor.
The Unreal Editor gives us a lot when it comes to developing a multiplayer game, especially the ability to act as different clients without the need for more than one computer. So far, to run our game, we clicked the Play button on the Toolbar and the game was started in the viewport of the editor, right? In the case of a single player game this is enough, but in the case of a multiplayer game where you want to try different bodies (clients), this run style is not feasible.
If you look at the Play button on the Toolbar, this button has an arrow next to it to display more options. By clicking here we will display a menu with 3 sections and the Advanced Settings option.
In the first section have different modes of play:
Selected Viewport : This is the way we have used so far to run our game from the Editor. By selecting this mode the game is launched within the viewport in the editor.
Mobile Preview : We launched a new mobile simulator window with two virtual joystick on the screen. Very useful for testing mobile.
New Editor Windows : By playing in this mode, the game is opened in a new window independent of the Editor window. This is the most comfortable way to test our game on multiple clients, as each client opens a separate window that can fit on the screen to easily visualize the behavior of the game in those clients.
Standalone Game : The game will be released in a new window but runs in its own process. I you run the game in this mode, you can not pause or stop it from the Editor as we normally do.
Simulate : This option is extremely useful, especially for testing the AI of our game. This option allows us to run the game as a kind of spectator. We have no control of our character, basically we will not have a PlayerController serve us as a bridge between us and our Pawn, but the rest of the game will run normally and we can “fly” across the stage, inspecting everything we want. When you are running the game in this mode you have full access to the tools of the editor, or you can change the scene and its contents as the game is running.
PS: I have no idea what the VR Preview option is. This option was recently added to the Editor and will have to do with all the new features of Virtual Reality version 4.8 and later.
The section following the Play Modes section is the Spawn Player At section. Here we have two options: Current Camera Location and Default Player Start. These are fairly obvious by name. The first allows us to launch the game the player at the same position and rotation of the camera in the viewport. The second is the one generally used so far, makes the player always start at the Player Start in our level.
Finally we have the Multiplayer Options section, which is the section that most interests us in this tutorial. In this section we have two options:
Number of Players is a field to enter the number of players with which we want to test our game.
For example, let’s enter a value of 2 here and play so we can see what happens. If you keep the Selected Viewport option checked, you will see two instances of the game run within the same editor. This makes testing in the two clients are a bit complex, so the best for this case is to select New Editor Windows. Now hitting Play will open each of the timing game sessions in separate windows.
If you’re working on a small monitor, you’ll have another problem; the size of each of the windows is quite large. This can be fixed by clicking the Advaced Settings menu option. In the window that opens (Editor Preferences / Level Editor / Play) you will see the Play in New Window, New Window section, and the Size property. There you can change the resolution of the window so you can accommodate two clients (or more if you want) on a single screen. In my case, I usually write tutorials on a MacBook Air 13-inch, and I have to set the window to 640 x 480 :(.
After setting 2 Players and New Editor Window in the Mode drop down menu, re-launch the game. You will see two windows of the same game open. Look at the title of each window:
As you can see, by default Unreal launches the first instance as the server in Listen mode, which also functions as a client. It is the window with the title says ThirdPersonShooter Game Preview Server. The other instance is a regular client. Running the game with the Listen mode server is always very helpful because it often happens that when we are developing, we are notified that the server’s action is successful but was not replicated for the other clients. Running the game in this mode makes it so if you see that an action took place correctly on the server instance but not on the other client, we have some idea where to start looking for the error
Besides this, Unreal also allows us to test our mutiplayer game on a dedicated server. Look just below the option to define the number of clients in the Mode dropdown. Check the Run Dedicated Server option. If you select this and hit Play, you see that just as before, there two instances of our game running, but if you look at the name of each window you’ll see that both say they’re clients because the server is also running but dedicated mode.
A you will see in each of the instances you can control a character and if you move the character, the character moves in exactly the same way for the other client. At least, when I saw this, my expression was :: -o !! But how, if I have not done anything !!? . . . I have not written a line of code to achieve this, and I remember in my Unity project it took some time to achieve this. I took a week and had to program only “Like Crazy”, including interpolation methods.
I myself had to comment on an almost magical Unreal attribute: Replication
Replicated Actors in Unreal Engine 4
If you go to the Default section of any Actor, either PlayerCharacter or any other player in the game, you see that there’s a section called Replication. This section contains most of the properties that define the behavior of this actor in a multiplayer game. There you will see the boolean property, Replicates. If you open, for example, the blueprint of Character, you will see that this property is true (the checkbox is checked) as is the Replicate Movement property.
Well as simply as that, these two properties have all of the responsibility in the engine for managing everything regarding synchronizing actor movement across a level : -or !!! This is done sending the position and rotation of the actor to each client.
Let’s perform a very simple demonstration. Uncheck the Replicate Movement property and run the game again with two clients. You will see that now the two Players start as before but when you move one, the same character in the other instance does not move. Therefore, whenever we want to synchronize movement for any Actor in a multiplayer game, we have to set this property to true. This is true of the position and rotation attributes for an Actor. In a layer tutorial, we’ll talk about replicating other attributes across a network.
Well, without writing a line of code (or creating a node in Blueprint), we have the whole mechanism of replicating a Player Character across all clients in a game. Perfect!! This is a great starting point for our multiplayer game.
As I said at the beginning, the idea is to develop a simple third-person multiplayer game where several players can fight to the death and the survivor becomes the winner. In addition to the concepts and techniques related to multiplayer that will be the highlight of this series, future examples will show how to implement many new things we have not seen in previous tutorials. So don’t don’t far because the second part will be coming soon. Until then, bye 😉
Spanish version: Introducción al desarrollo de juegos multiplayer en Unreal Engine 4
Latest posts by Fernando Castillo Coello (see all)
- UE4 – Tip of the Day 2: Get the previous value of any variable after being replicated - 17 July, 2016
- UE4 – Tip of the Day 1: Camera FadeIn/FadeOut - 17 July, 2016
- Desarrollando un Third Person Multiplayer Shooter en U4 – Parte 1 - 15 July, 2015