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…)

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