Should I use Unity.Transport or NetCode?

Not sure if this is where I should ask it, but I will go for it.
So lately I been researching whether I should use new Transport package or NetCode for my multiplayer project.

The problem is that there can be around 500-1000 AI, 2-4 player entities running around in the big map and I think that would be too much to send each entity position as well as some other stuff to the clients. So my solution is to update entities that are visible or close enough to the player(wont cause any problems considering my project style/type). If they come close enough server will sent a packet to instantiate entity near the player, if it moved further away entity will be destroyed on the client-side or at least won’t receive updates anymore.

And so I was wondering which package I should go with for this level of functionality.

New transport package is low level so I definitely should be able to implement this with it, but if go with it I will have to implement some other things too, that are already covered by NetCode.

On the other hand if I go with the NetCode I can quite quickly setup everything but I’m not so sure if I can achieve this level of functionality. NetCode has something called distance based importance, so it will prioritize closest entities, but as I understand it will attempt to send all entities anyway and I don’t want to use up more bandwidth than I actually need.

Basically I’m trying to figure out which one would be better for this, I would love to try out NetCode so if anybody knows if this is possible please enlighten me. If it’s not then I will have no other choice as to go with new Transport package.

1 Like

So many time past after this post but, which one did you choose?

i think unity transport layer api is a simple and powerful option for create a good and optimized game for every platform .

1k AI agents is obviously a lot, but NetCode can theoretically handle this scale (with optimizations).

Relevancy: NetCode added the concept of “per-connection relevancy” in 0.3 (see changelog for description). You can specify a list of entities that should be relevant to a given connection, and only those relevant ghosts will be replicated for that connection. See the Asteroid sample’s ShipRelevancySphereSystem.cs which defaults to forcing your job to specify the irrelevant entities. You can change this behaviour to force your job to specify only relevant entities (which will be a much smaller set) by modifying the code below.

// Line 43
m_GhostSendSystem.GhostRelevancyMode = GhostRelevancyMode.SetIsRelevant;
// Line 73
if (math.distance(pos.Value, connections[i].Position) <= settings.levelData.relevancyRadius)

Ensure you also modify the GameSettings entity to set a relevancyRadius. Recommend 400 to 1000 units.
Note that this also changes the default behaviour when no ships are spawned too, so you won’t see any entities on the client until your ship spawns.

2 Likes

The Asteroids sample also showcases a major bandwidth optimization via GhostOptimizationMode.Static. Any ghost assigned as static during authoring will only be replicated whenever its GhostFields actually change. It sounds like it won’t be too useful to you as you seem to imply your ghosts will be updating indeterministically every frame, but it’s a great option if your ghosts aren’t moving / updating every frame. Entities like trees, dropped items etc are suitable.

Also note: “Distance based importance” affects how frequently relevant entities are replicated to any given connection. You’re absolutely right that this doesn’t stop those entities from being sent. However, you might still find it useful. The NetDbg profiler is great for determining these kinds of optimizations.

We’re welcoming feedback about all of the above too. Would be great to hear how you get on.

2 Likes