I know you need an understanding of how every piece of the code interacts with every other piece, whether that be an individual or collectively. Collectively makes it even more difficult, and that's the more likely scenario here since it wasn't designed with a multi-threaded infrastructure in the first place. Every piece would have to be analyzed and re-fractored into a thread-aware, thread-safe version. At a minimum. It could be that it's simply not possible without rewriting from the ground up. Right now, every frame gets taken care of linearly. You do some physics, some graphics, some scripting checks, and each of these happens in a pre-defined order. They all have been coded with this assumption. You take that assumption away, and all hell will break loose. When you have graphics and physics and scripting all trying to do their own thing independently, and report back to some master process, it would probably be ugly right now. And that's just one method of how to break it up. The very howto of multithreading a game is still up for debate. What gets its own thread? With a game like this it's especially difficult. Is it even worth multi-threading? Is there enough overhead on all fronts to warrant it, or is it mostly graphics these days? The other areas, physics, AI, etc, are old, and probably eat up an insignificant amount of a modern cpu.
