The legitimacy of Unity's claim on adding multiplayer to a finished singleplayer game?

Any insight into Unity's claim is appreciated; Thank you.



I am a bit skeptical as to this claim. One of the most common things I have read when it comes to multiplayer, is to design your game with multiplayer at the BEGINNING. That adding in multiplayer "at the end" is an awful experience.

However, on Unity's own website they claim it requires "few changes to your existing code". It implies that it is "easy" (whatever that even means, as we all know even a small feature in game development can be very hard to implement).


Right now, I am interested in making a simple 2D game featuring multiplayer with up to 2-4 players. The players walk around harvesting 2D objects and attacking by holding spacebar. Pretty simple stuff. Preferably, the multiplayer should be hosted by one of their client, not an individual server. From what I understand, Unity's networking is made for that kind of small-scale multiplayer, correct?

However, I am trying my damned hardest to make the game's scope as small as I can. The idea of multiplayer just makes that "small scope" explode to something much larger. That is a huge no-no for someone who just wants to finish a game.

This is especially true when I could simply do on-screen local multiplayer (via split-screen [2 cameras], or via multi-monitor support (two monitors, one for each player). Although I'm not sure the difficulty of the latter in Unity (I've never even seen any mention of multi-monitor support in Unity.)

My initial idea was to make the scope as small as possible- and then AFTER that small scope is finished, if it warrants it, add in additional features or content (enlarge the scope).

The idea of finishing the game first singleplayer, then adding in multiplayer as Unity suggests (with an implication that it is easy) sounds perfect. However, that is contrary to all advice I've ever heard (from people who may or may not know what they're talking about) and I am extremely skeptical as to Unity's claim.

I have plenty of programming experience and have absolutely no problem recreating a game on the scope of my current project (all features and mechanics, I know 100% how to accomplish, so the scope is within my ability to do easily)- however, I have very little networking experience. Part of the reason I postponed my other project is because the scope was too large (why I think I lost motivation, as things became difficult to implement) and I needed to tackle something I knew I could do (implementing a game of a scope which is easy for me)...so I don't want to end up losing motivation as my brain melts learning complex networking. I have no problem learning simple concepts or well documented features- but the more difficult it is to implement the more it drains my motivation (at least in theory).


I also take development very seriously, so if there are any preferred multiplayer networking assets in the asset store- I am more than willing to dish out the money to make my life easier in this regard. I just assumed none of that would really be worth it, seeing as how most of the work will be in the client telling other clients what data it needs to know to update their game. Assuming I used Unity's default networking, and assuming Unity's claim was at least partially true.

 

If you already know that it is going to be multiplayer it would be smartest to design it like that from the get go.

However with a game like yours (small scale) it shouldn't be that hard to do after you finish the singleplayer part.

 

From what I gather so far, you're spot on with both of those points. It seems that both "sides" are correct. Both the "Have it multiplayer at the beginning!" side and the "Unity makes it easy!" side.

I'm following this tutorial, to get a start

http://www.paladinstudios.com/2013/07/10/how-to-create-an-online-multiplayer-game-with-unity/

And I noticed two things so far (not even done with the tutorial yet, will update with progress.)

1. They seem to have the same thoughts / concerns as I do- contrary to Unity's "it is easy!"
   
   
   
2. Unity does indeed seem to make it "just work". I was actually really surprised at the "“reliable delta compressed" feature, among others. You literally just plop the component on a gameobject and wallah! It just *works*. (Hopefully the tutorial will cover making it smoother, as the characters jitter around right now).

So this out to be interesting.
Any tips/warnings/asset store or tutorial links are still appreciated.

 

Well it is easy as such. But when they say easy they probably mean compared to other networking solutions or rolling your own solution. In that regard they are right.

 

Somehow I think:

"Turning a single-player game into a networked multiplayer game requires a complete rearchitecture of your project!"

Just isn't quite as catchy....

 

My game is a very small scale. It was not designed with online multiplayer in mind. But adding it later was the worst experience ever. I had to redo every aspect over and over to get it working. Out of two years total, at least 6 months were devoted to getting the multiplayer integrated and working right. If I had started with MP in mind it may have been 2 or 3 months instead of 6.

The problem was not so much in the actual multiplayer integration as it was in overall program flow...creating rooms, joining rooms, notifying players of multiplayer-related events, where to add and show this stuff. My advice is to design every game you make from the very start with multiplayer in mind. Even if it is to be a single-player game. You never know when you might decide to add multiplayer.

 

Yea, and that is what I'm looking for. It definitely seems correct, after having completed the tutorial I linked. Pretty easy stuff.

Unfortunately, that tutorial doesn't really teach you anything all that valuable (WHY things do what they do, WHY you do it that way or this way, etc.)

I've googled for a bit, and am having a hard time finding multiplayer resources for Unity, especially for 2D games.

Unless I can find a resource (tutorial, book, etc.) I will just try digging into the documentation and see if I can't figure things out by myself. Otherwise, just forget about it (at least for now).

 

Thank you for your advice. This validates my concerns and the concerns of the author of that tutorial.

Did you ever find any resources on getting up to speed with how Unity likes you to do things? My experience with networking is very elementary, and I have absolutely no experience with Unity's networking.

 

I think when you work with networking, of course look to Unity for advice, but mostly, look to the company that created the networking solution you decide to use, and get a good contact in their support section. After a lot of research I decided to go with Shephertz. One reason was they had a Unity plug-in. Another reason is that they had a lot of info in their forum and a lot of Unity specific tutorials. The reason I stuck with them is they got everything a developer could want when creating an online game -- both gameplay networking, storage, and social. But the main reason I stuck with them is that their service is incomparable. Absolutely the best service I have ever received from any company in any business. I mean personalized, prompt, going-way-out-of-their-way perfect and detailed help. They even built DLLs for me to solve unusual problems. They have been helping me for over a year now and I have yet to pay them because I am a lone indie developer and my game is not published yet. (I doubt this will last). Everything I learned about creating an online multiplayer game, with or without Unity, I learned from the Shephertz website, and their support.

And although my game is a Unity game. it uses no Unity networking at all. It uses just Shephertz AppWarp and App42.

If I were you I'd make a simple two-player 'online' game which is a client that has a button and a textbox. When you click or tap the button, it sends a text string message (e.g. MOVETO X,Y) to another instance of your game client. That 2nd instance receives that text string message and displays it in the textbox. Figure out how to get Appwarp hooked up so that their server receives that message from the 1st client and relays to the 2nd client so that the 2nd client can display that message. Just follow the tutorials on AppWarp webpages. You can then see you could add a game object that responds to that received message. You'll get the idea of how a simple (very very simple) game does one kind of networking. That is basically how my board game works. That's how it places pieces at certain places on the opponents' boards, and that's how it sends chats to the other players.

 

A small personal advice, if you are going to create the single player first, is to go with a good component based design.
Don't scatter functions that as such "belong" together in too many scripts. Like have one dedicated for movement, one for animation, one for inputs, one for weapon damage, one for controlling health, one for inventory. Then it is pretty easy to check is a player is owner of the script or not and then manage sending the right data with an RPC for example.

And if you need info from other scripts then make sure to use delegates! Best thing ever!

 

Well i had a small wave based survival game my friend liked it a lot. So i wanted to turn it into a coop game, and it was a nightmare. I mean it was possible but very hard or annoying would be a better word. But not impossible thats for sure.​