Structural Specifications

Game structure is perhaps the most overlooked element of game design, but within the structure of the game is contained the capacity to frustrate or reward, to satisfy with meaningful choices, or to end a player’s engagement with an impassable bottleneck. In order to examine the structure of games, we need a common language to do so. The issue is non-trivial, and requires a specialised terminology. For several weeks now, I’ve been experimenting with a structural specification language that might allow us to explore this issue. 

Roots

This post follows from the following previous posts: 

• Play Specifications, which discusses the relevance of nouns and verbs to play. You should read this first if you are not familiar with the idea.
• Roger Caillois’ Patterns of Play, which links together six separate articles on related topics. Familiarity with Caillois’ terminology is recommended, but not required.
  
• Ratcheted Progress, which explains how the player’s achievements in a game are ‘banked’, either internally to the game, or via an external save file. Again, this is useful but not essential background information.

What would a structural specification need?

There are many elements of structure, so it is vital to consider which are the important aspects to pay attention to: 

• Identifying structural components is critical. How do we choose to break up a game into smaller segments? It will always be somewhat subjective. However, we can pick out Tasks (i.e. Goals, Quests etc.) as a key element.
• What about when the player is doing something without a specific goal? For instance, when they are just playing freely? Let us call these Activities.
• Once we have our basic components, the pertinent issue is how these Tasks and Activities are sequenced. Finding a means to express sequence of Tasks will be at the heart of any structural specification.
• How often do repeated segments of play recur? Some segments can be repeated any number of times, some repeat many times, some just a few, and others just once.
• Additionally, an inescapable aspect of structure is how ratcheted progress is implemented. When is progress banked (that is, the player is protected from repeating an already completed segment of play)? When is progress saved (that is to say, when is banked progress output to a save file so the player can resume play next time without having to repeat an existing segment of play)?

Addressing these five elements in a single notation would give us a powerful starting point for specifying the structure of games. 

Tasks

A task can be expressed in terms of a verb and a noun; these verbs are not quite like the verbs of a play specification. In a play specification, we are interested in what might be considered immediate verbs; i.e. verbs that refer to the player’s direct activities. In structural specification we are interested in verbs that relate to goals, what might be considered framing verbs. (Patrick Dugan considers these to be microVerbs and macroVerbs respectively, and I am grateful to him for buying me a ticket for this train of thought).

For example, consider these verbs and what they mean to a player: 

Collect                    collect noun, collect x nouns
Defeat                      defeat noun, defeat x nouns
Earn                         earn x currency
Survive                   survive x seconds
Find                         find noun
Cross                       cross noun (e.g. cross area)

These do not describe the players’ direct actions, but the goals being set. To really specify a Task, there must be both a noun and a verb – the verb specifies the type of Task being given, while the noun (and any number associated with it – also a noun).

Notice that each Task devolves to a basic sentence. This is the first time we have formed sentences in examining the specification of games. 

Notation: For the purposes of this structural specification we express Tasks as a simple sentence enclosed in square brackets e.g. [Collect 10 Keys]

Activities 

There are also things the player can do which are not goal-oriented. I have suggested calling these Activities; they are like partial Tasks in that they have a framing verb, but no nouns to turn them into a sentence.

In broad strokes, I suspect that most activities fall into the following general areas: 

Play i.e. engage in paidia
Act i.e. engage in mimicry
Watch i.e. enjoy the view!

As a concrete example, consider the Birdman mode in Pilot Wings 64. This has no goals! You are just asked to fly around, and enjoy the view. This could be characterised by the verb ‘fly’, denoting an open ended activity with no goals. 

Also consider cut scenes – in which the only verb on offer is watch (and listen).

Notation: Activities will also be expressed in square brackets, but as sentence fragments e.g. [Play].  

Additionally, those Activities which are one-off events and do not recur are expressed without brackets e.g. Briefing. These unbracketed elements are linked to other elements by using the spacing character ‘-’ e.g. Briefing-[Task].

In some cases, these one-off activities will recur with the Task that they relate to – as happens when the player is forced to sit through the same briefing every time they repeat a Task. Here, we have the option to include the one-time Activity inside the square brackets e.g. [Briefing-Task].

Sequence

Finding a sequence of Tasks and Activities is the core to understanding game structure. Do certain Activities precede certain Tasks? For example, in many games a Briefing comes before a mission (which can be understood as a Task).

Early videogames had very simple structures. For example, Nemesis/Gradius has the structure Level 1, then Level 2, then Level 3, then Level 4, then Level 5, then Level 6. Then, repeat on a harder difficulty. There is no variation in the sequence to which the Tasks occur. This could be expressed as:

