@Unity: Hello, is there anybody out there? :P

Those are only requirements for P2P. If you're making simple games like that, it's understandable you'd want to use something like Photon.

 

Agreed. Personally my game gets away with just utilizing HLAPI without both those. And you can implement them yourself if you really want to. My game is running Dedicated Servers only that are automated to restart after each game session.

 

NAT punchthrough is what I need most. Does anybody know of a way to connect to other players (that aren't on LAN) at the moment? I tried relay server and had issues (lag, data usage limit booting me within 1 minute).

Other than NAT punchthrough everything is progressing very well (I removed all UNET HLAPI and do all communication with MessageBase). Here's some UNET network synced videos.

 

Open.NAT works perfectly for me with UPnP
Other than that look into STUN

 

I wouldn't really say that games without a dedicated server are simple.

 

From my personal experiance, P2P has more to concider, security whise etc. But dedicated looses alot of it's appeal due to cost from many single man teams.

 

How does MessageBase work exactly and what is the advantages / disadvantages to it from Command and RPC (HLAPI). Maybe even a code example?
I am currently using HLAPI only. And I am concidering to switch to something a bit lower.
How difficult would such a transfer be?

Thanks, TwoTen

 

i got host migration working in my hacked version of unet without too much trouble, using 98% of the host migration code that's already in the HLAPI.

 

if you look at your game's assembly in ILSpy, you can see what actually happens with commands and rpcs. they basically just send a message in a very similar way to how MessageBase does. @Zullar has a lot more experience with seeing commands and rpcs be buggy i think, but under the hood it's sending data pretty much the same way. the difference is that commands & rpcs have their own message handler on the receiving end that figures out which object to call the function on for you.

 

MessageBase lets you send data from Client --> Server or from Server --> Client(s). MessageBase has a short ID + any serialized data payload you want. It does not require NetworkBehaviour/NetworkIdentity. When you read the payload then you can do whatever you want with it.

RPC's and Commands are mostly OK, but a few issues
1: They are buggy and don't always work (specifically around a scene transition where NetworkIdentity.observers fall off)
2: There is a bug where they can be sent to the wrong script (if method name hash isn't unique then UNET selects the first script in the hierarchy)
3: Often duplication of code (i.e. if you want to send a chat message from Client to all Clients first you must Command then replicate by RPC)

 

One of the bugs I submitted PRs for is now in issue tracker:
https://issuetracker.unity3d.com/is...-position-after-adding-and-removing-authority
Since they can reproduce and have the fix, one would hope it won't take long to be resolved.

 

Everything being relative, I guess I can't disagree. You could definitely make a specific P2P game that is not as simple as a specific game with a dedicated server. The assumption in my statement is that if you are making a P2P game, you're not saving much/any state between gameplay, so no persistent community, the scale of the game in terms of CCU would be limited due to player hosting, and you don't care about cheating because you don't control the authoritative process. Strip out all of that, and you are left with a pretty specific and well-traveled set of requirements that Photon can meet if you are willing to pay. I wasn't trying to offend anyone.

 

Have you submitted a PR for it? Lots of people here obviously would like to use your solution. You're probably already aware, but anyone can grab the PRs from the bitbucket site and build their own patched versions of UNET.

 

Any news on Host Migration?!
I really need it for my next game, if it won't work I have to choose photon...

 

Unfortunately, Unity makes features, builds up hype, releases it, then abandons them forever because it doesn't make them as much money as hyping up new features for them to immediately abandon.

Heck, people have been reporting bugs about something as simple and common as scroll rects, yet instead of fixing CORE bugs, they continue on to make features that are pretty useless for the average game designer (the new art features) because it will then invite extra seats to paid subscription plans D:

TL;DR: Promised, but never implemented/fixed? Shame to say it, but that's what's known as The Unity Pattern.

It's a shame, though. The developers work so hard - yet the upper mgmt makes such poor decisions obviously, the person that makes these decisions has never developed in their life.

EDIT: Or, if they have, then shame for not prioritizing stability/bug fixes over fluff.

 

I'm not sure spilling out your hate for Unity actually helped @mojtaba64 but I get where you are coming from. You are saying it's probably not worth waiting.

I don't know if upper management actually work like you think they do. Most of upper managment are technical, for example @Joachim_Ante is the CTO and you know, was working on Unity since day one. Just saying.

As for networking updates, I agree it would be nice to see some interaction with what is happening here. I too am a little bit worried if I should use photon or unet. Perhaps @LeonhardP could ping developers, have a quick ask around (pretty please!)

 

Yea, that was the translation haha. Don't get me wrong, it's one of those situations where it looks like you hate something, but you only say it because you love them. I love Unity. But I also hate it. Because it could be so damn powerful, so good... however, "The Pattern". Money > an actual stable, viable product, I get it: Pressure from funding partners to make more money, not necessarily a better product. I just hope they use the fluff money to fix bugs and increase stability to existing features, one day. A single, 1-week hackathon would surely do the trick.

But back on topic, Photon has documentation, years of experience, allegedly cheaper (I don't know), inline documentation (PARAGRAPHS long), and intuitive design. I sent UNET a message for 3 months with bi-weekly follow-ups, just asking how to properly disconnect a user. The final answer from QA was "I can't force the UNET devs to answer this". That's how much they care about you or UNET. Never got the question answered. Went straight to Photon and for what took me 3 months to trial-and-error took me 3 hours to implement the lobby with their intuitive design and in-line docs with real-world examples, tutorials and demos.

The above rant in my previous message may not seem like it was relevant, but it totally was. You see what I mean now? Networking is EVERYTHING if you have an online game. Without it, everything crumbles. This includes support. Documentation. Demos. Examples (both quickstart and real-use examples). Scalability. Experience. Knowledge. Staff willing to help you. Real support (as in, more than 0 people). Updates more than once per lifetime.

^ This is something UNET lacks in its entirety. Due to Unity's giant budget, they choose to do this -- which is why it's so frustrating. And if what the mod above said is true about upper mgmt having dev experience, then it's either facepalmingly shameful if that's his decision to make, or it's an unfortunate event that he's being pressured to make such decisions. Pretty much the minute any Unity feature "comes out of beta", that's when it translates to "it's in an alpha/beta-like state and it will never be touched again". Hence, The Pattern. Again, my rant is completely relevant - if this is what you expect from an enterprise game engine, use UNET.

This thread has become too emotional for me; I've officially stopped watching it. Carry on~

 

Host Migration a big problem in Unet, but something else is another problem in Unet that makes me to choose photon for my next game, You can't determine who disconnected when server or client disconnect!!
I've searched a lot, made an topic, but no help... the only whey is to ping for example 8.8.8.8 and see if you get any response... Internet in my country is not very good and it is a big problem for me to guess who disconnected!

 

You can inherit from NetworkManager and use 'public override void OnServerDisconnect(NetworkConnection conn) {}' to find out exactly who disconnected

 

It's been over half a year and several releases, and neither of my fixes have been merged. I messaged with larus who said (paraphrasing) one looked like a slam dunk and should be in an upcoming release. The other PR he didn't seem to understand, which is disappointing because it makes it clear he didn't have a deep knowledge of the HLAPI. Understandable as he didn't write it, but that means there is nobody working for Unity who actually could fix HLAPI issues.
The end result is the same for both bugs. I have to merge my fixes into the source and build Unity.Networking.dll each time a new version is released. I stand by my rant about how (paraphrasing again) shouting on a forum is counterproductive to doing networking in Unity, and that UNET is the best thing going unless you are doing P2P, but I accept now that I'll be responsible for solving any issues outside the transport layer. Way back on the last page someone said unity was about making things accessible to non-programmers or technical people. Something like that. I have to say that at the current time, that doesn't exist for networking unless Photon works for your game.

 

it won't work...
read this thread:
https://forum.unity.com/threads/who-disconnected.459693/

 

I am so understand you!

Seems like Unity no longer so cute as it was before : (

Seems like completely new people controlling a Unity development, and they have no idea what is "Unity" and what it should be.
When Unity switched to subscription pricing I thought "well, they deserve it", but this is the moment when they stopped to do the right things! As result, they have much more money then before, but they do nothing!

I heard Unity hired former director of Electronic Arts. Nothing personal, but we all know what is "Electronic Arts", I am afraid this is a cause of some modern problems of Unity.
And I am afraid it is a beginning of huge degradation of Unity. So sad : (

 

By the way. About Photon, someone explain me please. As far as I know. Photon does not allow me to start own server using a button right in the same exe (like it is possible in Arma 3, Factorio and many others games)

Seems like Photon is good only for p2p games with matchmaking such as World of Tanks, MOBA etc?
If so, it is a huge disadvantage of Photon for me.
I heard that I can setup my own dedicated server of Photon using separated exe, but it sounds extremely not comfortable for future users who want to quickly host a server for group of friends. And also seems like it is much harder to develop.


I am so confused with the current situation in "network solutions". Situation with UNET is so sad, so we are currently decided to continue to work on old Unity network (Raknet) until the better solution will appears.
Raknet was so good! Revolutionary simple, intuitive and powerful! Unity just need to improve it, instead of that they made UNET : (

 

Are you using the right version of Photon? Photon PUN? Unlike UNET devs, Photon devs are actually responsive -- just google "photon pun forum" and toss them a post.

 

worried about 100% NAT punch through, never followed up on the thing they were going to work on instead.... Watched a video with a guy and a laptop and golang, He literally said oh and websockets, and heres like 5 lines of code oh nat punch every time....

 

I tried to find some Unity multiplayer roadmap, but the latest thing I found is more than a year old blog post by @larus:
https://blogs.unity3d.com/2017/03/17/update-on-unity-multiplayer-current-and-future/

Im curious on what is the future of UNET and especially HLAPI.

And also, since Unity Technologies acquired Multiplay last year, how does that affect the multiplayer features in Unity, and when? Is it reasonable to expect an major update to Unity multiplayer support in 2018? Has there been any announcements?

 

Latest news is that HLAPI is getting abandoned and left for the community to take care of, and that Unity is starting to work a better-designed ECS-based networking solution instead

 

Take a look here for an actively-maintained replacement for the HLAPI that is transport-agnostic:

https://github.com/TwoTenPvP/MLAPI

 

I know I have seen it around and talked about, is it production ready?

 

I'm the developer of the project. I personally believe it's production ready. Any issues regarding bugs usually gets fixed within 24h and large features don't take more than a week or so. I review all PR's and I try to document everything in the wiki. If you have a HLAPI project and just want to test the MLAPI without rewriting. We have a copy of the Command, Rpc and TargetRpc system in the MLAPI that you can use. It's not recommended for production as we have our own, more efficient messaing system, but it's good for just testing the project.

 

My system fully utilizes messaging with no command/clientrpc business, so I would be interested to see the approach you took with it. I have been considering alternatives to hlapi recently. I will definitely give it a look over after work.I have been working on implementing RavenDB, I am not particularly familiar with where this would fall in the scope of things, but would MLAPI be compatible with most any DB systems? I was having issues with x509Certificate2 and System.Net.Http.HttpClientHandler.get_ServerCertificateCustomValidationCallback, Raven offered to come out with a patch which should be out today or tomorrow to allow me to use it. I am not sure if that type of thing is more integrated into the engine, or if its in the networking layers such as this.

 

The MLAPI does not do any databases. So anything goes.

 

Is this something you are planning on keeping up with for the long haul, as in it won't be abandoned if / when Unity comes out with whatever new networking stuff they have planned? I would imagine that using my own serialization method would not be an issue? I currently use MessagePack / Lz4.

 

I am planning to keep it up yes. And you can use any serialization you want. We have a built in one that makes data ~6 times smaller by using varint compression with zigzag encoding. It's also "bit" based. No need for whole bytes.

 

Interesting. The majority of my messages end up being a simple byte enum code along with a dictionary <byte,object>, nothing crazy. All this is my first go at network programming in general, so I am still open to trying things out. I have replaced nearly every system in my game at least 2-3 times before I settled on what I wanted to use, lol. The networking portion just happens to be next in line, I started with uMMO as I had never touched networking at all at the time, then standard hlapi, tried some llapi. I am liking the sound of what you have going on though. I am making an RPG, so the observer system is pretty much a must.

 

The observer system was just added, it's works exactly like the HLAPI's observer system (At least in the API, idk about the implementation. I don't really know the HLAPI code wise). In the built in BitWriter we use, you can write enums as less than a byte. If you are saying that the enum byte is representing what type of message it is, we have that taken care of. The reason I made the MLAPI is because you don't want to have to reinvent the wheel. you can choose to use all the features in the MLAPI. They are not required. But often times you want to spawn a gameobject across the network, you want to send a remote message that invokes a method on a specific gameobject etc.

 

Much more so than HLAPI, especially because, as he said above, issues and even feature requests are handled very, very quickly.

 

BTW, I have an unfinished MSF/MLAPI integration sitting in my msf fork. I'll update to the latest api in a minute. Have a look... Maybe you'll get it working.

https://github.com/angusmf/barebone...k2/Assets/Barebones/Contributions/MLAPI_Rooms

MSF only uses LLAPI, so I ripped out the HLAPI stuff from the UNET rooms example. This would get you the MSF DB and server spawning stuff you want with a better API for the client-game_server networking.

 

Ah nice, I will be sure to check it out. : D

 

This is very interesting. Do you have a source for these news? Is there any schedule announced (i'm guessing not..)?

I think it would be really important that someone from Unity would confirm if HLAPI truly is discontinued. And what is the (rough) schedule for this new ECS based networking solution (if that truly is in development) that I have seen rumors about.

 

They have confirmed the ECS networking in their GDC roadmap talk. And they have scheduled it for 2018.3

As for HLAPI being discontinued, it isn't 100% official but I have seen a unity dev on the forums say that the plan is to leave it to the community.

 

Do we have ANY details of what the ECS networking is actually going to be? Or just that it's a new networking solution? I'm assuming it's going to be a mix of high and low level stuff similiar to the HLAPI & LLAPI that was released in Unity 5.

 

There will in fact be several new HLAPIs for several different contexts. They gave the example of one HLAPI for server-authoritative fast paced lag-compensated games, one for P2P RTS games, and one for fighting games. I think they'll probably keep the existing LLAPI though, and maybe just tweak it a little for ECS

A great advantage of ECS+Burst is that they believe they can achieve complete cross-platform determinism with it, even for floating points. So that's a pretty big deal for networking

That information is spread across the roadmap talk, the main keynote, and some of the ECS-specific talks from GDC2018

 

Why severral new? Pretty much every type of game has certain needs and it's just slight differences in how you want to create it. I don't see why you need different ones? Or am I missing something?

 

Well, if you take server-authoritative games and P2P games for example, it's two completely different networking architectures, so it makes sense to make different HLAPIs for them.

Making an RTS game with the current HLAPI would be a bit ridiculous. You might be able to make it work, but it'll be far from the ideal networking solution

 

For me it still makes sense to run one HLAPI. P2P and Server authoritive are different in how your game code is written. But the fundamentals are the same, you want to sync objects, variables, switch scenes etc.

As for making a RTS in the HLAPI? How would that be ridiculous? What part of the HLAPI design is limiting?

FYI. I'm just trying to understand here. Not questioning.

 

The short answer is that HLAPI is based on state replication from an authoritative server, and this would just cost too much bandwidth for a lot of RTS games (even if it would have many advantages). Instead, RTS games tend to rely on P2P lockstep, where every peer is connected to every other peer, and the game depends on only sending player commands instead of replicating the state of things

I was in the process of writing a big wall-of-text explanation but then I realized P2P lockstep is a subject that I actually don't know that well. So here's a good write-up on it: https://blog.forrestthewoods.com/synchronous-rts-engines-and-a-tale-of-desyncs-9d8c3e48b2be

However, now I'm having doubts: why not keep a client-server model instead of P2P, and still just rely on sending commands (and don't replicate the state of anything)? The only justification I can come up with at the moment is that it would increase latency considerably, meaning the game would become potentially 2x less responsive in a lockstep situation.

I don't know anymore!

 

To my knowledge you still usually run lockstep games as Server-Client and not p2p. Honestly, p2p is the only limitation I see with the HLAPI that would justify making another one. But I just see it as adding P2P support and not making like 3 new HLAPI's. The lockstep part is ONLY how you would actually write your own network code. Doesn't really touch the HLAPI, right?

 

yes, that's right. I imagine there must be a reason why so many RTS games choose P2P, but now I can't really figure out why, aside from the latency thing

 

For everyone who seeking for an alternative network solution I am also can recommend TNet
https://www.assetstore.unity3d.com/en/#!/content/56798
I am discovered it recently and so far I am really like how it works (except a few things, but benefits is great)