Introduction

One problem facing game designers today is that there is no commonly held theoretical basis to their craft. This has not stopped great games from being created: designers don't need theory to design games any more than children need a knowledge of grammar in order to talk. But a theoretical base would have considerable advantages: communication would be easier, common mistakes could be avoided and designers would have an analytical framework and set of tools at their disposal. There is no consensus on even the most basic theoretical concepts, such as game and gameplay.

The term “gameplay” is ubiquitous throughout the games industry: everyone uses it on a daily basis. The term also has considerable reach beyond developer jargon: hardcore and even casual gamers are increasingly familiar with the term through game reviews. Most people could agree on a rough definition along the lines of “the gamey bit of the game”. But disagreement will quickly arise as to what gameplay actually is, what its elements are, why one feature contributes gameplay and another doesn't.

Rather than working towards a definition, this article develops a theoretical model of how gameplay works in practice. The model is abstract and aims to be universal – applicable to any type game – not just video games. Its starting point is that gameplay is a property of all games and is a set of interactions between the player and the game. Although gameplay is something that is normally ascribed to a game (“Game X has great gameplay”), the model is focussed on the player and the player's actions. If a game remains boxed, then there really is no gameplay: only when it is linked up to a human agent is there gameplay.

The model contains only two components – the player and the game. The player is a human who has elected to play. The game is a system that the player interacts with - crudely speaking, everything that is not the player is part of the game, including other players. All information about the game is conveyed to the player through clearly defined output channels and all the player's actions in the game are carried through clearly defined input channels.

Gameplay occurs when the player interacts with the game. But in this model, the interaction is not random, it is a flow of information from the game to the player and from the player back to the game. The interaction is circular – the flow is always in the same direction and no stage can be missed. The simplest graphical formulation of the model is shown in Fig 1.

Even when applied to a multiplayer game, the model uses only one player and the game. The game can be seen as a system that encompasses a large number of internal processes and states, some of which may be human. If a full analysis of a multiplayer game is required then it may be necessary to do multiple applications of the model to the same game, something which is quite intuitive: a goalkeeper's gameplay experience differs significantly from a midfielder's, for example (or a pitcher's to a batter's, if you like).

The Player and the Game

Our model is really too simple to be of use to anyone in its current state. We need to start filling in the detail.

Three things must happen in order for there to be gameplay:

In addition in almost all types of game:

The player observes.

To engage in gameplay, the player must be able to observe the game. Observation informs the player's actions. Without observation the actions are meaningless. Imagine playing a video game with the vision and sound switched off. The player can still interact with the game: the game has no awareness of the player's sensory deprivation and will continue as normal. New game states will be arrived at, the player may make decisions which affect the final score, but clearly there is no gameplay. The player has no idea what is going on in the game, any actions they make are uninformed and effectively meaningless.

The player can affect the game.

The player's actions must affect the state of the game. If the user of a system is able to observe but not to act then they are observing a system from the outside – they are watching a film, or microbes under a microscope. There is no interaction.

Snakes and Ladders is only suitable for toddlers because the player cannot influence the game in any way - there is no gameplay, only an imitation of interaction. The player appears to act by rolling the dice but the result is random and the player is compelled to act on it. At no point does the player make a decision. It's possible and not uncommon for players to take goes for each other without any affect on the game.

