Search Unity

유니티는 커넥티드 게임 개발 과정에서 발생하는 어려움을 해결하기 위해 먼저 실시간 멀티플레이어 게임 개발에 주력해왔으며, 이 개발 영역을 민주화하려는 여러 가지 시도를 통해 많은 정보와 아이디어를 얻고 있습니다. 하지만 적합한 신기술을 구축하려면 무엇보다도 모든 개발 단계에서 사용자가 직접 느끼는 피드백이 반영되어야 합니다. 멀티플레이어 커넥티드 게임 분야의 새로운 장을 개척하는 동안 여러분도 함께 개발 과정에 참여하고, 의견을 주시기 바랍니다. 유니티도 성원에 대한 보답으로 업데이트를 자주 출시하고, 모든 정보와 과정을 공유해 드리겠습니다.

지난 블로그 게시물을 통해 UNet 지원 중단을 발표한 이후 보내주신 여러 피드백을 취합하여 앞으로의 계획에 대해 좀 더 상세한 정보를 제공해 드리고자 합니다. 이번 게시물에서는 유니티의 장기적 비전과 올해 가을에 출시되는 첫 릴리스를 소개합니다.

네트워킹: 성능과 확장성

장기적 비전:

유니티는 ‘고성능 최적화’를 통해 멀티스레드를 처리하는 잡 시스템(Job System), Unity 게임 코드 작성을 위한 버스트 컴파일러(Burst Compiler), 데이터 중심의 게임 코드를 작성할 수 있는 엔티티 컴포넌트 시스템(ECS, Entity Component System) 등 개발 중인 여러 기능에 대한 이니셔티브를 소개하였습니다. 이와 같은 요소를 함께 활용한다면 몇 배 더 높은 성능이 보장되어 성능을 크게 개선할 수 있습니다.

여러분이 개발하려는 모든 게임을 규모와 상관없이 지원하기 위해 이러한 이니셔티브를 수립하였습니다. 대용량 지도, 여러 동적 오브젝트나 AI, 심지어 네트워크로 연결된 수많은 플레이어까지 모두 지원 가능합니다.

이 새로운 패러다임에서는 네트워킹 환경에 맞게 컴포넌트를 훨씬 더 쉽게 사용할 수 있습니다. 또한 고도로 구조화된 ECS 데이터를 통해 델타 압축, 보간 등 높은 수준의 시뮬레이션에 적합한 뛰어난 솔루션이 제공됩니다.

유니티는 다음의 주요 원칙을 기반으로 하여 새로운 네트워킹 스택을 구축하고 있습니다.

  • 투명성: 패키지를 통해 새로운 솔루션의 소스 코드를 공개하고, 4개월마다 발표하는 정규 출시 외에 프리뷰 형태로 신속하게 업데이트를 제공합니다. 이를 통해 사용자는 각자의 게임에 맞게 유니티의 네트워킹 솔루션을 디버그하고 확장할 수 있습니다.
  • 모듈화: 단일 구조의(monolithic) 라이브러리를 사용하면 불필요한 기능에 대한 쓸데없는 오버헤드가 발생하게 됩니다. 따라서 기본 구성에 포함되지 않는 새로운 기능은 옵션으로 별도 제공됩니다.
  • 성능과 확장성: 모든 기능에서 성능이 매우 중요하며, 네트워킹이 향후 유니티의 ‘고성능 최적화’ 비전에서 핵심 사항이 될 것이라는 사실을 잘 알고 있습니다. 따라서 처음부터 최신 게임의 요구 사항에 맞춰 확장 가능한 네트워킹을 제공할 것입니다.
  • 기본형별 솔루션 제공: 모든 게임에 적용할 수 있는 단 한 개의 솔루션은 없습니다. 따라서 FPS, RTS, 격투 게임 등 게임에서 자주 사용되는 네트워크 기본형(archetype)에 맞는 다양한 솔루션을 개발할 예정이며, 먼저 FPS 게임에서 자주 사용되는 클라이언트측 예측(client-side prediction) 모델을 구축할 예정입니다.

단기 계획:

