I felt that this topic merited its own thread, instead of continuing to post in the "We Need a Shovel" topic, which was about something completely unrelated... That being said, here are the two relevant posts from there for context, to see why these three features alone, out of the HUGE list that are part of the 2018 Engine, would no doubt make for a large performance uplift for Planet Nomads!

Quote Originally Posted by martinsustek View Post
Speaking about multithreading and optimizations - Whole Unity engine is single-threaded, we use a Thread-Ninja, which is kind of multithreaded asynchronous coroutines. But the amount of work, that could be done in background threads, is very limited as it could not use any functions from Unity API. We use it mainly for database writes, animals terrain navigation, and few other things. The core of the Sandy terrain engine is written as a C++ plugin and this is multithreaded code. But synchronization between multi- and single- core as well as marshalling data between C++ plugin and C# scripts also takes some time.

Moving slow operations to background thread can save some lags, in expense of more complex code and necessity to synchronize things. But the main problem in low overall performance in the game is currently rendering, especially that part held on CPU side, physics computations and then few our Update scripts, the most annoying of them already moved to background threads.
Quote Originally Posted by martinsustek View Post
There are different PC configurations, and if performance is not enough, some of them might be CPU-bound and some GPU-bound, also depending on quality settings. Offloading things from the main tread should help in CPU-bound cases. But as I've seen it, most of the time spent on CPU is rendering, physics and some internal unity processes.

We are using Unity 5.4 currently. I am not sure if Unity 2017 is any better now, but last time we switched to 2017 we expected free performance benefit, but instead it was overall approx. 10 FPS worse on our testing machines and was forced to revert our project back. Maybe switching should be conducted with some rework of our code to gain a better performance. But we did not have a time for this.

Using multithreading is possible in Unity/C#, but not with Unity API calls, as stated in articles you've mentioned. We use asynchronous accesses to database, but switching between main and background thread costs a frame, so sometime it's better to do things in main thread instead of: getting values in main thread, waiting for background thread, computing something, waiting for main thread, using computed values in main thread. Also using asynchronous functions in interactive code is a little bit problematic. For example you call function to digg into terrain and never know, if modified terrain gets back in next frame or 5 frames later.
While the PN Devs are no doubt aware of the Unity 2018 engine, and the fact it has been officially rolled out now, I believe that given what is mentioned above as to issues and areas where performance is being held back, that these three things alone seem to be reason enough to give serious effort towards getting PN using the 2018 engine. Whatever benefits there were in 2017 that prompted an attempt at using it, I think that combined with all the things 2018's engine brings merit putting in the time needed to work on the code to get PN's engine updated...

Even if there were to be an experimental build put up that required users selecting the "Beta Builds" option in Steam, or a simple download link on the site for the required files, that some of us would be more than happy to give an unoptimized initial build a shot! You would then be able to see how the game is running on a larger sample size of system configurations and if there's a way to run the game so that it would produce a hardware profiler log (or if Debug Mode does this?), that'd be even better since you'd be able to see where each system has bottlenecks and whether it is something that can be addressed on your end through code tweaks.

#1) The C# Job System & Entity Component System (ECS)
Combined with a new programming model (Entity Component System), the new runtime system enables you to take full advantage of multicore processors without the programming headache. You can use that extra horsepower, for example, to add more effects and complexity to your games or to add AI that makes your creations richer and more immersive."

#2) "Shaders: Surface Shaders with many multi_compile/shader_feature variants import several times faster now (internally, Unity now multi-threads that process)."
#3) "Physics: 2D Physics can now use all the cores on a device to run its simulation. See Job Options (Experimental) in 2D Physics Settings."

Thanks for your time, and for PN!