All Games Are About Choices
Today I read a very thoughtful blog post by a game designer who I greatly admire, but with whom I absolutely disagree: Chris DeLeon wrote a scathing dismissal of the argument that games like Galaga are based on interesting decisions. (That argument was itself presented in response to Chris' previous blog post, titled "Many Games Are Not About Choices.")
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.
Quick Connectrode Update
Deep Plaid Games' latest game, Connectrode, has had considerable success to date; I thought I'd post a compilation of some quick data and links:
- 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!
Why Connectrode costs $.99 (…and why it shouldn’t have to)
Over the weekend I released a game that represents many hours of work, most from my own spare time: an indie puzzle game for iOS titled Connectrode. The release of the game is a big moment for me and I could probably write 1,000 pages about its development...! But instead I'll restrain myself and just use the game as a springboard to blog about some related game development topics I've wanted to blog about. Today I'll talk about the business side of things... and especially the state of the iOS App Store.
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:
- 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).
- 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.
- 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]
Connectrode on App Store!
Just a quick note here that the puzzle game I've been working on for the past ~8 months (entirely in my spare time, with some very talented game developers here in Austin) will finally be released on the App Store on July 2nd. Exciting times!
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!
Towards a “Rules-Based” Game Engine
I'll be doing a series of posts shortly about the iOS puzzle game I just designed ("Connectrode") and submitted to the App Store this morning. For now I thought I would "detox" from that project by writing about something else that interests me. Warning, this is a fairly off-the-cuff attempt to express some very abstract ideas about both game design and programming - I haven't necessarily polished these ideas into the most comprehensible language, I'm mostly just writing this to get the ideas out of my head and onto paper.
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:
- 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.
- 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
- 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!
Finishing a game, on a Twitter tear
Sorry for the lack of posts, but I thought I'd note that 1) it's due to me finishing up a puzzle game of my own design that I'm very excited about, titled "Connectrode"; and 2) I'm literally finishing up Connectrode as we speak and am kinda live-tweeting as I add the finishing touches. Follow me on Twitter at @IQpierce to keep up with the action...!
Back to work!
Pandemic: “The virus can only be stopped by the Borg Collective!”
[This is another in my recent series of board game "design reviews" - these are reviews less focused on the quality of the game and more on what interests me about them as a student of game design. Today's game: Pandemic.]
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: “We sent all the passive-aggressive people to THIS colony.”
[This is another in my recent series of board game "design reviews" - these are reviews less focused on the quality of the game and more on what interests me about them as a student of game design. Today: Puerto Rico.]
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.
Dominion review: “Makes constructing broken Magic decks even more fun!”
Lately I've begun attending (sometimes hosting) a Board Game Night with some other game developers here in Austin, and have finally been getting exposure to a lot more board games... I guess these are best described as "Euro-style" board games, or maybe "you will not find these in Toys 'R Us" board games. Speaking of which, for some reason my repeated proposal of playing the Saved By The Bell Board Game at these events never goes over well... maybe someday I'll be allowed to share the joy.
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!
On Implementing Rules
As you might have noticed if you've followed my work over the last year or so, I've become a huge fan of the Flixel engine. Part of this has to do with the fact that the engine is open-source, and was developed here in Austin. (It might also be because I have a major man-crush on Austin indie game developer Adam "Atomic" Saltsman, who created the engine.)
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:
- Think up the rules for a game.
- 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.