I'd like to respond with an assertion: that Galaga really is a game based on interesting decisions; and that, in any game which includes anything that could possibly described as "challenge" (in other words, virtually all games), the gameplay is in fact entirely based around interesting decisions. My argument is that we should take Sid Meier's definition that "a good game is a series of interesting decisions" (which Chris dismisses as only applicable to certain types of games) and apply it in a deeper and more holistic way than it's typically applied; and that doing so will show how it is possibly the most important, fundamental law in the field of game design. Recognizing this may involve rethinking one's definition of the term "decision"; but I believe that thinking this way reveals certain fundamental truths about game design which seem to elude even many experienced game designers.

Mario's resume, like mine, is varied - though none of my jobs' descriptions have been "killing baby monkeys." Yet.

Learning the Ropes

I should provide a little background before I continue. My formal education isn't in game design, it's in software engineering; however, I've always had a great passion for game design, and several years ago I set about methodically self-educating myself in it that discipline. But for the most part, I was disappointed in the lack of rigorous academic material available - coming from a highly analytical and well-defined field like computer science, I kept feeling that there must be some hidden cache of "Game Design 101" educational materials that really explained what game design was about, but eluded me. To make a long story short, my education in game design has almost literally been a self-education - I was basically unable to ever find a "universal theory of good game design" which I found satisfactory... so I set about defining my own.

(Note that there are diamonds in the rough... in particular: virtually everything ever written by Marc LeBlanc; and most of the teaching coming from NYU's Game Center, especially the book Rules of Play by Eric Zimmerman and Katie Salen, which I'm currently reading and loving.)

Scientists spent years trying to decipher Einstein's coded Unified Theory documents before realizing they were actually chords for Rolling Stone songs.

Guitar Heroes and Unified Theories

My personal "unified theory of fun gameplay" didn't begin to crystallize until a couple of years ago. Until then, my definitions of "fun gameplay" and "good game design" were rather fuzzy and non-rigorous: various theories and definitions floated about in my head, but it was unclear how they related to one another. (I now recognize that this is pretty much the current state of game design theory in general.) One of these definitions was Sid Meier's "interesting decisions" quote, which I intuitively felt to be extremely important, though it was hard to explain why.

Then I read a blog post by Chris Bateman which directly challenged the Meier quote, holding up Guitar Hero as the ultimate proof against it:

"...these rhythm action games do not rely upon a series of interesting decisions, for the most part they have no decisions of any kind!"

I realized this was an important question: was the idea of Interesting Decisions fundamental to good game design, or was it optional and disposable?

I thought about it extensively and realized that it was the former: all good gameplay is comprised of interesting decisions ... but only if one expands one's definition (and understanding) of what a "decision" is. And once I expanded this definition, I finally found the "uniform theory of good game design" that I had sought all along.

Does decision-making break down somewhere between these genres? Also, what would happen if Princess Peach fought Kerrigan? That would be so sweet. Sorry, what was I talking about?

Who Turned Off the Choices?

I played Guitar Hero obsessively, and much like I played any other game: I'd go to a level that I hadn't completed yet, attempt to complete it, and fail. I would then try again and again until I succeeded, at which point I would move on to the next challenge. I noted that this was exactly the same pattern that I applied to a game like Advance Wars: Dual Strike. And though those two games clearly had huge differences, it was clear that there was some kind of fundamental similarity between them as well. Advance Wars (a turn-based strategy game) was clearly about making interesting decisions. But Guitar Hero wasn't... right?

But consider the following genres of game, and tell me when they stop being about "interesting decisions":

