[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.
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:
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.
What will be the maximum number of players per room?
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.
When will it be ready for beta testing because i sort of need it NOW!
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.
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.
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.
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.
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).
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.
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.
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 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.
