Home About EIS →

Xorex: An Abstract Matching-Shooter

Screenshot showing the players ship charged with pink ammo, carrying some yellow inventory.

Screenshot showing the player’s ship charged with pink ammo, carrying some yellow inventory.

Xorex is a haphazard pastiche of various games I’ve played over the years.  It has several elements you’ll feel right at home with: gems to be arranged into color-matching linear groups, a forward-firing ship with flexible inventory and ammo storage, a grid-based board to which you can add and remove tokens, an unstoppable source of new clutter to be blown away, and a timer and leader-board for use in posturing with friends.  While making this game was a fantastic first-experience with open-source Flash development tools like HaXe and FlashDevelop, I must admit to a hidden agenda.

Inspired by Jesper Juul’s analysis of tile matching games and Raph Koster’s brief, visual analysis of early shooters in A Theory of Fun, I did my own informal analysis matching and shooter games.  Rather than aiming to explain the historical development of these games, I tried to get a hold on the elements from which games in these spaces could literally be assembled.  For matching games, these are elements like the topology and division of space, the influence of timers, a means of manipulating gem-like tiles in the space, policies for what determines a match, other policies for repacking and refilling the space, and auxiliary goals for getting tiles to drift to into certain configurations.  For shooters these are elements like, again, the topology and division of space, the range of ship locations (and orientations, or more generally the PC-avatar’s phase-space), the fitting of weapons to hardpoints, classes of enemies and bullets (and their corresponding pathing), and the role of power-ups.

Whiteboard design for Xorex

Whiteboard design for Xorex

If you filled out a form with fields for each of the above for matching game or a shooter games, you’d have a decent way to compare and contrast various games, but if you filled in the fields with new details, you’d have something like a recipe for a new game. Xorex was created by running down each list, drawing a picture of how each element would manifest in my new game and imagining a data structure or function that would effect my desire, or deciding that a particular element wouldn’t be present.  The result was a rough sketch for a game mashing up familiar elements of the two genres.

Design in-hand, all that remained was the straight-forward process of learning a new language and tool-set, transforming abstract design ideas into a formal system, realizing my whiteboard scribbles with vector art, and leaning back while the advertising revenue streamed in.  OK, it wasn’t that simple, but at least it got me something my friends are willing to play for more than the obligatory 30-seconds of attention I get for sending them a link.

Behind it all, I was really looking to answer one question: what are the building blocks of games in genre-X?  We have notions like rules, mechanics, and now operational logics for analyzing the design of games — for taking them apart.  But are these sufficient for putting new games together?  The informal elements that I used to plan out my new game don’t feel like there were really rules, mechanics, or operational logics, but they certainly felt related to those notions.  The way I addressed each element in my game was with the combination of a piece of code (or data) and an associated story about what that code meant in the context of my game’s fictional world.  Each unit of code and story worked together with the skeleton of elements derived from the genre to form both a working game and a complete story about how the abstract world maps to the conventional worlds for that genre.

That is, in a very real sense, games are built from nuggets of code and story about that code, but a pile of such nuggets does not a game make.  These nuggets form coherent wholes when they fill slots held open by definitions of boundaries or interfaces between concerns (or they aspects?).

If I’m going to turn this general understanding into an automated process (that might pop out new games on its own) I’m going to have to make my vocabulary more concise — “elements” and “nuggets” will not suffice.    So, Internet, what do you think games are made out of? (And you thought this post was about a Flash game…)


About the author:  Adam is a PhD student, research scientist, software engineer, musician, artist, and hacker. He has a very special kind of respect for those elegant weapons like lisp (pronounced "scheme") and prolog, for a more civilized age. Read more from this author


This entry was posted in Academics. Bookmark the permalink. Both comments and trackbacks are currently closed.