• Turn-based strategy [Advance Wars]
• Slow-moving real-time strategy [Kohan, Neptune's Pride]
• Fast-moving real-time strategy [Starcraft]
• Tactical "action" games [Defense of the Ancients]
• Pure action games [Super Mario Bros, Galaga]
• Rhythm action games [Guitar Hero]

At what point in this spectrum does the gameplay stop being about "interesting decisions"?

My answer: they don't stop being about interesting decisions. Each genre is fundamentally about making decisions during every moment of gameplay. There are decisions being made in every one of these games; they're just extremely different decisions, which occur in different layers of the brain.

At the bottom of the spectrum, the decisions are so minute that they're no longer what we would call "decisions" in a normal definition. In other words: the exact way you configure your fingers across the buttons to prepare for the next set of notes coming towards you in Guitar Hero is a decision that you make.

Again, this is not what we'd typically call a "decision" in day-to-day language - we might normally call it a "choice" or even just an "action." But fundamentally, they're all the same thing.

These games each use different parts of your brain. They're also both so hard that they make you want to lobotomize yourself... but each in a different part of your brain.

Fretting Over Tanks

Is there a difference between choosing what configuration my fingers are going to be in during a given millisecond-long period of Guitar Hero, and choosing what configuration my tanks are going to be in during a given turn of Advance Wars? Of course there are differences: in Advance Wars, my conscious mind is rationally considering the battlefield and making an intellectual decision; in Guitar Hero, my unconscious mind, my physical instinct, my muscle memory, and my intuition are deciding where my fingers need to be this instant, and moving them there as best they can.

But though they're happening on different levels of consciousness, they are still fundamentally the same thing. Now that we've acknowledged the differences, consider the commonalities:

• Each are actions defined solely by my own initiative. What actions I take, and what exactly the action is comprised of, are defined entirely by myself. I never move my hand on a Guitar Hero controller without it being my decision to move it; and no one but me is deciding where my fingers are going and how they're getting there.
• Both are always decisions which may be either "better" or "worse" than other decisions I might have made. My line of tanks could be more or less optimal for defense; the arrangement of my fingers could be more or less optimal for allowing me to hit the notes currently moving down the screen.
• My decision-making improves as I learn. I don't just get better at Guitar Hero because I'm memorizing the level: my hand is also constantly learning better ways to move and arrange my fingers on the keys. With time, my skill increases and allows me to take on new and greater challenges.

I admit that there's a big difference between decisions that a player must make under time pressure, and decisions that the player has infinite time to make. Playing my puzzle game Connectrode (which has no time pressure) is very different from playing Dr. Mario (which does), though the games have mechanical similarities. But both types of decisions are still decisions: just because a decision has to be made within a time limit doesn't mean that it stops being a decision. They're just different flavors of decisions.

Boom, headshot. No more decisions for you.

Counter-Semantics

Essentially I'm expanding the definition of "decision" here to encompass something that happens on all levels of human consciousness. Consider a game like Counter-Strike, where within one round the player must make "strategic" decisions (what configuration he and his squad should take and what points of the level to assault with what strength); "tactical" decisions (what vectors to approach from, what hiding places to choose); and minute "action" decisions (whether to use gross-movement muscles of the arm, or fine-movement muscles of the wrist, in order to maneuver the mouse so as to place the crosshair over an enemy player's head onscreen). I think it's best to holistically view all of these as "decisions" which are made during gameplay, but which simply exist in different layers of the operations of the human brain. (For a more detailed analysis of the varied decision-making in a Counter-Strike game, read Tynan Sylvester's excellent Gamasutra feature Decision-Based Gameplay Design.)

Now, I'll admit that calling these things "decisions" does seem silly (or at least inaccurate) once we start talking about minute movements of fingers on the buttons on a plastic guitar! In regular language, no one calls what you're doing in Guitar Hero "decision-making." I would probably be better understood if I said instead: Guitar Hero tests a skill, and so does Advance Wars; and though these are very different skills, they're still both clearly skills, testing different areas of human mental (and physical) performance. But I believe that all "skills" have, fundamentally, the same "structure" - they're composed of actions.

In the end, all games that are based on an element of challenge are by definition based on testing and challenging one or more skill. (If you think that your challenge-based game isn't based on testing any player skills, then either you're wrong and you're not looking hard enough for the skill... or else you're right and your game is neither challenging nor fun.) And all skill levels are essentially defined by what decisions you're making and the quality of those decisions. As you play the game, you learn more, thereby improving your decision-making capacity - which is the same thing as saying "improving your skills".

Letting your ship get captured: The classic risk vs. reward decision. Thing is, it represents about 1% of the decisions you make in this game.

Galaga and Garrison Keillor

While playing Galaga, I definitely make decisions, at a rate of about 60 per second: I'm either pointing my ship in a direction or not, hitting the Fire button or not... every moment of action (or inaction) is my own decision. But a large number of those minute choices are made by my "lizard brain"... or my "muscle memory", or my "instincts", whatever you prefer to call it. For some reason we don't usually call such choices "decisions"; but I believe that classifying them holistically with other types of decisions clarifies their role, and their importance, in game design, and allows us to better understand and compare game designs.

