Classing up turn-based games, part 2: Defining state and input classes

In the past I've sorta covered (i.e. mentioned) the notion that classing gameplay types is more important than classing game types (I really don't remember when I said that and it's not worth my time or yours to look it up). As I haphazardly introduce classes of state progression and input mechanics, keep in mind that these rarely will apply to 100% of the content of a game and certainly don't mandate anything as high-level as genre. Two games in the same state progression class may be in a different input mechanics class and a different goal/opposition class and a different origin class and etc. As mentioned in Part 1, we're looking for a middle ground for relativism, where everything isn't completely different, but everything isn't completely the same*.

*plus ça change, plus c'est la même chose.

State Progression

By state progression I mean "the realization of time", or what governs when the game variables (collectively, the "state") are evaluated and updated. I could probably churn out something slightly more formal but the classes can probably speak for themselves. Differentiating "game state" and "interface state" is outside the scope of this piece, but basically take "game state" to include any variables that have a direct relation to the outcome of the game (i.e. stuff like player health and position and not stuff like cursor position (unless this is Knights in the Nightmare)).

In a real-time paradigm, the game state is evaluated and updated independent of player input. Basically this means that the game will progress at the same rate whether or not the player's controller is plugged in. Having a "pause" function which halts all progress does not disqualify a game from being considered real-time, because the pause function switches evaluation to a separate state paradigm which follows its own rules.

In a turn-based paradigm, the game state is evaluated and updated only when triggered by a defined player input. A pause-command function does not guarantee a turn-based paradigm because exiting a pause state does not necessarily trigger state progression. It is necessary to the notion of turn-based paradigms that the player input for progressing the state is isolated and known. Enemies changing attack patterns at random intervals doesn't guarantee the game is turn-based.

KEY NOTE: Real-time and turn-based are not necessarily the only classes of state progression. I intentionally give them separate definitions rather than saying "turn-based is the opposite of real-time", because there's clearly flex room - delays, bullet-time, and timed turns are just a couple examples off the top of my head of ways to split the real-time/turn-based atom. Just the speed at which states progress and any customizability therein can provide countless subclasses.

Input Mechanics

Moving on to input mechanics: the rules of the interface through which the player is permitted to influence the game state ("mechanics" being the rules for an interface and "input" being the system of accepting player influence [it's kind of obnoxious to define "input" - Ed.]). Also important: an action is an externally initiated change in state.

Action mechanics execute individual game-state-dependent actions specified by the player. The game state determines an input mapping; that is to say, the same input in different states may map to different actions, while the same input in the same state will map to only one action. Essentially, action mechanics let the player do things but only at the right time. The player is required to structure inputs such that they will have the desired effect on external states.

The most significant follow-ons from this are that action inputs tend to be layered (e.g. the player must be running to roll, requiring an analog input to put them in "running" state and then a button input to "roll"), interdependent (e.g. the player must be locked on to strafe and can only strafe when locked on), and order-sensitive (e.g. aiming first and then shooting is going to be more effective than shooting first and then aiming).

Tactical mechanics execute a (series of) action(s) determined autonomously to reach a game state specified by the player. Inputs are mapped explicitly to outcomes regardless of the current game state. This doesn't mean that commands are deterministic; only that the evaluation criteria is (i.e. an attack can still have a 10% chance to miss, so long as that's an independently calculated property not dependent on additional player input). The player may need to anticipate what actions will be executed in reaching the desired state, but generally will be more concerned with simultaneously tracking game states. Tactical mechanics allow the player to chart out a sequence of events.

The first implication here is that the player has either a guarantee or a means of evaluating what the effect of their input will be. Indicators, numbers, words - some kind of abstract interface is almost necessary to facilitate tactics (that doesn't necessarily go the other way - just because a game has life bars and damage numbers doesn't mean it uses tactical mechanics).

It's all pretty self-explanatory really; action and tactics are what you expect they are. In an action game you can miss an attack by pressing a button too late, in a tactical game you'll only miss if you roll a 1.

KEY NOTE: While action and tactical mechanics are mutually exclusive (if actions are being determined autonomously the player can't be individually instructing actions...), they can easily co-exist. Pretty much any traditional JRPG where you walk around with an analog stick (action) and then issue orders from a command menu (tactical) demonstrates that. Even further, it's not uncommon for a game to offer both options for the same mode - direct your party around with stylus taps (tactical) OR use the d-pad to walk!

Input Buffering

Speaking of menus, there's one more characteristic to consider - the input buffer. An input buffer is any game component that accepts player inputs without immediately applying them to the game state. Generally speaking, something's probably wrong if the controller itself is buffering input - when the player presses A they tend to like seeing an immediate result. This is more like command menus that accept player input solely for the purpose of browsing potential state-altering inputs. AI scripting and input delays are two more examples of buffering, so long as they offer a split between choosing a command and executing it. 

While buffers more naturally complement tactics (due to the potential for input evaluation and an extended list of commands separated from game state), they are not exclusive to one type of mechanics or another. Hotkeys and point-and-click allow tactical PC RPGs to circumvent input buffering, while button-based action controls can easily be transposed onto a menu (as somewhat depressingly demonstrated by smarthphone touchpad-only ports).

We could certainly class games by buffer type, though it does seem a bit superfluous.

Now

God that all got way hairier than I wanted. Maybe it makes sense if you haven't been staring at it through eight million edits like I have. Hopefully any ambiguities will be cleaned up with some examples/applications, courtesy of Part 3. Yes, we'll take to the streets and take on Final Fantasy XII, Chrono Trigger, Dragon Age: Origins, Xenoblade Chronicles, and many, many, many more.

Take this fun fact home to mom: for the purpose of this theory article I changed my formatting scheme to bold key words and italicize titles. Normal articles don't have key words so it isn't a conflict.