Search Unity

How easy is it to add multiplayer to a game now?

Discussion in 'Multiplayer' started by imaginaryhuman, Apr 6, 2017.

  1. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    Am curious, since it's been so many years that games have been featuring multiplayer networking etc, how easy is it now in Unity to add multiplayer to your game? Maybe a simple turn-based game or a even, let's say, a 2-4 player realtime game?

    Here's what I would HOPE the experience would be like:

    Check a box in the Unity editor, the whole scene is now shared by the players. Right?

    Or, select some objects and click a button and the positions/states of these objects is now automatically shared by all users, right? Regardless of whether you know how to set up a server or any such networking API stuff?

    And... how do users find each other... erm... you create some kind of 'virtual server' on Unity website and it gives you an ID which you plug into your inspector window and then hey presto, people can join and leave and choose who to compete against and have a chatroom and lobby and so on right? Easy peasy? All the networking is totally hidden and automatic, because this is how advanced everything has become now, right?

    If not why not?
     
  2. donnysobonny

    donnysobonny

    Joined:
    Jan 24, 2013
    Posts:
    220
    I guess with unity, it's fairly standard for unity to provide features that focus on accessibility/ease-of-use, but multiplayer in general is a tough topic when it comes to this. Although we're seeing high-speed internet becoming more and more available around the world, many parts of the world and many devices still suffer from only being able to realistically handle less than thousand bytes per second before lag just ruins everything. I say this because while we have to make networking efficient for real-time games, it's very unlikely there will be an efficient way to provide an out-of-the-box multiplayer solution. You're always going to have to make considerations on how to make the networking more efficient, until "bandwidth" becomes a more readily available resource; Like how we don't really have to worry about how much ram we have available anymore where as only a few decades ago we had to limit everything to only 16 bits!!

    Couple that in with the fact that multiplayer, at minimum, needs two things: a server and a client. The client part is easy, and in actual fact if you've built a single-player game you pretty much have the client-side 90% ready to go. The hard part is the server. There are challenges in getting people to connect to a server, then there are challenges on top of that with how you keep messaging between the server and the client consistently smooth, so not to malform the gameplay. Then on top of that, how do you manage varying number of players and resource requirements... it can get complicated very quickly.

    Ultimately there are a number of thought processes that you need to take into consideration when building multiplayer games, that you just don't need to think abut when building single player games. I don't think we'll ever end up with a solution where you can plan, build and execute single player games in almost exactly the same way as multiplayer...


    With all of the above being said, and hopefully with expectations now in the right place, unity's networking framework has improved a hell of a lot over the years, particularly the HLAPI which does provide a good set of tools to try and make it as easy as possible to work multiplayer in to a single player game while still taking efficiency into consideration. With the updates in 5.6 and the incoming patches further increasing performance and functionality, it's becoming a much more stable framework and definitely does provide a fairly accessible platform for developers looking to make multiplayer games. If however you are going to require clear documentation/official tutorials to help you through the initial steps, I would recommend waiting a little longer as work is still ongoing on that front.

    Just my 2 pence :)
     
    Last edited: Apr 6, 2017
    LaneFox likes this.
  3. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,521
    Okay, you clearly have no idea what is required to make a networked application so I'll just spare the reasons this would be madness and suggest that you simply jump into UNET and try to make something simple, then derive your own conclusions.

    If you want to talk to something over the internet you can't just say "Internet, tell Fred I'm over here". You have to ask the computer to ask the router to ask the internet to connect you to some extremely specific point and send a specific message through specific rules and just pray that it goes through without any issues in a matter of milliseconds.

    What that translates to for developers at this point is either a master server or p2p - having a server which relays data and all of your application clients communicate to that server. This is required if you want matchmaking or rooms or something and requires some kind of statically accessible hardware that is always online (money and bandwidth, regularly). That's basically what Photon provides.

    Peer to peer on the other hand is simpler, and something that UNET does fairly well. Essentially that 'specific point' becomes some explicit IP that the player puts into a field in the game and if the port is open then it allows people to communicate in the application. When there are more than two clients then one of them acts as a host and his client is effectively that 'specific point' the others are targetting. This basically costs nothing to developers because it removes the intermediary hardware. Photon also offers this type of thing.

    Unfortunately there are a slew of other issues like nat punchthrough, firewalls, router issues and end users that are not technical enough to even know what an IP address is to begin with.

    Aside from all of that connection hubble bubble you still have to deal with bandwidth! If you sync the entire scene then you could be trying to send like, megabytes per second, for simple crap happening. That is a stupid thing to do and entirely wasteful. To deal with bandwidth you basically try to send as little information as possible while still allowing 1:1 representation of the scene state between clients and server. That means stuff like caching and sending updates only on changes, sending events or small bools instead of other heavier data, etc - and all of that effects the code design of your game.

    Anyway, I think you can see the point. It's getting more auto-magic but like @donnysobonny points out - bandwidth is a big issue and making an optimized, always-in-sync, fast and light networked game is not trivial or automagic-able.
     
    donnysobonny likes this.
  4. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    It is easier than it used to be, but significantly harder than you're describing. Now if you are just building something like some of the multiplayer demos, some simple models moving around a terrain shooting simple bullets, with a few players on a local network, and you know the IP address of the player hosting the game for you to type in on the clients..... Well then it actually is almost as easy as you're hoping.

    The devil is in the details though.....

    How do you handle more complex data about players, like data that persists between game sessions? How do you handle two players joining a game but from two separate networks where the host is behind a NAT? Latency is not an issue when sitting next to each other, but it becomes a huge game design problem with fast moving objects but with ping times at 100+ ms, so how do you handle shooting bullets at people where the bullet is created and destroyed faster than even the ping time between players to host? How do you have snappy movements for all clients yet prevent cheaters from taking advantage of trusting clients on their own position?

    All those are huge problems with no one size fits all solution, which means Unity includes some solutions that work for some game types some of the time, but the game designer is going to have to put in a lot of thought and work into them.
     
  5. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    How about something relatively simple like slither.io which supports a large number of users sharing a single game arena? It's likely for the most part only sending user inputs and a bit of data about spawned objects etc?
     
  6. donnysobonny

    donnysobonny

    Joined:
    Jan 24, 2013
    Posts:
    220
    Slither certainly appears to be a simple game in concept, but it's still multiplayer, which ultimately means that all of the advice given in responses above are valid, even for a simple game like slither.

    Honest, try it! The advice above is all completely valid, but it seems as though you haven't yet taken time to try it out for yourself and rightfully so you're taking the advice with a pinch of salt (they are just views/opinions after all). It doesn't take too long to see the challenges of multiplayer networking so I honestly recommend diving in and seeing them for yourself.