Oh my, why so complicated

Two weeks ago there was the global game jam and in the spirit of tackling something challenging I decided to include Unity multiplayer into our small game. Long story short: after around a day I gave up.

I would claim I am by no means a bad developer. I can do some pretty awesome stuff in Unity and other environments. The thing is: a year ago I added multiplayer to a Unity game of mine using Photon. Two players doing turns one after the other, lobby, skillbased matchmaking etc. This took me 2 hours for the initial prototype and 1 day to get right. I would ask for simple "isServer" and if not do the client stuff, otherwise the server logic. I could broadcast messages to all, to all clients etc. Super easy. And the beauty was, if no server was connected it would automatically switch to local multiplayer without any change of code.

So now UNET. My expectations were really high. I was sure Unity staff had looked at Photon and how easy it was. I read blogs how they hired the best of the best with years of experience. And I was sure they had made it the best there is out there.

How could I be so wrong. What I encountered is incredibly hard to understand conceptually, poorly documented, and simply disappointing. The concept of a server which can only send RPC calls, and clients who can only send commands, this makes things tremendously complicated. Or I didn't get it. In Photon a function call was a function call. Call it and it would be received.

I dissected the tanks example, which is really nice and I learned quite some other things from it. But I could not figure out from it how to do a two player turn based game. I could get the server to send something to the first player but I could not figure out how the client could send something back to trigger the end of the turn. Or playing in offline mode without a cloud server (PhotonNetwork.offlineMode=true). Essential but simple things like that.

Probably someone with more knowledge will point out how simple it is and probably it is if you have been working on that and understood the concept. I just have my comparison to Photon. One is simple to use and had super quick results, the other made me throw the keyboard against a wall. I don't think this is what Unity should be going for, even though keyboards are rather cheap.

Someone else might say, then simply use Photon. As sad as it sounds, probably the answer is yes. But shouldn't it be the ambition of UNET to blow all the other solutions out of the water and simply offer the best there is?

I have the strange feeling that some hardly relevant requirement to support multiplayer games of gigantious scale needed to be possible (for 0.01% of corporate Unity users) and that shaped the UNET the way it is right now. I might be totally off here but being in product management myself I know how requirements from the big players can cause many normal users to raise their eyebrows.

I really wished there would be a high level API for the high level API. We are not yet at a point where it is the no-brainer it should be.

 

I agree, it's a bit of a pain all round. I removed it, probably will check out Photon again unless things will improve in the HLAPI. Networking IS a complicated beast and I did have decent enough networking going with UNet, but it just wasn't much fun how it worked.

The LLAPI is ripe for asset store authors to wrap and create their own take on things though. The HLAPI should be taken out to a field and shot.

 

The UNet update for 5.4 was pushed back as well, with a vague "delayed based on feedback" note on the roadmap. Would be nice to get some clarity on what's going on there and whether that update will improve ease of use.

 

UNet HLAPI can work okay if you play by it's rules and don't have too many expectations for the built in components. I use a mix of Commands, RPC calls and NetworkServer/Client.Send methods and I was able to implement a pretty solid setup for my FPS-type game (uses client side prediction, interpolation, reconciliation etc). The benefit of this is that you don't need to fiddle with setting up your own remote procedure calls or your own network identity tracking, but can still kind of write everything yourself.

But really, it should be the goal of the HLAPI to make the concept you outlined (simple turn based game) really simple to implement, and it's not.

 

UNET is just a bit complicated at first if you don't understand SyncVars, ClientRpcs and Commands. Also it doesn't really help that they have somewhat redundant [Server], [ServerCallback], [Client], [ClientCallback] attributes, when isServer and isClient would be enough. Also a ClientRpc doesn't really call a function on the client object that you call it on, but on all clients within the observer range (http://forum.unity3d.com/threads/suggestion-globalrpc-observerrpc-targetrpc.382486/), that's really weird. The documentation is not very good, but you can read through the source code on Bitbucket (which is an outdated version though, so that sucks too). There are also a lot of really weird bugs that existed for a long time and are still ignored by the developers, so that sucks a lot too.

But the core idea of UNET is absolutely amazing. I tried making my own MMORPG in C++ a few years ago, and I ended up with about 50.000 lines of code for just the networking part with some very basic MMO features. For my Asset Store project uMMORPG I needed about 3500 lines of code for about the same functionality, which I find mind blowing. Don't get me wrong, it was a pain to develop it due to the things mentioned above. But in the end, UNET makes impossibly large multiplayer projects like MMORPGs possible, that's why I love it.

Could you share your source for that? Would be interesting to read.

 

@vis2k, it's just a note on the official roadmap. I don't have any insight beyond what's on that page, unfortunately.

 

I agree with most on the HLAPI, to complicated and docs need to get updated.
LLAPI is great though, sticking to that for the time being.

 

Funnily enough I also have a two player turn based system that I've recently tried converting from a local game to a networked game. The actual code for doing the turns part was pretty simple in concept:

A CurrentPlayer [syncvar] on my gamemanager script.
A [command] called EndTurn which handled score, and updating CurrentPlayer.
The player script simply checked to see if their playerID == CurrentPlayer before allowing control.

BUT, my experience with UNET so far has been terrible in a lot of ways. I've wasted DAYS of development trying to get to the point where my local 2p game is networked using the prototyping NetworkManager. It's been so disheartening that I've almost canned the project completely. I appreciate that networking is tough - I've used XNA and Lidgren in the past - and the general concepts of UNET aren't bad, but the bugs & documentation have really made it difficult. Some thoughts....

I was fully expecting my game classes could be used between local 2p and LAN 2p simply but setting a boolean. This was not the case. I've had to start a host for it to work, but even worse, anything with a [command] or [clientrpc] attribute won't run unless actually networked so I've had to put ProcessFire() (for example) wrappers around Fire() and CmdFire() methods with a check to see if I'm running a local game or not.

The NetworkManager class is still very buggy/tricky to use, with duplicates being created, events firing twice etc. It's taken me days to figure out how to allow a new host game to be started after exiting a previous one without problems (such as players not spawning or two HUDs overlaying each other). Even now I have that working, for some reason it jumps straight past the need to hit Client Ready and goes straight into the game with no explanation.

