NetworkBehaviour Singleton

Unity Engine
1

I’d like to have a NetworkBehaviour singleton to manage general networked information. However I’m not sure the proper way to do this.

If I have the singleton as a scene object then it doesn’t ever “spawn” once the server starts (at least in the .exe… in the editor it works fine… unsure why editor and build file give different results). In addition it never “spawns” on the client even if it spawns on the server. The object is there… it’s just disabled/grayed out (not “spawned”). And if I check the server and the NetworkBehaviour is being watched by client… so I’m unsure why client never got the “spawn” message.

If I manually Instantiate/Spawn the singleton during NetworkServer.OnServerStart then it spawns on the server, but not on client. It seems buggy. If I manually add a few second delay then things seem to work.

Since the object is persistent you use DontDestroyOnLoad. But when entering a scene this additional spawned object that is not part of that scene seems to make UNET count mismatch errors.

CRC Local Dump Inventory : 0
UnityEngine.Networking.NetworkIdentity:UNetStaticUpdate()

Spawn scene object not found for 9
UnityEngine.Networking.NetworkIdentity:UNetStaticUpdate()

Also not sure how to handle the singleton when the game quits and everybody returns to main menu and network connection is lost.

Has anybody had success making a NetworkBehaviour singleton? Any tips? Thanks in advance.

1 Like
2

I can’t really see why you’d want a network behavior to serve as a singleton, you can derive a client manager from network manager and use network message for sending and receiving some info, a network behavior is designed (far to my understanding) to describe the object behavior in network manner, not to send and receive network info.

3

The reason for a NetworkBehaviour singleton is to allow SyncVars to be used.

So lets say your game has a score, player chat, and a bunch of other game info. If another player connects a game in progress the SyncVars will automatically give the late-connecting player all the latest information.

This can also be accomplished with messages… but just takes more work.

1 Like
4

I have been struggling with this architecture myself. The most frustrating part is that certain network code works in the editor, but not in the standalone build. Also, I am very new to Unity and am still wrapping my brain around the NetworkBehaviour libraries and trying to understand just what happens on the server, and what happens on the clients…and when. Have you managed to figure anything out in this regard? What was your final solution?

1 Like
5

This concept already exists within the HLAPI, as a “player” object as part of the functionality of the NetworkManager comonent. The idea is, in order to inherit functionality such as syncvars, rpcs and commands, you must have two things:

  • an object with a script that inherits NetworkBehaviour. This is where your syncvar, rpc and command functionality exists
  • to the above object, an attached NetworkIdentity component. This is needed to be able to identify the object over the network (to know who to send syncvar updates to, and who to send rpc/commands to)

So when you think about things logically, mainly that every “networked object” that exists over the network has to be uniquely identified, static NetworkBehaviour wouldn’t make sense… nor is it really realistic because a singleton/static environment suggests that there is only one instance of whatever it is that you are dealing with…

In stead, thinking within the design of unet, particularly the HLAPI, just follow the “player object” concept of the NetworkManager: a networked object that is spawned when a player connects, to act as a global control for an individual player. This “player object” is a networked object (the prefab that you assign to the Player Object setting in the NetworkManager within the inspector), in that you must have a NetworkBehaviour script attached to it, and a NetworkIdentity component. This means that from this player object you can do syncvars, rpcs, commands and pretty much anything else that you might want to do from a player-perspective, rather than from the perspective of a networked object (such as an object that is spawned by the player).

It’s worth noting too that the concept of the “player object” is tied directly to the NetworkManager component. It’s literally just an object that is registered as a network-able object (via ClientScene.RegisterPrefab) and then spawned using NetworkServer.SpawnWithAuthority when a player connects to the server. This is something that you could easily implement yourself without needing to use the NetworkManager, if you so wish.

On a side note, and since you mention messages, and since there’s talk here about understanding the architecture if unet, it’s worth noting that using messages would be a better solution for some sort of chat functionality. Yeah, using the HLAPI’s syncvars/rpcs/commands takes less effort, however you take a performance hit for using them, especially when using them for things that they aren’t really designed for. If you can stomach it, I definitely recommend using messages for your chat-related functionality.

Hopefully this helps, good luck!

5 Likes