[Cross Level1][Defeat Nemesis][Cross Level2][Defeat Nemesis][Cross Level3][Defeat Nemesis][Cross Level4][Defeat Nemesis][Cross Level5][Defeat Boss][Cross Level6][Survive Cage][Kill Brain]

This is a series structure – there are no parallel elements. (It is intended that this should be read as one long line with no carriage returns; sadly this sequence is too long for this to be clearly apparent!) 

However, modern games typically have Tasks and Activities available at the same time. For example, We ♥ Katamari offers ‘as big as possible’ and ‘as fast as possible’ Tasks in parallel. This could be expressed as:

Select Level-Briefing- [Earn Size]
                                             [Beat Time]

This is a simple parallel structure. The player must select a level, and sit through the incomprehensible briefing, then they have a choice of Tasks. (Of course, this is slightly simplified as the player must complete a mandatory Task before they get this choice, but structural specifications, like play specifications, are not intended to be perfect representations).

Because our focus in this endeavour is structure, we should in general resist the urge to decompose Tasks into their component activities, except when doing so is pertinent to structure.

For example, the Task ‘Defeat Colossus’ in Shadow of the Colossus can be broadly decomposed into sub-tasks: Solve Puzzle, Climb Colossus, Stab Colossus. But in structural terms, the composition of the global Task ‘Defeat Colossus’ is less important than how this relates to other global Tasks.

A key to how structure works is what alternatives are available to the player at any point.

Notation: series sequences are written on the same line, while parallel options are provided on separate lines, with the parallel options being formatted to line up with their alternatives.

Repetition

Related to the sequence of Tasks and Activities is the issue of repetition. Certain segments of play will repeat a certain number of times, or indefinitely. A structural notation therefore needs to represent this element of structure. 