In all honestly whilst I think the NetworkManager is a good (and necessary) idea you also need to document the order of methods & events to do things manually without the manager A) so that people can roll their own which they will probably need to for a production game and B) it's the best way of learning how to solve problems. Just a simple On The Server: Start Server, Set IP, Start Host, This Event Fires. On The Client: Start Client, Add Player, This Event Fires etc etc.

Because of this lack of information I'm constantly aware that I might not be writing the code in the best way. For example I saw on a video that there is an OnDestroyed event (or something) that I can put explosion code in.

Even now, with what is a relatively simple base project - 2 players, firing code and simple collisions - my project is reporting "CRC Local Dump" errors, "Did not find target for sync message" warnings and "sending message header failed" messages. I'm tired of Googling errors, finding other people with the same problem and no replies on how to fix it. I just want to get back to coding...

Saying all that, I've never used Photon but the idea that "functions are functions" worries me a bit that it might be too high level and that Commands and ClientRPCs could actually be a good thing. I'm not best placed to say due to my lack of experience with UNET.

Finally, we're all merrily adding UNET to our games but (as far as I'm aware) still have no idea how much it will cost. My game really only works as multiplayer and therefore needs to work over the Internet for people to want to play it. However it's also a simple game that can't be sold at too high a price (if at all), so with 100 people playing this simple game it could end up COSTING me money to put out the game.

 

I agree with @vis2k as well. It's not the most intuitive at first maybe but it's powerful and once you understand concepts and if you don't use ready made components like NetworkManager and NetworkTransform maybe you can build what you want with it. I'm not saying Photon is bad or something, Their API is much easier to use and they are a more mature technology but uNet has it's own advantages.

 

We all have to remember that uNet is still beta. I have had quite a few issues getting things going for a project that took me a day to get going single player, to 2 weeks + to make it multiplayer. I also have no previous networking knowledge, and had to learn as I was going so that accounts for some of the time, having a full time job being the other.

My sentiments as well. Again though uNet is beta and has very little information and hasn't had the time for people to figure out its little quirks and demands to let the rest of us know.

I don't like that its not updated, but at least you get an idea of what is going on in those classes and can learn a lot from them.

Using the basics of uNet costs nothing for LAN or internet games. Its the matchmaking service that will cost. That is paying for the use of a server that everyone connects to, to find other people to play with. You would need to fork out this money on your own to create and maintain the servers that allow matchmaking.
If you use services like Steam/Google Play that allow you to use their servers for matchmaking purposes you can bypass the cost of uNet matchmaking but still use uNet for multiplayer(you only need the port and ip to connect and Steam/Google Play will provide that info like uNet matchmaking does.) If you don't want to use matchmaking at all like Minecraft, users need to know the IP and punch it in manually, which will cost you nothing but inconvenience the user.

 

Thanks for that. Presumably then, we'll also need the matchmaking service to do NAT punch-through? Given most games with UNET are designed to be P2P, NAT punch-through will be a necessity for most?

Going back to the broader question of the quality and direction of UNET, and given what a major release UNET is, I'd really like Unity to at least...

1) Keep everyone updated on the changes being made and when they expect updates to documentation etc.
2) Chuck a few more people at support on the forums until the community can take over.
3) Provide a simple project example that doesn't use NetworkManager/HUD and makes uses of the core methods and events.

 

Hi All,

I don't usually post as I've been a happy Unity user for some time but this one is bad enough that I want to step into the spotlight and humbly take up the microphone.

*Gosh.. here goes...*

I've seen that Hippocoder is a good Unity supporter over the years and for them to say what they have means there is a real problem. I would like to share our experience with networking.

Our story: Anjin Games run DeadBotz a singleplay/multiplay/lanplay third person shooter. We are live on the Play Store now and have been using Unity5 since the middle of last year.

We are currently having to hang back on Unity 5.1 as thats the only one that works with the RakNet based system.

We took a look a UNET and gave up like most of you did. UNET was too complex for our needs and we felt that it was not fully ready. Good thing we didn't go down that path as it would have been a blocker for us.

I recently tested 5.3.3 in the hope that it would fix crashes on our Linux servers (a forum comment said it did). I think the Linux bug was fixed but unfortunately the servers now wont register with the master server properly.

This is really unfortunate as Anjin has been making great strides with other areas of Unity5 and feel sure that 99% of it is gold.

Hopefully Unity devs can see from this that no one can upgrade beyond Unity 5.1 (if they want to support networking without rolling their own stack). It would be great if they could ensure the old networking functionality works at least until the new solution is fully working.

Please help us Unity developers. We are doing our best to make a good product that shows off the engine.

Thanks for listening folks and sorry if its a bit garbled.

Peace,

Anjin.

 

Here are some thoughts from my personal experiences so far.

UNET is still beta. There are bugs. This makes it risky to use it for production-level already. But I think we can expect many bugs being fixed for 5.4 (e.g. client re-connect bug with matchmaking).

Matchmaking is beta as well. However, given the current information in the forum, the current concept sounds reasonable and quite fair to me. But we still have to wait until more information is provided here.

I found some out-of-the-box components not convincing yet (e.g. NetworkTransform) so it seems better to use custom implementations.

Documentation is lacking and this is a significant gap, even for beta. The docs are not complete and much more stuff could be added, e.g. complete descriptions of object creation and destruction flows/callbacks, best practices, comprehensive up-to-date and working examples, bandwidth optimization hints, more detailed documentation on custom network manager implementation, etc.). However, the docs are currently being improved which is good to see.

As it regards the HLAPI, I got used to the basic concepts pretty fast. I actually don’t think SyncVars, Commands and ClientRPCs are that complicated. Personally, I found it quite amazing how fast I could implement working FPS multiplayer game play with these concepts. Other network solutions might be even more user-intuitive, but higher abstraction might also include higher loss of control. Personally, I'm perfectly fine with the UNET HLAPI concepts.

I found some aspects to be more complicated, like properly implementing a custom NetworkManager while fully understanding what is going on. This required me a decent amount of trial & error in the first place. However, I guess this is less a fault of the NetworkManager itself but more of the insufficient docs.

