[Official] Multiplayer Improvements

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.

Thanks a lot!

 

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.

Thanks!
moco

 

Who are you?
I made http://noobtuts.com, a site with a lot of Unity tutorials.

What kind of game are you trying to build or would like to build?
uMMORPG: https://www.assetstore.unity3d.com/en/#!/content/51212

How does Multiplayer fit into that? What use-cases do you have?
MMORPG

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).

Take a look here: http://forum.unity3d.com/threads/bug-syncliststruct-only-works-with-some-file-names.384582/
(just tested it in 5.3.3, it still happens)

It affects uMMORPG too, because I have to rename the Skill.cs file to
BuggySkill.cs, ironically that file name works.

RPCs
http://forum.unity3d.com/threads/suggestion-globalrpc-observerrpc-targetrpc.382486/
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.

I don't know the Unity internals, but Unity already does show some initial log
in the terminal: http://forum.unity3d.com/attachments/headless-output-png.169641/

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:

Code (CSharp):

1.  
2. [Command]
3. public void CmdCancelAction() {
4.     CancelAction();
5. }
6.  
7. [Server]
8. void CancelAction() {
9.     // do things. this can also be called from the server without errors.
10. }
11.  

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:

Code (CSharp):

1.  
2. ...
3. case CheckMethod.Physics3D:
4. {
5.     var hits = Physics.OverlapSphere(transform.position, visRange);
6.     foreach (var hit in hits)
7.     {
8.         // (if an object has a connectionToClient, it is a player)
9.         //var uv = hit.GetComponent<NetworkIdentity>(); <----- DEFAULT
10.         var uv = hit.GetComponentInParent<NetworkIdentity>(); // <----- MODIFIED
11.         if (uv != null && uv.connectionToClient != null)
12.         {
13.             observers.Add(uv.connectionToClient);
14.         }
15.     }
16.     return true;
17. }
18. ...
19.  

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:

Code (CSharp):

1.  
2. using UnityEngine;
3. using UnityEngine.Networking;
4.  
5. [NetworkSettings(sendInterval=60)] // resynchronize every now and then
6. public class NetworkTime : NetworkBehaviour {
7.     // add offset to Time.time to get the server time
8.     public static float offset;
9.  
10.     // server-side serialization
11.     public override bool OnSerialize(NetworkWriter writer, bool initialState) {
12.         writer.Write(Time.time);
13.         return true;
14.     }
15.  
16.     // client-side deserialization
17.     public override void OnDeserialize(NetworkReader reader, bool initialState) {
18.         offset = reader.ReadSingle() - Time.time;
19.     }
20. }
21.  

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<Animator>.SetTrigger
GetComponent<NetworkAnimator>.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.

ClientScene.localPlayers isn't cleaned up
See here: http://forum.unity3d.com/threads/bu...ayers-not-cleared-after-disconnecting.380190/

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.

 

Hi Erik,

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.
1. 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)
2. 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.

All the best,

Anjin Games.

 

If you use StartHost instead of StartServer it wont complain.

 

Yes, because a host is a server and a client, too. Sometimes we need dedicated servers though.

 

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.

 

@Anjin_nz On the subject of missing NAT Traversal / Punchthrough support, I think I may have this more or less 'solved'. Check it out: http://forum.unity3d.com/threads/unet-and-nat-punchthrough-it-can-be-done.391845/

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

 

Hi Erik,

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

 

What about [ServerSuppressWarnings] instead of [ServerCallback]? It would be clarifying and also work with autocomplete.

Totally agree, working with Animator should automatically also use the NetworkAnimator when one is attached.

 

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.

Thanks!

 

https://bitbucket.org/Unity-Technologies/networking/src

 

vis2k! You are my god damn hero! How long has this existed?! I can't believe I never found this, would have saved me so much guess work. Sigh

 

For a long time. It's not up to date though.

 

SIMPLE:

Sort out the costs for small devs writing a $2-$4 game that may only sell a 1000 or so copies....

1. Scrap the pro-license requirement for essentially anything more than testing.
2. Add NAT punch-through so the above dev isn't spending fortunes making relaying data.
3. Add a non-relaying matchmaking only CCU pricing scheme.
4. Give small devs a version of your matchmaker server so they can host themselves and allow the above game to run for more than a year!