단기적으로는 처음부터 다시 새로운 네트워킹 스택을 구축할 예정입니다. 이를 위해 최소한의 전송 계층인 UDP 기반의 송수신 기능을 소스와 함께 프리뷰 패키지 형태로 제공합니다. 바로 사용 가능한 패키지에 포함된 API는 잡 시스템과 호환되며, ECS 기반의 게임과 원활하게 페어링되도록 최적화되어 있지만 둘 다 필수 기능은 아닙니다. 지금은 우선 기본적인 것만 갖춘 시작 단계이며, 게임에 필요한 모든 요소를 구현하려면 네트워크 신뢰성과 시퀀싱 등 여러 중요한 기능이 필요하다는 사실을 감안하고 있습니다.

클라이언트측 예측, 보간, 델타 압축을 위한 완성도 높은 품질의 샘플 코드를 포함하는 FPS 샘플 게임의 전체 소스를 공개할 것이며, 다른 원형에 대해서는 차후에 릴리스할 예정입니다.

전용 서버 호스팅: 일관성과 보안

장기적 비전:

실시간 멀티플레이어 토폴로지의 현황을 분석한 결과, 전용 게임 서버(DGS) 모델이 실시간 멀티플레이어 게임에 최적의 옵션이라는 결론을 도출했습니다. 이 모델에서 제공하는 기능은 다음과 같습니다.

  • 일관성: 프로세싱과 로직이 사용자가 관리할 수 있는 리소스에서 직접 처리됩니다. 이렇게 하면 연결 품질을 예측할 수 있으며, 지연이 발생할 때 영향을 많이 받는 게임에서 ‘호스트 어드밴티지’가 발생하지 않습니다.
  • 확장성: P2P(Peer-to-peer) 연결은 게임 인스턴스당 소수의 플레이어 풀(보통 12명 이하) 이상으로 확장하기가 어려운 반면, DGS 모델은 더욱 강력해진 시스템에서 보다 많은 플레이어를 지원할 수 있습니다.
  • 보안: 서버 권한을 가지는 코드를 사용하면 공정하지 못한 이벤트가 발생한 경우 이를 사후에 감지하는 것이 아니라 속임수를 사전에 방지할 수 있습니다.
  • 신속한 반복: 멀티플레이어 게임을 조정하려면 출시 후에도 반복 작업을 여러 번 해야 합니다. 하지만 DGS 모델을 사용하면 인증을 통과해야 하는 클라이언트 패치 없이 서버에서 실행되는 로직만 업데이트할 수 있습니다.

이러한 이유로 유니티ㅏ Multiplay의 기술을 도입하게 되었습니다. Multiplay의 검증된 전용 서버 오케스트레이션(자동화 관리) 기술을 통해 게임에 맞게 서버 플릿(fleet) 규모를 유연하게 정할 수 있습니다. 또한 Multiplay는 베어메탈(bare-metal)과 ‘버스트 클라우드(burst cloud)’의 하이브리드 호스팅 방식을 통해 비용을 규모에 맞게 최적화합니다. 이러한 기술은 PUBG, 타이탄폴 2(Titanfall 2), 갱 비스트(Gang Beasts)를 비롯한 다수의 게임에서 엔진과 상관없이 실행되는 커스텀 엔터프라이즈 솔루션에 적용되어 이미 검증되었습니다. Multiplay 기능에 대한 자세한 내용은 유나이트 베를린 2018의 Multiplay 관련 세션 녹화본을 참조하세요.


단기 계획:

현재 유니티는 사용자가 직접 액세스할 수 있는 방법으로 Multiplay 기술을 Unity 생태계에 통합하기 위해 노력하고 있습니다. 머지않아 원격으로도 팀원 및 친구들과 게임의 플레이 테스트를 진행할 수 있는 개발 게임 호스팅 서버를 사용할 수 있게 됩니다. 첫 알파 릴리스에는 플릿 프로비저닝, Linux 서버 빌드 업로드 및 배포, 서버 쿼리 프로토콜을 위한 패키지, 그리고 서버 활동을 모니터링할 수 있는 간단한 통계와 로그가 포함될 예정입니다.

매치메이킹: 유연한 로직과 원활한 통합