These are just some of my thoughts. I agree that UNET is not perfect yet, but still I find it quite amazing. Also, I had the feeling that the UNITY team has recently put some priority on fixing bugs and improving the docs. I hope that they don't lose pace here.

 

unity really did no favors to people when they made this , my biggest problem with UNET is the authoritative HLAPI system , unity usually alllows you to do things which ever way you want , complete freedom , now they restrict unity users to this , authoritative is great and all , but really its useless when your internet speed isn't a 100mb line , Also they say all you have to do to get networking is a simple sync var here and there , couldn't be further from the truth , It took me 50 lines of code just to get movement and shooting synchronized , in photon it took like 5 or maybe 10 at most , i really liked the old system , it just needed fixing , it had alot of bugs and missing features thats all , no need to revamp it completely.
/\ my opinion .

 

For anyone else reading this thread...you in NO way need 100mb line to use authoritative movement. If you're not using client side prediction and interpolation, it doesn't mater how fast your internet line is, you're doing it wrong.

I think the short answer is, if you're playing around, prototyping, testing concepts, or learning. uNet is really cool, but like anything, if you're using it out of the box and trying to use their canned examples for more than they're meant for...shame on you, nothing works like that.

If you're trying to do serious work, or have a real intent to release a game, forget uNet, it's nowhere close, it has no documentation you can rely on, it has no published metrics on reliability, bug or exploit response...we don't even have a descriptive roadmap at this point, yea...you can't base work off that.

 

Yeah thats why most authoritative servers don't work here in south africa , where the fastest download speed is 10mb at a cost of 1800 rand a month with a cap of 1gb , without that playing online is useless .Average down speed here in is 1 mb at 320 ms , client prediction only works on movement what about opening chests and inventory etc , in the games i play i press a button wait a minute then the server responds not my idea of fun . so no authoritative is useless unless you live in the north where all the servers are.

 

Yea, you're right about direct server access for things like chests, inventory...two really great examples of places it's hard to compete with a good ping.

 

This is why I love Forge so much & go around bragging about it shamelessly.

• I tried to implement UNET when it first released for a total of 40 work hours. I failed.
• Forge took me about 5 minutes to succeed in what took UNET 40 hours to fail.
• Forge has no CCU limitations. No messaging costs. Buy once, free after that for life.
  
• Forge is completely open source. UNET is not. In fact, Forge is the only package that is open source. HUGE DEAL for me.

So as you can see, this is why it won me over for life. #$@# UNET. What a freaking waste of time. 40 work hours for a hobbyist developer is a lot of hours. It set me back horrendously & caused a huge lump added to the burnout scale (so theoretically UNET costs me even more than 40 hours, with nothing to show for it.)

You weren't the only ones fooled. Idk if it's even true that they hired "the best of the best" but if they did, then Unity somehow causes "the best" to become incredibly incompetent. Which would make sense, given how many employees they have but how poorly Unity is developed. (Obviously I have a huge bias against Unity as a company. Which makes sense considering I've been around since near the beginning- before it was even popular. I only use Unity for its Asset Store. Those developers are the real "best of the best". Unity just skates off their coat-tails.)

Don't use Photon. Use Forge.

Isn't this true of EVERYTHING Unity does? Its 2D features were a great handful of breadcrumbs they threw at us who were beginning for it since the beginning (When Unity was only used to make 2D games, but had horrible/non-existent 2D support.) Then they just dropped the ball, ignored the features, and chased that 3D crown. Their priorities are not aligned with their developers. (If they were, they'd already have given us nested prefabs years ago.)

If you're using UNET for a huge project like a MMORPG, then I have to say: Your project will never see the light of day. No professional would ever be caught dead using UNET for an enormous project.

Idk man, I am skeptical they are focusing on anyone. Unity's decisions seem more aligned with the idea that they roll a bunch of marbles in a craps wheel and just focus on whatever it lands on.

That is unfortunate. It's been a very long time since I first used UNET (shortly after its initial release). I was hoping it would have been improved by now. Some said it was. I'm sure it has been, but I knew I was right to assume that despite any improvements it was probably still as horrible as everything else Unity seems to half-ass.

Reading your experience just pisses me off & infuriates me more towards Unity as a company. Yes, it's great they made their engine (I guess. Not impressed with it at all & mostly just negative things to say about it.) and YES, it's absolutely amazing they created the Asset Store & made it successful (This is where I give them all praise.) But yes, their irresponsibility/incompetence/rushed-releases/incorrect-priorities do harm people every day. It costs us in time & sometimes even money. That infuriates me.

Unfortunately there isn't really a good alternative. Not for me, anyway. That Asset Store is awesome. Assets like Forge Networking make Unity freakin' awesome!

Here's a link to Forge.

 

As a gamer, as a developer, as a freakin' human being: I am sick of this whole "Beta" excuse. "Early Access" crap. "Pre-Alpha, Alpha, Beta, Early Access, Release" it's all one big scam to put out software that isn't ready to be released. And consumers eat this S*** up like it's a buffet.

Note: While I ranted against game developer's gross misuse of Early Access & Perpetual Alphas, I realized that UNET very well may be correctly classified as Beta. I guess I got confused because I was unaware it was in Beta. The release notes I read acted as if it were Released.

Others seem to think the same thing: http://forum.unity3d.com/threads/unity-multiplayer-unet-features.336203/

I can't readily/easily find out where it claims it is still in Beta. So maybe my rant is justified. Even if it were in beta, a company is responsible to make sure it comes off that way (it should be obvious). Instead, at least IMO, they want us to believe it's release


As a company, Unity irks me. Mainly because I feel as if these days, even our software is suffering from the "Early Access" scam. Replace [game] with [UNET] and IMO it fits well.

As one of the world's leading game engines, Unity has a moral obligation to not half-ass things, to be more honest about their releases, and to for the love of God have better documentation for UNET. @Freakyuno said every complaint perfectly

Spoiler

Forget uNet, it's nowhere close, it has no documentation you can rely on, it has no published metrics on reliability, bug or exploit response...we don't even have a descriptive roadmap at this point, yea...you can't base work off that.

But here is my rant anyway.

Spoiler

