Question Can I access Unity Native Containers outside of a Unity project?

Hi! I'm working on multiplayer game with voxels. I want to move the voxel data structure over to Native Containers so I can start writing jobs to handle operations on it. However the issue is that my game server application is not a Unity project it's a .NET core app and I have a shared .dll that holds the voxel datastructure so I can execute the same operations on the voxels on client and server side the same way.

So is it possible to access NativeArrays from a non-unity application? Or is there another array-like data type I can use in Unity C# jobs that I could access from both a Unity and non-Unity application?

 

There is headless Unity feature.
Maybe try to investigate it.

Either way, in your case, you will need many Unity libries to run such on the server. Stripping from the Unity build, or extracting individual libraries, may conflict with Unity EULA. You may need to ask Unity support for more details.

 

So ... that means the server isn't running Bursted code. Which means you may have very fast client code, the server will have a hard time procssing all that data. Server may be operating the same code paths 10-100 times slower. Have you thought of that?

You'd save yourself a ton of headaches and performance issues by implementing the server with Unity.

 

I've been avoiding implementing the server app in Unity for performance reasons. The server mostly just maintains data and what clients are authoritative over the enemy's AI. The server is running on a small GCP instance and can support 100s of players at a time.

Implementing Unity in the server would add unneeded overhead and complication.

 

In that case you don't need dots. Just use c++ or relevant.

However, I got impression you are underestimate power of DOTS.

Either using just burst alone or with jobs.

Mind, correctly executed DOTS written application, can gain lots of performance and battery saving on mobiles devices.

Similar will apply for server handled.

 

I have been trying to transition from my traditional C# .NET threads to Unity C# Jobs. But the amount of time it takes with little to no noticeable performance increase has got me skeptical about DOTS. Admittedly I don't know the benefits of the other aspects of DOTS or how it works. Please correct me if I'm wrong but ECS seems like it's purpose is to consolidate many separate Update calls on many of the same types of game objects into one pass? So it seems like it's only helpful if you have tons of the same types of game objects that all have Update calls?

Honestly the main reason I like Unity is because C# is a joy to code in and the job system sucks the joy out of that by not allowing you to use classes, manual memory management, and everything needs to be thread safe. I assume other aspects of DOTS follow this pattern.

 

NativeArray is just a pointer and length, you can construct the NativeArray on the Unity side easily.
If you want performance then why complain about DOTS restrictions? They're what makes the JobSystem performant

 

The way you are wording about DOTS indeed confirms, you don't have experience with DOTS. Which is natural that it will be hard for you, to get the performance comparison in any meaningful way.

ECS means Entity Component System. That requires to write systems and operates on entities, which is unmanaged data type. You must not think about Game Objects. This is different paradigm.
You would need swith your way of thinking from OOP to DOD first, to follow benefits of memory organisation hence benefits of DOD paradigm. Following with DOTS.

Using DOTS allows to process even milion of entities in crazy performant way. Getting benefits of burst and jobs, can result in safe multithreaded code with minimum effort. Enabling burst can alone gain you in some cases over 10x performance.

Writing code in SIMD friendly manner, gives you additional performance boost.
Jobs adding multithreading. And you can operate on native arrays if you need to, to get benefits of both worlds.

Entities is another step level up. But if you haven't worked with ECS before, it may be steap learning curve ahead for you.

So the performance benefits are there, but need to be recognised and measured for each specific project.

You could run complex AI logic in paralel for example. For many 1000s of AI entities. Your CPU could barely feal it, if DOTS systems are designed in correct manner.

Or you could run compression and decompression algorithm for your networking layer.

Whole skills and physics of players also could be computed with DOTS.

I'd world is divided into some sort of chunks, where grop of players don't interact with other chunks directly, then each group of players could be calculated on own thread.

Servers have these days many cores. Seems like waste of capability of the server, not utilising efficiently threads.

 

You know you can make a dedicated server build in Unity? The build is stripped of unneeded assets and I believe won't even render anything.

It may not be as barebones as a "naked" C# app but it's definitely worth considering.

 

Btw. regarding headless runtime.
https://docs.unity3d.com/Manual/PlayerCommandLineArguments.html
See batchmode

Command Details:
-batchmode - Run the application in “headless” mode. In this mode, the application doesn’t display anything or accept user input. This is useful for running servers for networked applications.