foreign [Music] I'm going to run through setting up a multiplayer game on Multiplay. I've started at the setup guide, and I've already waited for Multiplay to be activated in the background, and so I'm ready to integrate my game server and follow the steps in the setup guide. First, I'm going to integrate my game server. This is a set of instructions on how to install the relevant package SDK or code snippets for your particular game engine or platform so that you can integrate with Multiplay quickly and easily. At the moment, we offer instructions for Unity, but we'll soon have instructions and packages for Unreal or custom engines. I'm going to be creating a Unity game for my Multiplay game, and so I've already completed these instructions of connecting my Unity project to my game, as well as installing the correct package from the package manager. Now that I've done that, the next thing to do is upload my game server binaries. We do this in a thing called a build. A build is a collection of files that we

will distribute onto different servers and start and execute them for the game server backend. I'm going to call this Battle Royale. I'm going to run it on Linux, and it will be a direct file upload. We also support container images. After the build has been created, the next thing to do is upload the relevant files. So, I'm going to drag and drop the files from my backend into this area and then upload. Depending on your internet connection, this can take some amount of time. Foreign files have been uploaded. We can continue finishing the creation of the build by creating the very first version. In the future, if we want to update our game binary backend, we can add files, remove files, or modify files, and then create a new version, which will then be rolled out across our Fleet. Now that we've created our build, which contains all of the files for our game backend, we have to create a build configuration. We can have many build configurations for a single build because they instruct to multiply how to actually run the build on a server. So, I'm going to go ahead and create a

build configuration now build configurations. We encourage to use a b naming so that you can switch between one and another quickly and easily with zero downtime. So I'm going to call this one standalone. Hey, I'm going to choose the build that I've just created and uploaded files to. From there, I can search for the particular executable. So I'm going to choose bytoril.x8664, which is the executable to run for the query type. We support two query types or no query type. sqp is our primary, a more recommended choice, although we do also support a2s. I'm going to use sqp for my game back end. Next, we can configure our launch parameters, which are flags to apply to the binary at runtime. It's important that you provide the port, which is passed in as a variable at runtime, query reports, and log directory, which all points to the correct and necessary numbers or folder directory structures so that you can make use of them. For our particular game, we need to apply additional launch parameters to make it run as we want it to. So I'm just going

to paste in my launch parameters here. We're still making use of the log directory for our log file and the port for the server port, but we're also passing in additional things such as a server name, max players, flags to tell our game server library that we're using multiplayer as well as dedicated server, and particular flags that are specific for a Unity engine game like batch mode, no graphics, and FPS. In the configuration variables tab, we can provide additional variables alongside the launch parameters which can change throughout a game server binary lifecycle and then are exposed through the server.json file which lives next to it. Finally, we want to specify our usage settings which will tell multiplayer the ideal usage resources for this particular server by providing these as accurately as possible. Multiplayer can scale the system as effectively as it can, so we've successfully created a build configuration. Once again, a build configuration tells multiplayer how to actually execute the build as well as what kind of usage settings that build will be using with that particular configuration. The next thing to create is a fleet.

A fleet can contain multiple build configurations, which is where a B switching comes in with zero downtime. It also lets me configure the scaling settings, which is how many servers to run and when I'm going to call my fleet production. It's running Linux, and I'll be using the build configuration that I've just created. I will choose Europe as my region, as I am living in Europe at the moment, and I want it to be nice and fast for me. I'm going to set a minimum available servers of one. Minimum available servers mean how many servers to start spinning up at a minimum so that there are pre-warm servers that will be able to be allocated as quickly as possible. If there are no servers available on an allocation, a new one will be created, but at least one minimum available server means the allocation time will be shortened. I'm going to set a maximum available servers to 4, and this is really good to cap my spending so I don't produce too many servers. So to recap, I've created a build by

uploading my game server backend binary files. I've specified how to actually run that binary, and I've specified how to scale that binary through build configurations and Fleet. Now at this point, it will take a moment for the fleet to provision all of the servers required to satisfy the minimum and maximum server requirements that I specified. And so I want to wait for that to happen before creating a test allocation. Otherwise, a test allocation may take some time. But in the meantime, let's recap. In the builds page, I can see my single build listed. I can modify and see all of the information, including the files and version history and its installation progress. The build configuration is showing me all of the configuration for this particular build, as well as its usage settings. And my fleet can tell me which build configurations are attached for when I want to allocate. I can see the scaling settings, and I can see the Analytics. Something to note with scaling settings, you might see in actual runtime more available servers than the max available server is configured. And this is because

multiplay is being as efficient as possible by filling up a provisioned machine with as many services as can fit onto it, but don't worry, they will not be billed any extra. I'm going to return to the setup guide. Now that my servers have been provisioned, I can create a test allocation. To create a test allocation, I need to specify the fleet, the region, and the build configuration that's in use. I'm going to run my test allocation, and I can see that it's successful. An allocation comprises an allocation ID, a server ID, IP, port, and time remaining, which by default is one hour until the server is automatically de-allocated. Servers can be deallocated in other means by stopping the server or firing a deallocation request. Now that we completed our setup guide, we have a few extra steps that we can go on. We can start to integrate a Matchmaker, which can handle allocations automatically. We can view our server list or read the documentation. I'm going to view the server list just to see that I've one allocated server.

which has got an IPM Port as such, and clicking on it, we can see more details about it, including Analytics. We can see the events such as it has started with the correct build configuration and the server logs as we are specified with our launch parameters to confirm that we have created a server successfully. I'm going to run my game client. This is using the Battle Royale sample, and the clever thing about this is instead of having to put in the server IPM Port manually, it will actually automatically report itself in the server browser. And so here we can see the server has reported itself successfully, and I can join the game. And here we are in the game as expected. Now if I go to the analytics and quickly change, we can see we have one concurrent user, which is myself, and we can see the memory and CPU usage, which are a little lower than what I configured but will peak as more players would join. I'm going to stop the server, which will force a deallocation, and now we can see that in here I will

be deallocated with the connection lost, and that's our game running end-to-end using multiplay ER. Finally, we can go to the overview page, as we've been using this project for a little while now, and I can see that live and historical data is shown for concurrent users, crashes, and events. Again, if you go to the servers page and go to the logs, we can see our own logs from our game here, as well as looking at events to see what actions have happened, such as start and stop. I hope you enjoyed this demo, and good luck with using multiplay, and I hope you make a successful multiplayer game. Thanks very much. Foreign

How to set up Game Server Hosting | Unity Gaming Services

Unity is the creator of the world’s most widely-used real-time 3D (RT3D) development platform, giving content creators around the world the tools to create rich, interactive 2D, 3D, VR and AR experiences. Our 800+ person engineering team keeps Unity at the bleeding-edge of technology by working alongside partners such as Magic Leap, Google, Facebook, Oculus and Microsoft to ensure optimized support for the latest releases and platforms. 

Apps made with Unity reach 2.7 billion devices worldwide and were installed more than 24 billion times in the last 12 months. Unity is powering the real-time revolution, expanding beyond games and breaking into other industries including automotive, film, architecture, engineering, construction, and more. 

You can download Unity from our website: https://on.unity.com/3FSLbKn
Facebook: https://on.unity.com/40zifiE
Twitter: https://on.unity.com/40h2dtS

How to set up Game Server Hosting | Unity Gaming Services

How to set up Game Server Hosting | Unity Gaming Services

Scripts