You know what things USED to be called? Released. That's it. Then they added in "Beta". Then "Beta Preorders". Then "Alpha Preorders." Then "Early Access Preorders". Now they do all kinds of things, including games that aren't even games released on Steam as "Early Access". Stuff that doesn't even run that has to be removed by the vendor.

It wasn't so bad until it began to happen with our development tools too. It used to just be "Release" and "Beta". You understood that Beta was just release with some bugs. Then it got worse as developers (Idk anyone else, except Unity) who start to release "Alpha" and call it "Beta". When UNET was "officially released" it didn't even work. That's Pre-Alpha being labeled as a Beta-Release.

And the funniest part?

All those words are meaningless ANYWAY! They mean whatever you want them to mean.

Take the developers of Project Zomboid for instance.

Spoiler

They claim their game is still in alpha, and it is but only because they actively pursue insane amounts of feature creep. They extend their features, which extends their alpha & increases the gap until Beta. They did this for so long, succumbing to so much feature creep, that they have been correctly labeled as a Perpetual Alpha. This is similar to Dwarf Fortress, except that Dwarf Fortress is honest about it. PZ is dishonest about it and tries to convince consumers they are not a perpetual alpha. That they are not like DF. (Although it would be beneficial to them if they claimed to be similar. People LOVE DF. They would understand too.) They even recently made promises of the DF-variety. "It's taking 4+ years to do NPC's because the NPC's will be so amazingly complex they will change the world." (Paraphrase).

People constantly say "Software is never finished." because you can always improve it. That is in part true, but at the same time there is a quality standard where your core features are finished & free of the majority of bugs. That quality release isn't required anymore by consumers, so most just abandon the idea entirely.

There isn't even a real thing as "Pre-Alpha".

Spoiler

That's just what you call something that doesn't yet exist. It's just a prototype. It's just messing around. It's also a very short phase in development. In reality, for consumers there is just Alpha, Beta, and Release. You wouldn't recognize these terms though since the majority of developers abuse them or misuse them. Most don't even know what they mean (which is increasingly true the more amateurs become indie devs, selling hundreds of thousands of copies of games & randomly picking what label they want).

Traditionally,

• Alpha: When you are working on adding features. (Wikipedia) The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.
• Beta: (Wikipedia) Betas when the software is feature complete but likely to contain a number of known or unknown bugs.
• Release Candidate: A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities.

Developers these days just don't seem to even care to write a feature list. Feature Creep is so common.

Spoiler

I've seen projects that would have been released years ago, still called alpha. Projects that should have been released years ago that are still called Beta. Then once release finally occurs? No one cares because everyone already bought & played the game.

Sure, not every game misuses these terms. Yea, some games are stuck in perpetual alpha and are rightly classified as alphas even 4+ years after their initial early access release. You could even argue that technically they still are Alpha/Beta. In reality though, consumers just perceive Release differently.

Companies used to release a game and it seemed like it was still in Beta. Very buggy.

Spoiler

They could always patch the game later, so np.

Then they realized they could just release the game as an Alpha, and get the same benefits of releasing too early without the negative repercussions. Is it more honest? I guess so... but the right move would be to just not release until it's ready. That's what Valve/Blizzard do, and they are considered the higher quality developers because of it. And their Betas? They are probably true Betas, if they even exist externally.

 

Man @CarterG81, your avatar sure fits those posts. But I agree that Unet's HLAPI seems really confused about what it wants to be. None of the components are really ready for a high-quality production. The way you communicate between client and server is a bit clumsy (can't send an RPC to a single client? But you CAN .Send to a single client).

I know you're talking about the HLAPI, but according to this page you can use the LLAPI for peer to peer.

I agree strongly with this. If you take the HLAPI as a small set of networking abstractions (RPCs, Commands, SyncVars) it can be a pretty useful toolbox. The problem is that in order to use them efficiently, you kind of need to know exactly how they work...and given the state of the documentation, that can be hard unless you spend a bunch of hours doing various tests.

 

LLapi is a mess of its own , way to complex for a new dev like me to use , seriously the old way of networking worked perfectly , it just severely lacked features and was a buggy mess , this new way has to much voodoo magic going on that users just cant understand , if i wanted voodoo i would use playmaker or the like in unity , i like to know what code is running and how it's running and when , theres just to much black boxing going on , I really liked the old networking , it was simple and let me do things my way ,If i wanted to go authoritative i could .

Thankfully I can do my own non authoritative server through unet , its just a pain in the ass , cause i have i to use commands and syncvars depending on if its the server or client so double the networking code and that means code is running for no reason , really i have to agree that who ever the people that wrote UNET or who ever told them to do this should be fired , sad but true , they didn't stick to unitys core belief , make game making accessible to all , That is not what unet is , it seems mostly catered to big companies with experienced devs , not the small indie devs that unity grew up with.

 

The only answer then is an open source package. If you can afford it, anyway.

I don't think it's catered to big companies either. If I were a big company, I would never in a million years use UNET. MORE SO than otherwise. I'd be more likely to use it as a small indie dev or someone who refused to spend the money in the asset store (or didn't have the money & needed the free solution UNET provides). Then again if I had no money, I wouldn't even use Unity in the first place. I'd just roll my own engine.

 

That's true , so unet is a pointless waste of time basically , to bad i'm that dev that cant afford to buy anything from the assetstore , and I'm the dev that can't roll my own engine either , so I'm stuck with what i can get for free , as unity pro cost's about as much as a used car here 22 500 Rand is not something I'd spend willingly on a piece of software , nor would i ever spend 750 rand on a networking solution .

i wonder is it possible to just roll my own networking In unity?

 

It's definitely possible, I mean that's what Forge & Photon did, isn't it? Is it feasible though? Idk. I have next to no networking experience. I can definitely see that being a PITA / consume lots of time.

If you need free, then UNET or (Photon?) might be the best solution. Either that, or just making a singleplayer game or taking the longer but better road of learning network programming yourself. Lots of work learning, but then again you'll learn a lot by the end of it. Or maybe a crowd funding / gofundme to raise some money to purchase Forge? It might be very feasible to get $75 crowdfunded if your game looks awesome and you have some supporters already. (And before that, I believe all the packages have free versions to test out?)

