Best practice with dedicated server while working on levels

[scornflake]

So, I have a game connecting to a standalone server on Mac now. Yay. That was easy

I'm very new to Unity / Game dev though.
What's the best practice when working on a level in Unity, that you'd like to have server connectivity for?

Sure, I can add a custom "AutoJoin" component, but I'd have to figure a way to not run that when connecting from the first scene (the connection screen)...  it seems, some kind of "conditional auto join" might be appropriate.

Am I heading down the right track with my thinking? Or have I missed something obvious?

[cmifwdll]

I'd handle server connection & channel joining on the main menu (or server browser or whatever).
As for creating the player, the AutoCreate component works well. Initialize your player in its Awake() or Start() function. I think there are some cases where marking your local player as DontDestroyOnLoad is a sound design, but it's probably best to just keep instantiating it on scene loads and having your initialization step load any "persistent" player data. Lately I've been serializing everything to JSON and using that locally, but using TNet's SetPlayerData(...) would probably work just as well.

[scornflake]

I get the menu idea, which I'm planning on doing.

My question was more about how I'd handle server connectivity, without using the menu (it gets old running the game right from the main menu every time).  Example: I want to enter the persistent world, at a certain point, while I'm testing a new level/scene. I'd prefer to have a way to do this without having to load the menu level, just to start the game...

I could of course write some code in the Start() to join the server, but that seems a bit clunky?

[cmifwdll]

Not sure. Static or singleton-pattern LevelManager with a LoadLevel(string sceneName) function that handles the connection process? You basically just call TNManager.Connect(serverAddr, serverPort) and then TNManager.JoinChannel(-1, sceneName, ...) when TNManager.onConnect fires and you've got your networked scene ready to go.
Though for testing purposes you don't really need a connection, do you? I guess it depends on what you're testing, but I think RFCs and RCCs work even without a connection. Actually, I think everything may work without a connection in TNet3, even saving player data and whatnot.

[scornflake]

Hmm, OK. Thanks.

I'm still getting my head around the architecture, but it's nice to know I don't *need* a connection. Might still have to code up some test/fixture type data (what I need is data representing multiple players, even when there are not multiple players really connected). 

I'll prob just factor that out to a SimulatedPlayer type class, which could even join the channel if necessary...

[cmifwdll]

Normally each client creates their own Player gameobject when they connect (through something like TNAutoCreate), but for testing you could write a debug-only function that just calls TNManager.Instantiate(...) for you. It's still a networked call so it follows all the same rules as if a real client had connected. I register all Player GO's in their Awake() function with my GameManager so I always have a List<GameObject> PlayerGOs available. Unregister in OnDestroy().

[ArenMook]

In Sightseer what I have is a scene that loads that has the "Connect" button. This scene is also where all mods get loaded. After the external data is loaded, the Connect button is enabled. Clicking it essentially calls TNManager.Connect with a null passed for level name and a fixed channel ID -- the "global" channel used to instantiate world-wide objects (player factions, teleporters, etc), which is also used for communication. The player is able to see the world map at this point and choose their starting location. Doing so proceeds to join a second channel, loading the scene that actually loads the procedural content for the game.