Snakes and Ladders could easily be improved as a game for adults (I dimly remember that it's quite exciting for toddlers as is). We could introduce a second die, for example. The player rolls both and chooses one as a move. This seems like a trivial choice but in fact with the right balance of snakes, ladders and empty squares this could provide quite compelling gameplay as the players play the odds. With this single change in the rules, player influence is introduced and there is gameplay.

New game states restart the cycle.

The model cycles. Gameplay is not a one-off action – it is an activity. The experience is one of repeated interactions by the player. Usually there are a relatively small set of interactions that are repeated many times, each time slightly differently or combined in a different way. In a racing game, we repeatedly steer, accelerate and brake. Tennis players repeatedly hit the ball with a racket. In a platformer, players walk, run, jump, shoot, collect.

The changing state of the game constantly prompts new actions from the player. The gameplay typically goes through many cycles of observation and action until an arbitrary endpoint is reached – a fixed time, a certain score, an objective reached. (Games are an activity designed to take place over time: therefore the end points of all games are always arbitrary – we could always play for longer, to a different score, reach another objective.)

When the cycle breaks down, there is no gameplay.

Why does the cycle sometimes break down? It could happen at any stage of the cycle and the model prompts some areas which can be examined. But the most common is that the new game states are not sufficiently interesting to keep the player's attention – the player has been in similar situations before, or the game is too easy or dauntingly difficult. The skills to capture and maintain a player's interest are well out of the scope of this article. It's enough to say for now that unless we can hold attention then there will be little gameplay and the player will stop playing.

The game creates its own states.

It's very typical for new states to be created by the game itself. This can sound counter-intuitive for some games until we remember that this model forces a single viewpoint: other players are part of the game. The internal system by which chess creates its new state might be a second human player (who can have the same model of gameplay applied to them) or it might be game AI choosing the move. From the player's point of view – in terms of the gameplay – this is irrelevant. What is relevant is that a new state is created. (In terms other than gameplay, whether the internal system is human or machine is highly relevant).

If the game doesn't create states, if new states are only brought about by the player – then what we have is perhaps more properly a puzzle than a game. The player is entirely in control of events, though the consequences of actions may not be immediately apparent.

As well as through other players, new states can also come about through random number generation– machine generated, the throw of a dice, the spin of a bottle. Or through a pre-ordained order – as when a new card is drawn, or in alphabet based games (“I love my love…”) for example.

As a generalization, the new states generated by the game will offer a greater incentive to act than the new states created by the player. The confrontational nature of most 2-player games is set up to force the players to repeatedly act, each trying to create a state of advantage to themselves.

Better Model

We can now create a new diagram showing this level of detail (Figure 2). Note that the player and the game are separated by an interface layer consisting of an input and an output. This is very easy to understand with video games where the input and outputs are objectified. The interface is less easy to conceptualize in board games, and much more difficult in games like football. It's important to show the interface in the model because often gameplay problems (of the player not observing the game properly or of the player's actions not affecting the game state) are problems of the interface rather than the game mechanic. We need to recognize that the interface is part of the cycle, and is not unproblematic.

Skills and Decisions

What happens between observation and action? So far we have treated the player as a black box with observation and action as the interface between the player and the game. Now we want to enter the player's head. For each game, the path from observation to action will be radically different – but on the simplest and most abstract level, key processes emerge.

Somewhere between observation and action, the player makes a decision, even if it's a decision to do nothing. We are striving for simplicity here: of course the gameplay may not break down neatly into a series of regular decisions, or multiple decisions may be made at once, or the player may not formulate a clear decision. But, for the moment, we'll press on with the simple idea that before an action is taken, a decision is made.

At the heart of each gameplay cycle is the player's decision – and for simplicity –we will insist that each cycle of the model contains only one decision. A key feature of gameplay then is that the player is repeatedly making decisions – something seen in all games of all types from GTA through to Doctors and Nurses.

The idea that games can be analyzed as a series of decisions isn't new (it has been outlined well here here) but it doesn't provide a full analysis. A decision is in a sense nothing – something which takes up an infinitesimal amount of time. It is a change in the state of the overall intent of the player. The change is discrete and instantaneous. So it is productive to ask what happens between the observation and the decision and between the decision and the action. The answer is that the player uses skills to support the decision.

Between observation and decision, the player uses analytical skills. The player's analysis of the current and potential future states of the game inform the decision. The player tries to work out the best course of action. This may be relatively simple (racing games) or extremely complex (chess), or anywhere in between, depending on the type of game. At the end of the analysis stage, the player makes a decision, which may be confident or a guess or instinctive or the player may fail to act where a decision was possible, much of which depends on the player's skill to analyze the situation. The skill supports the decision and it is the player's skill which is being tested. As a rule of thumb, strategy games tend to test the player's analytical skills, their reading of the game situation, and their weighing up of the options. Therefore decisions are important in strategy games because they constitute the test of those analytical skills.

After the decision has been made, the player uses another set of skills to implement the decision. Anyone can make a game-related decision (“I will shoot at the goal”), but the skills required to bring that decision about are what sets the good player apart from the bad. As with analysis, the skills required may be simple (most strategy games – where the implementation is designed to be trivial or totally invisible) or complex (a racing game). As a very rough rule of thumb, action games tend to test the player's implementation skills. But this is not as clear cut as with strategy games because action games also look to analytical skills as a way of providing depth and variety.

We can now create a complete diagram (figure 3).

Each cycle has only one decision and implementation within it. In the case where many decisions are made at once, the model may be applied many times to the same timespan of a game, isolating different elements at each application.

Example: Burnout

