Think twice before adding Multiplayer to your game.

Now that it's all sorted out when you get some free time write a post about how to best use Forge to add multiplayer support to a Unity game covering the gotchas to avoid and so forth.

 

@CarterG81 Yeah, I would like one as well.

 

Interesting topic. Though the OP seems to have the most issue with the technical learning curve of the sweat of tools available to solve networking in Unity, I feel this problem is at least solved by experience. Eventually you will get good enough with your tool of choice that you can avoid most pitfalls. This learning curve shouldn't be taken lightly though, I still feel, after years of being a developer, that most of the time spent is in learning versus doing.

The biggest issue I see with Multiplayer development is the way is scales the simplest of tasks. For instance, I just recently added support for chests to my current project. In a single player environment this pretty easy:
1) when a player opens a chest, pull the inventory for the chest from the database (for things like this I use sqllite)
2) display the data to the player
3) when a player transfers an item to or from the chest, update the players inventory, update the chests inventory
4) update display of both player inventory and chest inventory

In a multiplayer environment, you'll wish it was that simple:
1) a player opens a chest and triggers an open chest event that is sent to server
2) the server processes the open chest even, pulls the chest inventory from the database and sends it to the player
via an open chest response event
3) the player processes an open chest response event and fills a local data type with the chest inventory data sent from the server.
4) the player either opens a chest ui display either when they initially hit open or when they receive the open chest response event, either way we need to handle the possible delay of data in some way ("loading..." on the chest ui screen, etc)
5) when a player takes inventory from the chest, they send a put/take chest inventory event with inventory taken or placed in the chest
6) either update the result of taking or placing inventory immediately (and eventually update agian with step 10) or wait for the response from the server to update the display
7) the server processes the take/put chest inventory event, updating the database for both the player and the chest, the server verifies that the proper items inventory is available for the player to take transferring only what is available
8) the server sends out a take/put chest inventory response event, containing all of the updates it actually did (note that this could be different than what the player actually requested to be done)
9) the server also sends out a chest inventory update event to all other players that have that chest open as the chest inventory has now changed in some way.
10) the taking/putting player processes the take/put chest inventory response from the server possible reconciling any differences between what the server updated and what the player expected to be updated.
11) the player updates the display of both the chest inventory and player inventory based on the new data
12) other players that have this particular chest open process the chest inventory update event from the server updating their local data and updating the chest inventory display.


The biggest issues with multiplayer is now we have to worry about data collisions, data synchronization and racing conditions. These are intermittent issues when they manifest and hard to track down. These are some of the hardest issues to debug you will ever face as a developer. For a lot of these issues you must force the server to be authoritative and this means the server must verify and approve cases like moving inventory to and from a chest, using items, interacting with npc inventories, etc.

Worst part of this is that you must account for extreme edge case conditions. Having two players take the same item from the same chest at precisely the same instance just isn't going to happen that often. For most situations like this I would even advise that getting something out there in front of players is more important that worrying about 99.999% edge cases. However these types of situations are probably the exception forcing you to deal with rare edge cases as they lead to game breaking inventory duplicates or really bad data synchronization problems.

 

So true. Really, all of game development is 99% learning how to do or thinking of what to do versus actual doing.

I rarely have a problem learning fundamentals / low level stuff, but nearly always have a problem learning to use other people's tools, assets, code, etc. It's always when other people enter the fray, I bog down enormously. Otherwise it just takes time, but it's a consistent amount of time (the rate at which I learn), with the added benefit that I understand everything low level & know my own code inside & out.

That's why I strongly refer people to use their own engine, unless they make heavy use of Unity's Asset Store, which is IMO the only reason to go Unity. And not because it saves you time. Not because it saves you from frustration. Just because it saves you from learning. That sounds idiotic, but when you've been learning to gamedev nonstop every day for the last 5 years, it gets to you. Your brain feels like it's being crushed to learn even one more thing, and you just want to make one damn video game.

Plus the high quality assets are either really easy to understand or have amazing documentation. Those cannot be ignored because they actually DO save you time AND learning. For example, I don't have to learn any network programming since I'm using Forge. I don't have to spend the time to create my own Behavior Tree game tool or AI system because I'm using Behavior Designer. I don't have to worry about creating my own dialogue system because I'm using Dialogue System. Wonderful assets. Wonderful. Unity by itself? Pretty much a useless PITA, IMO. For my last game, I created in my own custom engine the exact same thing I created in Unity, in the same amount of time. However the custom engine had the added benefit of: EVERYTHING. Plus over time it would become infinitely more efficient than using Unity because the tools I created / way I did things were much more efficient. But I digress, that Asset Store is what keeps me with Unity, DESPITE Unity itself.

 