Notation: the following format is used to express enumerated repetition:

  (# | [Task] )

Where # represents the number of repetitions.

Consider, for instance, the previously given example of Nemesis/Gradius, which with this new notational element can be expressed:

(6 | [Cross Level][Defeat Boss])

Notice how certain details that were given in the fully detailed version previous have been lost in this simpler version. We could preserve them, but since the goal of a structural specification is to get to the root of the structure, we should permit a certain latitude in allowing the finer points to be glossed over in favour of accessing the pertinent structural details.

Sometimes, we will not know, or care, how many repetitions will be involved. In these instances, we can use abstracted terms.

Notation: we can use certain terms to connote more general structural repetitions:

  some to connote a small number of repetitions
  many to connote a large number of repetitions

These are intended to be subjective, and therefore do not need to be precisely defined. However, ‘some’ might be assumed to mean something akin to ‘less than a dozen’, and many might be assumed to mean ‘more than a dozen’.

Progress

The last key element we need for this structural specification is that of the mechanics of progress – specifically, when the progress is “banked”, which is to say, when and how ratcheted progress takes place. There are only two basic issues: when progress is banked in the internal game state (such that the player need not repeat previous activities), and when progress is banked in an external save file (or similar device) such that when they return to play at a future date, they do not have to repeat previous activities.

Notation: the following characters are used between Tasks and Activities to record when progress is banked: 

    .        progress can be saved at this point
    ,        progress is internally ratcheted at this point

Note that wherever ‘.’ is used to denote that progress can be saved, this can also be understood to mean that progress can be loaded from this point, i.e. play may continue from this point.

Imbedded Elements 

For ease of use, it is helpful to be able to imbed game structures inside a specific structural specification. For example, in the GTA games, there are many “mini-games” which can be found. The structure of each of these is scarcely worth considering as part of the overall structure of the game (although they could be described separately). In these instances, we can therefore note an imbedded element.

Notation: imbedded elements are placed inside curly brackets e.g. {game}

We are now ready to employ this structural specification in the analysis of game structures.

--- 

Key

    noun or verb                  Unique, one-off Activity (e.g. a cut scene)
    [verb noun]                     Task
    [verb]                                 Activity
    (#| Task)                           Repeat Task # times; # may also be ‘some’ or ‘many’
    {game}                              Imbedded game (e.g. a mini-game)

    .                                            Save and/or load at this point
    ,                                            Progress is banked, but not saved
    -                                            Connector for unbracketed segments

Examples of Structural Specifications

 

Shadow of the Colossus:

    (16 | Briefing. [Navigate World][Cross Area][Defeat Colossus].)
                                [Find Tree][Collect Fruit]
                                [Find Temple].[Hunt Lizard].

Play with Fire:

    (30 | Choose Quest, (6 | [Find Exit].))
                                                     [Cross Area].
                                                     [Solve Puzzle].
                                                     [Watch]

 

Grand Theft Auto: San Andreas:

    (many | [Navigate World][Briefing-Task])
                     [Find Game]{game}
                    (many | Find Token)
                    [Find Safehouse]-Buy Safehouse.

 

Conclusion

This is a provisional attempt at a notation for structural specification, but I believe it already shows great promise in the task of analysing how games are structured. In particular, its capacity to express apparently complicated structures (such as the playground world structure of GTA et al) in just a few short lines of tokens suggests that it may be possible to conduct useful structural comparisons using a system such as this.

This is still at an early stage of development, however, and it remains to be seen how viable it is for general use. The only way to find out will be to begin to use it and to explore relations between the many and varied structures of games. I look forwarding to seeing how this notation develops, and what we can discover though this particular lens.

The opening image is Structure; the artist is Tatiana (alas, I do not know her surname). I found it here. As ever, no copyright infringement is implied, and I will take the image down if asked.

Comments

[Patrick Dugan]

This could be really useful for early design and for composing a medium sized design doc for purposes of wooing publishers, though I suspect a key would have to be included.

You may notice that, according to you sytax you've created, the size of a play spec and the size of the structural spec are inversely proportional. Seems to support the idea that agency is conserved, as well as denote precisely what the global and local agency is, whne taken together. Most of these game's are structurally just simple sequences, in other words global agency is minimal.

This notation could be a good vehicle for exploring new variations of agency distribution/ ludus vs. paidia.

[Donald Gay]

This all sounds great to me (not like you needed my aqpproval or anything). As Patrick said, the two specs seem inversely proportioned, so you could combine the two into one hybrid spec if you wanted. Of course it's valuable to look at each separately, but I bet that there is some very important aspects of a game that can only be see with the two together. For example, with Shadow of Colossus, the fact that you use the same play spec (same verbs and nouns)to achieve all tasks and participate in all activities in the game is important. That is part of what defines the game. If you look at a game like Omikron, this is not the case. At different points of the game, different play specs are forced upon you. When you are presented with certain tasks, the game operates completely different than when you are presented with others. In Omikron, there are several play specs for different parts of the game which do not fit together, whereas in Shadow of the Colossus, the same verbs are always available to you, and it is part of the reason why SOTC is such a tight, engaging experience, while Omikron can jar you out of the game world in a flash with its disjointed play. With a hybrid spec, this could be seen easily by just noting where each play spec fits into the game structure, or which tasks or activities are completed with which play specs. This is only one thing I could see coming from a hybrid spec, but it is possible that other bits of important info that could be seen with it as well.

[Patrick Dugan]

Which brings me to a key point, how do you specify inconsistency in the verbs? It seems like inconsistent verbs sets, even if theres a core set thats consistent, are becoming the new deal, particularly with interactive drama.

[Chris]

Don: I may not need your approval, but it's nice to know that what I'm writing is well recieved. :) You certainly can provide play specs and structural specs together to get a fuller picture of a game. I wonder if there is something important in the middle ground that is being ignored in this perspective though?

I know precisely what you mean about having multiple different play specs in the same game - this was established wisdom for creating 'variety' of play for some time - but of course, it has the negative effect of requiring the player to learn many custom systems. I'm not a fan of this approach myself. It's going to be interesting to see how these notations pan out in practice.

Patrick: I doubt publishers would give a damn about this sort of thing, to be honest. :) Could be useful for internal reasons, though. Personally, I'm just interested in exploring structural issues inside some framework - anything will do! :)

Regarding your hypothesis of conservation of agency, see my recent comments to your blog.

I don't see that play spec and structural spec have to be related in any manner at all, however. Case in point: I can define a game with a series of linear segments:

(many | clear level)

This structure will take *any* play spec of any complexity.

Conversely, I can define a super complex structure of some kind (say, the GTA structure) and this too could take a play spec of any complexity.

Of course, the fact that it doesn't pan out in a thought experiment doesn't mean that there isn't a trend in real software products... We probably need to dig into this some more. I personally don't see any signs of anything being conserved in a meaningful way, but I still sense that there is something interesting going on - we just haven't identified quite what yet. :)

Regarding inconsistency of verbs, I'm not entirely sure what is meant here. Case by case expressions of verb usage? I can see why drama games would need this, perhaps. Do you have a reference for this I could look at?

Best wishes!

[Patrick Dugan]

I'd hate to be that guy who rants about the need for conservation. I'll take your counterpoints as fuel for a paper I'm writing for the ACM conference in Santa Barabara in Oct.