Let's take a break from abstract theory and see how the model can be applied to an actual game – our example will be the Burnout series (specifically Burnout 3: Takedown - which I happen to have on hand). I've chosen the Burnout series because the gameplay is generally very good and the developers have continually added elements to the game which take it further from a traditional racing model. The model we're developing can help us analyze and understand why these gameplay changes might have been made. We'll look at a typical scenario in a race, where the player can either speed past an opponent or try to take him out, looking at each element of the model and identify what they correspond to in this situation.

Output: Burnout has traditional video game outputs – the screen, speakers and rumble-pack. All the player's knowledge of the current game state comes through these output channels.

Observe: The viewpoint is a camera just behind the car, giving the player a full view of the road ahead. In addition, the player is given a traditional game HUD, showing their speed, race position, boost bar (a critical gameplay element) and any other relevant information to the game mode. Opponent's cars are additionally highlighted and the player is shown pop-up text relating to in-game events and player behavior. Overall, the developers have strived to ensure that anything that is important to the player and has an impact on the player's analysis of the game state is clearly visible and highlighted.

Analyze: When analyzing the game state, the player will try to assess their likely success of pulling off a successful takedown, the overall state of the race, how far they are from the finish line, their race position, how much boost they currently have, what other traffic or environmental obstacles are around, whether there is a better stretch of track for action just around the corner, etc.. Clearly there is too much information and uncertainty for the player to be able to make a definitive analysis: the assessment of the risk and reward will be incomplete.

Decide: The player has a very limited amount of time to make a decision based on their analysis. For the sake of this example, we'll say that the player decides to take the opponent out.

Implemen: Attempting to carry out the decision, the player waits for the opponent to begin turning a corner, angles the car into the opponent, applying boost at the last minute and as the opponent crashes into the wall, straightens up to continue on his way.

Act: The player's actions are the actual movement of his thumbs and fingers on the keypad.

Input: The game input is the actual movement of the joysticks and buttons on the keypad.

The Game State: The game state in Burnout comprises details (including position, velocity, boost) of the player's car and all opponent cars and of all non-opponent vehicles.

Game Internal Systems: As we have seen, new game states are brought about by the player's actions. But new game states are also brought about by the Game Internal Systems. In Burnout's case this includes either opponent AI or by the actions of another player or players, but it also includes physics systems like gravity.

Interesting observations arise from the analysis provided by the model. We have seen that if the cycle breaks down for any reason, then the gameplay stops. The original Burnout featured what was then cutting edge crash sequences as the cars crumpled and twisted under realistic physical forces. This was an eye-catching and exciting feature. However it also quickly became irritating: the player's actions had no effect on the game state during crash sequences: there was no gameplay. In Takedown, the player continues to “steer” the car after a crash by adding aftertouch. Clearly this nonsense in terms of realistic car physics but it ensures that the player is kept in the gameplay cycle while still being given the eye-catching brand signature of the crash physics.

The Scale of the Cycle

The model we have developed is best understood first time around using a turn-based game such as chess. Here the analysis, decision and implementation are obvious and clearly demarcated. There are no overlapping gameplay cycles and the game itself has clearly separated phases. When analyzing a real-time game (like Burnout) things are more difficult. The model is a deliberate simplification, an order imposed on a complex system by the model user, who must make a decision about the most useful scale to apply it at. However, in many cases an obvious cycle will suggest itself. One has only to ask what sort of decisions the player is making to see the scale of analysis and implementation required – once you are thinking like the player or being the player, then the cycle is obvious to see. It has to be – the cycle is what the player is getting out of the game. In games the cycle is foregrounded – it's the reason for playing. Imagine a player commentating on their game performance to get a good idea of the scale the cycle should operate at – in a real-time game it gives the granularity that we need to work at. Like us, the player is trying to impose an order on the complexity of the game, and the model we are developing is centered on the player.

A couple of examples: when playing Street Fighter, the cycle is on the level of the button press. The player attacks, analyzes the response, and either attacks again for a combo, defends or backs off. Sometimes a series of button presses will be pre-planned, but the model is flexible enough to cater for this. We are interested in the player's intent – not the mechanics of the game. In a Tony Hawk game, the gameplay cycle is on the level of the trick – the player thinks in terms of moves which are pulled of with a series of key-presses. In a game that involves stealth, the scale of the cycle will often be below the level of the button press – as the player waits for other game elements to move into predicted positions before acting. While waiting, the player is constantly re-analyzing changing game states and making adjustments where necessary.

The unit of interaction

Because of its fundamental importance to this model of gameplay, we will call a single complete cycle, starting and finishing at an arbitrary point, a unit of interaction. Each unit of interaction requires analysis, decision, implementation and change in game state.

