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!
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'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!
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!
[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.
[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.
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!
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.
A YouTubevideo is up of the 10-minute "microtalk" I gave on prototyping - I previously blogged about this and posted the slides here.
Here's the video! Thanks to the local Austin IGDA chapter for providing it, and for making the event possible.
Unfortunately it looks like this video has pretty poor audio, and my slides aren't clearly visible. Oh well, at least it's there for posterity if nothing else; and if you really wanted to you could probably make out what I'm saying and follow along with the slides themselves, found here.
I (and a team of 8 others) made a new Flixel game: it's called C.O.O.P. It's a Flash game, but to play it properly you need two players at the mouse/keyboard!
Move up/left/right/down: W, A, S, D
Shoot up/left/right/down: Arrow keys
Place object on game field: Click there.
Choose object to place: Click on buttons at bottom of screen, OR use the mouse-wheel.
How we made it: I led a team of 9 people in creating this game in 48 hours; it's built using the Flixel engine. It was intense, and some things about the final product are a little rough, but I'm very proud of what we accomplished!
Gameplay: One player is playing the game as a top-down shooter, using the keyboard. The other is playing something more like a tower defense game, placing items on the game field using the mouse. Both of them are cooperating to keep the "keyboard player" alive. This was the high concept I came into the jam with; the team agreed to run with the idea (our second choice was a game about getting pandas to mate - the theme of the jam was "extinction"); and run with it we did.
We're planning to clean it up, add a single-player mode, and try to sell it to a Flash portal - we'll see how that goes.
I'll write up a more detailed "postmortem" of the development process within the next few days, watch for that here. If you have any feedback, I'd love to hear it; just leave it in the comments below!
Me, Laura, and our friends Harvey and Leah sat down to finish our game of Arkham Horror (which we had "serialized" after our first session by taking a number of photos and putting a lot of stuff in separate plastic bags). Though we played for a couple more hours, we still felt we were far from actually finishing a game, and chose to simply let the game die this time. Still, I think I learned a fair amount from the game - I figured I'd write it down here so that our experience felt like less of a waste of time!