장기적 비전:

매치메이킹(Matchmaking)은 여러 플레이어를 서로 매치하여 게임의 즐거움을 최대한으로 높이는 기술로, 생각보다 쉬운 작업은 아닙니다. 게임마다 목표와 매치 규칙이 서로 다르므로 상업용으로 사전 제작된 매치메이킹 솔루션으로는 이러한 특성을 반영하여 지원하기 어렵다는 피드백을 반복적으로 받았습니다.

이 문제를 해결하기 위한 첫걸음으로, 유나이트 베를린에서 Google과 함께하는 오픈소스 매치메이킹 프로젝트 Open Match를 선보였습니다. 이 프로젝트는 확장성을 최우선으로 고려한 설계로 규모에 맞게 기능을 제공하기 위해 추진되었습니다. 이렇게 하면 사용자 프로젝트에 맞게 원하는 대로 매치 로직과 오케스트레이션 모듈을 커스터마이즈할 수 있습니다.

유니티는 Open Match를 중심으로 관리되는 매치메이커를 빌드하고 있으며, 향후에도 발전하고 개선되는 Open Match의 기능을 지속적으로 활용할 것입니다. 또한 Unity 개발자들에게 다음의 고유한 혜택을 추가로 제공할 예정입니다.

  • 완전히 관리되는 서비스: 개발자가 게임 개발에 집중할 수 있도록 매치메이커 서비스를 운영, 확장 및 관리해 드립니다.
  • 확장 가능한 게임-서버 호스팅: 유니티의 매치메이커는 기본적으로 Multiplay의 오케스트레이션 기술과 원활하게 통합되며, 게임을 플레이할 플레이어 수에 따라 게임 호스팅 서버 용량을 자유롭게 조정할 수 있습니다. 즉, 매치메이커 서비스를 사용하는 Unity 개발자는 복잡한 서버 수명 주기에 대해 배우지 않아도 됩니다.
  • 접근성: 향후 Unity의 관리되는 서비스는 게임 개발자가 커스텀 로직을 작성하지 않고도 지연, 기술, 대기 시간의 균형을 맞출 수 있는 단순한 기본 옵션을 제공할 예정합니다.
  • 커스터마이징: 2019년 하반기에는 추가 커스텀 기능이 필요한 게임을 위해 관리되는 환경에 완벽한 커스텀 형식의 매치 로직을 제공할 예정입니다. 이 매치 로직을 Unity 표준 C# 언어로 작성된 Unity 환경에서 매치메이커에 배포할 수 있습니다. 사전 제작 솔루션만으로 충분하지 않을 경우 게임에 맞는 매치 로직을 커스터마이즈할 수 있습니다.

단기 계획:

Open Match의 v0.1 버전이 지난 주에 출시되었습니다. 유니티는 앞으로도 지속적으로 Google 및 여러 커뮤니티 구성원들과 협력하여 이 솔루션의 품질과 기능을 개선하고 발전시키기 위해 노력할 것입니다.

또한 곧 Unity 생태계에서 관리되는 매치메이커의 첫 버전을 출시할 예정입니다. 이 버전에는 플레이어 수 구성, 서버 할당 작업과의 원활한 통합, 패키지에 포함된 클라이언트 라이브러리 및 자동 배포 기능이 포함됩니다. 이 버전에서는 플레이어 수가 충족되면 서버가 유연하게 할당되며, 게임 클라이언트가 서버에 연결됩니다.

서버 런타임: 비용과 모듈화

장기적 비전:

전용 서버를 호스팅할 때 사용자들이 가장 많은 우려를 표하는 부분은 바로 비용입니다. Google 클라우드와 같은 공용 클라우드 환경의 경우 비용은 가상 머신 사양, 사용 시간, 사용된 네트워킹 대역폭(이그레스(egress)), 운영체제 라이선스 비용을 고려하여 책정됩니다. 비용 절감을 위한 방법은 다음과 같습니다.

  • 서버 런타임 사용 프로필 최소화 – 가능한 최소 VM 사양에서 가장 높은 성능으로 게임을 안정적으로 실행할 수 있게 합니다.
  • 서버 사용 시간 최소화 – 플레이어의 요구 사항에 맞게 필요한 경우에만 서버를 가동 및 할당하는 서버 오케스트레이션 및 매치메이킹 기능을 사용하여 서버 사용 시간을 최소화합니다.
  • 네트워킹 대역폭 최소화 – 이전 프레임 이후에 변경된 데이터 중 연관성이 가장 높은 데이터만 전송하는 양질의 시뮬레이션 코드(예: 델타 압축)를 사용하여 네트워킹 대역폭을 최소화합니다.
  • Linux OS에서 서버 실행 – 독점 운영체제 사용으로 인해 고액의 라이선스 비용이 발생하지 않도록 합니다.
  • 베어메탈과 클라우드 버스팅 조합 – 게임이 규모의 경제(economies-of-scale)를 달성하면 베어메탈 서버를 일정한 기준으로 활용하면서 클라우드 버스팅을 함께 사용합니다.

유니티는 이 5가지 중 아래 4가지 부문에 대한 솔루션을 이미 제시했으며, 현재 서버 런타임 사용 프로필에 대해서도 솔루션을 찾고 있습니다. 새로운 패키지 관리 시스템이 완전히 구현되면 개발자가 최소한의 소비만으로 Unity를 서버 런타임으로 실행할 수 있을 것으로 예상됩니다. 이와 같이 소비 수준이 최소화되면 앞으로는 게임 목적 달성을 위해 서버에서 반드시 필요로 하는 패키지만 포함할 수 있게 됩니다.

단기 계획:

유니티는 ‘헤드리스(headless)’ 모드에서 의도치 않게 실행되고 있는 렌더링, 애니메이션 및 오디오를 제거하는 등 쉽게 해결할 수 있는 작업부터 시작하여 Unity Linux 런타임의 ‘헤드리스’ 버전을 최적화하는 데 주력하고 있습니다. 이를 통해 ‘헤드리스’ 모드가 적용된 Unity 현재 버전에서 안정성을 높이고 가동 시간을 늘리면서 메모리, 빌드 크기 및 CPU 사용을 최소화하고자 합니다.

또한 Unity 2018.3 버전에서는 모든 스탠드얼론 플레이어를 위한 새로운 ‘서버 빌드’ 옵션을 도입하여 개발자 워크플로를 개선했습니다. 이 옵션은 기본적으로 헤드리스 모드로 실행되며, 새로운 UNITY_SERVER 정의를 통해 서버 스크립트 로직을 분리할 수 있습니다.

소식 받기

 

48 코멘트

코멘트 구독

