Connected Games: general feedback and questions

[Edit: removing old sticky threads as our new SA team begins to manage this forum]

We are committed to making connected games accessible to all creators, and the commitment to solving the breadth of this problem space is a long-term commitment at Unity.

This sticky post will be kept up-to-date with links to talks and blog posts that are relevant to Connected Games as a whole - bolded items are the recommended starting points.

Talks

• "Connected Games: Real-time Multiplayer" - Unite LA 2018
• "Connected Games: New Networking Foundation" - Unite LA 2018
• "FPS Sample Game: Networking Deep Dive" - Unite LA 2018
• “The Future of Connected Games” - Unite Berlin June 2018
• “The Future of Matchmaking” - Unite Berlin June 2018
• “Hosting AAA Multiplayer Experiences with Multiplay” - Unite Berlin June 2018
• Unite Berlin Keynote (Connected Games Announcement) - June 2018

Blog Posts

• "Navigating Unity's multiplayer Netcode transition" - June 2019
• “Multiplayer Connected Games: First steps forward” - Sept 2018
• “Evolving multiplayer games beyond UNet” - Aug 2018
• “Creating Together: Unity and Google Cloud” - July 2018
• “Bringing Connected Games within Reach with Google Cloud” - June 2018

We will monitor this thread for feedback and questions related to the general vision and direction. We are initially focused on solving the “Real-time Session-based Multiplayer” problem space, and we will expand our focus in the coming months and years.

Specific technical topics will be discussed in the following sticky threads - if you have feedback and questions about any of these areas, please post there to ensure the support team members and developers dedicated to those topics see and respond:

• Networking
• Hosted Dedicated Servers
• Matchmaking
• Server Runtime

 

Hey,

here is some feedback.

General thoughts:

• The new focus and increased attention on networked games is exciting. However, IMHO, this step also is absolutely overdue because I think that multiplayer is among the most relevant and exciting aspects regarding video games.
• When current UNET started back in 2015 it was pretty exciting as well. For example, I really like most HLAPI concepts and the simplicity it provides for creating networked games (SyncVars, SyncLists, Callbacks, etc.). I do not yet fully understand the point in the blog that the old HLAPI has been too over-general. Yes, please make it better, more stable, modular, slim and such. And game-type-specific solutions are nice as well. But do not let the good things of the current HLAPI go to waste.
• When talking about HLAPI support, documentation, bug fixes and improvements, the last 3 years were highly disappointing (LLAPI support was fine though). So, the improvement potential is all there.
• I highly appreciate that you plan to closely listen to community feedback. Again, I remain a bit skeptical because this approach was visible for UNET as well. But I guess this time you are more serious about it.

Expectations / needs / hopes :

• Willingness to be flexible and actually adjust/improve your plans based on community feedback
• Support for both dedicated servers and player-hosted servers
• Support for both Internet games and LAN games (even without internet connection at all)
• Fair-priced optional matchmaking options
• Fair-priced optional relay options (in contrast to the current system, using a relay service should be uncoupled from matchmaking, it should be an independent service/module)
• Support for NAT punch through
• Support for Steam
• It should be as comfortable as possible to port existing UNET projects using the current HLAPI to the new networking stack. I’ve spend 3 years developing my project with UNET, incl. workarounds for existing bugs. However, I don’t want to stick with a deprecated networking system. Also, I don't want to stick with an LTS release but instead keep up close to the latest unity releases. So I would like to start porting my project to the new system just as soon as possible. Sure, I’m fine that this will require some considerable migration efforts. However, I do not want to recreate the whole game's network code and architecture. So, I really hope that the new system provides solutions to replace existing concepts such as SyncVars, SyncLists, Commands, Rpcs, different channels, etc. with reasonable efforts.
  
• Don't make a step back regarding essential features.
  
• Yes, ECS might be exciting, but I hope that you do not over-prioritize on this.

Just my 2 cents. I hope that it's helpful. Keep up the good work!

 

I'm very excited about the new realtime multiplayer solution and I would like to know if I'll be able to use it on 2017 version of Unity. My current project has a lot of custom complex shaders and I'm a bit sceptical about the new 2018's version render pipelines.

 