I really hope to whenever it is 100% confirmed working with a massive world. Right now I'm still polishing it up to make sure it runs perfectly in a tiny 3x3 tile world.

I think it would not only help Forge compete, but would also be a great boon to users everywhere who want to create a large open world with authoritative multiplayer.

Hopefully I can explain enough topics so that people wanting to do something different can still get help from my example.

Anything to save others from all the frustration I had to go through.

 

@CarterG81,
I stopped using Forge when I encountered similar issues. I fixed some of their early problems with the sources but din't had that much time to deal with the issues so I stopped using it completely. Though I'm sure they already sort it out by now, would probably give it an other go when I get some free time.

 

Just build the singleplayer game. You can add multiplayer at the end

All you need is a dummy player that has a behavior on it that receives messages from a server that are sent by another client.

 

Thanks, I think I'll take that advice.

Although the Forge developers are helping resolve the issue, I still have to wait for them to fix it. (It started to work, and does a lot better, but it's still only partially working. Which is way better than "Not at all" but not enough to continue work on a strictly multiplayer-version.) Until then, I think I'll just continue onwards with the singleplayer portion, writing to the best of my ability as if it is multiplayer. (This is actually not that problematic, because Forge has an "Offline Mode" and I use a "Server Host" mode (Server Online + Server has a PlayerObject/Client too) so I can build the game based on those, even with the correct RPC's. I think. Plus I have a lot of experience working with Forge/Networking now... enough to work on singleplayer with proper commenting / notes on what will be needed for multiplayer.

That way when Forge is updated, I can just write up a few RPC's, maybe change a few lines of code, and wallah/voila! Multiplayer!

I tried to help them solve the bug, but when he asked me to run some unit testing / real debugging to assist, my brain exploded & I woke up to realize that although I know how to program, I am far from a professional & still very much a self-taught hobbyist. I never learned about some of these crucial aspects of professional programming, nor do I really want to / need to learn them. Not since I'm using Unity. If I was making my own engine, I'd learn that stuff ASAP. But I use Unity so I don't have to have an endlessly mind-crushing learning experience.

I have to fight that burnout. I'm a hobbyist who has been learning everything about gamedev for the last 6 years. I knew nothing when I started, and now am moderately competent in "everything" or "enough to make any game I want, with frustration." 6 years of learning, sometimes 18 hours a day, every day... that took a huge toll on my morale. I just had to stop learning & start doing, or I'd burn to a crisp.

 

Looks like I won't have to!

​

------------------------------------

I noticed that it's only when I'm sending a large amount of bytes. I assume that's why, anyway. They serialize/deserialize perfectly fine, but when sent over the network if too much data? that Client never receives.

• I CAN send my World class, if it is empty List<TileData>.Count = 0
  
• I can't send my World class, because it's a List<TileData>. (Too much data?)
  
• I CAN send my TileData class, but ONLY if its List<ObjectData>.Count <=3
  
• If TileData class' List<ObjectData>.Count > 3, it fails (Too much data?)

So what I did was something @darkhog helped me come up with.

I don't send the World class, and the TileData no longer contains any List<ObjectData>. Instead, the TileData is now a sparse class with minimal tile information. ObjectData is also minimal in data size.

Anyway, until Forge figures out what the issue is, I will use this temporary (inefficient) method.

I simply iterate through the Server's "WORLD" class, which now holds lists of "AllObjectData" and "AllTileData". As I iterate, I send a SINGLE object or a SINGLE tile. This is so little data, it always succeeds, and in the exact order it was sent in.

Okay, well it's a flawed victory, but whatever. I can progress!
​

Yes, it's inefficient. Yes, it's a bad method. But yes, I can progress until the devs take a look at my example project & update Forge. Woo!

I think I'll have to wait on that guide though, until I can make it infinitely more efficient by just sending a SINGLE message to the Client, with the "World" custom class, and that's it.

 

@CarterG81 I think a lot of the struggle that comes from making unity games multiplayer is the adhoc nature of the samples. There is no dedicated / external server. The game wants to do multiplayer via having everyone run all of the code and try to keep it in sync.

I'm making a server now. It's going better than it ever has when trying to use unity as a server.

But when multiplayer is an afterthought, I've had success in adding an empty object that listens for input and sends it to the other clients and controls a character in other people's games and another empty for receiving input and controlling dummy players in your game.

Going forward... every game I make it server based! Even the singleplayer ones. The reason why is exciting. Hey, @CarterG81 , what kind of phone do you have?

 

android, a galaxy s6, im on it right now actually lol

It's a great idea to make every game server based. Every game I've made, I always keep the data completely separate from the rendering, etc. That way if I need to serialize for any reason (save game system, networking) I can easily. Plus I can switch engines or even languages and bring over "the game" in all its data form. Which is pretty much everything. Although that isn't really a need, I do find it helpful all around to structure things in those ways, as if server/client ; separating data from art, etc.

 

Good, good. In the future you can test something special I'm working on. I just hope I finish it before I get sucked into the VR vortex of May2016.

You also free up your choice of environment for the server end of things. I'm doing java now because I know it, but in the future I'd like to try making a server with GO. Also, if the core game is abstracted away from the client, you can have a variety of clients connecting with different and hardware for a mess of asynchronous but fascinating gameplay

 

Well if I make my world any bigger, I start getting problems. Not sure the cause, other than the obvious horribly inefficient method this is anyway. So I have to keep my game with a tiny world until Forge is updated.

I honestly just don't understand why it is so difficult to send such a simple class that is nothing more than a List of a List of integers/strings.

 

I think I tried forge once. Or which ever one only runs on windows. It wasn't great. Much more complicated than just writing sockets n stuff.

 

*sniff* I knew you would come around...Go is perfect for these types of servers! You can literally learn it in 1-2 days, it is an extremely compact language!

 

Tell me it also has easy bluetooth connectivity and I'll use it for my experiments this weekend.

--edit

something like this maybe?

https://github.com/paypal/gatt

Or whatever you recommend. I just want to have bluetooth stuff because I think it's a cool technology.

 

Sorry man, I haven't played with any bluetooth libs but you can call C directly from Go(albeit with overhead) pretty easily and I am sure there are lots of bluetooth C libraries.

 

I found some. I was considering wifi direct for a few minutes, but I really am curious about bluetooth. I even ordered a usb dongle from amazon to give me better range (default usb thing on this computer range is so bad it didn't find my phone until I placed it INSIDE the case)

I installed GO and liteIDE last night and after the easter festivities die down today I'm going to dive into golang.

 

Just make sure your game kickasss otherwise forget it especially with multiplayer.

 

Come Monday, it will be exactly two weeks since I posted this, and still no fix. It's been over 2 weeks since I've hit a brick wall, unable to continue with my project because of Forge not functioning as it should.

I don't feel that it is unreasonable to see two weeks time as significant enough to warrant frustration with the Forge developers. Especially when I'm doing nothing more than trying to send an incredibly simple custom class serialized into a byte[ ].

I really need to go back through my history & retract all my referrals of Forge. Unless the community here feels that 2 weeks is acceptable to wait for a fix for sending simple data across the network?

What do you guys think? Is 2 weeks to fix an issue like this acceptable or unacceptable? It's not like I'm trying to do something crazy. I'm doing nothing more than sending this data across network, via serialized byte[]:

Spoiler

Code (csharp):

1.  
2. [Serializable]
3. public class World
4. {
5.     public List<TileData> WorldTiles = new List<TileData>(); //Collection of all tiles.
6. }
7.  
8. [Serializable]
9. public class TileData
10. {
11.     public myVector3 myPosition = new myVector3();   //Tile's Transform.Position
12.     public myVector2 tilePosition = new myVector2(); //Tile's TilePosition
13.     public string myName; //Name of Prefab to load (What Tile type?)
14.     public string myBiome; //Biome the Tile belongs to
15. }
16.  

The problem is not on my end, as it serializes/deserializes perfectly fine. The problem is with Forge. And I am not a networking programmer, I'm just a hobbyist, so I can't simply fix it myself. This is a serious drain on my motivation, as multiplayer is a pretty big component for my game & I have already invested significant time & effort into implementing Forge.

 

Some problems stop me. I wouldn't say a whole system causes it, but say, tackling one particular aspect of anything can. For instance, about 6 months ago I was between a rock and a hard place on where to proceed with a project, and focus on either single player or multi player, and having screwed with unity networking pre-unet and post-unet, I can say it was quite challenging mucking around with.

Ultimately I tried implementing a* pathfinding instead, and having failed at that, pretty much took a few months break and made other projects, researched and tested other things, and just genrally forgot completely why I was having issues getting a* and networking figured out.

Came back day before yesterday and revised the a* with a more informed approach, and earlier today had a breakthrough getting a simple path figured out and returned without crashing the editor haha, which I had all but given up on before!

I guess what I'm saying is step back, reassess, adjust your approach, and take the problem down after you've cleared your head of it, with fresh eyes. Somehow it works for me on many occasions...

 

Yea, that definitely helps & works if the problem is on my end. Unfortunately, I didn't develop Forge so there's no fixing that. The problem is outside my control. I can continue working on singleplayer, but it is very frustrating when you pay for a product only to find out it can't even do the simplest thing right. I don't expect much. I just expect to be able to perform the fundamentals (send some bytes) without problem. If I'm not mistaken, that is extremely fundamental to a networking asset.

 

@CarterG81 I imagine unless they have other huge problems to fix, 2 weeks (if they're aware of your issue) definitely warrants frustration for being able to serialize data and send it as a byte array.

I'm not a network programmer either, but even I can do that!

The timing on this is also bad, what options do you have to turn to? Unet? pff

 

I had a need for a centralized server setup in the Dark Ages of XNA, in which access to servers was Forbidden Technology. Before the game began each console shared StorageDevice.FreeSpace to the other players, and the player with the most space was voted the server for that game. The game (a Diplomacy implementation) often spanned many sessions, and it was turn-based so more common metrics like ping-time didn't matter much, but obviously you could use ping or anything else to pick the server. Originally I just used the lowest app start-time until one of my friends ran out of space mid-game (it stored quite a lot of data, hundreds of game turns could be viewed in replay at the end).

Anyway it might still be a useful trick if you can't afford a server or don't want to mess around with one.

The thing about servers is, as soon as the owner loses interest in supporting it (or gets hit by a bus, or the data center burns down, etc etc), all copies of your game are instantly rendered useless...

 

Ahh yes the problems of assets lacking support sucks. Guess there's nothing to do besides either find, or develop an alternative. Writing a networking solution is huge though. Unet can be extremely frustrating as well for right now. Your between several rocks and hard places, haha.

 

All I can say is... I feel your pain.

I made a working single player game with inventory, movement, monsters, combat, whatever in like a couple months when I was learning Unity initially. My friend was supposed to do the server/networking stuff but kept getting busy and never really did anything. I had no idea I would have to (more or less) redo EVERYTHING to make it networked and that by making a single-player game I really... had accomplished not much. I guess I figured out some mechanics and became more familiar with Unity.

3 years later, game is close to Beta. So much of this involved the networking. Deciding to go with uLink and finding out their drawbacks and complete/utter lack of support. Switching to Bolt and then in its prime just having all development/communication/support disappear for months. Trying out UNet and realizing, uhh... this is actually worse (at the time.) Then back to Bolt.

Lack of support is horrible. I feel like Forge is suffering the Bolt-syndrome. They got your cash, but there's no renewable contract so why spend premium time on it when UNet is improving (slowly) to compete. No incentives. No accountability. At least they offer source code access now (though I really felt it was more of a "Here's the source! You can fix our bugs and upload it to Git for us! Isn't that awesome" sort of thing.

It's sad to realize that assets you purchase have no guarantee of ever having updates, support, etc. I've purchased some stuff thinking, "This is hot grits man, can't wait till it's completed! (AI Breadcrumbs or whatever you're called, looking at you)" and then... an update... and nothing, like ever. Asset store is awesome, but can be a real PITA too.

Good luck man. At least it's not like trying to get support from uLink. At least with uLink I knew what kind of dev support I'd get: none.

 

If Unity would just give us full source to UNET, maybe as a community we could help fox bugs and get it working to where this isnt such a ridiculous problem.

 

Or if a member with decent networking knowledge could come up with a lightweight alternative to unet and assets like forge.

 

I don't understand why people aren't just using standard C# client server programming or existing libraries. Is there some reason these cannot be applied to Unity games?

Either just following the Microsoft .Net tcp/ip examples or using things like NetworkComms.Net

Granted, I have never tried doing multiplayer stuff in Unity but I always figured if I ever did I would do it the same way I do for the apps I develop in my day job.

 

you can do it pretty easily if your game uses tcp/ip but a lot of games want to send lots of little packets via reliable udp so you'd have to build that layer yourself, along with sequence checking, nat punchthrough, etc.

At some point having a existing network library do that part for you is nice, lidgren is a pretty decent one to build off of.

 

............

Uh, yeah bro. Networking sucks. I looked into it a few times and from a few brief experiments, I realized that it was absolutely freaking complex and convoluted. So, I looked up networking basics, going back to TCP/IP and learning about the internet and how it works, and from my experiences trying to set up routers and what I know about running your own game servers... it is too much. Simply, far too much.

Not because it is actually complex, but because from the very beginning, the people in charge of making computers talk to each other were social retards who had no concept of making what they were doing accessible to normal people. They just... well, they just did whatever. And now we're stuck with something that is almost as esoteric as the god damned Necronomicon and the Order of Dagon.

The nature of the internet is inherently complex, due to the sheer number of moving pieces and whatnot, but to make your game FOR SURE be able to let two people's computers talk to each other over a vast network that you have NO CONTROL OVER and have it be CONSISTENTLY RELIABLE even though things are CONSTANTLY CHANGING at ALL TIMES is not something you simply "set and forget"... it's an on-going effort. A war against entropy and "what the F***!!!???" moments, with a little bit of "this S*** was JUST F***ING WORKING!" sprinkled for good measure.

Yeah, bro. You could have just asked me and I would have asked you if your game ABSOLUTELY 100% HAD TO HAVE networking to work.. and if not, DON'T DO IT.

 

Not that I can see, in fact that approach has been working fine for me in my experiments so far!

 

Well when Forge actually works, it's pretty fantastic. You don't have to do any real work, and can (within minutes) connect & sync players together without any effort on your part. Sending data To/From is also pretty simple & not very time consuming. (Although learning Forge itself is very time consuming, as is anything with sparse/no documentation; And network engineering takes time, figuring out HOW you want to handle your game & what you want to network & when.)

It's just that it doesn't work all the time, and is riddled with bugs. Even when I get past the bug by sending tons of tiny messages instead of one big one, it still ends up breaking Forge because another bug enters the fray (well, it seems to be the same bug, but causes multiplayer problems by getting everything out of sync) So it's a mess.

Once those bug(s) are resolved though? Within a few minutes you have connectivity & synchronization, and if I were to write a tutorial on how to stream huge open worlds- you'd have multiplayer completely setup in a few hours/days. All with very, very little work on your part actually programming. And with no required knowledge of network programming; Although you do have to learn a bit of knowledge about network design (engineering your game & how it relates to or should relate to networking).

That quality documentation is what separates "It took me a month" from "It took me a few hours". Quite literally in some cases, like mine. The past month I've worked on multiplayer could have been nothing more than a few hours if I had rapid answers to my very rudimentary questions or a more thorough documentation (along with a bug-free asset that worked when attempting to use rudimentary functions). Or simply a (working) example project to reference.

So in the end, this is all so unnecessary. And the asset developers...
Like Forge: Don't have the resources (money/time/employees)
Like UNET: Are incredibly incompetent (broken upon release, years until becomes acceptable release-level condition)
Like Everyone Else: Are excessively greedy (ridiculous costs, CCU limitations, from what I can tell just as incompetent/low in resources as one of the prior two, etc).

If only we had a company that had the resources: time, money, & employees, the competence & determination to make a quality product rather than rushing things for profit, and cared more about the product & community than they did about squeezing every penny out of consumers. This could be Unity, but never will be. Even their recent attempts to address these weaknesses is an incredibly surprise to me since I've been following them & seeing that since its inception so many, many years ago. It takes them many years just to acknowledge they will attempt to improve what everyone was telling them from the start. As for actual improvements? With Unity as a company, I'll believe it when I see it.

Of course...that's a pipe dream to think such a company could ever exist. From what I have seen myself & have heard from experts, the IT world is full of incredibly incompetent and greedy people for the majority, and a minority of competent good guys who are simply burned out by obsessive crunch-time requirements or simply driven insane by corporate bureaucracy or loss of creative control. Leaving indies to be the "creative" ones, but then it's less about incompetence & a lot more about "What the hell am I doing?" lack of experience. And those who are fully capable, highly experienced & motivated, well organized, and well funded? They are almost certainly doing something completely different & would never in a million years go as "low" as working on a niche networking solution for a niche product. Especially when those people are extremely valuable (and they know it) and so both their price & their ambitions are both very high.

 

Also I use Unity so I don't have to learn how to specialized programming like networking. If I were to simply use a non-native solution, I might as well just make my own engine. It sure as hell wouldn't have the problems I find so often with using Unity+Assets. The Asset Store is the exclusive reason I use Unity to make games. So when an Asset fails me or aren't there, it significantly devalues the Unity Engine, for me.

 

This is exactly why I generally avoid the Asset Store (the big exception being Rewired input/controller support) -- too much risk of building a dependency on something that could literally go away tomorrow.

So which is it?

The people who designed this stuff were working with hardware that was more primitive than the coffee machine in my kitchen. (Admittedly, I have a nice coffee machine.) And it wasn't designed for browsing xkcd.com or multiplayer Flappy Birds VII, it was designed to survive a frigging nuclear war.

But more concretely speaking, it is complicated because it's actually radio communication. A CAT5 cable is literally a radio antenna, it just happens to be connected at both ends. Errors happen in an analog world, and you definitely don't want to be dealing with them at the protocol layers below the ones you guys are griping about, or the architectures that preceded TCP/IP (shudder, Token Ring).

It simply isn't that complicated. I had never done any socket-level programming when I was hired to create a custom news-scraping web browser, probably 1996ish. It took about two days to get a basic implementation running. That was using C, Win32, and winsock. I'm not bragging, my point is with the .NET libraries just about any dev able to complete a simple game ought to be able to knock out something similar in a few hours tops. Today I could build something like that in minutes.

Granted multiplayer sync and managing bandwidth for simultaneous downloads is a different domain but the underpinnings are identical.

Hell maybe I should write a library and make people dependent on my implementation.

 

Networking is a little different though. You see how you made your data serializable? The only other step in transmitting those bytes over a network is... transmitting those bytes over a network. For most things I agree, if the engine can't suit your needs you might as well find another / make your own. But when it comes to networking, you have the option to use whatever you want. I'm using a combination of golang, c#, wifi and bluetooth for my networking

Maybe you can find a networking solution that makes sending data between clients easy that isn't bound to an engine.

 

The internet is inherently complex, because it is a physical network where nothing sent is guaranteed to be received. The internet itself is so inherently complex, that the concept of the "internet" is merely an abstract way of thinking about something... a massive (or perhaps tiny?) system of interconnected computers sending electronic signals back and forth that are being interpreted as data, but there is no agreed upon single format for this data, so everything is basically deflated into robot morse code and then re-inflated on the other end (hopefully). Somehow, things get lost and so a protocol of sending a confirmation of receipt and a sum total of packaged contents sent is accompanied with each tiny transaction, and even at this... the data sent is interpreted differently depending upon the application receiving the data, since there is no single agreed-upon robot morse code that is universal or logical.

In addition to this, every machine has its own hardware, software, firm ware, semi-firm tofu, terminology and there exists a continuing evolution of these terms and concepts. All of this, without actually having any correlation to anything else. Sometimes when a new technology comes out, it is compared to something that already existed before... look at cars, they were compared to horse drawn carriages and so there is a certain eloquence to the terminology, anyone can understand a car if they try.

The internet is like a group of people who never spoke to anyone who was not a professor or computer science theorist got together in a small room with coffee-stained modular carpeting, smelling of pit stink and desperation, and beneath the hum of florescent lighting made of a bunch of the stupidest sounding S*** I have ever heard in my life and never even bothered to rethink it. It was just done. There. Endless abbreviations. No manual. The internet is almost an accident, an accident that we can not do without and so we have to keep it operating as is. It's like something broke and we discovered that it was actually more useful this way, so we have to keep it working, which means keeping it broken in exactly the same way that it was originally broken, duplicating this broken form indefinitely, even though it is clearly possible to make something better by now... it's simply what everyone uses.

Sockets? Socks? TCP/IP? Protocol?

And people say they understand it, they say that it is not convoluted, they criticize and do all of the things people do when allowed to brag about their abilities when they know full well there will NOT be a test on Friday. But the proof is in the pudding... show me your MMO and maybe I'll believe its simple if I don't get "Cannot connect to server" errors. But you and I both know that I will, because networking is convoluted bullshit. Nobody is ever confident that it's going to work. It's the world's biggest game of Telephone, played between robots, speaking in code talk.

The big boys like Blizzard get it to work, because they can afford to hire people who have been doing this their whole lives. They have learned the idiosyncrasies and nuances of the system. And they have billions of lines of code covering all kinds of "oh S***" situations. And you know what? It still doesn't always work.

Our answer is still... restart your everything.

 

Maybe it really is too big? I just did a test with your code

Code (CSharp):

1.  
2. World world = new World();
3. world.WorldTiles = new List<TileData>();
4. TileData tileData = new TileData();
5. world.WorldTiles.Add(tileData);
6.  
7. Debug.Log("World byte length = " + ObjectToByteArray(world).Length);
8. Debug.Log("TileData byte length = " + ObjectToByteArray(tileData).Length);

The results...
World byte length = 953
TileData byte length = 582

Im assuming such a size would be fine as long as your network channel allows that many bytes at once, as well as what ever method you are using is properly fragmenting the bytes and sending it across the network. I never used forge nor did I even get into networking yet, so I am somewhat speaking out of my ass here ^^. Maybe forge has some kind of setting you can set to allow X amount of size bytes? What does Networking.PrimarySocket mean?

Looking here
http://developers.forgearcade.com/Changelog
If you go to Releast V16.8 and Releast V17 you see this...
- Fixed issue with cache not sending data larger than 1024 bytes
- Fixed bug with byte[] and BMSByte sending after large data sets have been sent

I assume your class looks something like this..
http://developers.forgepowered.com/...ite-Custom-Sending-Classes-Across-the-Network
Which means the bugs above might be related.
What version of forge are you using?

Also, out of curiosity I made this test you could try out.
Use the ObjectToByteArray as your serializer and ByteArrayToObject as your byte[] deserializer.
This will not serialize your whole world class, but its just a test to see if it is maybe size related. Use the same thing I am doing in OnEnable and see if you receive the data. The size should just be 16 bytes in this example.

Spoiler: Click for code

Code (CSharp):

1. using System;
2. using UnityEngine;
3. using System.Collections.Generic;
4. using System.Runtime.Serialization.Formatters.Binary;
5. using System.IO;
6.  
7. public class TestWorld : MonoBehaviour
8. {
9.     void OnEnable()
10.     {
11.         World world = new World();
12.         world.WorldTiles = new List<TileData>();
13.  
14.         TileData tileData = new TileData();
15.         tileData.myObjects = new List<ObjectData>();
16.  
17.         ObjectData objectData = new ObjectData();
18.         objectData.myPosition = new myVector3() {x = 4};
19.  
20.         tileData.myObjects.Add(objectData);
21.         tileData.myObjects.Add(objectData);
22.         world.WorldTiles.Add(tileData);
23.         world.WorldTiles.Add(tileData);
24.  
25.         byte[] worldInBytes = ObjectToByteArray(world);
26.         Debug.Log("World byte length = " + worldInBytes.Length);
27.  
28.         World convertedWorld = ByteArrayToObject(worldInBytes);
29.         Debug.Log("World WorldTiles Count = " + convertedWorld.WorldTiles.Count + ", First TileData myObjects Count = " + convertedWorld.WorldTiles[0].myObjects.Count + ", First myObjects position X = " + convertedWorld.WorldTiles[0].myObjects[0].myPosition.x);
30.     }
31.  
32.     //Just as a test we will serialize some stuff, but not everything.
33.     public static byte[] ObjectToByteArray(World obj)
34.     {
35.         List<Byte> bytes = new List<byte>();
36.         bytes.AddRange(BitConverter.GetBytes(obj.WorldTiles.Count));
37.         bytes.AddRange(BitConverter.GetBytes(obj.WorldTiles[0].myObjects.Count));
38.         for(int i = 0; i < obj.WorldTiles[0].myObjects.Count; i++)
39.         {
40.             bytes.AddRange(BitConverter.GetBytes(obj.WorldTiles[0].myObjects[i].myPosition.x));
41.         }
42.  
43.         return bytes.ToArray();
44.     }
45.  
46.     public static World ByteArrayToObject(byte[] bytes)
47.     {
48.         World world = new World();
49.          world.WorldTiles = new List<TileData>();
50.  
51.         int worldTilesCount = BitConverter.ToInt32(bytes, 0);
52.         for(int i = 0; i < worldTilesCount; i++)
53.         {
54.             world.WorldTiles.Add(new TileData());
55.         }
56.  
57.         world.WorldTiles[0].myObjects = new List<ObjectData>();
58.  
59.         int firstWorldTilesMyObjectsCount = BitConverter.ToInt32(bytes, 4); //4 since we already read 4 bytes to get worldTilesCount(int is 32 bits) and we started on index 0
60.         int startIndex = 8; //Since we read another 4 bytes...
61.         for(int i = 0; i < firstWorldTilesMyObjectsCount; i++)
62.         {
63.             ObjectData objectData = new ObjectData();
64.             objectData.myPosition = new myVector3();
65.             objectData.myPosition.x = BitConverter.ToSingle(bytes, startIndex + (i * 4)); //ToSingle (ToFloat) is also 4 bytes
66.             world.WorldTiles[0].myObjects.Add(objectData);
67.         }
68.  
69.         return world;
70.     }
71. }

Just throwing out info =)

 

I'm not sure what the problem is, but the Forge developer said he will eventually check it out.

They send large amounts of data fine, so it has something to do with my custom class.

 

I think this thread illustrates why you wouldn't want to do that. You want to support all these guys with no networking knowledge using your product incorrectly? Sounds terrible!

 

Except I'd argue the majority are using it correctly, and have all of these problems despite that.

Even if you were right, that most use it incorrectly, it's the fault of the supplier not the user. People would easily use it correctly if there were better documentation for all of this.

I just wanted to clarify that the blame is overwhelmingly on the vendors who supply these products, not the consumers who try their best to use them with lack of success due to bugs, lack of docs, and often outright broken features. (When UNET first released, the example projects didn't even compile, let alone work as they should once you fixed the errors.)

 

And you could see network lag and desync... on localhost.... in a game with nothing except 2 balls rolling around a box. If a networking solution can't sync 2 objects in a game with nothing else then what hope is there?

 

Sorry I didn't mean to imply your claims are warranted or unwarranted, I have no way of knowing that. I am just saying of all the things I could think of to put on the asset store, a networking library has to be the absolute last one I would consider because the support cost is so high and variable depending on the users knowledge.

 

I think so too, unless you developed a networking related component that had a specific enough function.

 

Yeah there's no way in hell I'd actually do that. Spent 30+ years writing and supporting software. I'm done with that mess! (It was a joke... guess that wasn't clear.)

 

Perhaps if someone were to release a networking asset that actually worked, with thorough documentation, it wouldn't be such a hassle to support so many of their users. I'd be willing to accept even the most rudimentary asset (something that barely had any features, thus making it more feasible to be bug-free. Something that added features very slowly by focusing on bug-free polish quality rather than "as many features as possible, as soon as possible; add more features ASAP before fixing bugs with the core!"

Hell, I'd also prefer not even HAVING any feature or asset until it was ready for a quality release. Keep UNET from us until it's actually ready to release. I'd rather have a slow, quality release than to have a fast release full of endless bugs & broken release candidates. Instead with Unity, we almost always get an extremely slow, buggy release & broken features that takes years to eliminate all the bugs.

 

Honestly I don't know what's up with UNET. I was excited for it at first, then when they kept delaying it I tempered my expectations as it seemed something was wrong. Then they "released" it in "beta" and it was even more underwhelming without even proper documentation. I think that is probably the most insulting part, that they hired "top notch network developers from the AAA industry" to design this new system but they can't bother to document the API and provide some decent examples that work? It makes no sense.

 

Well, as always, nobody is saying that you have to use Unity. It's not like there are no Unity games out there that have networking capabilities. How did they do it? I guess it really just comes down to technical knowledge and experience. It can be overwhelming to learn about networking and sure, I play it up like a crazy person, but ultimately it is a finite subject and you can learn all about it if you put in the time.

Unity is a good tool, ultimately it's just a tool, though. It's not a magic wand that you wave at your problems. You can't get angry at the tool when you don't know how to use it properly to get the job done. The good people at UT have really outdone themselves with Unity and you'd be hard-pressed to find something better out there that has such a large community of users supporting it.

I guess what blows me away about people complaining about Unity (or GameMaker, or any tool really) is that there seems to be this mindset that because some really bright people got together and forged something for all of us to utilize... that we are now somehow owed their continued support and improvement of that thing. Like they are somehow obligated to serve our needs... that's not the case.

The people who wrote Unity's foundations and libraries are people just like you who learned a lot more stuff than you know and used that knowledge to make something infinitely greater than any game it can be used to produce.

You can't just sit there on the ground and complain that the thing you want is too far out of reach and that someone else is supposed to go grab it for you, and then when they do go grab it for you as a favor... complain about how they did it... it just doesn't make sense because you can always go do it yourself. You're lucky they helped you in the first place.