We can see RTS interfaces as a communication mechanism. You communicate to your units your intent. You can relay intent at many different granularities. Fine-grained intent could be queuing up a series of move orders, then precisely telling your unit who to attack and for how long once it finishes moving. Other games, like the Paradox grand strategy game series Hearts of Iron, Europa Universalis, and Victoria, give a far more abstract view of war, where the player gives broad orders to his units. Usually such orders would be simply to move to another province—if enemies are there, a battle will begin, otherwise the unit stations itself in the new province. The grain of control is usually what we use to differentiate the tactical from the strategic when discussing RTS games.
Much like MMORPGs, RTSes have seen parts of their acronym misused and misunderstood. The “S” does not (at least in practical usage) refer to strategy in the military sense—strategy meaning military planning that sees individual engagements as the atomic unit. Very few RTS games work at above an engagement-level, and so are more fit to be called tactical games, at least by the military definition. The “S” apparently does not refer to the military definition, though: it refers to planning being a inextricable, central component of gameplay. This is the only definition that seems to hold true to the genre today.
But planning cannot itself a game make. Strategy games are engines that compare plans. The plan is communicated to the engine by the player manipulating the game’s interface. So often strategy games have incorrigible interfaces because a depth of communication about specialized concepts is necessary—and the player probably does not go into the game understanding these concepts. Concepts implemented in the game may also not map closely to concepts in real life for various reasons, including weaknesses in simulation and insufficient or excessive granularity of control. Sometimes games represent concepts that do not actually map onto any real-life experience at all; communicating the use of these concepts is doubly difficult.
The quality of an RTS game hinges on the ability of the game to interpret a player’s commands to reproduce her plan in the game’s engine. The game must give the player an appropriate set of commands, and allow the player to use these commands in a sensible way. The player needs to see how the commands can be combined to produce aspects of their plan—the player will need time to learn how to do this even in the best of cases, but some games either do not expose the necessary commands to sufficiently implement appropriate planning, or they so confuse the player in how they expose commands that the player cannot figure out how to use the commands to accomplish even relatively simple tasks.
An RTS's interface should aim to make communication as easy as possible. If a player needs to click multiple times and press several hotkeys to communicate a relatively simple order to his units, that is a flaw in the RTS. The common measurement of user activity in RTSes, Actions per Minute (APM), takes on an odd character now that we have brought to light the critical role of communication in RTS games. A well-designed interface for a specific game’s mechanics would allow the player to communicate his plans to the game with such facility that APM, above a certain level achievable with a modicum of experience with the interface, would be unimportant to how well a player plays. Instead of physical keypresses and mouse-clicks being a barrier to plan execution, the mental act of planning becomes paramount. It follows from this discussion that a great RTS rewards mental APM—the ability to create and adapt plans—more than it rewards rapid clicking and hotkey pressing that characterizes physical APM.