(I'd like to see someone from Unity provide a business model for the above game example using UNET.)

 

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:

1) Chat
2) Equippable/carryable items that show up for other players
3) Synced animations
4) Slow(ish)-moving projectiles
5) Smooth player movement
6) Server info broadcasts of varying types
7) Synced game timer
8) Observer mode
9) Powerups, and control over how and where they spawn
10) Match discovery via filtering
11) 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:

1. Networked physics prediction of rigid bodies
2. Lots of fast moving objects
3. 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?

1. 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.

2. Strange warnings that are difficult to debug - particularly 'Unknown message for ID' This is usually caused by my code.

3. 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?

1. Add NAT punchthrough support
2. Ability to see message sizes in the Profiler
3. Ability to see message type and contents in the Profiler to aid debugging
4. 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.

 

Who are you?
An independent developer, creating a multiplayer game.

What kind of game are you trying to build or would like to build?
A relatively fast phased shooter. between 12 and 24 players per game.

How does Multiplayer fit into that? What use-cases do you have?
Multiplayer is necessary to the gameplay since the enemies you are supposed to be fighting will be other networked players.

What are the GOOD things about the new Multiplayer system you like?

• Ease of use
• LLAPI and HLAPI
• Native to unity - Build into the engine.

What are the BAD things about the new Multiplayer system you dislike?

• No NAT support. This makes the matchmaking system useless since the relay server results in unacceptable latency for a game like the one I'm developing. This forces me to use dedicated servers, that are expensive and require extra work from me.
• There is little transparency in the development. I have no clue how many people are working on the networking system, or what they are working on at the moment. All I have to go from is what's on the public roadmap, which currently only shows Server Library and Standalone Simulation Server as planned features. I'm honestly not sure what either of those are. The bitbucket repository isn't up to date either. It would be nice to have a more precise roadmap showing what is being worked on, and when it's supposed to be released. (Some devs are very active on forums which is great)
• Feels buggy and error messages are often very vague. Often it is unclear if I as a developer made a mistake, or there is a bug with Unet. I still have an issue where 12 ccu are constantly used even though I'm the only one with a copy of the game.
• Documentation is lacking.

How can we make it BETTER?

• Add NAT as soon as possible. I think many people are choosing other networking solutions because NAT is not available. It is a key feature that is absolutely necessary if the peer to peer system has to be used for anything other than strategy, card games and other slow phased games, that don't require a fast connection. I understand that a NAT punch realization will require additional servers/facilitators, developers and management, but I also think that it is very important. You could charge extra for NAT.
• Make a roadmap for networking specifically. Make it clear what is being worked on, and what the things are being worked on, and what is planned for the future.
• It would be nice if you wen't through all console error messages related to Unet and made them all clearer, and made it easier to understand why they were triggered.
• Update the documentation to be more in depth.

 

At this point I'm still learning the networking library, but I do have some questions:

Why can't spawned objects have sub-objects with NetworkIdentity? In the prototypes we've done so far, we've felt it would be convenient if the behaviors attached to sub-objects could be NetworkBehaviours, using SyncVars, Commands, etc. We've discovered that this doesn't work, but examining the UNET code, it seems relatively straightforward to implement support for nested NetworkIdentity (it looks like we could do it ourselves except that some of the important methods are internal and/or not overridable), so the question is why was this decision made?

 

Who are you?
I'm an engineer that recently quit my job to make a computer game. *Crosses fingers*

What kind of game are you trying to build or would like to build?
3-player co-op dungeon crawler

How does Multiplayer fit into that? What use-cases do you have?
Need to connect up to 3 players, where 1 player is also the server. A master server to find random players is a possible nice-to-have, but not needed. I assume that the players will know each other and can connect directly... somehow (not sure how yet... port forwarding/NAT punchthrough/Steam?).