And what of the decision in Galaga to allow my ship to be taken away, so that I might recover it later as a power-up? Clearly this is a higher-level, "strategic decision", and it's actually unusual and is used to break up the constant low-level "action decisions" that the gameplay is mostly comprised of. Many great games have multiple layers of decision-making, often taking place at the same time - this is an example of that.

Ultimately, that one decision in Galaga is the one that's easier to talk about (and recognize) than the many tiny "wrist decisions", because it's the one occurring at the higher level of our consciousness. But a truly far-seeing game designer is willing to acknowledge the importance of all types of decisions, which may compose all types of mental and physical skills. Garrison Keillor said "Nothing human is beneath a writer's attention." Similarly, no human capability for decision-making should be beneath a game designer's attention... from leading a civilization, to moving a finger over the correct button - and remember, the former is never possible without the latter.

• We launched on July 2nd (not the best timing as many games were either launching, on sale, or releasing in-game specials over July 4th weekend).
• We were reviewed by the Austin Chronicle on their blog, on July 13th.
• We were reviewed by TouchArcade on July 18th.
• We were featured by Apple (in "New & Notable" on the App Store) on July 21st.
• Joystiq featured us in their "Portalbliss" column on July 27th.
• Several other major app/game sites have done reviews, all of them positive.
• Flixel creator Adam "Atomic" Saltsman tweeted about the game and mentioned it during a recent appearance on the TouchArcade podcast.
• The game has hovered around the #10 position in both the Puzzle Games and Strategy Games categories on the App Store since being featured by Apple.
• The game's peaks (to date) in the All Games category at ranking #70, and at #125 in all apps overall.
• All of this is for the U.S. App Store. We've seen comparable success in the Australian, Canadian, and U.K. app stores, though with different timings.

The game is doing well financially as well, and the enthusiasm in most of the reviews and on Twitter is both humbling and exciting.

We're still planning an update with volume control support, and GameCenter support for leaderboards. There's also many requests for a harder difficulty mode, which is something I'm thinking a lot about and which may make it into the 1st or 2nd update we do, we'll see...!

Fun times!

I'm selling Connectrode for $.99... and though that price is a fact I've long accepted, that doesn't mean it's one I'm happy about. The fact is that the current state of the App Store left me no choice but to sell my game for $.99. Why is that the case, and how did the App Store get that way? Is the price erosion that's occurred there an inevitable fact of digital distribution, or could another system have prevented that phenomenon? Is my game really worth less than a pack of Altoids?

I absolutely believe that I've made a very high-quality puzzle game, worthy of comparison to classics of the genre such as Tetris and Dr. Mario, as well as modern gems like Drop7. I'm also very proud of what I've accomplished just in designing a fun abstract puzzle game: creating any type of gameplay that is truly "easy to learn, difficult to master" is a difficult feat. I'm also very proud of the work that my ragtag team of Austin-based indies has done in creating excellent art and audio for the game (I particularly love the music, by David Pencil, who did the soundtrack for Penny Arcade: The Series season two).

Yet the fact remains: I'm selling the game for less than the cost of a burrito! How did things come to this?

The current state of the iPhone market has been described well before, and it's been this way for a long time: read How to Price Your iPhone App Out of Existence from 2008, or this post from 2009 by Adam Saltsman about Canabalt pricing instead. (Small world: Connectrode uses the Flixel iOS engine that Adam's company used for Canabalt and which he was kind enough to later open-source.)

But the bottom line is that I have little choice but to release for $.99, and I feel a bit dirty about it... and not just because I'm giving away a quality product virtually for free. I see developers launching quality games at $.99 as increasingly damaging, not just to the iOS market, but to the entire games industry. Reggie of Nintendo raised these concerns, and I think that such statements are more than just Nintendo lashing out at its mobile-game competitors: it's the perspective of a company that's been in this business a long time, pointing out business practices that really are not only unsustainable, but actively damaging.

A big part of why this problem came about is simply that many small indie app and game developers are not very business-savvy. Their understanding of economics goes as far as "if I sell my game for less than this other guy, I'll probably sell more; and since it doesn't cost me anything more to make each copy, I can easily make up the difference in volume."

There's several flaws with this logic, and one of the big ones is that price sends a signal.

