[Will]

It would not actually be too much of a problem structure-wise to get most games multi-threaded. For example, SEV; instead of each AI processing its turn in order, just spawn a thread for each AI, and have each work on its processing at the same time. For combat, spawn a new thread to resolve the combat, and continue processing other parts of the game.

The issue isn't with games not having multiple threads in mind at the design stage; the issue is with actually writing the games to exploit multiple threads WITHOUT concurrency bugs. A FPS-type game is fairly natural with two threads, one to update the game state (player input, monster movements, etc), and the other to read the game state and do the appropriate rendering on the screen. This avoids the issue of concurrency bugs because it doesn't really matter much if the renderer reads part of the game state before or after an update, since it will just render all over again in a few milliseconds. The combination of read-only and rapid looping means that programmers can use two threads with no trouble. However, when there are multiple threads that are reading AND writing state, there become issues. They are issues that in principle are solvable (TSL, semaphores, monitors), but do not always amount to performance gains. Making code multi-threaded will ALWAYS add overhead to the process, and often that overhead will exceed the gains from having multiple execution units. And since some things will always need to be processed serially instead of in parallel, there is a limit to what multiple cores can accomplish. That's why the most performance gains you will usually see from doubling processing cores is 50%, and sometimes you will see performance hits. That's why it is not worth shelling out cash for a quad core in the current environment.