Applying Burgun's Lens of Game Design

I recently read Keith Burgun's Game Design Theory, an intriguing manifesto on game design and philosophy. The author argues that reasoned discourse about games requires a shared vocabulary, and to this end, he offers the following hierarchy of interactive systems.

Burgun's hierarchy of interactive systems
(Taken from What Makes a Game?)

Burgun's defines a Game as "a system of rules in which agents compete by making ambiguous decisions." More specifically, these decisions have to be endogenously meaningful in terms of the game mechanics. Whether or not one agrees with his definition is less important, in my opinion, than the fact that a vocabulary helps us move forward in the science of design.¹ 


The hierarchy of interactive systems permits Burgun to explain what he's not talking about: because he wants to address game design, he can cut out problems of interactive system design, puzzle design, and contest design. Many of his game design recommendations echo what others have to say. However, it's Burgun's zealotry that makes his work so valuable: he makes fewer and stronger recommendations. In the introduction, he discusses how he sees his work with relation to other books on game design:

For those who might defend these books by saying that they're only giving readers wiggle room or that they're allowing readers to come to their own conclusions about what games are: readers do not explicitly need to be given permission to do this. Thinking persons will come to their own conclusions, regardless of whether they read something wishy-washy, or something pointed... (Introduction, page xx)

This sets the tone for the rest of his book. He is unapologetic about his philosophy of game design and leaves it to the reader to decide whether they agree or not. In fact, I don't think anyone who is serious about game design could read the book without being either uplifted or offended.

In an attempt to better understand Burgun's philosophy, I decided to apply his lens to some of my work and my students' projects. The following analyses assume familiarity with his philosophy, and while this is best presented in the book, there is an overview in the freely-available Gamasutra article, What Makes a Game?


Morgan's Raid

According to Burgun's lens, Morgan's Raid is a Puzzle² because there is no randomness: a play experience can always be replicated by repeating a series of decisions. The goal of the puzzle is to maximize score, which is themed in the game as Morgan's reputation. The impact of a player's raiding decisions on reputation are not immediately clear: a player must choose all of his orders prior to seeing their combined effect, although Basil Duke does provide thematic hints.

Basil Duke informs the player that he will help explain the puzzle.

There must be a series of decisions that maximizes reputation, but no one on the development team knows what it is. From our observations, groups of players will gladly make it a contest to see who gets the highest score, although their interest in the game wanes well before anyone finds the optimal path.

It is interesting to note that the original Spring Team design for Morgan's Raid involved more interesting behavior of the Union troops who were chasing Morgan, such that this would have made the project a Game. The original plan was for the Union's movement to be like Morgan's, making heuristic decisions in each town in an attempt to capture the player. However, working within our time constraints, we simplified the Union behavior to make them a fixed integer distance from Morgan. This distance is modified by player's decisions but in a fixed and predictable way.


Museum Assistant: Design an Exhibit

Museum Assistant is also a puzzle, albeit one with multiple solutions. Players get themed feedback based on the solution chosen; for example, creating an exhibit with African scientific artifacts from three different periods yields the generated exhibit title, "African Science through the Ages." The themes provide reason for players to try alternate paths, but from a mechanics point of view, one solution is as good as any other.

As with Morgan's Raid, Museum Assistant underwent a design change that resulted in its moving from Game to Puzzle on Burgun's hierarchy. Details of this design are described in my MeaningfulPlay paper, but to summarize, there were systems of input and output randomness that made it so the same series of game actions could produce different results. However, in the major redesign we agreed that we needed one good play experience, and that balancing the ambitious original design was outside of our scope. In terms of Burgun's hierarchy, the team decided to make a good Puzzle rather than a bad Game.


Equations Squared

While the previous two examples are student work, Equations Squared is my own, and it's certainly a Game. The player makes strategic decisions about placement of digits and operations, in terms of which to use and where to place them. Not all sequences are legal equations, and the scoring system rewards more complex equations. There is input randomness: the sequence of digits and operations you receive is different each time you play the game, so you very likely will never play the same game twice.