I challenge you to write a structural spec for GTA to compliment the play spec you wrote. I suspect you'll find the two forms of specification married at some primal level. An even better way to test this is to write up specs for Spore; which is a great example of a consistently inconsistent verb set, i.e. play spec, united along a structural specification. Spore is actually a great example of conservation of agency at work, you start with lots of local agency but no global agency, as a bacterium, and slowly shift towards more global agency and less local agency as you develop into a space-faring civilization. Sure you can zoom back to local agency as you develop individual planets, but this involves temporarily giving up global agency. As I noted above, this notation may be a great way to explore these sort of unproven ideas and perhaps set-up protos that might experimentally test them.

Another great example of inconsistent verb sets is in comparing Facade with Storytron. Facade seems to have a consistent verb set, you can move around, pick stuff up, hug or kiss the couple at any time, and you can also talk at anytime. Storytron patently has inconsitent verbs, and this is clear because of its turn-based structure. Facade's real-time structure masks the fact that the speech verbs are inconsistent from context to context, but since the tension of a context "scripts" the interactor to say things pertinent to that context, there is an illusion of consistency. Maintaining this illusion, which I think is better called the active creation of belief, than that date colerige quote, is a key element of game design in general, and interactive drama in particular.

[Chris]

Well, my structural spec for GTA is above. It doesn't directly connect with the play spec at any point except navigation, but only because I have not enumerated the tasks. If these were specified, the play spec and the task specs would correlate implicitely (but not explicitely) at the level of the task. I'm not sure what of note this tells us, however.

It's funny you mentioned Spore - I just asked about this at your blog, only to find you'd already written a response here. :)

Your ideas seem to be developing quite cogently, although I'm still uncertain on much of the relevant details. Perhaps your ACM paper will bring it all into focus.

I still claim you can only call this a 'conservation law' in a metaphoric sense, though; there is no measurable property and so nothing that can be considered an invarient - at least, in terms of the language of physics. Also, perhaps you must define what you mean by agency in this context, as it is not quite what is meant by agency in philosophy, for instance. In fact, do you have some references upon which you are building? Who has written about agency in games with any clarity?

Looking forward to seeing where this takes you.

[Chris Wilhelm]

Hello Chris,

I've just recently started reading through you blog, and I must say this is all absolutely amazing information. I am an artist by trade, but have an (un)healthy interest in gane design that I have recently started to indulge.

Part of that pursuit has been absorbing as much game design information as possible, and part has been patiently teaching myself how to code.

On reading this and your play structure articles, it occurs to me how similar to programming syntax these structures you are proposing are. It really seems like an entire structurally standardized method of construction could be implemented using this system.

I understand ttay this post is somewhat dated, but it seems very relevant to someone like me, who is just getting their "sea legs" in the art of game design. Would you happen to have any follow up articles to these thoughts and explorations? What are your current opinions on the applicability and usefulness across the gamut of this kind of structurally systematic approach? Have you found it to be limiting, or liberating. I intend to apply your suggestions to my own studies, but I'm curious to know how these ideas have developed with you over time.

Thanks for the awesome blog!

[Chris]

Chris: thanks for stopping by and leaving a comment!

This is, as you say, an awesomely old post - this was where my head was five years ago, today it's in a very different space. :) I think back then I was looking at getting game design into a more formal program-like space, but I feel now that this was a misstep.

I wrote about this structural approach for several months, but then stopped using it and abandoned this notation completely. I haven't even *thought* about it for years! :) I do think it's *extremely* useful to think about game structure, but I'm not sure a formal notation is the best way to go about it - but then, I suppose the flipside is that if you *haven't* thought about structure, the notation might be an interesting way to begin to look at it.

So in answer to your question, I found the notation limiting, not liberating.

In my recent work, I've been coming in from a philosophy of art angle, which is giving me a new perspective on game design - but not one that is quite as practical as this piece! Although I now post game design content over at my company blog, ihobo.com, it's always linked to from here, so if you stick around you'll see where my head is at these days.

I applaud you as an artist taking an interest in game design - it's wise for people to take notice of what other related professions do. When I worked in-house at Perfect Entertainment I always made sure the artists kept me up-to-date with the software they were using, and their major techniques. In many respects, working as a consultant has left me a little isolated in this regard, but I still keep my ear to the ground as best I can.

I suspect my old posts on game design are probably the ones of most interest to you. Over at ihobo.com you'll find a list of the articles I think are the most interesting:
http://onlyagame.typepad.com/ihobo/articles.html
(It's the "articles" link in the sidebar).

Many of these posts are here at Only a Game, some of the later ones are at ihobo.com, but this is a great place to start if you want to look at what I've written on game design.

All the best!