It would be interesting to know what is the main thin that slows down the game... my games usually slow down to 4-5 seconds and stay there for a rather long time. I don't think this is an issue or anything just would be interesting to know for future optimisation what is the main thing that slows down the game?
Movement orders is the greatest time-sink.
I'd like to take a crack at mentioning a possible solution, this will be completely bastardized since I have no familiarity with your code whatsoever. And by possible solution, I mean a relatively vague example of threading described in terms of movement orders.
This assumes that movement orders aren't inter-dependent to eachother, which as far as I know is true.
You could concievably set up worker threads that look at a
thread-safe queue of movement order tasks (objects describing the movement order and maybe including a pointer to where to write the results of the calculation) and give the threads the ability to insert the results of their calculation into the appropriate destination (hard to say what that would look like exactly). Thread safe task queueing is a relatively common multithreading technique. You don't really need to worry about the timing of the threads since the game is turn based so you can just wait for all of the threads to finish before going to the next queue item.
In this case 'worker thread' would be a function
(threadProc in this example) that takes a pointer to the task queue as a parameter as well as pointers to any other info it would need access to in order to do the calculation (pointers to variables containing info about the world for instance). Most C# objects support concurrent reading, so generally (emphasis on generally) you would only need a thread-safe task queue for the threads to pull jobs out of until they see that the queue is empty. This also assumes that the final destination of the calculation results is not going to be getting hit by multiple threads, which is usually reasonable when you are doing a bunch of serial calculations (normally they aren't overwriting eachothers results).
Even if you don't use this for anything, I rather suggest playing around with threads in general, because while you are right that generally threading is pretty dangerous, this might be an exception. Usually threads are particularly problematic when they are running continuously and are directly interacting with eachother in a manner where timing is important and whatnot. In the turn-based context, you can usually just wait for all of the threads to finish working (in this case you could loop over the list of active threads and call .join() on all of them, which is a blocking call, so doing that will in effect wait until each thread is finished before the code moves on).
By the way I am just trying to share some information, I am actually a software developer so I am not blowing smoke up your ass here, I just wanted to mention the above since it seems like you might be overestimating the difficulty of threading in this case (but also maybe not depending on how the code works/how much you already know).
Apologies if you already knew all of this, or of the movement orders themselves are inter-dependent (which would also throw a huge wrench in this).
