Sunday, April 25, 2010
Saturday, April 17, 2010
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.
Tuesday, April 13, 2010
Saturday, April 10, 2010
Post volume has dropped here. I’m busy playing games and not having much to say about their design. MMORPGs are boring games for me now, of little interest in any aspect. I’ve been looking for work, which has eaten a surprising amount of time, while also holding an editorship at a smal independent literary journal. My time has been eaten and my interest in kvetching about design has waned.
I’ll probably post once a week or less for a while as my motivation and interest is lax.
Sunday, April 4, 2010
To solidify some of the ideas presented here, I have decided to make public my design process as I design a game. The game is tentatively titled “Mage War”. It is a short, replayable game of strategy.
Here’s a sketch of the skeleton.
In one sentence: In Mage War, two ancient wielders of arcane power warp the very world on which they battle in order to tap greater amounts of magical power and eventually trap their opponent and forever strip from him his magical capacities.
- The game is turn-based.
- The game plays out on two tile-based maps simultaneously—these maps effect one another throughout the course of play.
- The terrain map is your standard map of hex tiles that represents mountains, forests, plains, etc.
- The mana map represents what mana can be pulled from each tile. Mana veins run along some tile boundaries, from these mana veins mana is replenished to nearby tiles more rapidly. The kinds of mana present in a tile depend on its terrain map contents.
- Mana veins have an intensity, and only mages that can harness a certain amount of mana can cross veins of high intensities.
- Mana is an exhaustible resource and can be entirely stripped from a tile if there is no nearby mana vein.
- In order to cast spells, the mage must move in the mana map and collect the appropriate amount of mana, though each turn the mage must start his mana map movement from the tile that corresponds to his location on the terrain map.
- Mana veins can be manipulated later in the game through the use of meta-mana that accrues to each combatant on the same regular schedule.
- Magic is used primarily to alter terrain on either map in an attempt to trap your opponent or starve him of mana.
- There are two ways to trap your opponent, once your opponent is trapped and you’re within casting range of him, you can strip him of his magical powers and win the game.
- Raise armies of immortal warriors from the villages that dot the map and position them such that the enemy mage cannot move next turn.
- Manipulate the terrain of either map in such a way that the enemy mage cannot move.
- Mages themselves cannot be harmed by magic. Casting a fireball on an enemy mage’s square only burns the terrain, it does not do damage to him.
I will be more specific about individual mechanics in future posts (as I design the game further).