A google search for "rts engine schematics" turns up a few relevant hits.
ORTS:
Stratagus:
These might not necessarily be the best examples of code design (I haven't looked in detail), but by looking at them you should be able to pick up a few ideas - both on how to structure your code and how NOT to structure your code. Lessons on structuring code will also come with more experience.
To answer your questions:
- The name of the logic that manages units is basically irrelevant; there are multiple ways to do this, and often this kind of logic transcends the genre of the game.
- In general, the simpler the multithreading system, the better. If it helps you to reach your target frame-rate on your target platform, then thread your systems.
- Yes, if you're targeting multi-core systems as your min spec. Most modern PCs and consoles will benefit from task-level parallelism, but often that can introduce latencies depending on how granular and dependent your tasks are.
Most RTS game engines will have similar structure to other game engines, both in terms of unit management and multithreading. The difference in engine would be reflected based on the specific differences in the RTS genre versus other genres.
There is too much information to cover here, but here are only a small number of characteristics of an RTS that would reflect the engine and content evolution:
1] RTS games are played from top-down view. This means a visibility system (occlusion and/or sector/portal) is unlikely to be worthwhile. Artists can spend more time adding detail to the top and sides of objects than the bottom.
2] RTS games are mostly played from a fixed height. Firstly, this typically means you have a limited range in which action is happening. In other words, a Level of Detail (LOD) system based on distance from camera is also probably not worthwhile. The artists should be able to produce assets that are optimally detailed for the camera height.
3] Units in RTS games are not controlled directly, but are controlled by sending commands to them. A higher latency between when the command is received and when the unit is executed is more tolerable to the user in an RTS game than in an action game. This is a desirable property because most RTS games operate in a networked environment which often has to handle the inherent latencies of the network.
4] Often, there are many units of the same type on the screen at the same time. This means that a system for batching/instancing for objects is likely to have benefit.
5] Often commands are dispatched to groups of many units at the same time. This means that any path-finding, navigation and obstacle avoidance logic, and acceleration data structures can be shared between individual units within the group.