• If game A is $5 and game B is $1, customers are going to take this alone as a sign that game A is of higher quality, and worth more, than game B.
• Even taken alone, if game B costs $1, customers just aren't going to perceive it as valuable. We can't sell games for less than a pair of socks forever and expect people to treat what we're producing as works of real value (commercially or otherwise).

My concern (and Nintendo's) is that this perception is carrying over beyond the mobile app market; when polished games stuffed with dozens of hours of gameplay (such as Angry Birds) are being sold for less than a box of Kleenex, how long can we expect people to continue paying $60 for a AAA that provides dozens of hours of gameplay?

We're not just eroding prices, we're eroding the public perception of the value of what we do.

So what would a digital-distribution market look like where this decline wouldn't have happened?

A lot of people complain about the App Store being too much of a closed platform, and that it is too tightly controlled by Apple. But my contention is the opposite: Apple (who really does know better) should have controlled the market more, to prevent the classic "Tragedy of the Commons" which has run its course. The market could have been healthier for everyone if Apple had not let developers simply release their game for the minimum price. Instead they could have:

1. Required developers to release their games for something close to the maximum price the market would bear, say $10 (depending on the scope and nature of the game).
2. After a while, encourage the developer to put the game on sale for $5 briefly; and help the developer arrange for the game to be sold in "value bundles." Note that these are always couched as being a sale; this sends a completely different message to consumers that doesn't degrade perception of the game's value.
3. Eventually, as time passes, the price on a game could be gradually dropped, until it reaches a "bargain bin" minimum price of $.99.

This is the strategy that 99% of businesses actually follow in pricing products, because 1) it actually captures the most money in the market and leaves the least money on the table; and 2) it maintains maximum public perception of what the products are worth. And guess what, one digital distribution market has done exactly this, to terrific success: Steam.

Unfortunately when it comes to business decisions, I have to be a realist, not an idealist; I decided to release my game for $.99 because that's the reality of the current App Store market, and because I believed I had a product whose quality gave it a chance of being one of the lucky few. Pricing my game higher wouldn't accomplish anything to stop this trend... But what I can do is try to draw attention to the problem; point out the alternative pricing strategies we developers could have followed; and hope that future digital distribution markets learn from the mistakes of the App Store.

Further reading:

• Camels and Rubber Duckies [Joel Spolksy blogs about the problem of pricing software]
• Price As Signal [Again, Joel breaks down an economic concept in a fashion that anyone can grasp]

Find out more on the Connectrode website; you can download the game here.

UPDATE: The game is now live! On day 1, so far we've managed to hit #132 in the "Strategy Games" category and #182 in the "Puzzle Games" category, and we have eight 5-star reviews, three of them with rave written reviews. Seems like a strong start... again, exciting times! Thanks to everyone who's been helping create buzz so far, it's been greatly appreciated!

I've been a "Gameplay Programmer" in one form or another for most of my career. A lot of this has taken the form of my designing games myself, and then proceeding to implement them myself - a process which I love both sides of. Not very many game designers actually do the coding themselves; and not many gameplay programmers do a great deal of game design. I feel like it's given me a unique perspective, and in particular it's led me to conceive of a new type of game engine - one that would minimize the need for even having a gameplay programmer, and put the implementation directly into the hands of the designer.

The idea started to come to me as I worked on card game and board game design prototypes - this, I realized, was a very pure form of game design. Though "table game" design gives you a limited set of tools compared to those you have on electronic games, it can really open your eyes as to what the core of game design really is.

I've believed for some time that, structurally, a game is comprised of only 3 things:

1. Nouns - Elements of your game system, and variables related to them. Example: Players, avatars, NPCs, items, a map, a world, locations, tiles, cards, XP, HP.
2. Verbs - The actions that agents (players or player stand-ins) in your game can enact; the "things you can do." Example: Attack, jump, move, bribe, play card, roll dice
3. Rules - Rules, which limit the nature of the existence of the nouns and create relationships and interactions between them; and which limit which verbs can be enacted when and in what context. Example: "draw a card at the start of every turn"; "when a unit attacks another unit, it does damage equal to the attacker's base damage value"; "when Mario is not on the ground, gravity pulls him down at a rate of acceleration of 1 pixel per millisecond".

Every game has these three elements, and I think that games (in terms of a formal structure) are solely comprised of these three elements. (In fact I theorize that all systems can be defined by these three elements, and that the "engine" I'm about to propose might be a new approach to developing not just any type of game, but any type of software. But for now I'm sticking with the domain I understand best: games).

