Unet to com.unity.transport tutorial

I've been looking over the new networking stuff for com.unity.transport trying to get an understanding of it and think I'm lacking some basic understanding on how to architect classes to work with the new networking API. For reference: https://github.com/Unity-Technologies/multiplayer

Looking at the Client-Server sample seems pretty straight forward for sending and receiving data, but it leaves a lot of un-answered questions. How do you handle multiple types within a class (It appears to always anticipate sending integers). How do you handle value changes, and know when they occur? What's best practice for triggering events or methods when new data is received? How does a Cmd or RPC get triggered?

I attempted to dig into the FPS sample to hopefully get an answer to some of these questions but didn't really know where to look to find anything basic enough to start digging into. If you know of any classes I should have a look at please let me know. For reference: https://github.com/Unity-Technologies/FPSSample

I thought the best way to get an idea of how to handle the new networking would be to try and convert a simple class that uses Unet . Lets use the Unet tutorial for a health class located here: https://unity3d.com/learn/tutorials/topics/multiplayer-networking/networking-player-health

How would go about translating this using the new networking layer? Code snippet below

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.UI;
3. using UnityEngine.Networking;
4. using System.Collections;
5.  
6. public class Health : NetworkBehaviour
7. {
8.  
9.     public const int maxHealth = 100;
10.  
11.     [SyncVar(hook = "OnChangeHealth")]
12.     public int currentHealth = maxHealth;
13.  
14.     public RectTransform healthBar;
15.  
16.     public void TakeDamage(int amount)
17.     {
18.         if (!isServer)
19.             return;
20.  
21.         currentHealth -= amount;
22.         if (currentHealth <= 0)
23.         {
24.             currentHealth = 0;
25.             Debug.Log("Dead!");
26.         }
27.     }
28.  
29.     void OnChangeHealth(int health)
30.     {
31.         healthBar.sizeDelta = new Vector2(health, healthBar.sizeDelta.y);
32.     }
33. }

 

The new networking API doesn't have any high level API implementation yet, so if you want that you'll have to create it all yourself for now, or wait for a high level implementation from Unity. It doesn't even have reliable messages yet, which you'll probably want for things like SyncVars unless you're changing the value very frequently.

 

I understand there isn't a 1-1 translation or even a 10-1. But in the instance of the FPS sample, it has some equivalent of the above code. By equivalent I mean, it has some way to track health, take damage, sync health to clients, and update the UI. I'm looking for a very bare bones start from scratch, what do I need to do to take the old API logic to the new.

In the FPS sample there is a "HealthState" class, it has a serializer, deserializer, apply damage, and set max health methods. Is this all that is needed? I'm assuming not since there is no reading or writing in that class, but I don't honestly know.

My understanding from the other deprecation threads and fps sample discussions is, it doesn't seem like there will ever be a HLAPI equivalent. We are going to have to do this all manually at some point or use some sort of "fps template" they've already written for us. If that is the case I'd like to try and learn this as soon as possible, as Unet has shielded me from some basic understanding of what is happening under the hood. I understand this is going to be complicated but I'm assuming (maybe incorrectly) this would be a good jumping off point.

 

Thanks for this thread. What is frustrating is they have 'flagged old networking as deprecated' in compiler warnings. They should have done it only after there is full example and full tutorial published.. Too much of agile these days.

 

They did that as a warning that Unet will be removed in the near future. The latest estimate is 2019.2 or 2019.3 as mentioned in another thread.

 

The real problem wasn't the UNET's deprecation, but its early deprecation. My team and I are working on Unity 2019.1 and UNET became a Package (and been removed from the Unity core). That's cool for us to continue on UNET, but we really need to move forward (with a better networking optimization), and Unity doesn't provide enough examples to really start from scratch.

Even the samples from the unity-multiplayer git are PureECS, and complex. We need more examples or tutorials for Hybrid ECS or MonoBehaviour projets :/

 

I'd suggest using an alternative network API than what Unity provides, even when they eventually do a full release of what they are working on. Unity's track record with network API's has been to deliver a buggy solution, drop the ball on support, and then deprecate the solution. There's no reason to expect their third try to be any different than the previous two.

 

I've just tried to build the https://github.com/Unity-Technologies/multiplayer example using the new Beta version only to jump through a load of package/build/compile problems to be stopped by a runtime error in ECS.

Spoiler: InvalidOperationException: The NativeContainer PongJob.Data.driver.m_genericConcurrent.m_Logger.m_PendingLog has not been assigned or constructed. All containers must be valid when scheduling a job.

InvalidOperationException: The NativeContainer PongJob.Data.driver.m_genericConcurrent.m_Logger.m_PendingLog has not been assigned or constructed. All containers must be valid when scheduling a job.
Unity.Entities.JobForEachExtensions.Schedule (System.Void* fullData, Unity.Collections.NativeArray`1[T] prefilterData, System.Int32 unfilteredLength, System.Int32 innerloopBatchCount, System.Boolean isParallelFor, System.Boolean isFiltered, Unity.Entities.JobForEachExtensions+JobForEachCache& cache, System.Void* deferredCountData, Unity.Jobs.JobHandle dependsOn, Unity.Jobs.LowLevel.Unsafe.ScheduleMode mode) (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/IJobForEach.cs:434)
Unity.Entities.JobForEachExtensions.ScheduleInternal_D[T] (T& jobData, Unity.Entities.ComponentSystemBase system, Unity.Entities.EntityQuery query, System.Int32 innerloopBatchCount, Unity.Jobs.JobHandle dependsOn, Unity.Jobs.LowLevel.Unsafe.ScheduleMode mode) (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/IJobForEach.gen.cs:372)
Unity.Entities.JobForEachExtensions.Schedule[T] (T jobData, Unity.Entities.ComponentSystemBase system, Unity.Jobs.JobHandle dependsOn) (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/IJobForEach.gen.cs:169)
PingServerSystem.OnUpdate (Unity.Jobs.JobHandle inputDep) (at Assets/Samples/Ping/ECS/PingServerSystem.cs:50)
Unity.Entities.JobComponentSystem.InternalUpdate () (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystem.cs:696)
Unity.Entities.ComponentSystemBase.Update () (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystem.cs:169)
Unity.Entities.ComponentSystemGroup.OnUpdate () (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystemGroup.cs:369)
UnityEngine.Debug:LogException(Exception)
Unity.Debug:LogException(Exception) (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/Stubs/Unity/Debug.cs:25)
Unity.Entities.ComponentSystemGroup:OnUpdate() (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystemGroup.cs:373)
Unity.Entities.ComponentSystem:InternalUpdate() (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystem.cs:570)
Unity.Entities.ComponentSystemBase:Update() (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ComponentSystem.cs:169)
Unity.Entities.DummyDelegateWrapper:TriggerUpdate() (at Library/PackageCache/com.unity.entities@0.0.12-preview.31/Unity.Entities/ScriptBehaviourUpdateOrder.cs:135)

 

If you use their low level api, you have to implement your own system for reading and writing between server and clients.

Syncing between current clients and previous clients. It's a lot of work.

Their high level api, Netcode, the ecs one I find at the moment very hard to digest and locks you in client side prediction. (I'm assuming they'll make it generic soon enough?).

So personally, I'm actually writing my own high level api for it at the moment.

The way I approached it was having an abstract RPC<T> class with Read() and Write() methods.

Server.Listen(new SpawnRPC());
Client.Send(new SpawnRPC(spawnData);