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

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.

 

You have many choices listed at the beginning of this thread:
https://forum.unity.com/threads/wha...of-available-network-solutions-assets.609088/

 

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.

 

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.

 

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.