Custom Networking - Shared Id for Scene Objects

Good evening,

I am in the process of writing a "simple" receive, process, relay server for a small Unity project I'm making. The server receives a well formed message from a client, processes if required, and then will relay the message to the appropriate connected clients. This system relies on objects that are either performing an action or receiving an actionable message have a unique id for matching.

Items/Players that are spawned are tracked correctly between all sessions since the id is generated at spawn time, but I've ran into a roadblock with objects that were in the scene during build time. I'm looking for a way to generate a consistent id on the clients (all client would generate the same id for game object during each run) or a way to find the same game object on each client.

I've considered the following, but am looking for more feedback/ideas:

• Requiring game object names to be unique - easy since it's currently only one developer, however in the near future end users will be able to load up their own worlds and could potentially not do this.
• Setting an id field in the editor for each object and somehow saving/loading this data.
• Creating a unique id based on game object name and the vector 3 position on awake and having the first connected user "inform" the server about already spawned objects and then letting each of the other connected clients know about this data - currently doing this, however I see issues as more and more items are created due to the finding game object with name and then checking position.

I've also spent a bit of time trying to understand how unet handles this. Looks like the "server" would tell the clients to spawn these items again, however I'm not sure how it lines them up with the existing game objects.

Thanks in advance for any ideas/discussion.

Cody

 

For objects that are part of the map or instantiated at runtime I have a data script on those items/prefabs that has their unique ID on it, so all clients (and server) have the same ID for a specific object.

 

Thank you, LukeDawn. I'm beginning to lean this way for objects placed on the map at build time.

 

I use scripts for networkable objects on maps so I can use the same map assetbundle for the server and the client. I have a separate project for each map, that builds the assetbundle, and uses the same set of scripts. Makes life much simpler.

 

This is a very old thread, but I thought I might leave this here for anyone who stumbles across this.

They way I'm doing it is that the networking component on each networked object checks whether the game is a server or client. If it's a client, all the networked objects are deleted and the server hands out all the networked objects with correct state and IDs. Server-side, the IDs are assigned to objects in whatever order they register to the central networking manager.

I am using a listen server (one client also acts as host), but this ought apply to regular servers as well!

 

Wow, old one!

Here is the approach I used (and seems to be doing well with our vr social platform at my company).

All network items register with the central server and get a unique id which is then passed to everyone else during the item spawn.

At design time a networked object is assigned a random that is persisted when the scene is saved. That script instance will always have that value. New scripts check what exists on the scene already to avoid duplication. The same check occurs on save to avoid malicious attacks. These items request a server side Id at load and use this is for all future operations.

this has worked great for what I’ve been doing since I started working on this project...simple and sweet in the end and was able to scale without contention—the biggest memory usage comes from keeping track of the dynamically spawned objects, but even then the client chugs way before the server does.

 

I just wanted to comment that approach #3 might produce slightly different ID's on different CPU's since you're involving floating point math when generating the ID's. Floating point math isn't guaranteed to produce exactly the same results on all CPU's.