Unity 5.6 need help with MMO type server

Hi all,

I am trying to add multiplayer but I am confused with why there are so many things you need such as relay server, authoritative server, dedicated server, ,master server, UNET, etc.

I want to make a drop-in/drop-out type multiplayer, similar to agar.io where you just pick a name and spawn in a server with a hundred other people. How do I go about doing this the best and most efficient way? I just need to be steered in the right direction, and I can figure out the rest.

Thanks!

 

Understand that when you say you want 100 players per server, but with networking don't know where to start, you're saying the same thing as you don't know much about cars but need some advice on building a Ferrari.

One of the first things you need to do is decide who is going to host the server. Are you going to do it on some kind of dedicated server? Are you going to have one of the player clients host the server?

The later saves you some infrastructure headaches, but you're unlikely to be satisfied with the performance of the game when you have some random client computer that spends most of its cycles rendering the scene for the player sitting in front of it, also trying update 100 other clients with the state of the game world. You also have to have a solution for that host being behind a router firewall and still able to host the game (which is the entire point of the relay servers).

If you host your own servers, you avoid the router firewall issue but now have to build out both a hardware or virtual hardware server infrastructure, and manage your server processes. For example, if you game allows clients to "create" new servers on your hardware, you have to build out a system that accomplishes and manages that.

 

On a previous project I was using ulink and Amazon EC2 server and was able to get a client to connect to a host, but later on I found out that ulink had no support from devs so I dropped it all together.

My question is, can I run a headless instance of a room on the Amazon EC2 virtual server that acts as the host, and have 100 people connect to it that way as clients? And if this way works, if I want let's say 10 rooms, do I then need 10 headless instances running? Also, is this example considered a dedicated server example, or master server example?

If the above examples works then I think thats fine. Like I said, it's not that I have no networking experience, it's just that I need a good direction since I haven't touched it in a while and a lot has changed. From there I'll handle it once I'm given a proper direction.

Thanks!

 

I had the exact same experience with uLink unfortunately. And because of how interwoven uLink was in my project I ended up shelving it for a couple years, and then restarting it virtually from scratch. It was very disappointing.

Technically yes even with UNet, though I'm not aware of someone on here stating they have successfully done so in a finished or near finished game. You'd have to be especially efficient in your design to be successful. UNet's HLAPI makes it very easy to do sloppy networking, like updating SyncVars or sending ClientRPC's to all clients even when just a small number actually care about the information. Superfluous updates are fine for a small number of clients and makes it easy to get something up and running quickly. Try to take that from 4 clients and bring it up to 100? Suddenly what wasn't an issue becomes a huge one.

Unity itself is not really built to run multiple independent simulations in the same instance, and UNet doubles down on that. I'm sure there are clever solutions, maybe you could run multiple simulations in the same scene but stacked vertically, and then filter client updates based on what simulation they are supposed to be apart of? The most direct approach would be to just run 10 headless server instances for your 10 rooms though.

As far as the nomenclature, those would be dedicated servers, and if you have a central server that manages the dedicated servers or manages what clients connect to what server, that would be the master server. A master server itself generally doesn't run a game simulation, but does some form of management needed to either organize the players or organize the servers.

 

Just as an example of a dedicated server MMO I'm building. It isn't finished, and I haven't load tested even what I have now, but just throwing something out there to help you with some ideas. So I have a huge game world that I chop up and host individual sections of the map on separate servers. When you reach the edge of a zone, the client is transferred to the server that runs that adjacent zone.

So I'm trying to be efficient in my networking code, but even still with cannonballs flying, NPC ships to control and send updates for (its a sailing game), I'm targeting supporting at least 40 players before I hit problems. I'd love to do 100, but I don't think that is feasible with what I'm trying to do.

A central part of the game will be buying and selling goods at the various markets. These will naturally be places that players tend to congregate, so I need to support more players. My strategy is to simply not allow combat in market hub zones. So these servers won't need to track and send updates for cannonballs, won't need to control various NPC's players fight with, etc. There's really no action other that player ships sailing around and updates to inventories and market transactions. Using that strategy I'm fairly confident I can push the number of connected players up much higher, hopefully up to 100, but a minimum I'm targeting of 80 before players notice issues. Even if players get some lag, or the occasional position teleporting, they aren't fighting so the issue should be more forgivable than in the middle of a fight.

 

Thank you Joe for the informative messages!

I remember ulink had some sort of zone utility that did something similar to what you described. It works for games like Clash of Kings, Game of War, etc where you have zoned areas contained in a master server, and I actually thought of maybe segmenting my game in zones but the problem is the map is too big.

I think 100 for my game should work but you are right that the only way to truly find out is to test it. The reason I think 100 should work for me is because I am only updating player position and nothing else.