Personally? If I couldn't afford anything from the asset store but still wanted to use Unity, I'd probably either postpone a multiplayer game (go singleplayer) or try my hand with UNET despite it being a PITA. After all, it does have the strength that it WILL get better (eventually being good; not sure how much they are focusing on it but if they are focusing big on improving it then that's a great sign) and it won't go away. And it's free. Unless you're comfortable trying the free version of Forge and if it looks like what you want, trying to raise $75 on a crowdfund website. That's so little, I can see it being certainly possible.

My experience with rolling your own solution vs using Unity's, is that rolling your own is hands down better. Nearly always. The time it takes me to learn the "Unity way" or learn how Unity's features work, I could have learned how to do it myself AND done it. It's just that I can't say this about networking because I've never tried and it's an entirely different ballgame from what I normally do (which is closer to regular programming.) I don't have enough experience with networking to comfortable say it's the same as every other form of programming (learning / implementing wise).

Plus keep in mind I am not the usual gamedev. I've been learning to gamedev pretty hardcore for the last 6 years... so I know a lot and have done a lot. If I were a year 1 newbie who needed to release a game for income & not a hobbyist who just wanted to learn & eventually release something 6 years later... my opinion/perspective would be very different. So take everything I say with a grain of salt. I am a hobbyist in it for the long con.

UNET has its strengths. They are just strengths that will develop over time. Which sucks, but it's definitely the most secure networking choice (won't disappear) and will (hopefully) receive consistent updates. Unity promised this year would be big on documentation too, especially with UNET. Although it's already march and idk if that is true yet or not.

So it's not without its strengths.

 

I don't mean to ask unrelated questions or anything, but I floated around trying to settle on a networking solution to learn for quite a while. I ended up buying Forge about... 6 to 8 months ago and giving it a shot. I couldn't seem to get things working properly, even following the tutorials. Their equivalent to SyncVars were mixing values and all kinds of confusing things. Granted then, I had literally no experience. But I started over using Unet and didn't have any issues. Right now I have authoritative movement with client prediction working, as well as throwing items around. It's not much, especially since I'm working in 2D, but as I'm a hobbyist with little experience I feel Unet was pretty simple to learn, at least up until this point.

I constantly read negative things about Unet though and it's troubling considering if I need to switch I'll be relearning another solution all over again. All the negative comments and info stating that any game made with unet is doomed make me want to go ahead and try to switch to forge again.

Aside from the "premade" components like network transforms, which I do not use, what parts of unet are so awful? I realise these components aren't really transparent in how they work and don't really help making authoritative serverserver and whatnot but is it really fair to say that if I continue down this road I'll be completely screwed? I'm not planning on my hobby producing a massive mmo or anything but rather just a simple server with a small capacity that I can eventually play with my friends.

Would you say it's worth it to go ahead and try to switch to forge again and rebuild all I have? I considered it multiple times but since Christmas it seemed that the devs of forge kinda stopped communicating as much. The tutorials are good and all, but they seem outdated and less intuitive to me than unet's documentation, which even I could understand pretty well.

 

My experience with with UNET was mostly positive (except for 3 months old bug report with source which unity devs seem to be ignoring). Im using UNET for a dedicated partly-authoritative server, mostly with the NetworkMessages HLAPI. As long as Unity devs don't abandon UNET and keep developing, we should be fine.

 

Yeah, I just don't fully understand the flak it gets. I don't understand what I would gain from switching to Forge either. It seems either way I go I can make a headless build to act as an authoritative server, but neither of them handle allowing users to connect without port forwarding. I just spent an hour trying to get the few things I have working working through Forge, and realized I can't send data types like Vectors through RPC's using forge. I'm sure that's not necessary or anything but I would have to rewrite a decent amount of code to re-handle how I make packets of information just to try to send RPC's to and from the clients.

Maybe its just because my only experience is with Unet but it seems much clearer when I have Commands and ClientRPC's because I immediately know what is being called for servers and clients, without relying on just checking if the code is run by the owner or not and returning if not.

I forked my project and I might continue trying to convert to Forge just to have both started and learn both, but right now Unet just seems to make vastly more sense to me, and I don't really see the upside to working with Forge. I asked on Slack if anyone could point me to some benefits of using Forge over Unet and the only answer I got was that they hadn't any experience with Unet. I would love some info on this or maybe someone who has worked with Unet that would like to point out some advantages Forge has over Unet, but for now I guess I'll just stick with Unet as I haven't had any complications so far.

 

I wouldn't say that. In fact, the more time that passes, the better UNET will probably be. (Although the same could be said of Forge too, you have already done work with UNET.)

As long as it works, it works. Does UNET work for you? If so, then great.

I would be careful rebuilding everything you've done. You don't want to waste all that time you've already spent for no reason.

What do you have done? If it's a ton of work, you probably want to stick with UNET.

Yes, they were out for a few months after Christmas because they switched lead developers & brought on a second developer to the team. They're back now, although the new dev is still getting caught up. They just the other day released v19, so they're pretty close to getting back on track updating every week.

That's one of the first things they plan on tackling, the outdated documentation & lacking API. We'll have to wait & see how fast they update that.

If UNET works for you, then I'd recommend sticking with it.

However if you do go from UNET to Forge, I did quite a lot writing up on the transition.

Once you get access to the wiki, http://wiki.forgepowered.com/index.php/UNET:Getting_Started

It's not the best writeup, but I tried my best to write it out as I converted from UNET to Forge myself.

 

Seriously, you can't be for real. I hope you are enjoying your early access "scam" for free btw. It's ok to give feedback. It's not ok to talk smack about unity :/

Unet has a lot of problems with it's confusing and a shock to understand vs other networking systems. I really want UNet to work because its native, it's not going to suddenly have the author decide that it's not receiving enough money and stop working on it. That, I could not tolerate, therefore my options are only Photon and UNet.

My next attempt will be to remove all the confusing stuff. This means I never use [Server] etc and I never use syncvar. Once I dump those, and stick strictly to commands etc then I should be able to have a decent handle on it.

The problem for me was the whole [Whatever] and [Sync] stuff. That's actually causing way more problems than it solves bug wise, it's not something I'll ever use.