4 Comments

  1. Posted August 25, 2009 at 10:58 AM | Permalink

    Hi Adam,

    “what are the building blocks of games in genre-X? We have notions like rules, mechanics, and now operational logics for analyzing the design of games — for taking them apart. But are these sufficient for putting new games together?”

    Although I’ll agree that a little planning in the beginning is almost always required, just as some fine-tuning at the end is almost always required, I believe the genre greatly influences how much of the middle 90% is composed of planning, if any. I notice that in genres that have either discrete space (tile-based) and/or discrete time (turn-based), planning works better. But in other genres, especially in action games of continuous time & space and especially those with heavy simulation aspects (such as martial arts and sports games), iterative development is much more appropriate than attempting to cooly plan everything ahead of time.

    Given the same goal of merging the matching-tile genre with the shooter genre, I likely would have taken the same tack you did — the majority of the game would be planned out, since the resources and tokens are so easily and clearly demarcated. But if I had to merge matching-tile with, say, a turn-based multi-player card game, I would likely go to the list of games in economic game theory — each one being a “pure” example of a game itself — and mixed & matched from there. And yet again, when I designed a game that was true to the Olympic sport of fencing, I found planning to be counterproductive! Iterative development, and constantly referencing the real thing to find appropriate trade-offs, were the way to go.

    (For reference, the narrative of the fencing game’s morphing from what I thought it would be, to the way it was supposed to be, is found at Gamasutra: http://www.gamasutra.com/blogs/RonNewcomb/293/

    And the list of games in economic game theory: http://en.wikipedia.org/wiki/List_of_games_in_game_theory
    )

  2. Posted August 25, 2009 at 11:53 AM | Permalink

    I think some of what you are looking for might be covered under the notion of “game design patterns” (Bjork & Holopainen), “game grammar” (me, Dan Cook, a few others), and “formal abstract design tools” (Doug Church). Happy reading! :)

  3. Posted August 25, 2009 at 12:48 PM | Permalink

    @Raph: Thanks for the pointers! We have actually looked at most of that stuff while working on various aspects of this research (Adam’s research overlaps with mine, though not w.r.t. this game), and taken some ideas.

    An initial hope was that something already existing could be directly implementable as modular, recombinable components, at various levels of abstraction. Church’s FADT was actually a motivation for a good portion of this work, but I think (?) he would agree that the FADT paper is more of a call for such tools to be developed. Patterns are getting closer, but they are, well, patterns, something more like ideas you might reuse, rather than concrete modules that can actually be plugged and re-plugged (to continue the OO analogy, we want classes, not patterns). The relationship to game grammars (both the recent kind, and the kind used by classic AI systems like Metagame) is a more involved discussion, but for the purposes of this post, the main worry is that grammars don’t give a clear indication of how to make games modular, and it’s hard to make them flexible and combinable while still staying formal. (The pros/cons of grammars in general is a much bigger discussion, though.)

    There are some other decompositions of games we’ve drawn on as well: Zagal et al’s game ontology, which provides game elements that can be put into any higher-level structure we come up with; Bogost’s unit operations, though it’s not clear how to use those in an implementation-side way at the moment; and Wardrip-Fruin/Mateas’s operational logics, one of the subjects of this post. The latter in particular seems interesting because they’re both strongly modular (particular operational logics have self-contained internal logic) and speak to how the game rules affect meaning.

  4. Adam M. Smith
    Posted August 25, 2009 at 4:45 PM | Permalink

    To clarify what I’m after, consider this little exercise.

    Suppose I want to know what the building blocks of a business model are as you might build one in a spreadsheet. When you save your spreadsheet file to disk, it remembers what constant values you’ve typed into some cells and what expressions-to-be-evaluated you’ve typed into others. The building blocks of a spreadsheet business model must include these low level code elements somewhere, but they don’t need to be as expressive as general programming.

    Common models make use of rectangular tables where the number of rows comes from some element of the business to be modeled and each of the columns have a heading that (ideally) explains how values of that column relate back to the business as well. So let’s say tables-with-annotations are one building block. Instances of this block can be tweaked internally, but other tables may only depend on the values produced, not the implementation.

    Another building block is the singleton parameter, a cell with a value containing some tweakable constant. Even more, there are input and output cells who’s values are tied to properties and controls of the business via some external person who keeps the model updated or enacts the policies it suggests.

    In this business modeling domain, I can imagine making a data structure definition for each building block (with some properties filled with natural language and other with code) that, when put together, would produce the desired spreadsheet along with a story of how it maps to the business being modeled. That is, you could imagine a “programming language” that let you make all-and-only valid models.

    What is the equivalent for games? It need not necessarily cover all games, but it should be sufficient for formally constructing playable artifacts.

    Design patterns (whether patterns for gameplay or software engineering patterns) help you structure your game, but they don’t account for all of it. Likewise, some game engines have a nice partitioning of client code into distinct, named buckets, but they always require some general purpose programming in the cracks. Is there something between design patterns and middleware/engines that has the best of both?