Given that this is the structure of any game, shouldn't a proper game engine be focused on, first and foremost, modeling these three things, and making the creation and modification of them as straightforward as possible? A few game engines seem to do this, but in very specific ways which don't seem to get to the heart of the matter.

What this comes down to is that I feel that current programming paradigms do not provide an appropriate language for expressing these structures. This may not be true for the "nouns" element - Object-Oriented programming, as its name implies, is very good at representing different types of objects ("nouns") and the relationships they may have between each other, with minimal duplicated code or wasted work.

But both verbs and rules are hard to express clearly in any programming language I know. In particular I think that rules (which I see as the more important and often-changed element of game design) can often be difficult to represent in existing programming/engine paradigms.

Let's say I'm developing a platformer and I want to add rules that say "when you jump on any enemy's head, it dies", but then add an exception that says "when you jump on a porcupine's head, it survives and YOU die". In current Object-Oriented programming paradigms, I'm probably going to express this by 1) adding a "jumpedOnBy()" function to the Enemy class with a body of "die();" ... and 2) overriding that function on the Porcupine enemy class with a body that says to kill the player instead. (This is not exactly how I would actually implement this but it's close enough for the point I'm making.)

The point is that the habits of Object-Oriented programming lead me to instinctively express this rule as properties or behaviors of the nouns. I think this habit is inappropriate: each rule should be represented as an object in its own right; and conceptually the rule should in fact be an element that "controls" the nouns and can modify them. But our current typical representation of rules doesn't do this at all.

Instead they find themselves poked and prodded into various places in code. It's rare, in gameplay code, to find a rule that is even concisely expressed in exactly one place in code - in other words, it's rare to find a 1-to-1 relationship between "a game rule" and "a chunk of code."

As I think this through now, I think that perhaps the biggest, paradigm-shifting implication of coding this way would be that nouns do not have behavior of their own. In a game of Monopoly, the Thimble on the board has no behavior of its own; it just has the capacity to rest on different locations on the board. It is verbs that put the thimble into motion (a player initiates a "move" verb), and it is rules that restrict and define that motion (a rule states that the player performing a move verb must roll the dice and move the thimble that many game spaces in the forward direction).

If we believe that our code will be cleaner and more maintainable if it structure matches the structure of the conceptual objects that we're actually representing, then we should move gameplay code to a paradigm in which Nouns have no behavior of their own; and push to make Rules and Verbs first-order objects.

Furthermore, this should be extended to the point that Rules are entirely data-driven, and can be defined entirely by designers using engine tools. My ideal game engine looks like this:

• The Gameplay Designer can add Rules into the game engine using a straightforward but robust engine for expressing those rules. (They also define Nouns, and have some capacity to define Verbs.)
• They can then immediately play the game with these rules being applied by the game exactly as defined. They see where the rules fail to create the behavior that they want, and can easily modify those rules and run the game again.
• That's it. There is no Gameplay Programmer in this workflow. It's kind of like the Game Designer is sitting down and defining a board game design, playing it and iterating on the rules... except that this game happens to automate all the enforcement of the rules, allowing them to make much more complex games. Because that's all that video games are.

All right, this is a grand high-level vision of intentions, but how exactly do we go about it? I gave a counter-example with the "jumping on the porcupine head" rule and how we shouldn't be representing that; but where's my example of exactly how we should?

I'm afraid I haven't gotten that far; I only have the glimmer of an idea at this point, and I feel like throwing out my half-baked answers wouldn't help anyone. But, it's something I've thought a lot about and would like to spend more time researching. Googling for "Rules-Based Programming" has been encouraging, as it turns out that there's a substantial amount of existing knowledge for programming frameworks that work along these lines; but I haven't yet explored them thoroughly enough to determine whether they truly apply what I'm trying to get at here.

The "hard problem" here is representing rules as abstract entities. The fact is that a "rule" is something that we as humans have a very loosely-defined idea of. I don't know if there's a single language that can be used to express any and all possible "rules"; perhaps the only language that can actually do that is human language itself.

But perhaps it's not as hard as all that, and we need to simply sit down and take this abstract ideal and determine what concrete form it could take. Or perhaps someone out there has already made significant strides in this direction, or an entire engine based around this, of which I'm unaware.