Since it looks like the headless instance idea is good enough to work, I think I will re-open my Amazon EC2 account. Their virtual servers were easy to deal with and since I have been able to connect players before, it shouldn't be a problem messing around with it again using UNET. I should be able to bypass a lot of things too, like lobby scene or lobby manager because I am implementing multiplayer as a live mode, where you simply enable a setting and the game joins you in an open map, and if there are players within a certain radius of you they will appear and update their positions to you.

Again, I appreciate the direction and will let you know how it all turns out.

 

Until you get to close to being an expert on client/server architectures, stick with existing solutions. Just using those will teach you a lot. Otherwise the only thing you will accomplish is creating a bad version of something that already exists, and spending a lot of time doing it and not actually working on your game.

IMO the best progression here from simple to complex is Unet then jump to Photon or SpatialOS. The latter is a more modern approach to client/server architectures, it's also probably overkill for a lot of simpler use cases.

 

Welp, looks like my EC2 account is locked due to inactive activity. Their customer support sucks and I remember it took them a month to originally open my EC2 account, so rather than wait another month, is there something similar I can go with instead? Can I use Azure VM to host headless instances?

 

Don't like Photon, too many products and prices to deal with, also their documentation is not that clear. I took a look at SpatialOS, and it seems too early in development to trust.

 

I generally prototype on a standalone Linux server at my house, and port forward to it on the router. This avoids any costs related to provisioning hosting services until you want to test it scaled up. YMMV

 

I'm going to chime in on this too. Personally I'm building my own server right now, I've found that uNet is over complicated and doesn't work in WebGL. All other solutions are overpriced and often paid monthly (XXX/month). Also, if you don't know what's going on under the hood, it makes it exponentially harder to develop your game for every unknown line of code you import (at least on networking). Also, uNet seems to be sending 100-300 kbps per player because the serialization is so bad, and I'm wary that other solutions might be better but still bad.

IMO, OP needs some kind of out-of-the-box solution, and even then, OP probably couldn't figure out how to handle player data persistence (putting it in a database of any sort).

My own server right now runs on WebSockets doing a custom binary serialization, I consider myself an expert on the architecture.

The networking itself was built on top of UnityEngine's transform/MonoBehaviour/Component system, but I'm starting to realize that, as mentioned, it's not built for multiple instances! So instanced zones of any sort are a problem... Can anyone elaborate for both me and OP on how multiple instances are supposed to be run? I could start a new thread, but I don't want to make duplicate threads.

I didn't realize that there was a huge gap between the Unity runtime with Component/GameObject instances and the UnityEngine.dll, which I thought was handling all this.

 

Good post, but I want to disagree with this statement. I am not lazy, I am just simply a little confused. I don't really need an out-of-the-box solution, I just need direction so that I can invest time and money the right way the first way. Also, I definitley could figure out how to handle data persistence as I already do that locally in my games, and doing it using SQL won't be hard because I use SQL and work with databases. Player data persistence is the last thing im worried about.

 

You could consider looking into the UNet LLAPI (low level API) and building your own higher level systems that suit your game off of that. The LLAPI gets a lot better support from Unity, is generally well regarded (more so than the HLAPI), and would give you the flexibility and efficiency you need to potentially reach your 100 player goal. The downside is simply the fact it is the low level API, meaning all the handy high level stuff that makes UNet fairly fast to get something up and running with is out the window.

 

@Joe-Censored : I wouldn't necessarily say it takes very long to get a decent LLAPI setup going. One night and a couple hours today learning as I go I have players communicating positions and rotations at 10 updates per second, with basic interest management. Now I haven't yet synced positions, just client and server communicating. Syncing shouldn't be fairly hard either, keep a serverside representation of the players, instantiate them for other players and move them to the locations being told by the server. Which can be made in the matter of a few moment if you understand what it is you are truly wanting to make.

Now if you have no idea on where your target is, you're never going to get there.
This may be because I'm a major planning freak, I know specifically at any given time what actions I want to take next,
even if they are completely off the top of my head, I just know lol.

But yeah the High Level stuff, you won't get anywhere near as much control without building it your self (which is what I'm assuming you meant), but in my opinion, if you have a clear target and goal, you can get at least a running game client/server working in a couple of days.

 

I think I may go the more direct route and just rent a VM, azure has a 30 day trial so once I'm ready I think what I will do is just run separate headless instances as needed with a maximum player count per instance. When clients turn live mode on, matchmaking will search for a server that still has a spot, and will join immediately. My biggest complaint with this setup though is since this is an Android game, I guess I will have to switch platforms everytime I make an update and rerun all instances, which will obviously get repetitiveley annoying.

The sad part is, I really was getting somewhere with this networking stuff a few months ago with Amazon EC2 and uLink, and managed to even connect a pc player with an android player, but once I found out that uLink had no real dev support I dropped it all and started a new project, which I now would like to add multiplayer to.