As you have probably seen in other threads, we like to check in on the direction we are taking with our technology to make sure we are best serving you. In this thread we would like to discuss the direction of our Multiplayer system with you. Instead of restating the long term planned phases and short term projects I’d rather just step back and listen what you all have experienced and what you all are needing. Knowing a bit about you also helps us better understand your feedback so please consider the following questions to get this discussion started.
Who are you?
What kind of game are you trying to build or would like to build?
How does Multiplayer fit into that? What use-cases do you have?
What are the GOOD things about the new Multiplayer system you like?
What are the BAD things about the new Multiplayer system you dislike?
I am a hobbyist and grad student in an unrelated field.
Picked up unity about a year ago just to try to play around with it and got hooked. A couple months ago I started trying to learn Unet to continue my project which hopefully will turn into a small multiplayer RPG I can play with my friends and continue to expand.
As a hobbyist and beginner I don’t expect to generate some extremely well made MMO, just trying to work on the “game I always wanted to play”. I’m doing all artwork, code, and design by myself so it’s very slow, but the goal is a small dedicated authoritative server that me and a few others can connect to and I can continue to expand as a hobby, anything further than that is just icing on the cake.
The good about Unet? I tried Forge and PUN networking prior to unet by forum advice, this was a while back and I think Unet was still very young. It felt completely over my head and I could not get anything nailed down. I ended up giving unet a shot because I really wanted to stay within the supported unity framework and I had networked movement for my 2D top down game working within an hour with no experience. I was blown away. Since then I’ve managed to develop that movement into server authoritative movement with client side prediction, which works really well testing over the relay servers. I’m really pleased with how easy it’s been for me to learn, and once I’ve gotten some of the basics down, it’seems started to feel like less of an impassable wall for a beginner programmer. Though I see a lot of complaints, unet is my first dive into networking, and it makes sense to me the rules that are in place. I like that commands and rpc’s work the way they do, and that it’s easy to see exactly what is running server side and client side.
Some things I would improve on:
Clarity, I think. I find it slightly confusing that we have both overrides for declaring local player starts and servers and things like that, but also have attributes to do the same thing. I realize they are accomplishing different things but this has been something I’ve seen multiple complaints about.
Of course, number one thing people seem agitated about is the documentation. I at least like to think I’ve gotten most of the HLAPI to a point that I understand what’s going on, but there are things that are unclear to me. One example would be SyncVars: what exactly are the allowed data types? If I remember correctly, it states a general list of things in the documentation and ends with “like vector3’s”. In my experience it also doesn’t throw any errors when unacceptable data types are used here or in commands, which can cause some frustration. One other question I’ve had is that SyncVars send out to clients anytime the field value is changed on the server. Is this bound by the send rate? And is this defaulted at 0.1s? If so, what happens when the value changes more often than the send rate can accommodate?
Anyway, for someone like me, I’m extremely pleased with unet and what I’ve been able to learn and accomplish with it. I think the things above if improved upon would vastly make it better. A lot of the issue I’ve seen people have with Unet is just understanding what to do because it’s often necessary to dig through posts or watch tutorials to know exactly what’s happening at times, and what to do.
Also, if this is valid to include as well…
For myself, I really would love to know the end game steps to taking this beyond the relay servers and be able to host my own small server. Is this what the “server library” on the road map is for? Is there any information on this available yet? I realize I can just do a headless build now and allow players to connect but I just don’t have any info on exactly how to accomplish this.
First, thanks for this thread. I think it is a good and necessary step.
Personally, I am a hobby indie video game developer working on a coop multiplayer FPS RPG game for PC. For this type of game, multiplayer is one of the most essential aspects.
When UNET was first introduced last year, I had nowhere to zero knowledge of network programming. So I got myself some books, read through all available online documentations and watched some youtube videos. A little time later I found it quite amazing that I had managed to implement basic working multiplayer with UNET. Personally, I am fine with the HLAPI concepts of SyncVars, Commands and ClientRPCs and I think they are quite easy to use. Thus, I can say that this part of my personal experience has been quite positive.
On the other hand, I have experienced that there were a lot of bugs and documentation was/is significantly lacking. This would probably be my biggest complain. What about custom NetworkManager implementation examples? What about bandwidth-optimization? What is going on with NetworkTransform? What are best practices for specific types of games? Etc.
To be more specific, here is a list of potential fields of improvement.
You have just released a new tutorial in the docs. This is good to see, but the tutorial is very basic. Of course this is great for beginners, but I feel we have a strong need for more advanced docs. I would also like to see official UNET developers being much more active in the forums. Then you can collect most significant open issues and get an idea of which priorities need to be set. I would also suggest to go through the threads and collect relevant information in order to transfer them to the official docs.
The object destruction flow is not sufficiently documented for non-player objects. I’ve pointed to this issue here. This is 3 months old and still has not been addressed yet even though I think it just requires some more lines of documentation. I could be wrong though. Anyway, this is just an example and my point is that there still might be some potential to improve the speed of reacting to community feedback and for implementing improvement measures.
I think the default NetworkManager and NetworkManagerHUD components are fine for prototyping, but many serious games will soon need custom NetworkManager implementations. However, from my view there is too less documentation on how to implement those with all the callbacks and such. At least I found this very difficult to do and I had to do much trial and error myself. So improving the docs on NetworkManager might be valuable measure.
I have learned a lot from GTGD awesome youtube tutorials. They are great but also contain some experimentation and guessing. No wonder because many aspects had to be guessed at this time because of the lack of documentation. Anyway, I think there should be much more official UNET tutorials directly from the developers. Tutorials can be either documents or videos - preferably both. While I think that docs should be finished first, I also think that videos have strong advantages. Tutorials should also feature advanced knowledge, best practices, etc. Also, different approaches should be discussed like pro’s and con’s doing stuff on server or client, how to set sendRates, where to best put client-to-server transmission, etc. There are so many (important) details, which currently are just not covered by the docs.
In the HLAP, the option to send a ClientRPC to one single client somehow feels missing to me. I think this should be added.
Matchmaking is currently in beta. Given the current information in the forum, the current concept sounds reasonable and quite fair to me. Anyway, it would be nice to have more information soon because this is just a very crucial aspect, especially for near-production-level games.
Some out-of-the-box components like NetworkTransform are currently disappointing. Documentation is completely lacking here. What do the parameters do? How to set them? What about interpolation for non-rigidbody player controllers? Currently, for implementing smooth and efficient network transform synchronization, a custom solution seems to be the better choice. In future, I would like to see a NetworkTransform with options to use most efficient bandwidth optimization, optional client-side prediction and such.
I would like to see information added to the docs about persistent storage of player stats and data in the cloud. Unity is supposed to make it easier to develop games. And cloud databases are required by mana games. Even if this is not directly related to UNET, it should be covered somewhere, at least on a high level.
Thanks to seanr for the many examples projects he posted in the forums. Nevertheless, I would like to see example projects to be more polished, being updated and being integrated and connected with the documentations. Also, while example projects are highly valuable as learning resources, it would be nice if they are also usable as drop-in-solutions without any bugs.
We definitely need options to measure bandwidth consumption and network traffic. This is needed for optimization, especially considering that the matchmaking and relay server have bandwidth limitations and likely CCU costs in future. We also need hints and best practices on how to optimize network traffic. Personally, I could get great help in the forums on this, for instance here or here. Maybe such kind of information should be available in the docs as well. Again, I recommend to have a UNET dev check the forums, collect questions and transfer relevant content to the docs to put it in adequate structure and make it easily accessible for everyone.
[Update:]
Added 2 things which I would consider top priority:
- NAT punch through with optional relay server fallback - Steam Integration
Please don’t lose the pace and improve UNET because I truly think it can become something amazing. Also, I hope that it proves stable enough to use it for production level soon. IMHO networked multiplayer gameplay is one of the most magical aspects of video games so it deserves as much attention as possible.
How does Multiplayer fit into that? What use-cases do you have?
**MMO**RPG
What are the GOOD things about the new Multiplayer system you like?
The basic architecture of UNET is perfect in my opinion. SyncVars, SyncLists, Cmds, Rpcs etc. are exactly what is necessary. Having the server and client in one project seemed weird first, but is a blessing now.
What are the BAD things about the new Multiplayer system you dislike?
UNET feels a bit abandoned right now. We don’t really know who is still working on it or what they are working on. Nothing really seems to be done about all the issues that pop up on the forum.
How can we make it BETTER?
Make it more stable and (always) fix all bugs before adding new features. We are all trying to make multiplayer games used by hundreds and thousands of people. Any networking bug will be a nightmare to deal with.
Here is a more detailed list that I already sent you a while ago. Ordered by priority: SyncList critical bug
I have been losing my mind over this for almost half a year now and I encounter
it every now and then again. I know how to work around it, but others might just
give up on UNET all together when encountering this (I almost did too).
It affects uMMORPG too, because I have to rename the Skill.cs file to
BuggySkill.cs, ironically that file name works.
RPCs
in short: people shouldn’t have to write custom messages to reach ALL or ONE
client, this would be HUGE. and ClientRpc is only for observers, documentation
says it’s for all clients.
note: seanr mentioned working on a [TargetRpc] already.
hosting
most people don’t know/don’t care/don’t want to deal with hosting their own
servers. Perhaps Phase 2 and 3 solve that problem already, I couldn’t find much
information on that.
in short: hosting with ddos protection, admin start/stop panel, ram/cpu info,
fast enough hardware and seeing the log (perhaps highlighting errors like in the
unity editor console).
more players
again, this might be solved by your Phase 2 and 3.
Unity scripts run in one thread, which turns out to be very useful for
networking. I love not having to worry about concurrency issues.
this means that bigger servers can’t really scale with many players, there is
always a cap where we depend on 1 CPU core mostly. so we would need either:
a) more unet concurrency in the back end, without us having to deal with it so
that we can really make use of 4, 8, 16, 32, … cpu cores. this would be
very cool to work with while not worrying about multiple server instances.
b) multiple servers with multiple scenes and teleporting players between them
did not find target for sync message
sometimes there is a ‘did not find target for sync message’ warning which is
very confusing in the beginning. I had a situation where an arrow with a
networktransform would fly to a target, deal damage and be destroyed. now
because I didn’t use a ‘sequenced’ channel, the client seemed to still receive
1 or 2 messages after it was destroyed alread.
I couldn’t figure this out for the longest time, because the message only shows
some kind of id. it would be a LOT easier if it also shows the object’s name,
like ‘did not find target for sync message for Arrow’. it could also have some
kind of hint that this might happen when messages don’t arrive in the right
order and that the user should consider using a sequenced channel.
on a side note, most unet errors are not very easy to track down, there should
be more explanations/solutions in the docs or in the error message itself.
headless server logging
running a headless server from the terminal should show all the log, just like
the console does. looking at log files or doing the tail -f thing gets old
really fast, especially when running the server on a VPS. right now it kinda
‘feels’ like I never really now if there were important errors etc.
movement prediction
this might be solved by your new network controller, not sure.
I currently only use click movement and synchronize the navmeshagent.destination
which will be somewhat delayed when the server is far away from the player.
The same goes for WSAD movement, where every little delay will pretty much make
any WSAD movement extremely frustrating for the user.
both cases would benefit from movement prediction. we either need some kind of
component or some kind of documentation about the best way to implement that.
[Server],[ServerCallback],[Client],[ClientCallback]
I did some 1on1 lessons for UNET, and everyone is really confused by those 4
attributes and never knows when to use which version.
I suggest something like [Server] and [Client] with an optional parameter like:
[Server(showWarnings=true)] to replace [ServerCallback]. This would simplify one
of UNET’s core concepts a lot.
Calling [Command] from the server
Calling a [Command] function from the servers gives an error because it should
only be called from the client, which makes sense.
Often times we do want to call those Cmd functions on the server too, for
example: I have a ‘CancelAction’ function. A client calls it if the user presses
the escape key, but sometimes a server also needs to cancel a player’s action
when he is stunned etc.
Right now I work around this with a wrapper:
[Command]
public void CmdCancelAction() {
CancelAction();
}
[Server]
void CancelAction() {
// do things. this can also be called from the server without errors.
}
It’s not critical or anything, it just leads to ugly code. Perhaps something
like [Command] and [Command(showWarning=true)] would be more useful here.
NetworkTransform is laggy
The NetworkTransform interpolation is laggy, but I am sure you know that already
NetworkProximityChecker collider
I noticed that the networkproximitychecker component needs a collider on the
same GameObject, otherwise it becomes invisible.
(to be more exact, the Physics.OverlapSphere call returns a collider and your
networkproximity component requires a NetworkIdentity on that same object)
any game with animations will most likely have a collider on a child object
though, for example on the skeleton’s pelvis object. this way the collider
always follows the animation, so that a dead monster doesn’t have a collider on
the standing position, but properly around it in a dead position etc.
(note that it’s sometimes also on a child’s child etc.)
I noticed two ways around this:
a) make Physics.OverlapSphere’s hit.transform be the root object’s transform like Physics.Raycast seems to do. Physics.raycast always returns the root Gameobject for me, even though the collider is on a child like I explained. Physics.OverlapShere only returns the collider on the child though. and since your proximity checker looks for a networkidentity on the SAME gameobject, it won’t find one because we are on the child.
b) modify the networkproximitychecker to also look for the NetworkIdentity component on any of the parent objects. this is kinda not that elegant, but it’s what I used as workaround to my animation collider problem:
...
case CheckMethod.Physics3D:
{
var hits = Physics.OverlapSphere(transform.position, visRange);
foreach (var hit in hits)
{
// (if an object has a connectionToClient, it is a player)
//var uv = hit.GetComponent<NetworkIdentity>(); <----- DEFAULT
var uv = hit.GetComponentInParent<NetworkIdentity>(); // <----- MODIFIED
if (uv != null && uv.connectionToClient != null)
{
observers.Add(uv.connectionToClient);
}
}
return true;
}
...
Network.time
we often need to know the network server’s time. for example, my skill class has
a ‘cooldownEnd’ property which is just a time at which it can be cast again. now
this time is based on the server’s Time.time. The client’s Time.time is always
different, so clients see weird cooldowns.
It seems like the old networking system had a Network.time property, but that
doesn’t work with UNET obviously.
I worked around this by having a ‘NetworkTime’ GameObject in my hierarchy with
the following component:
using UnityEngine;
using UnityEngine.Networking;
[NetworkSettings(sendInterval=60)] // resynchronize every now and then
public class NetworkTime : NetworkBehaviour {
// add offset to Time.time to get the server time
public static float offset;
// server-side serialization
public override bool OnSerialize(NetworkWriter writer, bool initialState) {
writer.Write(Time.time);
return true;
}
// client-side deserialization
public override void OnDeserialize(NetworkReader reader, bool initialState) {
offset = reader.ReadSingle() - Time.time;
}
}
so that I can calculate the server time on a client by using
var serverTime = Time.time + NetworkTime.offset;
So anything like UNET.timeOffset of UNET.serverTime for clients would be highly
useful.
A way to save data before closing the server
If I run a server from terminal or in a window, I sometimes need to close it.
If I close it, then OnDestroy is called, but 90% of the time it’s too late to
still access player connections / player objects and save them properly.
Something like a ‘OnServerQuit’ function that is called early enough to save
player data would be very useful, especially for MMORPG servers we never want to
lose data.
The current workaround is to save all player data in a small interval like 10s,
and to use some kind of custom chat command that is called from a client. But
that’s just a lot of trouble for something that should be simple.
WebGL crashes in case of UNET errors
I didn’t test this lately, but some (if not all) UNET errors completely crashed
WebGL without any stack trace. This makes debugging very hard. I remember that
it happened because of an error where UNET tried to access a SyncListStruct at
an invalid index. The index was invalid because of the SyncList file name error
that I explained above.
NetworkAnimator
Even the improved NetworkAnimator is still not really usable for my project at
least. I use very simple animation controllers with a few parameters and
triggers, but often they are not synchronized to clients properly etc. Also I
have to use
GetComponent.SetTrigger
GetComponent.SetTrigger
whenever I call a trigger. It would be better if I just attach a NetworkAnimator
component and not have to worry about it, just like the NetworkTransform.
SyncList FindIndex
SyncLists don’t have a .FindIndex function, but since they are structs, we often
need to find an index and modify things. It would be useful if they had this
function. I guess I can implement that with an extension, but still.
SyncVars can’t be null
I didn’t test this with the latest version yet, but I noticed that when using
[SyncVar] NetworkIdentity test;
that I get UNET errors when setting it to null. I don’t use that in uMMORPG
right now, but I will create another test project if I encounter it again.
Overwriting NetworkManager functions
The documentation should probably mention that when overwriting NetworkManager
functions, we should always call base.OriginalFunction() in our custom one too.
I got the weirdest UNET errors when not doing that in the beginning.
networkmanager customconfig
the networkmanager’s customconfig should be editable in the inspector. otherwise
using a custom config is really weird and we have to pass it in StartHost etc.
Bitbucket is outdated
Bitbucket sources for UNET are not up to date. it would be useful to always see
the latest sources to be able to use/modify newer features. for example, I read
that the new NetworkManagerHUD has a button that stops the connection attempt. I
could really use that in my project, but I don’t see the source for that yet so
I can’t add it to my custom NetworkManager UI.
NetworkManagerHUD GuiLayout
This is really not important, but I noticed on BitBucket and by looking at it
ingame that the NetworkManagerHUD had some weird spacing issues because you
don’t use Unity’s GUILayout. Instead you use space+=20, do stuff, space+=… etc
To be honest, it looked like the intern wrote that part, not very professional
like the rest of UNET.
performance infos/tips
any performance info/tips would be useful in the documentation. I don’t really
know if UNET does anything in an extra thread or not etc. or what to watch out
for besides the obvious.
I’ve been using UNET since roughly half a year, for personal proof of concept projects. I like to code most high-level networking logic myself, so the NetworkMessages seemed like the perfect fit. All that I expect from the underlying API is a robust delivery system. A system with low overhead that just delivers my data. That allows me to focus on optimizing network traffic on the high-level (when and how much data is send) and not worry about the low-level (how network packet traffic is done).
The good things with UNET is that for me NetworkMessages were the perfect networking solution where I can have both high-level data objects and decide when to send data. I’ve never used the HLAPI such as NetworkTransform etc as I like to keep 100% control of data management and tailor the network exactly to my needs.
The bad part of UNET is while it works perfectly initially, once you go for real-life application (where you have lots of clients) you start running into issues. When I send a NetworkMessage I expect it to be send, not throw some bug about no free events or 16bit buffers. Else what is the point of using high-level NetworkMessages when you have to worry about buffers and message queues?
Which brings me to my next point: documentation. It’s bad. really bad. There are parts of UNET which give just plain wrong documentation (which is worse then no documentation at all: GetCurrentOutgoingMessageAmount() im looking at you). We have forum threads and unity questions about UNET issues which after some attempt of “Do this, maybe it solves your issues” are left without a solution.
UNET works fine as long as you don’t test it with large amount of traffic. Then it falls apart. Random disconnects etc.
Using the QoS.StateUpdate there is a 20-30% “packet loss” (as in not send or discarded) depending on the update rate. And thats on localhost where the actual network packet loss is 0%. Also as there is no StateUpdateFragmented what do you do once the StateUpdate Message exceeds the MTU? You can’t really split it up manually as the first part would just get discarded.
So how can you make it better? Do some stress testing and provide a configuration where NetworkMessages can handle at least 50CCU at an update rate of 20 on a localhost machine. And please don’t just use NetworkTransforms, use actual NetworkMessages. Giving a configuration which is capable of achieving that (or even better, making that one the standard) would probably drastically reduce all the threads asking about “no free events” and buffer overflows. That’s better then going into every thread and saying “So uuhhm did you try SetMaxDelay ? Oh you did? …Well good luck then”.
A networking solution should be capable of supporting a big amount of traffic on localhost out of the box, and I really hope you can make it work, because since I’ve made the switch from uLink (and before that lidgren, photon and smartfox) I was really happy at how easy it is to transfer data between unity client and server.
Thanks for opening up a dialog I really appreciate it. We love Unity5 at Anjin and want to contribute.
Who are you?
Anjin Games is a small full time indie studio run from Brighton in the UK. We have been using Unity for quite a long time and multiplayer is a big part of our success. Our app has over 2/3 million downloads and people say this is due to the multiplayer capability.
What kind of game are you trying to build or would like to build?
DeadBotz is our third person shooter on Android featuring singleplay/multiplay/lanplay modes. The game has console quality graphics and is heavily optimised for Android.
We are live on the Play Store and have been using Unity5 since the middle of last year. We launched in September of last year using Unity 5.1. We would like to use Unity 5.3.3 but can’t due to a problem with the current masterserver code.
How does Multiplayer fit into that? What use-cases do you have?
We have two use cases for a Death match style game between 8 players.
Internet play: We use the masterserver concept to connect people over the internet to Anjin servers which run server versions of the game ( this also uses the NAT facilitator)
Local Lan play: Players can set up their own server locally and connect by specifying IP address
Essentially we use a system where each player owns its own data and that distributes the load so that a handset can be a server. We need fast updates and use a mix of RPC and synched network states to transmit position/ actions/spawning of each player.
This is the singleplay game but you can get an idea of what it looks like-
What are the GOOD things about the new Multiplayer system you like?
we liked the concept that all the difficult stuff is taken away and done for you. The idea of this being managed by professionals who would shield us from nasty DDOS and provide a distributed global network (if I understood correctly) is a good one.
we liked the lower level access if it was necessary.
a master server was not needed if I understood correctly.
What are the BAD things about the new Multiplayer system you dislike?
It was confusing to understand how to migrate from the old RakNet system. Would be better if this had been a managed migration.
It is unclear if this is a fully baked product yet. Numerous forum comments suggested it didn’t work and that there were show stopper bugs.
no NAT support. I may have misunderstood but the lack of support for NAT is an instant no-go for us. Perhaps the new system does not need it?
The Linux implementation had a very bad bug which causes munmap crashes. Its fixed but cant work with the masterserver anymore.
If the server infrastructure is run by Unity this makes things very difficult to test.
How can we make it BETTER?
Bug fixes to ensure the product is stable.
provide a migration path from a working RakNet system to a working UNet system.
Options for people who want to run their own servers/elements of the infrastructure.
Have a low cost/no cost implementation for testing or games that have few online players.
What are the BAD things about the old Multiplayer system ?
no ability to exchange information unless the systems were synched. This makes it very hard to tell the client what level to load. We had to re-architect the game and use donotdestroyonload magic.
Buggy and compiling the master server code was near impossible.
If you would like to know more please send me a message. We are currently getting a lot of hack attacks so I can’t outline the whole architecture publicly.
a teamp-of-one studio trying to build 3rd person, multiplayer online games, for niche groups.
uNet is a big part of this, providing it scales up nicely. I use the LLAPI alone, creating my own higher level system on top of it. Dedicated Unity instance servers running headless (on a linux host) are my personal preference, as I can use the same terrain/colliders on the server but without any graphics or rendering.
So far it looks good, though I see other people having problems when there are more connected clients. I hope this isn’t a big issue, or one that will be resolved. I would certainly like to see some libraries suitable for HLAPI and LLAPI that contain methods for latency/loss/burst smoothing, better methods for broadcasting to specific subsets of clients for given criteria, along with added solidity. I think everyone wants a solution that is rock solid.
As far as suggestions, I would like to second the request for built in automatic port forwarding and nat punchthrough. It’s something I really miss from the Unity 4 days with the NATFacilitator. Other than that I would just love to see all of the documentation updated and expanded. It still seems like there is so much missing or outdated.
It would be nice to be able to update match info after a match is hosted so that if we’re storing any meta data in the match name for example we can keep it up to date.
Please please please allow us to set the port that a client connects from. Or at least let us set the transport level host id that the client uses to connect.
Also see my signature, it would be nice to see the source for some of the HLAPI stuff so that we can see how it utilizes the LLAPI
Thank you for asking for our feedback. We hope you will take it to heart and let us know what you plan to do based on it. We love Unity!
Who are you?
We are an independent studio working on our first game. I do the development and my partner does the art. I have been using UNet since it was released.
What kind of game are you trying to build or would like to build?
We are creating a 2D, side-scrolling, action RPG-like, rogue-like, procedural-like game. Single player or up to 4 or 5 players online.
How does Multiplayer fit into that? What use-cases do you have?
Playing with your friends or with anyone online adds additional variability to playthroughs, as well as a sense of togetherness… and, therefore, awesomeness.
What are the GOOD things about the new Multiplayer system you like?
Our players won’t need to worry about setting up networking, opening ports, or finding complementary software to “make the multiplayer work”
Not having to learn networking
It’s a native Unity service, so it can be trusted
It’s not hard to implement once you spend enough time learning the new concepts it introduces (SyncVar, Command, ClientRPC)
NetworkTransform does a lot
What are the BAD things about the new Multiplayer system you dislike?
Feels unstable (existing bugs)
Errors arise in the console that are sometimes ambiguous and unclear if it’s programmer error or a bug
A lot of trial and error was required to figure out the flow of client and host communication (the nature of SyncVar, Command, ClientRPC)
We feel unsure about what features to expect or what the future holds for it
Documentation lacks explanation and examples in many places
Getting answers to questions in the forum is difficult or impossible
Many of the sample projects from Unity are without helpful comments
How can we make it BETTER?
Thank you for the many sample projects, though video tutorials and live streams would make it easier to see how things fit together
Move the NetworkLobbyManager standard asset out of beta and make it so it can be dropped into an existing game, menu and all (right now it is coupled with a space game and requires a good bit of work to separate)
Sync physics, or at least something built in that approximates doing this
Something that would be a huge help is being able to see a script lifecycle flowchart for UNet, like the one for Unity on the Execution Order of Event Functions page
Be verbose when providing information in the docs and in comments in sample projects (this cannot be stressed enough… give us a fish, we eat for a day, teach us to fish, we eat forever)
Provide a roadmap in an easy to find place (there may information from Unity scattered in the forum, but it’s hard to find)
Guidance on how/what to sync so that the game is being efficient so as to keep costs in check
Guidance on how to come up with the values for the new Multiplayer monthly cost calculator
Who are you?
Some bloke pretending to be a hippo ineffectively.
What kind of game are you trying to build or would like to build?
Medium sized console game.
How does Multiplayer fit into that? What use-cases do you have?
We will use it for melee combat, racing and shooting elements.
What are the GOOD things about the new Multiplayer system you like?
Not much. I thought it would be good, but it ended up conflicting and confusing (HLAPI)
What are the BAD things about the new Multiplayer system you dislike?
Hard to understand the thinking.
Made much worse by multiple conflicting things. Such as [Server] and then vars to check if is server. which, what? What’s going on?
Syncvar magic is confusing. Lack of trust, hard to debug.
HLAPI seems more confusing than LLAPI.
How can we make it BETTER?
Copy Photon or TNet for HLAPI.
Make things clear. Networking for HLAPI isn’t about choice. Since networking is a really confusing and a brutal subject, you want to dictate to users. You want to say THIS is how you do THAT. You do not want to give us a million optional ways or hints. That will confuse people. LLAPI Greybeards will ignore it and be fine.
Examples have wildly different programming styles and advice. At this point I was ready to give up.
I Want authoritative clear guidance, I am not very experienced in networking. I have made networked games in Photon and TNet though. I managed it with UNet but the resulting mess left me at a loss in some places. Way too much guesswork. I would have liked a voice that said “you do it this way, and this is the real, recommended proper way to do it”. I need that, networking needs very direct answers.
Who are you?
I’m a software engineer from that’s worked in Silicon Valley for about 15 years, mostly in mobile client-side development at startups, but also more recently worked on developing backend personalization platforms. I’ve shipped a couple of games before but never aggressively tried to monetize them. Been working fulltime on my new game for about 4 months at this point and am hoping to make it into a modest commercial success in the hopes to go fulltime as a gamedev permanently.
What kind of game are you trying to build or would like to build?
I’m building a competitive multiplayer 3D FPS set in a procedurally generated cave called “Dwarf King”. 8 players maximum. Lots of melee fighting, and no guns (but some projectiles/explosives). Full inventory management + crafting, which will play a large part in match win conditions in some game modes. Targeting PC/Mac/Linux.
How does Multiplayer fit into that? What use-cases do you have?
It’s a multiplayer-only game, so it’s important to all aspects of the gameplay. Some use cases are:
Chat
Equippable/carryable items that show up for other players
Synced animations
Slow(ish)-moving projectiles
Smooth player movement
Server info broadcasts of varying types
Synced game timer
Observer mode
Powerups, and control over how and where they spawn
Match discovery via filtering
Ranked matchmaking
What are the GOOD things about the new Multiplayer system you like?
I liked that it was fairly easy to pick up in the beginning and make progress fairly rapidly. The notion of [Server] and [ClientRPC] and SyncVars are very straight-forward and quite reasonable. The ease of spawning objects on the server and having them propogated to the clients. The matchmaker and relay server, while having their flaws, do solve some hard problems that I’d rather not deal with myself. NetworkAnimator “just worked”.
What are the BAD things about the new Multiplayer system you dislike?
It just seems like it’s a bit in its infancy, with a lot of rough edges. Didn’t especially like the ease of use of SyncListStructs (or whatever they’re called). Would love, love, love a synced dictionary of some kind out of the box (perhaps I’ve just missed something?). I don’t like the latency one gets when using the relay server. The web portal for management of unity services needs major work!!! I think the pricing model for the relay server bandwidth usage could use some looking at and perhaps modifying. Providing tools for people to host their own matchmakers and relay servers would be good as well, even if they come with a nominal licensing cost.
How can we make it BETTER?
Having a bit more transparency surrounding exactly what the team is currently, actively working on, and their target release dates would be nice. KEEP THINGS STABLE, and try a bit harder to be backwards compatible without breaking things.
Who are you?
I’m a programmer who works full time in the games industry using Unity Engine professionally for about 3 years now.
What kind of game are you trying to build or would like to build?
A 6v6 competitive multiplayer 2.5D 3rd person e-sport.
How does Multiplayer fit into that? What use-cases do you have?
The whole game is about multiplayer - it is very important to have solid net code. Some use cases:
Networked physics prediction of rigid bodies
Lots of fast moving objects
Ability to pause the game across the network
What are the GOOD things about the new Multiplayer system you like?
I have written much cleaner netcode in the new system. I like the separation of concerns brought on by the [Command] and [ClientRpc] calls in comparison to the previous system - so nice work there!
What are the BAD things about the new Multiplayer system you dislike?
Lack of NAT punchthrough support - I am suffering from high latency when the UNET matchmaker relay server is used. The old networking solution supported NAT punchthrough. This is a very high priority for me.
Strange warnings that are difficult to debug - particularly ‘Unknown message for ID’ This is usually caused by my code.
Sometimes if a client joins late some objects will fail to spawn - these situations are very difficult to reproduce and debug.
How can we make it BETTER?
Add NAT punchthrough support
Ability to see message sizes in the Profiler
Ability to see message type and contents in the Profiler to aid debugging
Ability to somehow record network messages for playback afterwards to aid debugging during playtesting
Who are you?
asperatology, Founder in the field of study of Knowledge Aggregation
What kind of game are you trying to build or would like to build?
Currently building a multiplayer real time strategy game, and it is just about done. Right now, I’m making a simulation model editor that goes alongside with the real time strategy game that I have, and turn them in as 1 fully-fledged complete game.
How does Multiplayer fit into that? What use-cases do you have?
This is built for 2 players, but I haven’t tested to see if this can theoretically scale upwards to as many players as the host can support. Each player controls a group of units, and only 1 player wins by dominating the other player.
What are the GOOD things about the new Multiplayer system you like?
SyncListStructs. After the initial hurdles of learning this and how to use hooks, I finally found out how to use them, I loved how simplified things are going for me.
What are the BAD things about the new Multiplayer system you dislike?
How do you tell having 20 [SyncVar]s is good or bad in a Multiplayer system? Same thing applies to me having to use 30 [Command]s and 50 [ClientRpc]s just to sync things around. The problem is not about encouraging or discouraging us from using them as such, rather, the Multiplayer system isn’t designed to make programmers be preventing themselves from doing these things. Is it good? Is it bad? I don’t know. All I know is that there was an issue where having lots of [SyncVars] breaks Unity, and that affected a few of us. I heard it was fixed, but the upper limit was just set higher, so theoretically you can still break Unity for that.
Is it possible that our codes were written like this, was due to the way the system was designed? I don’t know, but it is there. It happens, and the underlying problem exists to this day. What I’m referring to is the design of the entire system. The system doesn’t say programmers shouldn’t be using a whole tons of [SyncVars] and make them crash Unity, instead, it is not telling the programmers “your code is designed badly.” And if this is extended to [Command], [ClientRpc], you start to wonder if this is a good design, or a bad design, and that’s what I’m trying to say.
Error and warning messages are super vague. And usually, those vague messages would not even point you towards your code at all, instead does nothing in the Console. You couldn’t even tell if it’s my code that’s doing something wrong, or it’s a connection issue, or something. Give us a hint of some kind! I would most prefer the messages telling me what last [ClientRpc] function call in the stack triggered that message, instead of a UNET ID error or something. It feels miserable and tiring just to nail down what went wrong, setting breakpoints and printing Debug.Log() messages here and there, and repeating that over and over for hours.
I am not knowledgeable about the Multiplayer system as a whole. I feel like I’m only scratching the surface. N/A for me, I suppose? Other developers knew extensively what the bad things about the Multiplayer system are, and frankly, I’m really not in the position to say stuffs outside of my small area of expertise myself.
How can we make it BETTER?
If there’s a way where the clients can sync objects and states across to other clients without the server/host acting as a middle man, that would be great.
I would like to see more ways where states can be synced across the network. Dictionaries/Pairs would be fine.