My main hope is that this blog will spark more thought and discussion on the topic; lay out a (very vague and high-level) ideal we can work towards; and hopefully that someone will even point out to me a paradigm that already represents gameplay code in this way, or at least is a step in this direction!

Back to work!

Finally, a cooperative game - one that, unlike Arkham Horror (see my previous posts), can actually be comprehended by a human being and completed in one sitting! In fact we played 4 games of Pandemic in a single evening (though I'd call 2 of them "half-games" - we aborted them early on after making mistakes). Pandemic is a game in which the players work together to attempt to cure outbreaks of 4 different diseases across the world.

This game was what I was hoping Arkham would be: a game where we're all fighting together against the game system, which unfolds itself based on card draws and simple rules (that can nonetheless have interesting results). This is definitely a challenging game - we didn't win on the first try (in fact we didn't win until the 4th try)... but that felt like an appropriate challenge level, and the fact that we had time to tackle it multiple times with a "trial and error" approach was great.

What I really want to talk about though is some interesting behavior that we started to demonstrate, one that's is probably very common to cooperative games. Like in most games, I had a "character" I was playing, an avatar that I was (supposedly) controlling on the game board - so did all the other players. We even had very distinct characters as we each had a special ability. However, from the very first turn, all of us began planning and scheming for what all of the players would do.

At first this sounds like a great thing: we're all cooperating, we're deciding strategy and conferring together, and our characters are totally working together and coordinating their movements.

But I think there's a real downside, or at least a strange disconnect, here: none of us ended up having any real connection with our avatars. The actions my avatar took were never really my decisions, they were our decisions. Functionally, we 3 players were acting like a committee that decided what the 3 characters on the board would do - there was no individuality, it was like being part of the Borg collective.

A demonstration of this, and some of the clear downsides of this, came when a 4th player joined us for the last game. She was immediately left behind by all the strategizing that the rest of us were doing - we were navigating around rules and obstacles that she was still learning. Worst of all was when it came to her turn - the game almost became a situation in which the 3 of us were going to simply tell her what to do, possibly without her even fully understanding why she was doing it (since she was still learning the game)! We managed to end up avoiding this problem and certainly there were no hard feelings... but this "decisions made by committee" dynamic, which seems to emerge inevitably in the game, clearly has some negative sides to it.

Interestingly, in the D&D campaigns I've been part of and observed, this doesn't happen as much - even though the party is effectively another cooperative group, I've observed relatively few instances of players deciding their actions "by committee" - certainly it never becomes like Pandemic where almost every single action was being decided collectively. It would be easy to say that this difference is due to D&D being a "role-playing" game and the player and their character having a special relationship. But I think a larger element may be complexity - D&D characters have complex builds, and often many options available. The question of what each character even can do, much less should do, is much less clear to the players who didn't build that character - it's often the case that only one player understands how to "drive" each character.

All this really makes me want to try to play Catacombs - I heard about this on a Games With Garfield podcast where Richard specifically mentioned this aspect of cooperative games. Catacombs' core mechanic involves players flicking game pieces into each other - although this may seem like a turnoff to more tactical and strategic players, it seems like this would bring more individualism back into the game, including each player making decisions based on their own confidence in their ability to make certain shots... preventing the game from falling into being a "Borg collective."

Anyway I did have an interesting and enjoyable experience with Pandemic, though somehow I doubt it would hold up to many repeated plays.

Puerto Rico shares one element with Dominion, which is that there are "decks of cards" on the board, and during one phase of the game players get to pay costs to draw them and add them to their "colony." Your choices here let you define your strategy, and again these elements can have interesting combos with each other. I love games with such element of "customization" - finding a unique strategy of your own and working towards it really adds a unique element of self-expression, which is just really addictive to me (and of course it comprises one of LeBlanc's 8 kinds of fun).

Puerto Rico has an interesting structure in that there are essentially 6 different verbs available, but each player must choose to activate only one of them per round. However, you can't choose a verb another player's already activated this round! (Note: This is actually a very incomplete description of that part of the gameplay.) I love this element - making verb selection a limited choice, and one that can be affected by other players' choices, seems like a place where some simple rules can lead to significant depth - for instance, in this game I would sometimes choose to activate a verb simply so another player wouldn't be able to do so.

That leads me to what I hate about this game: it forces players to be passive-aggressive. I'm realizing this trait is common to Euro-style games: they seem to avoid "direct attacks"... yet these games are still usually competitive. The end result? I can still screw other players, but only in odd indirect ways. Maybe it's because I'm such an American (and as my wife says, I "don't speak subtle"), but this just feels more frustrating to me. (This isn't a reaction to my being screwed in the game by the way: I actually won my first two games of PR, primarily by screwing the other players in these ways... I just felt guilty about it!) This was most pronounced in the "Shipping" phase of the game, where a complex cluster of unintuitive rules (which all seem to say "you can'ttake very specific action X" - another pet peeve of mine) results in some very non-obvious but important ways in which you can indirectly screw over other players - sometimes very dramatically. Ugh.

To start to pick up on my sad rate of updating this blog, I'll start publishing more of these "reviews"... these are definitely from the perspective of a "student of game design", not even sure if I should call them reviews.

There's no quality of a game's design that I hold in higher regard than its being "easy to learn, impossible to master." Dominion is one of the best examples of this quality I've seen in a long time.

I'm an avid player of the WoW TCG (which is very similar to "Magic: The Gathering"), and my favorite part of the game is deckbuilding. Dominion essentially takes the "meta-game" of deckbuilding and turns it into the game itself; but it's simple enough to be picked up by those with no prior exposure to TCG's. Selecting cards, building combos, slowly iterating on and strengthening your deck - these are all done turn-by-turn, competitively against other players. Of course this means the game still includes the most exciting element of TCGs (to me at least): cards can combo in interesting ways, sometimes exactly as you planned, and other times in ways that you never saw coming.

Perhaps the most brilliant stroke is that the game can be setup very differently each time - in each game session, your decks can be built from 10 different card types, but the game includes something like 30 card types - you can choose which 10 card types are "in the game" for each session. This can lead to very different games from session to session, and the card types chosen (perhaps randomly chosen?) will greatly alter the style of the game. For instance, you may include many "direct attack" cards (making the game more directly competitive), or you can include none of those cards (and end up with players competing only indirectly -"playing solitaire at the same table").

Great game, would play it with anyone!

But there's are other reasons why I'm a fan of Flixel.

I'm a game programmer and a game designer; and on some issues, those two sides of me are at war. Flixel is one of those: in terms of following solid programming principles and good engineering practices, Flixel is far from ideal, and in fact is rife with practices that good engineers would advise against (like heavy use of global variables).

But the designer side of me wins out in this argument. You see, the game designer in me only wants to do two things:

1. Think up the rules for a game.
2. Implement those rules as quickly as possible.

If you can't do those two things, there is no game. It doesn't matter what kind of graphics, sound, music, particle effects, lens flare, cutscenes, dialog, characters, or story makes up your "game." If it doesn't have rules, then it's not really a game at all. (Remember, you can make a compelling experience without making a system of rules, but you can't make a game without rules. And if you're only concerned with making a compelling experience, you probably shouldn't be making games at all - making films is much cheaper, much easier, and gives you much more authorial control over the moment-to-moment experience.)

But I digress; let's return to rules.

Ultimately, being a gameplay programmer can be boiled down to one simple job:

Taking the rules of the game, and writing code that implements and enforces those rules.

That's it. Therefore, as a gameplay programmer AND as a game designer implementing his own designs, I'm a huge fan of Flixel. Why? Because it is an engine in which a single game rule can usually be expressed in a minimal number of lines of code.

Take collision. Collision of 2D objects has been part of games since Spacewar. This might lead you to think that it's a trivial problem to solve; but that's not the case. I've burned many hours writing and re-writing 2D collision code, and even then it was rarely perfect.

Flixel provides a solid and very robust solution for 2D collision. And best of all, almost every "collision rule" can be expressed in a single line of code. If you want the player to collide with enemies, you express that with this line of code:

FlxU.collide( player, enemies );

That's it. This is the type of attitude Flixel seems to take towards everything: in Flixel, everything that feels like it should take only one line of code, usually actually does take only one line of code!

The ideal game engine would be one in which each and every rule of the game could be written in plain but unambiguous English, and the game engine would simply interpret and enforce these rules. I actually have some ideas in mind for how something approaching this ideal game engine could be created; though I doubt I'd ever have time to properly explore such a project.

Until then, we must express our rules with code. But we can, at least, choose game engines that take care of everything possible EXCEPT our rule implementations; and in which our rule implementations can be expressed in the most simple, maintainable code possible.