Disclaimer: I'm first a programmer and then an RTS gamer. This means I'm a complete and utter newb in terms of patterns, best practices and glossary of technical terms on the game dev world.

Since I was a kid that most of my electric/electronic toys were always taken apart to learn how they were made and most of the pieces were stored for future use.
This gave me a VERY curious mind in terms of: How does it work?

I've started planning/scribbling for more RTS games than the market has dished out, but never got around to implement any of them due to the lack of basic knowledge about Game Devel.

So what I'm asking is that someone could point me in the direction of the engine schematics of an RTS game like SimCity/Civ/Settlers. Something that will assume a bit of programming background but will introduce the terms used for programming a RTS base game.

  • How do they do the Unit Manager? Is it called this way?
  • Is creating a complex multi threading system wise?
  • Should I use multi-threading just for groups of units?

Well, I think you get the picture of how newb I am ;)

Many thanks in advance.

  • 2
    \$\begingroup\$ It may help your various searches as you progress to know that SimCity is generally considered a Simulation game, not an RTS, and that Civilization, as a turn-based and not real-time game, generally won't be considered an RTS but just a Strategy game. \$\endgroup\$ Nov 4, 2010 at 2:21
  • 2
    \$\begingroup\$ -1. There are too many questions here, most unrelated to the title question, and "How does an RTS engine work?" is probably too general to answer other than by "here's an RTS game's source code". \$\endgroup\$
    – user744
    Nov 4, 2010 at 15:29

1 Answer 1


A google search for "rts engine schematics" turns up a few relevant hits.



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.

  • 1
    \$\begingroup\$ This has to be DE most complete and desirable answer that a newbie to game dev could've wished. The amazing thing is that you made it possible !! Many, MANY thanks!! \$\endgroup\$ Nov 4, 2010 at 23:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .