Multi-Process design causing many of the issues reported.
Ok well I found the main source of multiple reported bugs here. There is a reason you don't see most games do this because its poor back-end design. Spawning threads off a single process is messy enough to keep track of. Forking the entire process is begging for desynchronization.
You guys appear to be using a third party library as can be seen from the screen shots I will link.
Watch for the master game process and 3 different GUI processes. That means whatever process starts the game is forking 3 additional processes. Spawning threads is perfectly reasonable and much lighter weight then forking entire processes just to use a third party library. The game's core issues will only be fixed by a a complete rebuild of the GUI from the ground up OR a port to a game engine that has the functionality built in. Best guess this was a cost and time saving measure and although I cannot blame them for the decision being made, it harms the game's ability to scale up within its dimensions and does warrant valve offering a refund to players (I won't be doing it myself but if some people bought the game to play large scale games and feel like they should wait for the game to be re-designed then there is a reason to do this).
The very next patch to this game (a hotfix) needs to have an option to force each process to synchronize with a universal lock across all active processes to avoid desynchronization along with another option to force this lock to be cleared with the host even if it means inducing frame rate jitters followed by an eventual re-build of the game to a single process design with spawned threads rather than forked processes even if that means eliminating the 3rd party GUI. Also might be wise to put the AI on a priority queue with starvation as that would help the game scale much better then it currently does. Also if some way can be found to allow many or all of the AI calculations for a player to be done client side the game can be scaled up even further.
See images below:
1x instance of "WFTOGame.exe"
3x instance of "Coherent UI - A Modern User Interface Library for Games"
System:
-Win 7 x64
-AMD 8320 8-Core
-8GB RAM
-AMD 6950
-No SSD
-All drivers current.
Tweaks attempted:
-Allocated all WFTO processes priority to "high".
Suggested tweaks to further identify issue"
-Attempt 2 and 4 core affinity to force processes to share same L2 cache. If the game, on average, scales slightly better under these conditions over several tests then it strongly indicates that the issue is caused by latency associated with inter-process communication. Conventional software engineering wisdom strongly enforces the idea that this situation should be avoided at all costs and even more so with programs that can suffer issues with latency.
This is not a bug.
Coherent UI is our UI middleware which does allow us to code UI in HTML.
To achieve this it is using the chromium engine which runs as host process to render the UI.
This is nothing we do on our end but the way this middleware works.
The game code it self and unity engine uses threads and does not fork entire processes dynamically.
What you suggest is already done, the AI acts as coroutine, but is also no real bottleneck of the game.
I agree that using threads is more lightweight and the way to go to implement asynchronious tasks
but the Coherent UI processes have the same lifetime as the game process and it does not fork repeatedly at runtime.
Since the CoherentUI_Host is a server written as external program made in a different language it is required to run as a process and it can not share memory with the game process.
However, we can not change the way Coherent UI works we are just using it.