What are the GOOD things about the new Multiplayer system you like?
-The spawn/destroy system seems really nice. Managing client & server objects would be a mess otherwise.
-NetworkAnimator is great (although it's broken with Mutiple Animation Layers)
-Command/ClientRpc makes a lot of stuff very easy (Although bug 734257 makes it hard to use in some cases)
-SyncVar's are awesome. Especially nice for automatically handling late connecting players. (although initialization SyncList during Awake throws errors)

What are the BAD things about the new Multiplayer system you dislike?
-No port forwarding/NAT punchthrough support
-Can't add NetworkBehaviour components at runtime. This seems to really limit the usefulness. (i.e. equipment/items can't be components because you can't generate a new sword at runtime). It also makes initialization tricky... as you can't use scripts to add a bunch of default NetworkBehaviour components (i.e. if monsters have 10 default NetworkBehaviour components the proper way to do this is use a script to add all 10 rather than having do drag&drop all 10 scripts on every prefab... but this isn't allowed). So an anytime something changes I have to go through my game and repair every single prefab via. drag & drop!!!
-No high level support for split client/server authority. Many games have client side movement control, but server side action control. For example if I want the client to be able to control character movement (NetworkTransform: client --> server) and request actions such as attack (using Command). But the server checks if the attack is allowed and then performs the action and syncs the animation (NetworkAnimator: server --> client). This is not allowed currently... the NetworkTransform can't sync from client --> server while the NetworkAnimator syncs from server --> client.
-Finicky initialization. For example SyncLists cannot bet set during Awake() without throwing "SyncList not initialized" errors. Ideally what I'd like to do is...
1: Instantiate on server
2: Set SyncList values (causes errors if called before Start)
3: Spawn
So you must wait an update frame until Start is called before setting SyncList. This just makes initialization a bit finicky.

How can we make it BETTER?
I think UNET will be great in the end, it just needs flushing out. See issue list above.

 

There is a serious bug that is keeping dead matches laying around. Your CCU ends up getting used up and you're literally stuck potentially for hours. This isn't a sometimes happens kind of bug, or something minor. It's breaking my game and it's completely out of my control (I can't program a work around).

Jeremy is aware of the issue, but there has been no communication for weeks.

This bug has been around for at least 3 weeks. uNet is in production" however if my game was in production or just launched on Steam it would have probably ended my game and ruined my sales and caused refunds, bad reviews, etc.

This bug is very serious and while I know someone is "on it", it's just way too long for a bug that literally makes games unplayable to be around.

More importantly, we need some kind of communication about it (at least once every couple of days on something this serious) so we can communicate that to our players.

I have a lot of hopes for unity networking (especially the ability to host on LAN built in). But this is making me really nervous.

 

100% agreed. There NEEDS to be more communication from the multiplayer team, especially regarding this bug (even if it's a statement of "we'll have it fixed two weeks from now").

 

As mentioned here earlier tonight:

"On update on the issue: the fix is ready and being propped and QAd in our staging environment, there were some issues we needed to sort out with the deployment but it should be done soon. Since there is some uncertainty about this I can't promise an exact time, as soon as I know more I'll report it here."

 

Thanks!!!

 

Thanks for the update.

 

I agree with pretty much of it.

I think the most important thing to have now is the NAT support or the possibility to get the Unity matchmaking server code to setup our own servers.
Hot join with lobbymanager would be nice too.

 

Thank you so much!

 

The Bad:
some plateforms are totally forgotten.

I mean, if you want to deploy on WebGL using a linux headless server you are doomed.
My code works perfectly well on editor -linux headless - standalone.
But when i switch to WebGL the client crashes, i tried to get some informations, posted questions, sent a bug report: black hole.

I am chasing a bug for month, nobody from Unity ever tried to help, leaving me with my questions:

is it worth helping someone that don't use the Matchmaker ?

 

Do you have a separate thread discussing this problem?

 

Like some others said, while "Matchmaker and relayserver solving some hard problems" is good, I really would like the choice to use the relay server or not. And most importantly the ability to set up my own matchmaking server. Right now I'm looking to re-create my own matchmaking solution and rely only on the NetworkServer and the NetworkClient class for my game, because I simply can't afford Unity's solution.

 

I would also like to vote for high priority on the NAT support.
Maybe the matchmaking service could work something like this:

1. It shall provide the feature to register matches and to provide a list of all currently active matches (we have this feature already, check)
2. It shall provide different connection options, including direct connection, NAT punch through and relay server (NAT is still missing)
3. On joining a game, the choice shall be left to the game developers which connection options are to be tried/used (e.g. it would be possible to start with direction connection, if that fails then try NAT, and, if that fails as well, use relay server if we want to). The different connection attempts could automatically be run in the background so developers would only need to care about the options and their priorities.

In summary, the idea is to provide different options and leave the choice up to the developers which options a game shall use. So, using the matchmaking service does not necessarily mean to be forced to use the relay server. Though it is good to know it can be used if needed so we can always establish a connection. They keyword is flexibility and I think it will be a great benefit in many cases, especially considering those many free and low-priced game projects.

 

mainly :
http://forum.unity3d.com/threads/se...o-make-my-game-use-webgl.393816/#post-2600043
and
http://forum.unity3d.com/threads/un...disconnected-from-server.389204/#post-2582745
and two bug reports.
I wait, i wait.

 

Did you post your bug report case number? The numbers themselves are far more important.

 

I'm Ashkan Saeedi Mazdeh, I worked on multiple multiplayer titles and also for MuchDifferent on uLobby, uServer and a bit on uLink.
I'm making two small games for mobile and WebGL as contract for a company and also my own multiplayer fast pace action tank fighting game with user generated maps and ...

I've said these to unity devs or in forums before but still.
- Stability and fixing all issues which can cause disconnect/no free available space in event queue.
- Advanced WebGL version which supports GetRemoteDelayTimeInMS and has better congestion control.
Send object authority info with spawn message so correct callback for owner and none-owner clients can be executed.
Add a callback OnStartNoneAuthorityClient
Allow sending RPCs to specific targets (I know the codegen is not too easy)
Make it easy to have separate client and server scenes and manually assign sceneIDs (sent bugs in that regard which are confirmed)
Make more regions for relay server to reduce latency, reduce the latency in the stack if any.
Make buffered spawn messages to preserve their order when executed on new clients.
Add support for buffered RPCs (not too critical but might be nice to have instead of having to use StateSync for that)
Add network priority system so we can prioritize messages/RPCs when there is not enough bandwidth and flow control wants to drop some stuff. See the I shot you first video from Halo on GDC vault (I'm sure you've seen it however)
Make it possible to customize state sync rate per player per object so I can send less updates to far away players which are still observable. Helpful specially in WebGL games which you have to send everything reliable sequenced
And a bold suggestion, make the hack week parse server with C# logic added on top for server available, I have no use for it but it's useful for many.

 

Who are you?
Just a hobbyist, who definitely wants to release fully realized multiplayer games in the future.

What kind of game are you trying to build or would like to build?
A Survival Horror co-op game, much like the original Silent Hills/Resident Evils.

How does Multiplayer fit into that? What use-cases do you have?
I'm not sure if I want the game to include split-screen yet, so the only other way is to include networked multiplayer.

What are the GOOD things about the new Multiplayer system you like?
Everything I've tried to implement so far just works, after the obvious learning how to use the framework. I'd also read that UNET is cross-platform, which is great since I will eventually want to release on Steam and consoles and the less work required is great.

What are the BAD things about the new Multiplayer system you dislike?
First and foremost, the random disconnects caused from packet loss. I know the internet is faulty in certain areas, and some players could have terrible connections to each other. Even while simulating 1% packet loss (or even just playing with one player on a tethered hotspot from a phone), the client disconnects within a few minutes. Since my game won't be the standard multiplayer experience, I expect players will want to play for hours at a time. Obviously that can't happen if everybody has to reconnect every 5 minutes or so. I'm not exactly sure how much packet loss you should expect to have to deal with, but I'd think it's more than 1%.

No NAT punch-through. I really don't want to go through servers for my game, since it'd just mostly be a cost that I could easily avoid. So making it easier for players who don't know how to port forward (or can't) can only be for the better. I know there's packages on the Asset Store for NAT punch-through, but I'd rather use something that's built into UNET.

How can we make it BETTER?
I'm not exactly sure what the problem is that causes all the disconnections, but I'd assume it's because the packet loss is making your heart beat packets get dropped and never acknowledged. A fix for that is desperately needed, as when I eventually start deploying my game to friends for testing I'd hate to get random disconnections and think it's something I did that caused it.

Add a NAT punch-through ability. It's obviously possible because of the Asset Store packages that let you, but I'd rather use UNET's built-in feature for it.

 

Love seeing so many people requesting NAT Punch-through

 

Better to get it natively on UNET for free than to pay 48 euros for it. Am I right?

 

Everything is better when it's free But it's a question of dedicating the resources to what features/fixes/stability improvements. To me, the most important thing for uNet atm is having the current thing as stable as possible and without disconnects in the cases which other libraries don't disconnect and ... UDP whole punching is interesting and it's nice to both have that and WifiDirect as features.

 

Agreed with this. Using Clumsy or the built in simulator any amount of packet loss causes network degradation and disconnects after a minute or two for me with a simple scene with player prefabs syncing nothing but position and rotation updates 15x per second.

Can we get any sort of GUI or HUD script for connection stats? I can estimate my traffic based on my sendRates/commands/RPCs and what I'm sending, but I'd love to see my actual bandwidth statistics including unet overhead like headers and whatnot. uLink used to have a really great utility script that displayed the bytes/sec of each client and the server, I'd love to see something like that.

 

Yeah, I feel like we should have access to the same stats Unity will use to determine how much our game costs to run. That way, we can figure out what to expect while developing, as well as see live updates to our costs during production.

 

I only have 3 things to mention:

-NAT punch-through is a must have to complete this awesome network system and would be so damn beautiful
-ClientRpc for ONE client. Something like [TargetRpc(netID)]
-Please, fix the multiplayer service calculator. That price cant be real

thanks

 

For us, the most important things in order of importance are:

- Stability (we were blacked out for a weekend due to a relay server maintenance, apparently). We also see tons of orphaned matches and broken apis still
- NAT Punch Through. Current third party solutions do not work on mobile and latency to relay servers plus cost structure per CCU does not make a lot of sense.
- Coherent documentation. We managed to put together our working prototype though heavy trial and error and a lot of digging around ni forums working around issues with APIs not behaving as expected.

 

Who are you?
My name is Diego Vieira and I'm Software Manager and Indie Game Developer.

What kind of game are you trying to build or would like to build?
I am building a 2D MMORPG (check facebook page for videos if you like: https://www.facebook.com/eternalquestgame)

How can we make it BETTER?
Right now I have an Open World map, that have several tiles (about 240.000) and the server performance became poor. If inside the loop on NetworkServer.UpdateServerObjects(), unity consider only Active objects, it could improve a lot, because it's better to control Active/Inactive objects than spawn/unspawn.

 

The only thing I would is more tutorials. Lots more
I'd like to make a 2D top down arcade shooter with networked co-op - something like hotline miami but co-op / mp.

 

The Meteoroid Network example is quite a monster to untangle – for example,
why does the empty virtual (and un-overridden) OnLobbyStartServer() function exist? The less code the better, empty stubs are not instructive in such a complex framework example (imho).

To answer your questions:
- - -
Who are you?
Arun Mehta, Indie game developer in Japan

What kind of game are you trying to build or would like to build?
PvP (1v1), real-time table-top game with dead-simple match-making (Clash Royale simplicity, don't even need elo for starters)

How does Multiplayer fit into that? What use-cases do you have?
The core experience is multiplayer (to limit content production)

What are the GOOD things about the new Multiplayer system you like?
The API is available at BitBucket, and the separation of HLAPI and LLAPI.

What are the BAD things about the new Multiplayer system you dislike?
The examples work out-of-the-box but honestly hard to customize imho – having better luck using them as a reference and building a custom network manager from scratch, but the core ui-less logic flow (what if you don't need lobby players?) is hard to grasp.

How can we make it BETTER?
More regular official posts and responses by Unity in this thread.
- - -

@Unity folks, in the gist below for my custom network manager, making the call base.OnMatchCreate(createMatchResponse) on line 184 starts the game prematurely. Could someone please explain where the check is / should be made for the minimum number of players (2 in my case) so I can stop NetworkManager.ServerChangeScene() from being called immediately?
https://gist.github.com/arun02139/2bfd67e62c4c29d359b6434d1a5564c0

Thanks, and keep up the great work!

 

One thing I've come to realise is that network spawned objects don't appear to keep their instantiated rotation. If that's intentional, all good, but figured I would raise it
Otherwise thanks for everything. I never thought it would be in my ability to make a game, let alone a multiplayer one, yet Unity allows me to. Pretty amazing!