TLDR:

I think that adding "magic" code is a very, very bad idea going forward. You don't want to hide what is going wrong, you want to keep code as complex as it is and provide components, or blueprints to serve less technical users because you just alienated everyone between.

 

@CarterG81 , thank you so much for the very thorough response. I wasn't trying to say you're wrong at all, I'm obviously much more inexperienced with networking or programming in general than you are.

It's not that I have an incredibly immense amount of things I'd have to change to switch, it's just that I'd like to know what I'm trying to do will actually be possible, and with so many posts condemning basically all these solutions one way or another, it's a little frustrating feeling like I'm going to hit a wall eventually that will make any of this work worthless.

I realize this likely isn't the case, as any of the solutions will likely work for something as simple as I'm striving for, but I'm just simply too inexperienced I guess to know what the reasons are behind the arguments. What is it exactly about forge that makes it better than unet, what are the benefits? I will glady switch if I can find any, as at least my experience with unet has given me some knowledge as to how networking works. Thank you for your link to your write up by the way, that is brilliant and I've already forked my project to try to get forge working in my project.

Right now all I have networked is authoritative movement with client side prediction (top down just 2D) and some logic for moving items around through networking. It's not much honestly but it took me a while to nail down. I don't think it would take much time at all to get it working in Forge, aside from learning forge and what specifically to do.

Sorry for the rambling, I know it's likely going to come down to whatever works, use that, but as someone who has experience in both solutions, what is it about forge that you found was worth switching to? Just ease of understanding? Or was there something concrete that you could not do through unet?

 

I don't use UNET. It being free doesn't entice me to use it. That's like expecting someone to be grateful that they can get kicked in the nuts for free. Just cause it's free...

As for Unity Engine itself, that is different. It doesn't suck as much as UNET does. Still, it's not free. I have requirements to use Unity Engine, which are lots of Assets in the Asset Store. Those require money, in which Unity gets a cut. So it's hardly free when the requirement to make the engine useful is to spend hundreds of dollars on top quality assets.

It's also not as if Unity is this flawless company. Their flaws have been consistent for years, and I praise their strengths (the Asset Store & supporting third party developers) and admit their weaknesses (which they refuse to change, which is their greatest weakness). I tell it like it is. Without that Asset Store, it's worthless to me. Actually worse than worthless, it's a drawback. With that Asset Store which adds +$100's of cost? It's worthwhile.

So don't lecture me on entitlements, dissing "free" stuff, etc. It's not free. Not even close. And when the game sells? A pro license before release or after sales is pretty much a requirement for me. That is hardly free. I don't want my consumers to see a Unity splashscreen because gamers automatically think "Oh @#$, not another Unity game..." because even the successful ones have serious performance problems & lack of feature support. I'd know, anytime I see a game made with Unity I think "Oh no..." and anytime I find out an indie used Unity I think, "Everything makes sense now. Of course they used Unity..." The best we can do is fix Unity's problems, minimalize its weaknesses, and hide the fact we use it.

So for me, using Unity costs +$100's of asset store costs + $1500 license (minimum). For $2000+, it's barely worth it IMO, but worth it none-the-less. And that's on a good day. On the bad days using Unity, I contemplate whether or not I should have just rolled my own solution from scratch. It's not like making a simple 2D game engine is this incredibly huge task.

Unity gets paid by everyone who purchases assets, and they will get their dues for the product they give with those pro licenses. It's all fair. It could be more though- Unity could be so much greater than it is. That's my biggest complaint. Those asset store developers...they're freakin' fantastic. Unity should work with them more to make their engine better.

 

So you're upset you use asset store because Unity dared to try and make UNet suitable for all possible mp games for all possible devices, for all possible scales, and hasn't finished?

Would you rather they finished too soon with UNet, completing it with very minimal features, so minimal that you'd have to... wait for it.... go to asset store? by your argument (ranting tbh), Unity can't possibly ever win.

 

Welcome to the club

And for the record, I'm not at all experienced in networking. That's why I use Forge, because I don't want to learn networking anymore than I have to.

It's a lot easier to understand than UNET, but I also find that the lack of documentation for new features does make it a bit hard to understand. Nowhere near as hard as UNET (that documentation fried my brain, and the examples didn't even work when I was using UNET. idk if it got any better since), but still not easy to understand sometimes.

But having access to the source code lets me at least poke around, seeing what may be wrong with what I'm doing or figuring out how to do it. (Right now I'm at a bit of a standstill until I figure out why my proximity updates don't work when the feature works perfectly fine in the example projects. I'll have to make another empty project to figure out how to set it up before adding it to my game).

For UNET, I couldn't even get things to work. I got stuck for 40 hours just trying to instantiate a player after they select which character type they wanted to play as. With Forge, I got everything working in 5 minutes, and although I had the exact same problem in Forge as I did with UNET, the Forge developer gave me a working solution after I sent him the project. Took a single day, but mainly just waiting (not working). The solution was something I tried in UNET but it just didn't work. Worked in Forge. Ever since then, I enjoy working with Forge.

After that, I ran into a problem here or there, but it was mostly with my own code & understanding how to do networking. Not really Forge's fault, but still a bit of a hassle trying to figure out how to do things the way I wanted to do them. Forge had all the power to do it, but I needed to know how & the examples/tuts aren't there yet. But I was able to figure it all out.

With UNET, can you reach a Unity developer to ask them a question directly about UNET? Will they or the community help you resolve a problem, show you examples, etc? Forge has a slack community to post questions in, and very helpful developers who will take a look at your project or the way you are doing things to help you out. That's invaluable to me when I get stuck. Although it does take them long enough to respond, or I explain the problem so poorly, I inevitably figure it out before they are able to respond/help. But talking in the community about it helps. The alternative is UNET or Unity forum posts, which sometimes never even get answers. I'd gladly take an answer in a day or two over "never".

Forge also "Just works". Any bug I found, I just report it and pretty soon it's fixed. (This was back when they were active. Right now they are playing catchup, so it might not be as fast fixes as it used to be. But soon. Also, there are a lot less bugs now.)

