TNet: Tasharen Networking Framework

[ArenMook]

Yeah you can add it later. As long as it's there when you are trying to start a multi-player game, you're fine.

[xfinitystudios]

Loving TNet Framework so far!

One issue I'm having is when a user shuts down the game without logging out of the channel.

I'm creating a box in the scene using TNManager.Create() and when OnNetworkPlayerLeave each box in the scene checks to see if the player that left was the one that owned it. If the player that left owned that box, then it uses TNManager.Destroy() on itself.

This works fine.. however when the last player forces the game to close.. there's no client to remove the box, and it sticks around and never removed.

How can I handle things like that?

[ArenMook]

When you join a channel, specify a 'false' for the "persistent" parameter.

[MattCarr]

Great package. I was going to write my own networking framework for the game we're making soon, but I saw this and the quality of it's design and code and thought I'd save myself the time .

I've only been using it for a few hours so far and will probably have more suggestions and find more issues later, but so far I have these:

• "OnCreateObject" sets mObjectOwner to playerID after the instantiation happens. This looks like a bug as it is set to creator earlier which it should remain as.
• For my project I want players to be told when an object has been instantiated and who created it so that I can have them create themselves and then check if they can control that instantiated player. I've added a delegate "onCreated" which is called at the end of the OnCreateObject method and pass it the GameObject created, it's objectID and the creating Player object. To me this seems like it would be useful for other users so I thought you might consider adding it as well (would also save me merging changes later )?
• Thirdly, in TNManager.cs where you assign its methods to the mClient delegates (onError, onConnect, etc), could you change the assignment from "=" to "+=" as I could potentially see myself adding additional callbacks for those and if I add them in an earlier Awake() method they'll be overwritten.

Thanks again for making this package. I spent 3 years working on a large networked simulation project in Unity and produced for that something of a very similar design, but didn't end up as clean and easy to integrate into general multiplayer projects (mine was primarily for cluster rendering on multi-machine driven displays).

Edit:

Found what seems like another issue: Creating AutoSync objects at runtime won't work properly as their mCanSync value will not be set to true. I've fixed for now in my project with

1. if (TNManager.isConnected)
2. {
3.    mCanSync = true;
4. }

In Awake().

[fgame]

What I want to know most is how does it compare to the main existing networking solutions? E.g. Photon, uLink and so.
You know, those are Fxxx expensive, and yours is so cheap compared to them.

I always hate Photon, uLink this kind of stuff, they are even more expensive than Unity itself! WTF. I really hope you can finish them off and make them jobless.

[ArenMook]

@MattCarr:
1. OnCreateObject setting mObjectOwner does indeed seem like something that shouldn't be there. It's harmless as generally you will...
2. ...set the object's logic in its Awake() script. This is when you should determine who the object belongs to. There is no need for an OnCreate() function. And Awake() gets called right after Instantiate.
3. You can still append to them afterwards with +=, can't you? This happens in Awake(), meaning as soon as TNManager is created -- so you wouldn't be setting anything before that.

Regarding AutoSync: there is no need to sync anything unless you're actually in a channel playing multi-player, in which case you will get the OnNetworkJoinChannel callback.

[ArenMook]

What I want to know most is how does it compare to the main existing networking solutions? E.g. Photon, uLink and so.
You know, those are Fxxx expensive, and yours is so cheap compared to them.

I always hate Photon, uLink this kind of stuff, they are even more expensive than Unity itself! WTF. I really hope you can finish them off and make them jobless.

Just different packages. TNet focuses on simplicity of use and elegance of code. It aims to accomplish more with far less code, which generally makes it much easier to work with. I don't want to make anyone jobless... all packages have their use to the right person.

[MattCarr]

2. ...set the object's logic in its Awake() script. This is when you should determine who the object belongs to. There is no need for an OnCreate() function. And Awake() gets called right after Instantiate.

Ok, yeah. I didn't see the objectOwnerID property (EDIT: or isThisMyObject ) so didn't understand your usage of mObjectOwner.

3. You can still append to them afterwards with +=, can't you? This happens in Awake(), meaning as soon as TNManager is created -- so you wouldn't be setting anything before that.

Yeah, but my point was more that there's no reason to not use += in TNManager to remove the current limitation of not being able add callbacks in earlier Awake() methods. Awake is generally where I prefer to assign callbacks.

Regarding AutoSync: there is no need to sync anything unless you're actually in a channel playing multi-player, in which case you will get the OnNetworkJoinChannel callback.

No, I'm talking about AutoSync's being created at runtime. So the host instantiates one, it's default mCanSync value is false and OnNetworkJoinChannel is not called because it has already been joined. For this instance the AutoSync should be checking whether or not it's already in a channel in its init so it can set mCanSync to true.

[ArenMook]

Ah, good point about AutoSync. I've fixed it like so:

1.                                 // Only start the coroutine if we wanted to run periodic updates
2.                                 if (updatesPerSecond > 0 && TNManager.isConnected)
3.                                 {
4.                                         // If we're already in a channel, we can now sync this object
5.                                         if (TNManager.isInChannel) mCanSync = true;
6.                                         StartCoroutine(PeriodicSync());
7.                                 }
8.                                 else enabled = false;

I'll change it to +=, but any reason you don't want to just rely on automatic OnNetwork* series of functions?

[MattCarr]

I'll change it to +=, but any reason you don't want to just rely on automatic OnNetwork* series of functions?

Thanks. No reason at the moment, I'm actually not adding any callbacks to those right now and possibly never would, it was just something I noticed and thought I'd raise just in case it ever came up in the future. Not a big deal .

[ArenMook]

Well, one thing I don't like doing is changes for the sake of changes.

[MattCarr]

Well, one thing I don't like doing is changes for the sake of changes.

Sure. It was just a suggestion so it's up to you whether or not you incorporate it into the next version. I don't see an issue with simple changes that have upsides and no down sides though.

It seems like the player is not set as the host properly after joining a channel until other players have joined and told them they're the host? In TcpPlayer.FinishJoiningChannel there is a check for if the channel host is null and if so it sets the host to the player. Then in either case a packet is sent to other players informing them of who the host is. If you create a server and join a channel, you're set as the channel host but you don't receive the sent packet so the other host/isHosting values don't appear to be set until someone else joins and sends that packet back to the host. Is this the case or have I missed something? Can be tested by starting a server, joining a channel and checking the TNManager.isHosting value before and after a client joins.

[ArenMook]

TNTcpPlayer, line 60. There is always a host. You can't join a channel without getting that notification. This packet is sent to the player. I suggest you use the package, and post if you actually run into issues. Pre-emptive posting won't be helpful much. I am actually making a game with TNet powering its networking right now, and so far it's working flawlessly.

[MattCarr]

TNTcpPlayer, line 60. There is always a host. You can't join a channel without getting that notification.

Yeah, but there is still the issue of TNManager.isHosting returning false still occurs in that instance. Just checked again to see why and it's because GameClient.isHosting checks if players.size > 0 and the host is not added to that list so it is 0 until someone else joins. Is there a reason for that condition? I would think isHosting should return true when the player is the host and no clients are connected.

[ArenMook]

Oh that. Right, I fixed that about a week ago on my end. I'll go live as a part of 1.2 later today.