Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[HLAPI] Chaos and abysmal docs for Lobby, NetworkClient.Ready(), ServerChangeScene

Discussion in 'Multiplayer' started by Chris-Crafty, Jul 17, 2015.

  1. asperatology

    asperatology

    Joined:
    Mar 10, 2015
    Posts:
    981
    Okay, do you want me to explain the concepts of UNET or programming-wise?
     
  2. Chom1czek

    Chom1czek

    Joined:
    Sep 19, 2015
    Posts:
    66
    I think programming-wise would be more helpful :) If possible. Thanks!
     
  3. asperatology

    asperatology

    Joined:
    Mar 10, 2015
    Posts:
    981
    @Chom1czek , feel free to use this as example. And share it with others who are having trouble with UNET.

    Code (CSharp):
    1. using UnityEngine.Networking;
    2.  
    3. public class CustomScript : NetworkBehaviour {
    4.     [ServerCallback]
    5.     public void ServerStuff(GameObject newObject, Vector3 newObjectPosition){
    6.         //Do server-side stuff. Initializing all game stuffs can be used here. Syncing objects can also be used here.
    7.  
    8.         //Let's pretend "newObject" has NetworkTransform attached.
    9.         newObject.transform.position = newObjectPosition;
    10.  
    11.         //Now newObject's NetworkTransform will sync the new position across all connected clients. The values are updated on the server
    12.         //side, all clients will have their old positions marked as Dirty() and will update to the server's values.
    13.     }
    14.  
    15.     [ClientCallback]
    16.     public void ClientStuff(){
    17.         //Do client-side stuff.
    18.  
    19.         //Client may have this registered prefab from the Network Manager, but usually it's better to have it available in the Hierarchy before continuing. Usually, it's assigned directly through the Inspector, but let's go with this.
    20.         GameObject prefabObject = GameObject.FindGameObjectWithTag("SamplePrefab");
    21.         if (prefabObject != null){
    22.             //Always check for null. In UNET, there may be times where the object is not spawned through NetworkServer, thus the object will be missing.
    23.             CmdDoAction(prefabObject);
    24.         }
    25.     }
    26.  
    27.     [Command]
    28.     public void CmdDoAction(GameObject objectToUse){
    29.         //This is where you would do stuffs that the client wants the server to do.
    30.         GameObject obj = Instantiate<GameObject>(objectToUse);
    31.         NetworkServer.SpawnWithClientAuthority(obj, this.connectionToClient);
    32.  
    33.         //Or just have the server do something for the client.
    34.         obj = Instantiate<GameObject>(objectToUse);
    35.         NetworkServer.Spawn(obj);
    36.         ServerStuff(obj, new Vector3(0f, 10f, 0f));
    37.  
    38.         //Once the server has done whatever it needs to do, you can choose if you want to have all clients do other actions.
    39.         RpcDoAction();
    40.     }
    41.  
    42.     [ClientRpc]
    43.     public void RpcDoAction(){
    44.         //Do broadcasting stuffs. Stuffs where all clients (local clients = LAN host, and remote clients = LAN clients) will do.
    45.  
    46.         //Because there exists a game object with client authority (meaning the game object's NetworkIdentity has "Local Player Authority" property
    47.         //enabled), it means it's better to check for NetworkBehaviour.hasAuthority, rather than NetworkBehaviour.isLocalPlayer.
    48.         if (!this.hasAuthority){
    49.             //Clients with no authority do stuffs here.
    50.  
    51.             //Or if you want, you can do something that all other clients without authority of this game object can do.
    52.             Ping(new Vector3(0f, 10f, 0f), Color.red);
    53.         }
    54.         else {
    55.             //Do something in which the client itself has control over the game object of local authority.
    56.  
    57.             //Then do whatever you need to do that tells the player the unit has spawned, and all other enemies have taken notice of it.
    58.             Ping(new Vector3(0f, 10f, 0f), Color.green);
    59.         }
    60.         return;
    61.     }
    62.  
    63.     public void Ping(Vector3 position, Color color){
    64.         //Pretend this is a function which pings a colored ! symbol on a minimap.
    65.     }
    66.  
    67.     public void Update(){
    68.         //Because this is a custom NetworkBehaviour script, this is attached to a game object that the client may use.
    69.         if (Input.GetMouseButtonUp(0)){
    70.             //When something occurred...
    71.             ClientStuff();
    72.         }
    73.     }
    74. }
     
    hippocoder likes this.
  4. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,773
    In the time it takes to understand this stuff and "experiment", sometimes even a semi-competent programmer could learn AND create their own system- effectively having the exact same system but with the ADDED benefit of understanding it inside and out and having grown significantly as a programmer.

    I found this true of a lot of things dealing with Unity. To the point where I created a simple 2D game in my own engine measuring everything vs Unity. Even though I had significantly more experience with Unity and absolutely no experience in writing a game engine, by the end of the 120+ hour experiment I found that it was significantly better in nearly every way to NOT use Unity. However, this was before the major UI update, and the experiment did NOT use a large portion of Unity's features. That plays a very large factor. The more Unity features you use, the more time it saves. However, the time it takes to learn Unity, figure out the "Unity Way" of things, and then implement the systems- is actually LONGER than to do it yourself (for a simple 2D game.) I'm not sure if I ever posted the specifics, but I'd love to repeat the experiment again in the future, focusing on the UI and UNET specifically. If I had any interest in 3D games, I'd also love to see if that were true as well. Above all else, I love challenging (and being contrary to) popular opinions / myths. I get thrilled to show people that the common belief that "Unity saves so much time!" is only true in niche cases, with varying degrees of truth in most others (as well as serious drawbacks, strengths/weaknesses, etc.)

    It would be interesting to challenge UNET specifically, by making a simple multiplayer game using Unity. One with UNET, and another with custom networking. Measure the time it took to learn, implement, etc. and the benefits/drawbacks of both.
     
    Westland and terravires like this.
  5. asperatology

    asperatology

    Joined:
    Mar 10, 2015
    Posts:
    981
    There should be a study based on the net positive/negative gains of learning new APIs versus developing your own. I could pitch this to one of my CS professors, and see if they are interested in this.
     
    CarterG81 likes this.
  6. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,773
    That would be a fascinating study. I'd love that. It is the biggest reason why it isn't always a good idea to use a new API. If I didn't already know Unity really well, I can't imagine how much more time it would have taken me in that project. It would have ended as a project with the custom engine being a massive time saver comparatively; Instead of being an equal match for Unity.

    (Btw, I decided to stay with Unity because it was equal, but on top of Unity you have top quality third party assets like Behavior Designer, Dialogue System, Forge Networking, etc. That makes a HUGE difference and IMO is Unity's biggest strength, far above the engine itself.)
     
  7. Westland

    Westland

    Joined:
    Jan 26, 2015
    Posts:
    28
    Not to too much revive an old topic here, but it just seems discouraging to "end up" here, after presently investigating things relating to Unity Networking.. Was really hoping it'd make things fairly simple, since that'd be what I'd expect out of an all-in-one package like Unity, but with all the experiences here aligning with my own after several times trying to do Unity Networking over and over and giving up, I'm not even sure anymore.

    Have repeatedly wound up on forums suggesting Forge or some other networking solution (can't remember all their names, but even Photon popped up, which Mike Geig used initially in a Unity Live tutorial.. not sure what to make of that).
    Think I'll just give Forge a go then, since it seems to come highly recommended. Would really prefer Unity for all the same reasons listed by everyone else above, though.

    But hopefully then, in the future, for another project
     
    CarterG81 likes this.
  8. Homer-Johnston

    Homer-Johnston

    Joined:
    Nov 26, 2012
    Posts:
    46
    Unfortunately @Westland you didn't revive an old topic. One or two of the minor errors that @shadiradio pointed out have been fixed, but that seems to be about it, this issue is still current after ~15 months. I've just started trying to learn networking and am discovering that the manual has several nonexistent methods etc. There's enough info in it that I have been able to piece things together, but it's been harder than it should be. The various tutorials do well to help get a working test example but then it's really frustrating when you try to start implementing real game features with more complicated aspects, and you find these little tidbits of info in the documentation that seem great but they're not actually there...

    Unity needs to get a staff member who knows the networking system extremely well to spend a day and read through all of the documentation and mark it up for corrections. Make everything you do solid before you make it fancy, please!
     
    CarterG81 likes this.
  9. Westland

    Westland

    Joined:
    Jan 26, 2015
    Posts:
    28
    I hear that, fully agree. I've spent a fair bit of time now with the Network Lobby Manager, working from that beta Lobby example that's been on the asset store, and trying to figure things out with the Networked Meteroids example on there as well, though the documentation there is... Well, it could be better.
    If anyone else out there has played World of Warcraft for a couple years and had an eye on Blizzard's tooltip reworkings over time, there might be a bit of understanding for how semi-difficult process of formulating things "correctly" can be (I guess?)

    Just out of curiousity @Homer-Johnston you mentioned "real game features with more complicated aspects" - could you pop an example or two ? I've had some difficulty myself transferring player customization from local to lobby to game to finally triggering it code-wise on the networked game, but I'm slowly progressing towards completion of that.
    Anybody else welcome too, of course.

    I can still sorta tip towards the idea of how Unity Networking is meant to be a really simple plug-and-play solution, which is the vibe I continue getting whenever I watch anything with Mike Geig doing multiplayer. Must be rooted in the simplicity of the multiplayer-aspects of those projects though, since anything else more complicated is, like you said, horribly difficult to get functional.
     
  10. rXp

    rXp

    Joined:
    Sep 24, 2013
    Posts:
    8
    So I am not the only one suffering from the lack of actual documentation. The tutorial is a just a "follow these steps and you will get that".
    I want to understand what is happening exactly ! When I learned how to do the same with UE4 I had no problem finding all the information but here it is just tedious.
    I guess I should look into forge or photon ?
     
  11. Max_Bol

    Max_Bol

    Joined:
    May 12, 2014
    Posts:
    168
    Personally, I find the documentation infos relatively correct, but incomplete.

    • The first thing that is missing which should be mandatory is a note on every functions/calls/class about what kind of network is it compatible with. There's should be a clear identification of what available class, for instance, works with what kind of network.
    If someone works with Unet or Photon, searching through the classes in the documentation is a try&error attempt and, 80% of the time, the answer is found in the forum where someone previously asked "why this doesn't work" and he gets the answer "it's only working with Unet (or Photon)" or even "It's part of the old API and isn't used anymore with HLAPI."

    As an example, when you search for the calls when a player connect to a server, you will get 2 results:
    Network.OnPlayerConnected(NetworkPlayer)
    NetworkManager.OnClientConnect(Networking.NetworkConnection);
    Some might already know that Network is part of the old network method and only NetworkManager is used with HLAPI (Unet for instance). The NetworkManager has its description relatively correct, but the Network is clearly lacking any kind of information regarding what it can be used with. Even worse, some class in the Network "still work" with HLAPI while some doesn't. (Things like getting any information (such as the IP adress) from the network works. Anythings related to send infos to the network doesn't work.)

    • Second is, as previously stated by others, a clear roadmap of which class or function can be used at which part in the system or, at least, examples everywhere. Currently, we're working with demos made for specific and limited situations. Personally, I'm really creative and I'm able to work with those (through tries&errors) as I'm really good at linking "points" together through logical thoughts... but I can also easily see why many feels like it's overwhelming because, let's face it... it is overwhelming from every front.

    Just in the last week, I tried to help a couple of "answers" and "forum post" regarding how to set the the UI of an Unet based network system properly so that the information can get updated between all connected clients. The part where "Unet allows only 1 game object (1 Network Identity) per remote client to have access to the server" is something many don't know about and there's many people asking why, for example, a button works on the host, but not on the built (which is used as a Remote Client for testing)? It's an issues based on Authority over the network that isn't explained anywhere except if the devs read/learn about HLAPI from outside of the Unity documentation. Sure, it's relatively basic knowledge for Networking, but considered that over 70% of the users of Unity haven't passed through that basic knowledge since they self-teach on a "when-needed-basic" because they have other jobs which take much of their energy during a part of most of the week, having not just some demo examples to "scrabble through", but also a kind of road-map that is fool-proof (which covers everything needed to know) would greatly help many including those who at Unity Technologies' communications by removing a huge chunk of question or false-bug reports due to ignorance or lack of knowledge.

    After all, all the official tutorial (and 99.99% of the ones online) only covers what is already set in stone, but not how it works. For instance, try finding a tutorial that explain how to build your own Lobby UI or even a standard NetworkManager based UI. You'll be looking for hours if not days before you'll find something more complete than the usual "Add NetworkUI component. We don't cover how to build your own in this tutorial." Many people who do those tutorials don't even know how to make a custom Network accessing UI. They all goes with "It's easy. Just use this component!" and that has polluted online search for a solution.

    If Unity official website had a full tutorial series for creating (from scratch) and managing a network-based game including custom UI, things such as "choices" in lobby or online and how to manage network based instance creations, management and deletion.

    Originally, the tutorial videos on Unity were like that. They were fully informative and their explanations were covering most of the "what-if" situation. Since some "pre-made" tool and shortcut were added (which are clearly NOT for final products), the more recent videos were turned into user-guide which offers almost (if any) no creativity.
     
  12. RedRiverStudio

    RedRiverStudio

    Joined:
    Sep 8, 2014
    Posts:
    136
    Reviving this thread to see if any opinions have changed re: UNET. I am 3 weeks into developing a mp, have found it immensely frustrating, but chalk it up to learning curve. I am of the same mindset of @hippocoder, that surely the continued 1st party support will keep things progressing, but I just want to make sure that is in fact the case. I am starting to get the hang of it, but I still have time to switch to 3rd party. Anybody have anything good to say about it? Are there any big shot released games successfully using UNET?
     
  13. FireBolt-Studios

    FireBolt-Studios

    Joined:
    Dec 29, 2012
    Posts:
    58
    I will say that UNET is immensely frustrating to learn. The documention is still lacking in certain area's. But with that being said once you understand the basic concept of how UNET works it's actually quite flexible and easy to handle. I will say though it is much better designed for non-massive multiplayer unless you write your own message and authority system.

    If you wanted to start from scratch and setup your own servers and lobbys you can, but dont expect to get OnConnect messages and the like being sent since without the NetworkManager class its is pretty much just the core code to maintain a connection to another pc ie the transport layer which has nothing to do with your games content. So in that regard there the only limit is the connection and your own system.

    If on the other hand you wanted to use the NetworkManager things get a whole lot easier to get something working but a whole lot harder to implement advanced systems like chat etc. Like I said before it's about understanding UNet's way of doing things, your not gonna get far if you whack your own method in there without considering what has happened or what is required to happen to access that variable that hasnt been setup by the manager yet ;). You use the network manager with overrides so you are able to execute code before a manager methods content is called or after, now thats just flooded your brain with potential :). Because at the heart of it there are messages and thats it, you can create your own messages too and this is what is eternally frustrasting for most new users. Because most of the time people wont know where/when to register handlers and other things or do they need both for the server and the client etc...

    I have been working on a super smash bro's esque game for a week now and you bet ive spent 7 days trying to sync player data and ui across a network just for the lobby. But most of that time was spent building my own host/client system from scratch using just NetworkServer and NetworkClient to get a handle on things then I applied what i had learnt to using the NetworkLobbyManager, on a note regarding the NetworkLobbyManager the "On" overrides it has actually do nothing they are there for the developers use to setup and control data for the lobby scene.

    A pre-alpha of my game is coming to itch.io soon and the lobby is fully fucntional at the moment if you wanted to check out the code just give me a holla and i will send it over and you can mull over it.

    PS. Everyone imo should be using Debug.Log() in nearly every method, its goo practice and can always be hooked to a switch or taken out for build. It saves a headache in production and bug fixing.