1. What will be the maximum number of players per room?

2. Will it have RPC capability? I love RPC, Please take a look at PHOTON Multiplayer system, i been using that for a number of years, its great!! The only problem is you cant have many people in a room i believe.

3. When will it be ready for beta testing because i sort of need it NOW!

Thanks and have a nice day!

 

Hi Vaschuk - there are not currently plans to back-port to 2017, and your best bet there may be to stick with the existing UNet API's. With any luck, 2018.3 will have the rendering improvements you are hoping for.

 

1. The limit here is how well your server can process and respond to so many inputs, so performance is the literal limit to scale per room / game instance. In theory, a beefy server spec could support at least dozens of players today, but it likely would not be cost effective. Once ECS + Job System + Burst compiler are fully supported (out of Preview) and integrated with the transport, it's our goal to to be able to support much greater scale through 2019.

2. We typically talk about RPC as a potential possibility for service communication (i.e. as an alternative to REST for matchmaking, etc), but it's not often discussed for real-time game communication with a dedicated server. The typical fastest implementations today are based on UDP directly, and in Unity's case, have custom integration with the gamecode and runtime to manage the data transfer. What js it specifically about RPC that you like? For what it's worth, there are also challenges with specific platforms (like xbox) not supporting RPC today as well, so even if we do pursue it for service communication, we will also need to support a fall-back RESTful endpoint for those platforms.

3. Soon in preview/alpha (weeks not months). That said, we are still at the beginning, and many important features will not exist on day 1. We invite adventurous souls to build alongside us, and we'll be here for the resulting challenges and feedback.

 

Hello Thanks so much for your response,

You asked what i liked about RPC, im really a novice still, maybe there are better ways to do things that im not aware of. But the way PHOTON does RPC it makes it easy to make targeted function calls for example calling an RPC function on the master only, clients only, buffered, everybody, specific players only, and many other options is very easy to do. Will the new networking system have this capability, or even something better?

Right now i need to have around 100-300 players or more in the same room. I know that would be difficult, but having a system where synchronization is only done to players within a certain programmable range would possibly help. For example have two programmable ranges or distances. "In Range", and "Out-of-range".

Objects that are greater than the "out-of-range" distance will not get any updates, objects just coming "in-range" will be updated with the current information, and then get only changes as time goes on.

For example lets say the "in-range" distance is 5 and the "out-of-range" distance is 10. For objects greater than 10 meters away, they will not get any network updates. Objects that become closer than 5 will start getting network updates of the players position/rotation/animation etc. when they go past 10 then updates will stop.

This would let many more than just a few dozen people be in a room since most of those people may not be able to see each other anyway. If this could be built into the networking it would be great. Could also combine that with automatic ray casting to determine if other objects can even be seen by other objects, automatically not updating them if they cant be seen, saving bandwidth.

Also priority objects would get updates no matter how far away they were.

You can check out this video on how one company got 300+ players in the same room using photon combined with the technique i described above (I got it from them).

The video starting from time point 18:00 onwards is the interesting stuff about how they got 300+ players in one room.

Any chance that feature, or something similar could be added to increase the number of people in the same room automatically?

 

Is there a road map / time frame for turn based multiplayer? That is what I need for my game. What will be available and when are my main questions...

 

Since we are focused on real-time multiplayer first, it's unlikely that we'll have sufficient bandwidth to tackle turn-based until later in 2019. That said, it depends a lot on how quickly we can build out the team, so maybe we will get lucky with hiring and get there faster. Too much is still unknown to provide a detailed roadmap; that will hopefully become more concrete in the coming months.

 

Will the new multi-player be something like this

 

Honestly, it's a solid talk, and there are many things that will be similar, a few different, and some that aren't completely decided yet. The key concepts overall are great though:
- Separate simulation from presentation (in future both should be feasible and separable in Unity)
- Only send/receive data that is relevant to a particular user, and compress to only what has changed
- Write super-performant code to maximize the number of players, AI, objects in a single server/cluster (we will likely rely on entities / ECS over objects to achieve this)

We're gearing up for a lot of talks at Unite LA, so there should be *some* more details soon, though likely not everything you are looking for just yet. The feedback is great though, so thanks!

 