코멘트를 달 수 없습니다.

  1. So will it be possible to use p2p for optimization purposes? Like if you have a small group of players that are far away from everyone else, they could be treated as a p2p group instead of having them all relay through the server?

  2. Hello,

    With your new Unity/Google Cloud multi-player system, what will be the maximum number of simultaneous players you will support in the same room at the same time?

    Right now im using PHOTON PUN multi-player system for Unity, its nice and easy to use, but seems it can only do maybe 6 to 10 players tops per room, i need way more than that, maybe 50 to 100 or even 1000. Can you guys swing that?

    Thanks!

    1. You should really check your code, sounds like you could use some optimizations. Our game warscrap.io has 10 players per room and over 20 bots + vehicles.

  3. What is the recommendation from Unity on starting a new project today for a networking heavy game? Work through everything in a networking free setup for now until the new Multiplayer Connected stuff is done, or something else?

  4. Hi guys, any plans on in editor client + server splitscreen like in Unreal 4?
    I feel like the need to build and launch a server any time you want to test anything is the major drawback and i’ve seen many people
    trying to work around it by building separate assemblies and what not.
    I don’t see any mention of that, is that being worked on?

  5. Authoritative server models are welcome since at UNET this is a big headache and a mess to reach. Glad to see that there will be an FPS sample, prediction and safety are the most important things to it.

    1. Thanks Tomas – looking forward to your feedback when the Alpha comes out soon.

  6. I don’t quite understand where this leaves me, I have very little experience in multiplayer, I built what I thought was a p2p authorative model in a game i’m making.

    the idea being is that a player is a host, but not a server, its a single screen game, all input values are fed to the host and the host moves the players, which is then authoratively sent back to the clients. there is a small delay but for the most part its working well.

    this was all done in UNET HLAPI and syncvars. matchmaking is being used but no servers are hosting the games.

    are we now saying this setup will no longer be possible or supported in the new networking system?

    1. In the new system, instead of running the server on local hardware (that is inherently hackable), it will be by default hosted on a separate box (either by Unity/Multiplay or by other means of your choosing).

  7. The big question – Will there still be a completely “Free” tier for those small “between friends” games that use <1GB / year as we currently have with the UNet servers? Alternatively, will we still have self-hosting options?

    1. The networking code is agnostic, so self-hosting is certainly possible. LAN multiplayer games are always free and will definitely be supported since it’s required for development purposes anyways. Beyond this, pricing is still something we are working on with our Google Cloud partners.

  8. This is truly great news. My studio are working on a multiplayer RTS that cannot work with lockstep because of the complexity of the game. Support for the server-authoritative client-predictive archetype will make our lives easier in the coming months.

    I would really like to know exactly where Unity now will make the API’s. What will we as a studio have to do for ourselves and what will we be able to do in Unity?

    1. If there are specific features you most need – please let us know! Our roadmap is still evolving, and there will be many more features even after the upcoming alpha release.

  9. I hope there is still peer to peer for small scale free non competitive project, I pray the sin and the moon, even the cloud and teh rain!

    1. For small games, you may want to consider LAN or local multiplayer. You may also be surprised by cloud hosting; you only pay for what you use since the servers spin up/down based on player demand.

  10. At this point, I would love to see a post about what we should be doing right now to prepare for these changes. How should we architect now to avoid too much hassle in the future? What would a networking interface look like now that would/could work with both systems?

    For everyone that’s starting projects now that need networking, news of something so much better on the horizon is great but stressful. Multiplayer can be so deeply rooted in an application, it’s not something you want to completely refactor in a year.

    How do we create an application now, that is new-networking-ready?

    1. That is an excellent point and I’d like to hear something about this too.

    2. Hi Michael – there will be an alpha version to explore in more detail soon, and beyond that, we recommend using the LLAPI or other UDP-based transport. The API’s will be most similar on day-1.

  11. Great news, and I’d like to hear more about RTS archetype specificity. I am making a RTS right now, but have had to create an authoritative client-server using LLAPI. Unfortunately this will not scale when the number of players or units increases, and I’ve had to assume a low unit pop cap, using my own algorithms which send mostly deltas for moving units.

    My game uses Unity’s lovely pathfinding/flocking, and I also integrated the code Unity released which allows pathfinding on 3D objects generated at runtime. But because Unity’s internal logic isn’t deterministic this means making some sort of more traditional lockstep solution is out of reach right now. There have been deterministic lockstep solutions made with Unity… but not for my requirements, with pathfinding on dynamically generated 3D terrain at runtime!

    For my project, I do not want a dedicated server system. When AOE2HD came out even LAN games were routed through a dedicated server somewhere else… which meant playing a LAN game in a flat in London with a ping of over 200. Matchmaking sure, but dedicated servers hosting games will be too expensive for me as a lone indie dev.

    I’d just like to know if there’s anything you can tell me about how RTS or my specific case will be helped by these changes? I’m trying to make something innovative, but am having to deal with technical compromises I’d rather not have to make. Thanks.

    1. Hi Richard – nothing we’ve shared here is going to be immediately useful in an RTS-lockstep networking archetype. The baseline transport and parallel processing of ECS / Job System can help performance, but the simulation code for an RTS will not be a major focus until we feel great about the “server-authoritative client-prediction” archetype.

      As you mention, strict determinism is a BIG requirement, and it’s something we care a lot about. You’ll see big steps forward towards this over the next year, but depending on the timeline of your game, they may not be soon enough.

      1. Thank you very much for responding so quickly! I am glad to hear there will be progress towards determinism eventually, though I understand client-server model is more popular and a solid choice for many other games, so it makes sense for you to work on that first. If you could release some deterministic feature which would enable lockstep with Unity’s dynamic navmesh magic, that’d be really great!

  12. I am glad that you focus on “perfomance by default” and transparency. In my opinion you are going in the right way. I am sure you are already thinking on it but cross-plataform will be a nice adition!

    1. Thanks Adrian – agreed completely that cross-platform is a critical part of this story.

  13. As with the last post about the new networking system, this is entirely focused on games. Unity is increasingly used by businesses for non-gaming applications, many of which will use multi-user. These often cannot be cloud hosted and must be on separate (non-internet) connected networks. To extend on earlier questions, will there be full support for entirely lan based applications? And if I can sneak in another question – proper support for VR based multi-play?

    1. Hi Nigel – in the past we’ve struggled with focusing on solving too many use-cases at once, and the end result is that we often don’t solve any really well. Even games have a huge range of specific needs, so even within these, we’ve narrowed the initial focus to Real-time Multiplayer Session-based games that can use a “Server-authoritative client-prediction” networking archetype. This is certainly very specific, but a lot of the core challenges we solve in this use-case will speed our progress in future use-cases as we move forward.

      Per LAN-based connections, this will definitely be a supported development feature for the networking and server runtime, and I do not know of any reasons it couldn’t work as a production feature long-term. Services like matchmaking and orchestration are developed and designed for the cloud, but these aren’t particularly valuable for LAN-only games/applications anyways.

      VR is unique in that lagged frames and performance are of the highest importance. Locking a frame to wait for a network packet is just a bad idea no matter the connection speed (LAN or Cloud). Most VR multiplayer titles we’ve seen so far use the “server-authoritative client-prediction” model we are working on today – i.e. the game client continues to attempt to move forward with stale data and then corrects if/when incorrect assumptions were made. We’ve seen both DGS and LAN-based titles succeed.

  14. Is support for windows servers somewhere on the road map? I already have a windows infrastructure and that is the OS I am familiar with. So just wondering if that is coming or if it is not even being considered, thanks.

    1. Windows runtime will also support the “headless” player and will benefit similarly from some of the optimizations in progress today. However, cost reduction in a cloud environment by using Linux is great enough that our self-serve environment will focus on Linux for quite a while.

      We want to offer hosted servers at the lowest possible costs, and that will remain a top priority long-term.

  15. Hi,
    What percentage of the code will need to be changed to switch from unet to the futur API ?
    I am very slow dev, maybe when futur API comes my project “allmost” complete will not be really finished.
    will i need to change everything to make my project work when the next multiplayer code come ?

    1. If the majority of your code is written and working, it’s better to move forward as-is on 2018.3/4 LTS. This version of the API’s will be supported for at least 2 more years (critical fixes), and if you are relying on the Relay, it will remain live until 2020 or later. We’ll ensure there’s a sufficient migration path before that date.

      1. This answer sounds like there will be no nice solution to port existing UNET projects to the new networking library. If this is the case I think it’s very disappointing. Because it’s a punch in the face for projects who are created with existing UNET but still want to keep close to latest unity versions AND want to port to the new networking stack (for good reason).

  16. As part of the effort to make the Unity dedicated servers run better on Linux, I’d love to see IL2CPP support for Linux builds. I’ve heard Unity engineers say in the forums that was put off because the Linux user base is very small, but that of course isn’t the case when you included dedicated servers. If you agree, please vote on my Unity Feedback submission https://feedback.unity3d.com/suggestions/il2cpp-for-linux-standalone-especially-useful-for-cloud-server-efficiency

    1. This is in the Roadmap! Linux support is increasing drastically at Unity today due to Server runtime requirements as well as non-games requirements.

      1. Good to hear! Thanks for the reply. Looking forward to hearing more news on this :)

  17. An out of the box patching system would be awesome. I feel like that goes hand in hand with multiplayer games.

    1. Do you mean client or server patching, or both?

      We do have plans to support development and production versions of fleets, and we will figure out a good pathway for promoting a new server build to the production fleet. Sometimes when an update requires a change to both client and server, we will run into server compatibility constraints, so we will need an answer in both matchmaking and orchestration to ensure clients are only connected with server builds that support them. These are all somewhat complicated challenges, but they are on our radar!

      Client patching is largely determined by the platforms themselves. It’s unclear how much we at Unity can help improve this process, but we’re open to ideas!

      1. Sorry I should have been more specific. Desktop client patching would be amazing. I do understand that most games go through a platform such as steam or origin that provide the ability to update a game, but there are cases where a developer might choose not to. An out of the box desktop patching system someday would be pretty great!

  18. Joshua Rosenberg

    9월 12, 2018 2:38 오후

    Make sure you provide as many visual tools for non programmers as possible. i.e. a system where with nodes you connect sources of data (ie. player inventory, score to a user blob,) and another node connection taking that score and connecting it with a global ranking system.

  19. Robert Cummings

    9월 12, 2018 2:37 오후

    Hi Brandi and team!

    Great to know your plans. Can I help? Want to add it to my game in development. It might be difficult for you as it’s for console and not sure where support is there at the moment :)

    Thank you for the detail in the blog, it’s really nice that you go into detail, and I think we all want that.

    1. Thanks Robert! The very early alpha versions of this tech support desktop (PC/Mac with Linux DGS), and we’re hoping to provide updates as soon as possible to include mobile and console. We’d still love your feedback as soon as it makes sense to you, and we will be in alpha soon.

  20. Richard Kopelow

    9월 12, 2018 2:26 오후

    What if I want to build a client hosted game? Something small like a game jam project or local party game that I don’t want to be spinning up cloud hosting for. Given Unity is moving toward hosted game servers, how easy will it be in with the new architecture to locally host games?

    1. This is my main concern too, would be interested on what the answer is…

      1. Jérémy CROMBEZ

        9월 12, 2018 10:22 오후

        Unity being used a lot by small indie game developers, i’m also curious what is the plan for P2P.
        HLAPI is being deprecated and has been abandonned for a few years already, and the new system is focused on dedicated server, i feel like there will be a few more dark years for those games.
        I hope they just don’t hope everyone use the over expensive Photon solution…

    2. +1 for this

      It is crucial to still be able to do client-hosted games. Partly because it’s useful for development purposes, but also because sometimes it’s the best option for some games.

      I’d just like to be reassured that there will be no obligation to use Multiplay or Google Cloud or any of that with this new networking API, and we will remain free to choose whatever approach suits us best

      1. In this post, we didn’t talk much about anticipated development workflows, but we do know that local and LAN support are important for speed of iteration. This use-case will be supported regardless of where and how you host your game. You may host your game on any servers of your choosing, and we’ll provide fast workflows, fast set-up, and cost optimizations if you choose to use Unity’s orchestration and Matchmaking services.

        Production client-hosted games still fall into the P2P model that we’ve seen many/most games fail to succeed with, so it’s not an immediate priority for us to create a new Relay service to support it. However, there will be nothing in the networking and runtime preventing you from finding other pathways if you are certain this is the best option for your game.

        1. It is vitally important that players have access to the server software. One day, both Unity Technologies and Multiplay will no longer exist, and when that happens people should still be able to play their multiplayer games. Dependence on a third party for server hosting like this makes me really nervous.

          Unless I’m misunderstanding what is meant by the DSG model? (I hope I am)

        2. When you say “server software”, I’m assuming you mean the server runtime (i.e. the code running on a server). The server runtime is completely in the developers’ control – you can choose to use Unity headless runtime, or you can even create a custom server runtime. If at any time, Unity’s hosting service is no longer sufficient for your needs, you can take that runtime and host it wherever works best for you.

        3. Andrew Ackerman

          9월 13, 2018 1:37 오전

          There’s a huge difference between P2P multiplayer and client-hosted dedicated server software. Without support for the latter, a lot of games will die due to official servers going down, dropping support, etc. And there are plenty of examples of successful games with that model, like ARK, Minecraft, Garry’s Mod, 7 Days to Die… hell, even the unofficial WoW hosting servers were crazy popular before Blizzard shut them down. There are much bigger things that make a game is unsuccessful than whether the dedicated server software is cloud-hosted or local-hosted.