What is the ideal length of time for a unit of interaction? Clearly that depends on the game. And the model we've developed is descriptive rather than prescriptive but it can offer suggestions as to possible lines of investigation.

We have noted that the player's interaction passes through 2 distinct stages of analysis and implementation separated by a decision. A good rule of thumb would seem to be that the ideal time for the unit of interaction is the amount of time the player takes to analyze the game state and implement an action in response. The decision takes no time – it simply marks the end of the analysis stage.

If the length of time for the unit of interaction is greater than this – say because the game requires some time to produce new states independent of the player (either through required processing time or waiting for other players) then the player has downtime in each cycle. The downtime will either be before the analysis phase – the player waiting for the new game state to become apparent before they can start their work of analysis - or before the implementation stage, where the player has an action ready but must wait to implement. Either way, time when the player is not doing anything opens the door to boredom and frustration.

On the other hand, if the unit of interaction is too short then the player will not have enough time to complete both phases. This is likely to result in the player not implementing the action successfully and being punished by the game as a result – which is not a good thing. Or, as they adapt to the speed of the game, analyzing quickly but making sure they complete the implementation successfully – playing on their wits – which is usually a positive state for the player to be in. Since players analzse and implement at different speeds, each player will have a different ideal length of time for a unit of interaction. But it's probably true to say that novice players of a particular game have a more varied range than more experienced players who have been trained to analyze the game state and are accustomed at implementation.

Changing the period of interaction is a useful tool at the designer's disposal. Forcing a short period of interaction – shorter than the ideal for the average player at that stage of the game – forces the player to cut out the analysis and play on their instinct and to be less conservative in implementation, taking more risks. Lengthening the period of interaction gives respite and can create tension.

The model as a problem solver

As has been stated, this model is descriptive. It's an aid to analysis – and when it starts to fail, a more complex model or a model with a different base may be more applicable. Also it's an atomic model, describing gameplay in a stripped down and possibly obvious way. It's core purpose is as a building block from which to construct larger scale and less-obvious theories of how games work.

We know a game isn't working when we play it or play-test it and the results are not to our liking. We shouldn't rely on any gameplay model to tell us whether gameplay is good or not. But if the gameplay is not working properly then the model gives us a set of things to check by going through the phases of the gameplay cycle.

Is the game output giving us enough information to analyse the state of the game correctly? It's an easy mistake in video games to hide from the player information that's of relevance to their decisions. A frequent complaint is that the player “does not know what to do next”. This is because their analysis has fallen short – it does not encompass the full state of the game – therefore they don't know how to proceed. Has the player been given all the information requiredto make that analysis? Has that information been presented in too oblique a way? Or has the player not learned to analyze the game well at that point and therefore cannot correctly use the information they have been given?

Are the decisions informed? After the player has done a complete analysis of the information given, do they have enough to know what impact their actions will have? Are the decisions significant? Do they have a large enough impact on the game state? In Diablo or other dungeon crawlers, players pick up a lot of crap – for want of a better word – of negligible but determinant value. You have a fixed amount of space in your inventory and eventually the player is forced to make a series of decisions about what to take and what to leave. Frustration arises when it becomes apparent that these decisions are taking up a considerable amount of time – and yet the sums of money involved are trivial. The decisions are not significant. They change the state of the game but the player gets only a marginal gain from dealing with them.

Does the player know how to implement a decision? Is the implementation too easy or too difficult? Does the player “fight the interface”, where an intended action is difficult to pull off because the interface has a mind of its own?

Are the new game states of significance to the player? Do they force the player to react? Are they interesting to the player? The model prompts us to ask the questions even though it doesn't always help with the solutions when the game is found wanting.

Is the period of interaction right? How long does it take to analyze the game state? How long does it take to implement a decision? Is there enough time to analyze the game state and implement a decision before the next game state is brought about? Is there too much time?

Summary

This article puts the case for the use of a model of gameplay which emphasizes both the importance of the player's decisions and their use of skills to support those decisions. The model also emphasizes the circularity of the gameplay experience. The player responds to new game states brought about by their own actions or by the game itself. The circularity creates regular patterns of thought and action in the player, who repeatedly makes decisions which are similar but unique.

In some games, the repetition and circularity of the player's decisions and actions produce very noticeable beats and rhythms – think of Tetris and the player's adjustment to the new speed as the game goes to another level. An alert designer will also hear the beat in less obvious examples – racing games, sports games and action games. One of the marks of a great designer is the ability to hear and then harness the power of the rhythms which arise from the gameplay.

____________________________________________________