Hi, I am really an amateur in both Unity and Coding, my first concern with online games/multiplayer is usually cheating and hacking. So I guess: data mining server code, memory hacking, protecting game files, code-encryption, client authentication, locking files, etc...
In this regard, since you are developing a new multiplayer ecosystem, with ECS, it would be interesting to know if you could attempt to implement ways to simplify anti-cheat functionalities and prevent hacking.
Also how do you think ECS will make it harder or easier for the encryption of data that is communicated between the server and the client?
Finally, does all this limit the potential tick rate of matchmaking?

Thanks for the awesome work! Unity evangelists are great, looking forward to try a production version of Unity connected games ecosystem.

 

If you don't trust client input then it won't matter if they hack the client. Validate everything on the server and you will be fine.

 

I think what vis2k means is that if you *only* trust the inputs from the user, but none of their simulation, some aspects of security get a lot easier. Having a hosted server does mean that you can prevent cheating by just never trusting the simulation running on the client (i.e. you trust the input - they moved the left thumbstick x amount, they pressed "y" key, but not simulation outputs - they inflicted 5000 damage on playerB).

Beyond modifying simulation data, there are many other security concerns to consider, but even this is a great start and is sufficient for most games.

 

Hacks like aimbot, single shot weapons behaving as fully automatic, recoil compensation macros, etc, are a result of trusting the input from the user even when not trusting the user's simulation. So game types prone to cheating based on just the player input (twitchy FPS games for example) need to make input validation as much a part of their cheat prevention as anything else.

 

Imho this is something to worry about after release, if your game actually makes it and actually gets big.

There is no value in spending half a year on client sided aimbot/recoil protections if your game never sees the light of day. And for most of us here, this is the part where we failed in the past.

If your game gets so big that it attracts cheaters, there are lots of existing options too. A custom Themida license will get you very far. Virtualization in general is very difficult to deal with for the average hacker.

Even Counter Strike didn't manage to get rid off cheats. But they still made millions, and people do love the game.

 

Would it be possible to make a separate forum for the new network stack? I know the staff are keeping tabs on the sticky threads (thank you!) but it really deserves its own space. Even if it's just a sub-category in the beta area, that'd be helpful.

 

I'm beginning to think it's intentional as it's difficult to read, thus to talk about. It's such an important project but oh well..

 

I get the frustration, this is still very early code and information is kinda fragmented right now, but the folk working on this do seem to care about getting it right this time!

Anyway, between the deprecated LLAPI, 3rd party stuff, the community efforts, and the new one... there's a lot of info overlapping here in "connected games" and it's not always clear at first glance which threads are about which. To encourage new users to chime in and participate, a dedicated area would be great.

 

Thanks for the feedback; I think it's a good point that we should do some work to better organize everything under the header of connected games. We're in the midst of 2019 planning, so it may take some time to get to working on a forum update. Thanks for the patience.

 

in the current HLAPI, it looks like work was started to use a new transport layer (based the the GitHub commits for 2018.30 for this new networking (IActiveTransport)). what are the plans for this? it was all made obsolete in the same update. is someone still creating that? I'd assume the idea would be to allow the unofficialunsupported use of HLAPI.

I built a prototype project solely on HLAPI and lobby manager, this would solve my problems totally.

and yes, i'm aware of mirror, looks great but it needs a lot of manual work on the lobby side for me to just use it, thanks.

 

We are still investigating what it will take to adapt the HLAPI to use the new transport (i.e. so in-progress games can keep using HLAPI if they need to once the LLAPI is removed from the engine). It looks like it should be feasible, but we are not announcing anything more concrete until we've finished investigating this possibility.

 

For those generally following Connected Games - at Unite LA, we had a heavy focus on real-time multiplayer technologies, especially networking. Here are the 3 new related talks posted to Youtube yesterday:

• "Connected Games: Real-time Multiplayer" - A review of topologies, protocols, and services related to networking, and thoughts about our goals/priorities as a result.
• "Connected Games: New Networking Foundation" - TimJ (our networking lead) gives an overview of the new transport, its goals, and some initial thoughts about how we foresee future networking packages will leverage ECS, Job System, Burst etc to provide the scale and performance required for today's games.
• "FPS Sample Game: Networking Deep Dive" - Peter (our sample game lead) reviews the "reference implementation" of a client-prediction / server-authoritative implementation shown in the FPS sample. This code will inform future generalized systems, and can be used today as an example for devs eager to get started with similar types of games.

As ever - feedback welcome!

 

Will we soon have an official documentation and also a more accessible example project to study with?

 

that's cool I appreciate us HLAPI dependant not being forgotten. I use the couch co-op facility to allow multiple players(controllers) from each client to connect. is this still going to be in the new networking stuff one way or another?

 

If I’m not brave or talented enough for alpha, can I still get started on a game now? If I make a local multiplayer game can I later convert it?

If it maters my game will be a 2d 5v5 arena game. It will be free to play and incorporate purchasable in game currency and an in game store. I also would like crossplay between all viable platforms (analog stick and 4 buttons). I don’t need true crossplay as in incorporating Xbox live ps plus etc.

Do I have the right idea for how to start now? Do I need to wait to incorporate any online or is there a way to utilize something existing and not in beta in a way that it is easily replaced when connected games is out of alpha and/or beta?

 

I managed to convert my game pretty easily. The only thing the new transport layer didn't account for is the
NetworkDiscovery class which can be used to broadcast a game over LAN. It would be really nice if you could expand the new network api to at least make it possible to achieve something similar.

 

from HLAPI to something else, or just to the new transport layer? did you retain everything?

for me, HLAPI enabled me to do what I needed, I wanted to make a game and not code a lobby and matchmaker which is currently beyond my skill set and not very interesting to work on. the only issue I ever had getting it running was lack of understanding what was going on because I couldn't step through it, which I solved by using the source code on bitbucket and making copies of the classes that I could step through.

 

My apologies for cluttering this thread. I am in the very early stages of 2 different projects that would need to make use of the new networking system. One project team wants to move to Unreal (an FPS) the other (RTS) wants to stay with Unity. Both are leaning towards the MMO scale.

We have not started any network work as we are in the very early stages on both projects and have only a little on the glass for each.

I wanted to find out if this is in the latest release (have not downloaded) before I pull it down and dig into it and migrate projects.?

 

How do i get started with using this new networking system? My project is halfway done, and i am waiting for the new release of this new networking system.

 

:/ Not sure why my question/post has been sitting for over a week and skipped over to answer other questions. I'm being serious and have a game on the android store right now, getting ready to make a project for console and PC. If my post was out of context of the thread or rude or otherwise has issues I don't know what they are.

 

Thank you for responding.

So does that mean I can make an offline game in say 2018.9.18, and when connected games comes out I can utilize it without any compatibility issues? Just like scmulagah, I will be waiting for tutorials. If I understand the vision/direction of unity connected games, it's going to be easier to learn to use than existing networking methods? Connected games service will be my first attempt at creating anything networking involved.

 

Thanks. Cant wait to get started to work with it.

 

We are currently developing a new MMO game, should we get started with Unet and make the conversion later on? Will connected games be similar to Unet implementation wise?

 

Hi Jackt,
Thanks for the suggestion, I assume I can get the new network transport layer from Unity 2018.3?
Edit: Nevermind, I found it here https://github.com/Unity-Technologies/multiplayer
It seems it only has the low level api right now, any estimate when we will get the high level api?

 

Hey, thanks for that, sorry I have been away from Unity for a while back in the days when Unet was just introduced I halted this project waiting for Unet to mature in development, now when I'm back it is already being deprecated
But Now I know what options I have available. I will keep using Unet for the meantime, because to be honest, its High level API implementation is brilliant, yes it has problems, but it is still powerful.

 

When will the new networking system of unity come?

 

Thank you

 

I read source code, FPS Sample and network transport layer.

Perhaps I may have misread it, It seems that security(encryption of packet etc...) is not implemented in these.
Normally, packets are block ciphers such as AES or you use stream ciphers like TLS (DTLS is good for UDP).
Does this intentionally do so? Or is it planned to be implemented in the future?

I am new to English, so please forgive me for using Google Translate.