Understanding the TNet model

[TheCodeTraveller]

Also to add to above posts, my project is structured as:

NetManager
\- TNManager
\- TNObject
\- PlayerManager - Something similar to the GameUnitManager I saw around here a while ago (CreateEx example)

MenuManager

- When the MenuManager receives an instruction to start up the game, I call my PlayerManager.CreatePlayer (static function), which returns an RCC which kicks off a TNManager.Instantiate
- What happens next is the MenuManager has some load step logic so it finds the Player that was created by TNManager. I do this because I set certain parameters on the player. This is essentially the same as if I was doing in the RCC just more specific to disabling the menu system and setting up the game level.
- Every player has their own TNObject which I use to drive controller / gui logic
- When the MenuManager listener receives a level end command, the player is instructed to TNManager.LeaveChannel and the entire menu is reloaded.

Is there anything other than the above to do to get these objects to remove themselves? Am I meant to be checking in my PlayerManagers received RCC that the receive is for me? If I do this only, no other player will TNManager.Instantiate. Must the host only call TNManager.Instantiate in the RCC? If I must, should I be checking the TNManager of isHost? Or something else.

[TheCodeTraveller]

Cool so I've made progress. I've decided to manage players actively and have solved the problem with objects being left behind. Still need to battle test this with a few more clients open but two player games seem to be working just perfectly.

I've also starting playing around with UDP a little more, first thing I got stuck on is testing two clients, as they originally bound to the same port to listen on these UDP packets. I've not got rolling code per client for local testing so that these ports don't conflict with one another.

Here's a question though, SendQuickly sends via UDP when available but falls back to TCP - correct? The very nature of UDP is zero ACK., just assumes the packet arrived etc.

Now if I'm starting a UDP up on my local manager say port 6777 or whatever, how do you know that the UDP wasnt started in first place. What I'm trying to say is how do you know to send TCP without an ACK from the UDP side which goes against what UDP is.

Or are you sending another packet via TCP to say the first packet arrived, continue sending regardless via UDP (because it's up).

[ArenMook]

Whatever implements an RCC function needs to be defined on the same game object as TNManager, or one of its children. In your diagram you have it beside the TNManager, which would be wrong.

You can have two UDP game clients on the same machine, but you can't have two UDP listeners on the same machine (lobby Yes, if UDP is not available, TCP is used.

You should be starting UDP on a random port, not on a specific one. Only the server should be using a specific port. Check the example that comes with TNet.

[TheCodeTraveller]

Thanks for the reply, in the end I hunt for the next available port open 

[danfoo]

A few fundamental questions relating to ownership:

- Is ownership of an object determined by which client sends the RCC?
- Can an ownership change be performed at any time using tno.ownerID?

- In the case of a game hosted by a player via starting a local server instance, is there any distinction at all between the server and the host (I keep seeing both words used in documentation)?
- In the above case, if the hosting player disconnects will the session still live on? Ie. will another client instantiate a server and take over the responsibility, or does this transfer only apply to remote servers and independent clients?

TIA!

[ArenMook]

Ownership is determined by whomever sends the Create call, yes.

Yes, you can change the ownerID at any time.

Server is just a process that everyone connects to. IRC server is also a "server" for example. Host is a player -- usually the first player to join the channel. Just like a channel operator in IRC. The first person to join a channel in IRC is its operator and can boot people and do other administrative things.

If the host disconnects, a new player gets to become a host. Server does not migrate. If a server goes down, that's it. Everyone will be disconnected.

[danfoo]

Thanks for the reply! Have been on vacation but back to tackle this now.

If the host disconnects, a new player gets to become a host. Server does not migrate. If a server goes down, that's it. Everyone will be disconnected.

The planned model for our title is a locally hosted server model where players themselves will take responsibility for running a server and hosting. So, would this approach be recommended:

- The game allows players to start a local server. Connects to a lobby server hosted by us. Local server can be private/public.
- The player can (but does not have to) start a game on his local server.
- Other players can connect to the server and can (but do not have to) join the session run by the player owning the server.

The alternative would be game servers hosted by us, but that comes with scalability issues / cost. Thanks in advance for confirming the above!

Edit: Another related question: Per your recommendations, much of our code is written with multiplayer in mind and as such much of the communication will be routed through Tnet even when in single player mode. Does this mean that a local server has to be started for this to work - or will TNet still route RCCs/RFCs?

[ArenMook]

No need to start a local server. TNet's functionality will work the same whether you are connected or not. If you are offline it will behave as if you were connected in a channel by yourself (TNManager.isConnected will be false however).

Your model seems fine, and is ideal for TNet.

[danfoo]

Thank you!