Over the weekend I made a little experimental game about quantum mechanics. This was a good way of taking a break from my "real" projects and recharging my batteries, creatively.
So. I kinda made this game on accident...
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.
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!
I've been working in the Flixel engine lately, and the more I learn about it the more I like it. I decided to give back to the Flixel community by adding a new feature for the engine: the ability for to load variables from a Google Spreadsheet, allowing dynamic tweaking of numbers in your game, with the ability to see your changes in action, without even having to re-launch the game!
I thought I'd make a post describing why this type of feature is important, and use it as an excuse to talk about rapid iteration and its applicability to game development on multiple levels: building it into your workflow and your gameplay!
Last night I gave a 10-minute long "microtalk" at an IGDA Austin meeting, sharing my experience gleaned from developing various game prototypes, especially my work at Blizzard.
I just exported the slides, which are heavily annotated; you can download them here as a PDF. If you were at the talk and wanted to see the list of prototyping technology choices I recommended in more detail, now you can grab it.
Whenever the YouTube video of the talk goes up I'll share that too.
I had a great experience this past Saturday attending the Austin Flixel Jam, an "indie game jam" where about ~11 guys met up to make a game in one day - specifically 6.5 hours (which is as long as the library would let us work in one of their offices).
I showed up knowing no one, with no idea what to expect - a true "dive in headfirst" scenario. I met the host, Phil Knoll, a very cool guy, and chatted with him about my experiences at Blizzard and SOE - small world, he's indirectly done some outsourcing projects for SOE Austin and knows a couple of my friends there.
Finally some more guys showed up and we began talking about what we were going to do. I had expected that Phil, the organizer, might have had some pet idea already picked out; and that every single guy who showed up would probably have their own ideas as well... in short I expected something of a fight over who would get to make their game idea! Instead something very different happen: Phil mentioned that he thought we should make a game like Canabalt (the most well-known game made in the Flixel engine we were using). In particular we all felt the idea of a "single button" game seemed ideal.