멀티플레이에서 멀티플레이어 게임 설정하기

멀티플레이에서 멀티플레이어 게임을 설정하면 개발자가 원활하게 통합하고 효율적으로 서버를 관리할 수 있습니다.

### 멀티플레이에서 멀티플레이어 게임 설정하기: 단계별 가이드
* 🎮 멀티플레이에서 멀티플레이 게임 설정을 시작하려면 **설정 가이드**를 따라 멀티플레이가 백그라운드에서 **활성화**되었는지 확인하여 프로세스를 시작했습니다.
* 🛠 첫 번째 단계는 게임 서버를 통합하는 것이었는데, 여기에는 프로젝트에 선택한 게임 엔진인 **유니티용 관련 패키지 SDK 설치**가 포함되었습니다.
* 📦 통합을 완료한 후 게임 서버 바이너리를 빌드로 업로드하여 **"배틀로얄"**이라는 이름을 지정하고 Linux 플랫폼에서 **직접 파일 업로드**를 선택했습니다.
* ⚙ 업로드 후, **구성 간에 쉽게 전환**할 수 있는 명명 규칙을 사용하여 서버에서 빌드를 **실행**하는 방법을 지정하는 빌드 구성을 만들었습니다.
* 🌍 리소스 할당과 비용 관리를 최적화하기 위해 **최소 1대의 서버**와 **최대 4대의 서버**를 지정하여 여러 빌드 구성으로 구성된 플릿을 설정했습니다.
* 🔄 서버 프로비저닝 후 **할당 ID**, **서버 ID**, **IP**, **포트**, 자동 할당 해제 전 **1시간 시간 제한**을 제공하는 테스트 할당을 성공적으로 생성했습니다.
* 📊 분석을 통해 서버의 성능을 모니터링하여 서버 브라우저에서 서버가 **올바르게 보고**되어 게임에 원활하게 **접속**할 수 있음을 확인했습니다.
* 📈 마지막으로 동시 접속자 및 서버 이벤트에 대한 실시간 및 과거 데이터를 검토하여 설정 과정을 마무리하고 성공적인 멀티플레이어 게임 경험을 위한 준비를 마쳤습니다.

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

Unity

멀티플레이 설정 가이드는 현재 유니티를 중심으로 게임 서버 통합에 대한 지침을 제공합니다.

파일 모음인 빌드는 직접 파일 업로드 또는 컨테이너 이미지 옵션과 함께 게임 서버 백엔드를 배포 및 실행하기 위해 생성됩니다.

필요한 파일을 업로드한 후 빌드 구성이 생성되어 멀티플레이에 서버에서 빌드를 실행하는 방법을 지시합니다.

게임 백엔드를 위한 빌드 구성 만들기

빌드 구성은 다운타임 없이 쉽게 전환할 수 있도록 "b" 명명 규칙을 사용하여 설정됩니다.

구성에는 실행 파일 선택, 쿼리 유형(sqp 또는 a2s) 선택, 포트, 쿼리 보고서, 로그 디렉토리와 같은 실행 매개변수 구성이 포함됩니다.

게임 서버의 런타임을 맞춤 설정하기 위한 추가 실행 파라미터와 구성 변수가 제공되며, 멀티플레이어별 효율적인 리소스 확장을 위한 사용량 설정이 지정됩니다.

게임 백엔드용 서버 플릿 구성하기

차량은 여러 빌드 구성을 가질 수 있어 다운타임 제로와 유연한 확장 설정이 가능합니다.

작성자는 할당 시간을 최적화하고 비용을 관리하기 위해 최소 1대에서 최대 4대의 서버를 사용하여 유럽에서 함대를 설정하고 있습니다.

빌드 페이지에서는 버전 기록, 사용 설정, 할당을 위한 첨부된 빌드 구성 등 게임 서버 백엔드에 대한 정보를 제공합니다.

효율적인 서버 프로비저닝 및 테스트 할당

멀티플레이는 프로비저닝된 머신에 서비스를 채워 효율성을 극대화하고 있으며, 추가 과금 없이 서비스를 제공합니다.

테스트 할당 프로세스에는 함대, 지역, 빌드 구성을 지정하는 과정이 포함되며, 기본 할당 해제 시간은 1시간입니다.

추가 단계에는 매치메이커 통합, 서버 목록 보기, 서버 브라우저에서 자동으로 보고하는 게임 클라이언트 실행 등이 포함됩니다.

게임 개발을 위한 멀티플레이 데모

이 데모에서는 동시 사용자, 충돌 및 이벤트에 대한 실시간 및 과거 데이터에 중점을 두고 Multiplay ER을 사용하여 엔드 투 엔드로 실행되는 게임을 보여줍니다.

서버 페이지에서는 게임 로그와 시작 및 중지와 같은 이벤트 동작에 액세스할 수 있습니다.

발표자는 시청자들이 멀티플레이를 사용해 성공적인 멀티플레이어 게임을 만들 수 있기를 바랍니다.