PA's server really needs to be multicore.

That's right. I had completely forgotten the server-component. Well that would definitely make it easier as they would only need to update the server-side application rather than a complete overhaul of the engine since they're seperate.

I think pet planet is likely easier to achieve, and would certainly allow bigger multi planet battles with more players.

Full multi threading is possible btw (zerver made a multi thread version of the spring engine and the results are very impressive), though it would be a big undertaking I'm sure.

Really anything they can do to scale the simulation up beyond 1 Core is going to be a real positive move for the long term future of the engine, so here's hoping.

I never managed to find zserver implementation - distrib or source code or any type of insight about how he did this.

If I'm not mistaken, Spring is multithreaded by default since version 96.0. At least there are many occasions where loops are parallelized (using for_mt from https://github.com/spring/spring/blob/develop/rts/System/ThreadPool.h). That allows to parallelize only the parts you need (short but expensive loops) instead of threading entire tasks, so it becomes easier to avoid conflicts without any use of explicit locks.

That comes at one little drawback though, multithreading that way only remains easy as long as you can just partition both the work and the memory regions to write to, best case is having one read-only, and one write-only memory region in which case multi threading becomes trivial. If you have more complex, tree like data structures in the background, where possibly EVERY iteration could modify the root element (as changes could cascade), you are screwed.

Spring is not making heavy use of such structures, so it much easier to parallelize, but in that comes at the cost of slowing down by a massive factor if the map size or the unit count exceed certain limits, no matter how many CPU cores you throw at that problem.

PA uses a lot of such data structures for various purposes internally, as it is necessary to make the game scale properly with arbitrary numbers of units. Without these, PA could easily scale to as many core as you want, but at the cost of CPU usage exploding in square with the number of units in game.

So you have to choose: Good CPU utilization, but the game will still top out at 5-10k units in total even on high end multi socket systems while hogging the entire system, or heavy dependency on single thread performance, but in return the number of units possible will scale approximately linear with available single thread performance.

If anyone knows how to write a thread-safe spacial DB which yields at least the same performance and efficiency as Ubers current data structure, go forth

Wow this looks awesome, at last another rts to get exited about just hope the game play is more sup com rather than c&c x10.

Thanks so much for posting this squishypon.

I'ts great to see the pc starting to reach it's full potential and such a shame human resources was cancelled. Imagine what could have been, now that open gl is getting multi threaded lovin like dx12...

And they probably could have fed those improvments into Pa, seeing as they were going to use the same engine...

Found this on u tube..mind blown!!

That's the star swarm demo for the nitrous engine. Have you found any confirmation that there's a game being made based off the demo? I couldn't find anything based on a quick search.

https://forums.uberent.com/threads/ashes-of-the-singularity.68182/