Auralboros

Auralboros is an experimental make-your-own-rhythm-game toy. You can make the experience as simple, as challenging, or as ridiculous as you want. To this end, Auralboros is simply an Interactive System.

Auralboros encourages players to make their own Contests out of matching keystrokes in rhythm. The system rewards such behavior with visual feedback. There's no ambiguous decisions: you either make and match rhythms or you don't. In fact, a successful strategy to seeing all the visual bells-and-whistles is to spam a single key—a useful debugging technique discovered by co-developer Ryan Thompson. However, this strategy is not much fun, as you end up just making a bad Contest.


EEClone

I still occasionally install and play Every Extend (though it seems the original download site is now gone), usually after explaining to students what an amazing experience it is. EEClone is my academic knockoff, designed to explore and teach how design patterns occur in game engine software.

Like its inspiration and namesake, EEClone is a Game. The timing and orientation of incoming obstacles is not known, and the player has to make meaningful and ambiguous decisions about maneuvering and the timing of explosions in order to succeed. Of all these analyses, this one is the simplest, but it also shows how things that are obviously Games fit nicely into the hierarchy.


Conclusions

Most of my effort the past few years has been on serious games. As I use the term, serious games are those that are designed to have a particular real-world impact on the player. For example, Museum Assistant is designed to encourage players to think about collecting and curating. Applying Burgun's lens to my students' projects gives rise to an intriguing contradiction: serious games need not be "games" at all. However, Museum Assistant is no less successful in meeting its design constraints for its being classified a Puzzle. This is because the real constraint for serious games is serious, not game. It is difficult to say whether or not these projects would better meet their goals (however one defines "better") if they were Games, because this would fundamentally change them. For example, we know that Morgan's Raid could be a better Game if the maps were randomized, but this violates the goal of familiarizing the player with actual Indiana geography.³

The Morgan's Raid and Museum Assistant teams recognized that there were opportunities to make a better game—or from a strict reading of Burgun, to make Systems and Puzzles into Games. Both teams eliminated randomness in the face of time constraints, knowing that balancing games would be much more time-consuming than testing puzzles. This was shared knowledge among the team, although they didn't have Burgun's concise language to communicate the sentiment. In a similar vein, the Auralboros team was aware that we weren't really making a game at all. It is interesting to note that Equations Squared is a Game by Burgun's hierarchy, but it is not a serious game by my own definition. For the player, it is simply supposed to be fun. The serious aspect of it is in the assessment of player's behavior, an assessment conducted by someone outside the magic circle but facilitated by score, badges, and demerits.

Applying Burgun's lens to these projects has helped me to understand his philosophy. However, since much of his philosophy is prescriptive, there is not much extrinsic value in applying the lens to completed projects. That is, I do not think I gained any new insight into these projects, but then again, as an academic, I've already studied them inside and out. I do look forward to having Burgun's philosophy in my utility belt for future design projects, particularly as a lens for identifying and discussing decisions that could alter a project's position in the hierarchy. Next semester, I will be leading an experimental six-credit interdisciplinary game design and development studio, and you can be sure I'll try to keep up my reflective practice here on the blog.

---

¹ At MeaningfulPlay, I got into a bit of a debate with a gentleman over the definition of "fun." He argued that a friend's autobiographical game designed around the theme of depression and abuse, in which you decide whether or not to commit fantasized patricide, could not be fun. I said that if it was a game, and if I was using Koster's operational definition of fun as learning and mastery of a system, then it could be fun, though perhaps not in the informal "enjoyment" sense. My point was that if we defined these terms, we can be clear about our meaning and avoid the baggage. He didn't talk to me any more. I tell this story to demonstrate that I am surely in Burgun's design philosophy camp, and that there is a dangerous cultural divide in "game design" that prevents communication across traditions. See also Daniel Cook's excellent essay contrasting secular and mystical approaches to game design.

² As a typographical convention, I will capitalize the layers of Burgun's hierarchy so as to distinguish the layer "Puzzle" from the general use of the word.