Idk what else to say. I just hated, absolutely hated UNET. When I tried to find help in the community, I received none because everyone else was having the exact same problems. (It was just broken when I used it.) I haven't touched it since. But Forge, I got everything working in a few minutes & then a few hours to transition over from UNET to Forge, and from then on out it was just a matter of doing some software development / network programming.

 

This seems a bit off-topic. Don't want us to derail.

Spoiler

No, I'm upset with Unity's rushed, buggy releases. Poor quality releases, slow updates, and 4+ years to fix some nasty bugs. With UNET specifically, the fact they released it outright broken intially, and the fact it took 40 hours out of my gamedev time when they could have just waited to release it until it was actually working. If I knew it was in such a horrid state, I wouldn't have tried to be an early adopter. I don't care if it works now. Just like with everything with Unity, updates are uber slow & source is closed. I have a huge problem with closed source software, especially developer tools.

All quality asset store assets are open source- which is a big part of what makes them great.

Unity can win very easily. Work on a feature until it's quality, ready for release. Don't release too early. Don't rush it. Focus on it until it's quality. Stop rushing for big features that sell, and just work on a quality product first. Also, don't abandon features after implementing them because they don't fit their vision for the future. Finally, don't release features 4+ years too late. The 2D tools didn't come until years after they were in high demand. When they finally came, they weren't as necessary as they were back when Unity wasn't so popular & all people were making were 2D games.

They'd also be a big winner if they worked with asset store developers to improve the engine itself, rather than relying on them & then forgetting them later or pushing over them with their own feature rollout. There's a lot they could do to pull in those developers & improve the engine as a whole. Where everyone wins.

Also nice try attempting to minimalize my legitimate points by painting it as just "ranting". To be honest, everything can be considered a rant. Even your response. Not sure what that has to do with anything. Of course I'm ranting. Then again, it's a bit on-topic considering the OP title is "Why so complicated?" and my answer is basically a rant "Because it just plain sucks."

 

Honestly, I think people have gotten WAY to afraid of this, and I'm not sure why. Socket servers aren't hard. I think Unity with uNet are actually built for "prototypes" - that's the only thing I can figure out at this point. I'll look at it again when the release that contains the standalone server is produced...whenever and whichever that is.

With a little knowledge, and google, you can literally roll your own socket server in C# in 45 minutes. Now, that comes with the understanding that you've got YEARS of learing to make it production ready, but for what you're getting out of the box in uNet, you'd be in about the same place.

 

For anyone wondering whats wrong with UNET and why it sucks heres a list of issues i have.
failing to send sync messages at random times .
failing to instantiate objects at random .
failing to set parent of object based on net id.
failing to sync anything if client unless you use syncvars and commands.
ClientRpcs dont do anything due to errors: tried to send rpc from client and trying to send rpc from server (what?).
commands dont work unless the object is a player object (what ?).
syncvar only works on server (great job on this ).
authoritative server ( yes i hate it so much ).
documentation with examples that don't work(well done on this!) .
overrides instead of callbacks on void's such as OnNetworkStart and OnServerStart (why oh why did they do this ?)

I could go on but it'd be a waste of time .

It took me 2 weeks just to get movement synced on both server and client (Non authoritative ) , then another 2 weeks trying and failing to get the both players to damage each other .
Really I stand by my point that the old way worked fine just update it fix the bugs and release , Throw Unet away , It's useless .

 

Thank you so much for your reply, definitely a solid answer and I really appreciate the information.

 

While I agree that it's confusing using overrides in tandem with attributes and other seemingly redundant stuff,

I don't really understand the other stuff you've listed. I haven't worked with networking prior to unet, which may be the issue, but after watching one tutorial series on Unet I had non authoritative movement working fine (granted 2D, but still) and not long after authoritative movement. I haven't had any problems using ClientRPC's or Commands, instantiating over the network, using SyncVars, or anything else you've mentioned. Maybe it's just luck, but I haven't. Sometimes the documentation could be better, but I feel that as a beginner if I could piece it together then anyone could. I don't mean this as any sort of negativity towards you or anything, I just don't know how you haven't been able to get basically any part of Unet working correctly.

Honestly, my movement is authoritative and has client side prediction and only uses one command and one rpc to send back and forth from client to server and vice versa, so I don't know why something like that wasn't working for you. I've never had a command or clientrpc fail to work unless I was calling it incorrectly.

I also haven't come across a case where I needed something other than the player to call a command, but that just may be my case as well. Servers can call RPC's on anything I believe, so I think it's fine to only call commands from the player.

I don't use the components for Network Transform though, which may have given you trouble.

 

Yeah no luck has not been on my side , I had massive UNET corruption , had to reload my assemblies 3 times , It would work then stop working then work then stop , it was like an intermittent error of some sort , i had to stop using network transform from the beginning as it completely failed to do anything , Rpcs never worked due to my error i mentioned .

Maybe it is just me , but nothing works as it should , heres an example code that works for movement non authoritative

Code (CSharp):

1.  
2.     [SyncVar(hook = "playerPos")]
3.     Vector3 position;
4.     [SyncVar(hook = "playerRot")]
5.     Quaternion rotate;
6.  
7.     [Command]
8.     void CmdplayerRot(Quaternion rott ){
9.         transform.rotation = rott;
10.     }
11.  
12.     [Command]
13.     void CmdplayerPos(Vector3 pos ){
14.         transform.position = pos;
15.     }
16.  
17.     void playerRot(Quaternion rott ){
18.         transform.rotation = rott;
19.     }
20.  
21.     void playerPos(Vector3 pos ){
22.  
23.         transform.position = pos;
24.     }
25.  
26.  

 

unnecessary code is unnecessary.
But it does not work any other way believe me I tried everything else.
If it works it works well , but usually it just stops working half way through a game

 

:/ I won't lie that sucks to hear.

I'm not sure if it helps at all but SyncVars can only be changed on the server, in order for those values to propagate out to the client's. Each time they are changed on the server, they sync with the client. So I don't know why you'd be required to try to set them outside of the commands.

Otherwise, this only works if you have duplicate functions, one being a command, and one not, and calling them through hooks?

That's really strange, as I haven't had an issue with it. I call the command with the overload of whatever I need the syncvar to be, and then set the syncvar to the sent value, and it hasn't failed.

 

