A couple of presale questions

[danfoo]

Hi,

I am considering Tnet as a starting point for our net code. Having looked at Unity Networking and uLink, Tnet comes across as a very good alternative since Unity Networking seems unreliable and uLink is more geared towards authoritative centrally hosted servers. But I have a few questions:

- It is implied but not fully clear that TNet will work simultaneously as both host and client. But I am assuming a player can host a session while him/herself playing using the same Unity instance - correct?

- One strength of Tnet seems to be that the same scene and code paths are used for both multiplayer and single player sessions. I get the impression that the scenes / rigs should be set up as always in multiplayer and single player essentially being simulated multiplayer with one player. Correct? If so, does that mean that lag following / syncing happens much quicker for the local player both in single player sessions and in multiplayer?

- The described approach of separating physics from rendering is one we are already taking. However, we separate physics from rendering as two fully separate objects (to be able to switch off physics fully when not needing it). Will Tnet scripts handle this separated hierarchy or be easily modified to do so? (I am primarily thinking of the "lag following" script referenced in this forum).

- Last but not least, and definitely not meant in a disrespectful way - to the contrary: You seem very competent and I have been very satisfied with NGUI. However, as far as I can tell you are one individual. Are you / will you be able to continuously update Tnet and NGUI and provide support? Since net code is very sensitive and crucial this is a quite important decision factor. While we will definitely delve into the code and hope to be self sustaining, being able to lean on external expertise is a big plus.

Many thanks in advance!

[pyscho2day]

- It is implied but not fully clear that TNet will work simultaneously as both host and client. But I am assuming a player can host a session while him/herself playing using the same Unity instance - correct?

Yes you can, but let me clarify something first. With TNet host is a little different, you have a server which all traffic is routed through, a host which is the authoritative player, and then your normal client.  With this there are multiple setup options. You can have a dedicated server in the cloud (or where ever) that everyone connects to. You can have a lobby server that just keeps track of individual servers. You can have local servers (Single Player or Lan Play).  With the Dedicated server the first person to join a channel is the host and they do all the authoritative stuff (if you so choose to code it that way). With the lobby server, the players can host a server on their local machine but a list is stored so that they can be discovered and joined by random people (Many of the FPS games are doing this now days). The local is just that, no outside interaction unless you know what you are doing then it is still possible to join from outside your lan.

- One strength of Tnet seems to be that the same scene and code paths are used for both multiplayer and single player sessions. I get the impression that the scenes / rigs should be set up as always in multiplayer and single player essentially being simulated multiplayer with one player. Correct? If so, does that mean that lag following / syncing happens much quicker for the local player both in single player sessions and in multiplayer?

You are correct to an extent, it all depends on how you code your game.

- The described approach of separating physics from rendering is one we are already taking. However, we separate physics from rendering as two fully separate objects (to be able to switch off physics fully when not needing it). Will Tnet scripts handle this separated hierarchy or be easily modified to do so? (I am primarily thinking of the "lag following" script referenced in this forum).

I am not sure on this one Aren might be able to shed some more light on this.

[ArenMook]

Completely separate objects approach is a bit odd, I would say. I would suggest having a common parent object (generally the one that has a rigidbody), or how do you make sure that when you destroy one, the other disappears as well?

If the renderer is created dynamically and destroyed dynamically by your script as well, then yes, this is perfectly fine. In your case you won't be using a lag script though, you'll write your own interpolator that makes object A follow object B.

[danfoo]

Completely separate objects approach is a bit odd, I would say. I would suggest having a common parent object (generally the one that has a rigidbody), or how do you make sure that when you destroy one, the other disappears as well?

We have a "master object" that keeps track of both the rendered object and the physics object. The reason being that you can not toggle physics components on/off at will in Unity, so colliders, rigidbodies and components (joints etc.) will always use resources. By separating the objects, a stationary object can be stationary and rendered but unless needed can have the physics rig totally inactive = much more efficient if you have many such potential physics actors.

If the renderer is created dynamically and destroyed dynamically by your script as well, then yes, this is perfectly fine. In your case you won't be using a lag script though, you'll write your own interpolator that makes object A follow object B.

Why? Can we not simply modify the existing lag script to reference a separate object instead of a parent...?

[ArenMook]

You can, sure. But then when you grab the latest, changes will be overwritten.

[danfoo]

You can, sure. But then when you grab the latest, changes will be overwritten.

We will copy / override it if the algorithm you use works for our situations.

You did not comment on the last question though (re. your ability to develop/support both NGUI and TNet). I hope you do not think it is cheeky. Since Unity changes relatively rapidly it is a big plus if we can rely on TNet being updated during the life span of our project. One less aspect to keep up with so to speak.

[ArenMook]

I've been doing it fine so far

My next year's plan is to make a pretty large-scale game that will use TNet from day 1, so as I've mentioned to some curious parties, most of the future development on TNet will come as a direct result of that.