Search Unity

Unity Multiplayer Starting a new 2-3 year project, what tech do I go for?

Discussion in 'Connected Games' started by mrCharli3, Jul 26, 2019.

  1. mrCharli3

    mrCharli3

    Joined:
    Mar 22, 2017
    Posts:
    393
    I've spent the last few days reading about Unitys transition from UNET, and honestly I don't feel like I'm any more sure of how to proceed now than I was a few days ago.

    What tech should I use? Or is the only real option to wait for them to finish their new multiplayer system?

    Can someone answer what approach one should take for the different types of projects below:

    1. A project that will take 2-4 years, only co-op multiplayer for max 10 players, ping not that important, player-hosted servers.
    2. A project that will take 2-4 years, only co-op multiplayer for max 10 players, ping not that important, matchmaking and publicly hosted.
    3. A project that will take 2-4 years, competitive shooter with 20-100 players per server, w matchmaking.
     
  2. g_a_p

    g_a_p

    Joined:
    Mar 16, 2015
    Posts:
    122
    Joe-Censored and mrCharli3 like this.
  3. zhuchun

    zhuchun

    Joined:
    Aug 11, 2012
    Posts:
    379
    2-3 years is a long time, it's sufficient for you to build your own network stack. Most basic netcode knowledge almost stays the same in the past 20 years, so it's not too late for anyone to start from scratch. Personally, it took me a few months to learn lots of things like network essential, code generation, optimization, etc.

    I recommend you start from pick up an existing transport layer. This guy made a benchmark so you can have a basic idea about what's on the table, how good they are and where to find them.
    https://github.com/nxrighthere/BenchmarkNet/wiki/Benchmark-Results

    However, you can not just pick something looks good on that benchmark result, since the test scenario may not fits your case. More importantly, the transport layer you based on usually is not going to change in the future, so you definitely want to pick the one that is Robust, production-ready, well documented and also has an active community.

    A few useful sources/websites could help is GafferOnGames(shutdown but google can find its archives), GabrielGambetta, Valve Source engine networking docs, GDC talks of Overwatch and RocketLeague team, etc. After that, you should be confident to build everything you want, say the high-level feature that is NOT provided by any existing frameworks/plugins(AFAIK) like KillCam. You would also have the ability to evaluate and overcome network situation in operation.

    Good luck.
     
    Joe-Censored and mrCharli3 like this.
  4. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    6,049
    With Unity's track record of implementing network solutions only to almost immediately abandon them, I wouldn't be waiting for what Unity is currently developing. Their new solution has been in development for over a year, yet they have surprisingly little to show for it. Maybe it will turn out great (I haven't actually tried the alpha), maybe this time they will continue to improve and provide new features and bug fixes, but they have never taken that approach with their previous 2 network API's.

    Pretty much any network solution can handle this. With player hosted servers you will need a solution for getting around typical NAT router setups. That typically involves some kind of server (relay server or NAT punch through).

    Same deal, except if you are doing dedicated servers you don't need to worry about NAT router issues.
    Expect to be writing your own network API from scratch optimized for your game.
     
    AcidArrow and mrCharli3 like this.
  5. zhuchun

    zhuchun

    Joined:
    Aug 11, 2012
    Posts:
    379
    True. We're using the Transport package and have implemented our own reliable message, time synchronization, and many other basic things. Then we built our network stack on top of it. So, if unfortunately, the Transport package could not make it this time, we would still be able to switch to another solution quickly.
     
    Joe-Censored likes this.