³ We are currently conducting an empirical study on the effectiveness of Morgan's Raid, and I will report the results here when we have them.

Museum Assistant Kiosk at the 2012 Indiana State Fair

I am pleased to announce that Museum Assistant: Design an Exhibit will be featured at the 2012 Indiana State Fair. Our project will be on display in a kiosk at the Ball State Backyard area in the Ball State Ag/Hort Building.

Special thanks go out to two Root Beer Float Studio members who volunteered their time to making this happen. Ryan implemented a "kiosk mode" feature into the game, so that after a minute of inactivity, the game returns to the main menu. Ashley designed a beautiful handout, a great piece that visitors can pick up and take home. They'll be printed  four-up on 8-/12x11" paper, and here's a raster version of the design.

Handout Front

Handout Back

My task in all this was to make the game work on the laptop that will power the kiosk. As regular readers will know, the game is free to play online, but our kiosk will be offline, and we want it to feature just the game, not the whole site. My first attempt involved using Javascript to try to implement kiosk mode, but it turns out that all the mouse events were intercepted by the Unity Web Player, so this approach was doomed to failure. We also could not use a standalone Windows executable because the assumption of a fixed 1024x600 resolution is embedded deep in the implementation; when running the game in fullscreen mode (for which 1024x600 is not an option), many of the widgets are misplaced, so the game had to be embedded in a browser.


Knowing that Ryan was adding the kiosk feature directly to the game, I focused on making an interface that would be most useful to the player. At first, I hoped to just be able to run the game in a fullscreen browser window, but all browsers I could find have a "feature" in which moving the mouse to the edge of the screen pops up a prompt to get you out of fullscreen mode.

Fullscreen Chrome browser with the mouse having been pushed to the top edge

The player will only have a mouse and no keyboard, as the laptop is actually enclosed and protected within the kiosk. This makes it imperative to prevent the player from exiting fullscreen mode and poking around, as then someone else would have to manually go in and restore the settings before the next attendee walks by.


After a bit of surfing, I discovered that Chrome has a kiosk flag that does exactly what I need. I created a batch file that starts Chrome with the "--kiosk" flag, followed by the location of the WebPlayer html file, and it works like a charm. I put a shortcut to this batch file into the Startup directory, and now booting the machine takes you right into the game. So, in the case of failure, a volunteer at the Backyard area need only reboot the machine, and we should be fine.

Incidentally, it was easy to customize the WebPlayer HTML file with a bit o' CSS to get the look above. I'll share it here in case it's useful in the future (to me or to you).

<script type="text/css">
body {
 background: #5d337b;
}
#unityPlayer {
 position: absolute;
 top: 50%;
 height: 600px;
 margin-top: -300px;
 left: 50%;
 width: 1024px;
 margin-left: -512px;
 border-style: solid;
 border-width: 4px;
 border-color: #262263;
}

I'm using a little CSS magic to center the fixed-sized unityPlayer div in the screen. This will work fine as long as the kiosk display is at least 1024x600 resolution, and if it's not, we have even bigger problems. The small purple border around the game makes it pop against the background when playing the game.

Chrome in Kiosk Mode

We also want to prevent the user from right-clicking and fiddling with the browser or the Unity Web Player settings, and so we used the KillRightClick trick explained at lifehacker. Linking the script to the startup menu ensures that the kiosk starts in a stable and hopefully tamper-proof state.

A brief note about the value of reflective blogging. When I started this post, I had an inelegant, resolution-dependent hack for vertically centering the game in the browser window, and I had failed to consider complications of context menus (right-clicks). As I was copying my CSS over to FormatMySourceCode, I thought that there must be a better way; a few jumps around the Web led me to the absolute positioning, fixed-size div trick. As I was generating the screenshots for this post, I realized the vulnerability introduced by the right mouse button, and again, a bit of trial and error led me to the current approach.

Finally, I would be remiss if I did not thank Al Rent for inviting Root Beer Float Studio to showcase our game in the Ball State Backyard.

See you at the fair!