Hi All,

FYI Unity's Erik Juhl is asking for feedback on this thread. http://forum.unity3d.com/threads/official-multiplayer-improvements.390823/

Definitely recommend the feedback is constructive and concise.

If we are lucky this might help us all

Anjin.

 

I took me about half a year to recreated what I was able to do prior to UNet. But that's primarily due to lack of documentation and how a lot of my searches results would give me legacy solutions.

I've gotten used to it and sending RPCs have more or less been much easier and reliable (although more limiting in how large data can be and how often it should send, for some reason). My biggest gripes with UNet is how you have to setup prefab "player" objects in the NetworkManager like it assumes that I'm doing a basic arcade shooter and how you can't prefab with as hierarchy of objects with multiple NetworkIdentities combined.

Good news is that, since the transition, the networking features of my game are better for it.

It it was, then why did Unity tell me that my original code was deprecated?

 

Holy cow yes that was annoying. It was the same with the 4.6 UI too. The Legacy has faded a bit into the backdrop by now though, which makes it a bit easier. I guess it would be nice if they gave official names to the new systems, but then I suppose down the line it might be confusing to have the native networking system have some name like "Unity Mega Networking." Either way it was definitely a problem.

You don't have to use the NetworkManager, or are even required to extend the NetworkManager. For my game I just manually connect the clients to the server and do all the scene switching myself. This way I was able to build my own lobby system and have complete control over how everything is spawned and whatnot.

 

How did you figure out how to do that with the docs? Is the LLAPI documented well?

 

I used the HLAPI to do it. Here's a really system client-server script that uses the HLAPI, but not the NetworkManager.

Code (csharp):

1.  
2. using UnityEngine;
3. using UnityEngine.Networking;
4. using System.Collections;
5. using UnityEngine.Networking.NetworkSystem;
6.  
7. public class NetTest : MonoBehaviour
8. {
9.     [SerializeField]
10.     bool printSender = true;
11.  
12.     [SerializeField]
13.     bool printReceiver = true;
14.  
15.     [SerializeField]
16.     GameObject dummy;
17.  
18.     NetworkClient client;
19.     ConnectionConfig config;
20.  
21.     void Awake()
22.     {
23.         config = new ConnectionConfig();
24.         config.AddChannel(QosType.StateUpdate);
25.     }
26.  
27.     void InitializeClient()
28.     {
29.         client = new NetworkClient();
30.         client.Configure(config, 1);
31.         ClientScene.RegisterPrefab(dummy);
32.         client.Connect(inputHost, 7777);
33.     }
34.  
35.     void InitializeServer()
36.     {
37.         /*client = ClientScene.ConnectLocalServer();
38.         client.Configure(config, 1);
39.         client.connection.isReady = true;
40.         client.RegisterHandler(MsgType.Connect, OnClientConnect);*/
41.         NetworkServer.Configure(config, 1);
42.         NetworkServer.Listen(7777);
43.         NetworkServer.RegisterHandler(MsgType.Connect, OnServerConnect);
44.     }
45.  
46.     void OnClientConnect(NetworkMessage netMsg)
47.     {
48.         ClientScene.Ready(netMsg.conn);
49.     }
50.  
51.     void OnServerConnect(NetworkMessage netMsg)
52.     {
53.         NetworkServer.SetClientReady(netMsg.conn);
54.         netMsg.conn.SetMaxDelay(float.MinValue);
55.         var g = Instantiate(dummy);
56.         NetworkServer.Spawn(g);
57.     }
58.  
59.     string inputHost = "localhost";
60.  
61.     void OnGUI()
62.     {
63.         if (!NetworkServer.active && (client == null || !client.isConnected))
64.         {
65.             if (GUI.Button(new Rect(400, 20, 200, 20), "Init Server"))
66.             {
67.                 InitializeServer();
68.             }
69.  
70.             if (GUI.Button(new Rect(100, 20, 200, 20), "Client Connect"))
71.             {
72.                 InitializeClient();
73.             }
74.  
75.             inputHost = GUI.TextField(new Rect(100, 60, 200, 20), inputHost);
76.         }
77.     }
78. }

(I think this works. I haven't used it for awhile).

The docs don't really show how to do this, other than the Scripting reference. If you check my post history in this subforum you'll see it wasn't an easy journey...I wish they would have tutorials that would demonstrate this kind of thing as opposed to just using the NetworkManager.

 

@OP Ye, it is a lot more complicated than Photon, but I wouldn't totally agree with everything.

I have issues with UNet only because the manual has not enough information, and there's not much examples in the scripting reference. Method/property descriptions in the UNet code are misleading or not sufficient at times. Also google search doesn't help much because it's new.
Often you have to browse the UNet source code to understand what is actually happening behind the scenes or something.

But if you invest enough time into it - you can handle it.
I really like the philosophy of UNet HLAPI, the way stuff is done there.

Photon in the other hand is strictly designed for lobby-based games that doesn't have more than 32 concurrent players (talking about action games). Ofc you can lift message per second limitation via hosting your own server, but still design is design.

 

hmmm. i think your don't understanding how to use Unet.

failing to instantiate objects at random : You have to pass it as a [command] and ask the server to Network.isntantiate with and ID using a dictionary made of names(strings) for gameobjects. Set dictionaries at your setup.

failing to set parent of object based on net id.: again. a Command-Rpc using a string as Id to set parenting equal on all running games.

failing to sync anything if client unless you use syncvars and commands:
Your game should not rely on SyncVars... they are an shortcut you CAN use. For Exemple. you want the sync the name of all players. ShortCut = make a string SynVar that will keep telling everyone the info over the net ending up being... costy for yout wallet. Best practice = Make a simple command Rpc when a player logs in asking the server, by a command, to give you all the names of the objects X in his Game.

ClientRpcs dont do anything due to errors:
Its a very bad idea to try to ask a client to send an RPC command to other clients...this will lead to and open cheating game... you need send a command to the server and after ask the server to execute a [ClientRpc]... does clients will look in their dictionaries and assign the right change to the right GameObject

Hope this will help you

 

Is there any tutorial/documentation on unet that goes beyond making 2 players move around?