Deep Plaid One guy trying to make some interesting decisions

Flixel Game Jam: “Terminal Velocity”

Posted on January 26, 2010

If you like falling onto spikes, this game is for you.

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.

Since playing Canabalt, I'd been trying to think of some "single button" game designs myself (and I guess I even succeeded in making one on my own recently, though I'd hardly compare it to Canabalt). I'd only been able to come up with one half-baked idea, which I suggested, and which was technically a "two-button" game. Essentially it was to take one very specific part of Super Mario World and build a game around it... the portion in question being from the "Sunken Ship" level... a very looong chamber that you freefall through for a couple of minutes straight, adjusting your fall from side to side while trying to avoid being hit by enemies.

I explained the idea, and as we talked about it, it occurred to me that this game would be "reverse Doodle Jump" - less than a minute later, someone made the same observation! I've been playing Doodle Jump pretty obsessively since I got it a couple weeks ago, and whipped out my iPhone to show it to some of the guys who hadn't seen it. Comparisons were also made to "AaaaAaaaA - A Reckless Disregard to Gravity", and later to the Adult Swim Flash game Mountain Maniac.

Anyway, surprisingly, everyone seemed immediately enthusiastic about this idea and seemed happy to move forward with it. Phil seemed a bit skeptical about a core part of my concept of the game, which was that when you finally hit the ground, the game was over - and that the only point of the game was to "stay aloft as long as possible", while hitting the ground and ending the game was inevitable. I think perhaps he preferred the idea of something like Canabalt or Doodle Jump, where failure was inevitable sooner or later, but where you could in fact play indefinitely if you never made any mistakes. The fact that "the game is over when you hit the ground" seemed to be one that was a bit hard to get across - at some point, going off of some spikes that Phil had drawn on the whiteboard, I proposed that the entire ground was made of spikes, so that hitting the ground had some real finality to it.

A design direction that Phil and a couple of others got behind was the idea of slowing yourself down - that you wanted to avoid achieving a certain "terminal velocity" (which ended up being what we chose to call the game - second choice was "Freefall", and third choice was "AaaaAaaA" - the same as our inspiration, but with one less "A")! The idea was that you wanted to avoid achieving this velocity because it would kill you when you hit the ground; or perhaps kill you whenever you hit some other otherwise-innocuous object in the air. At one point I believe we had code in place to simply kill you if you passed a certain speed. I pointed out that this was a bit of a different direction that what I was thinking, which would be a "bouncing-heavy" experience; we ended up stating that we would build a "core engine" first, and then (since we were surprised at how many people had showed up and felt that we might have too many people for such a simple game) we might split into multiple teams that would explore these different directions, while sharing resources and code.

In the end that didn't really happen. We spent some time on logistics - first we set up a DropBox account, only to decide that hosting off of one person's network drive was simpler and faster. But I'm a big advocate for SCM, and thankfully one of our key programmers, Doug Daniels, took up that cause as well and set up a Subversion repository on Google Code. Phil and some others were a bit resistant to this, but I could tell that with the number of people we had (at least 5 of us were programming, in a pretty small handful of code files), the "claiming files" and "clobbering each others' code" issues were going to get out of hand fast. We ended up with most of us programmers working off of the SVN repository, while the artists kept throwing their stuff onto the network share on Doug's laptop (where he would quickly submit those assets into SVN for the rest of us). There was one primary artist, Justin, and later two other young guys, Scott and Jordan I believe, came in with one laptop between them and ended up sitting in the corner and cranking out a lot of random but nice art - including the rather eclectic collage that currently makes up our background (until the background unceremoniously runs out, that is)! Another guy named Michael apparently knew some programming, but decided to be our music and audio guy instead - and did a really swell job I might add!

In space, no one can hear you ask what is a hot air balloon doing out here? And do I still have legs?

In space, no one can hear you ask "what is a hot air balloon doing out here? And do I still have legs?"

As I said, and as you might have predicted anyway, the whole "make a core engine and branch it" idea never really happened - we ended up spending most of the day just getting our "bare minimum" core gameplay implemented - falling, dying, and having static "bounce obstacles" and "slow-down obstacles." I quickly saw that we would need a random level generator, and set to work putting one together - I'm pretty proud of the technique that I used, and of the way that I divided the task up into making a solid-but-extensible "architecture" first, then integrating it into the rest of the game, then coming back and extending my foundation into something much more useful. As I said I'd been playing a lot of Doodle Jump and noticed that their obstacles were divided into pre-made "level chunks" that were then scrambled into random orders each time - if you play many times, you'll notice the same sequences of obstacles crop up from time to time. I went with that model (like I said, this game was just reverse Doodle Jump); though I made the architecture extensible enough that later that evening, I was able to log on via SVN and submit one last elaboration, a "level chunk" that really just generated a totally random series of 5 obstacles; this did a lot to add variety to the game.

It wasn't without its snags. Though I consider myself very nearly an expert at ActionScript 3, I had always worked with the Flash IDE (which many programmers seem to marginalize, but which I think is extremely useful for giving artists a mature and flexible tool; for taking UI and layout specifications out of code and putting them in a visual tool, which is where they belong; and for providing a handy form of a "state machine" for UI and other visual elements, in the form of frames). But this project was being done in Flex. Luckily this didn't turn out to be a significant obstacle - I simply downloaded the Flex SDK. I was already used to doing my AS3 programming in FlashDevelop, so once I had integrated it with Flex, I was up and running.

Or so I thought. Eventually it turned out that I was breaking the build with runtime errors, but that for some reason I hadn't seen them at all. Turned out to be a simple matter of pointing FlashDevelop to the right Flex directories, to launch my SWFs with the Flash debug player so that I could get my errors/stack traces. Another programmer, Norman, helped me pin this down - since, embarrassingly, I was blocking him until I fixed my runtime errors! Luckily it didn't take too long to resolve this issue and get running again.

Things went quite smoothly for a while; Phil picked us up a pizza from across the street - apparently last time they did this they went out for lunch and it ended up blowing about 1/4 of their available time, so I'm glad he decided to eat in and keep our momentum high. It was a great time for coding - Norman and I were working in the same classes (he was making obstacles, and I had to make stand-in obstacles to have something to put into my level editor, and my Obstacle class had a slightly different approach than his); we might easily have stepped on each others' toes, but with clear communication we were able to keep on the same page and avoid any miscommunication.

At the very end things started to come together very quickly - within two hours we went from a white block that would fall and touch random red blocks that did different things, to a game with a score onscreen, a recognizable pixel-guy avatar for the player, recognizable spikes that always showed up at the bottom of the level, and three clearly-distinguishable types of obstacles (spikes, bounce obstacles, and slowing obstacles). Within the last few minutes of the jam, I added the foundation classes for "Creature" obstacles that weren't fixed and could move around, and got a simple "BounceCreature" implemented - a balloon that floats up. I'm glad I did as these moving elements make the game hugely more interesting than when there were only static obstacles. Phil and Norman also ended up working on the under-appreciated but crucial task of setting up the "screen flow" for the game, transitioning properly from opening screen to gameplay to "game over" (but only after a delay to show you our neato death animation) and back again.

It was satisfying to have everyone in the room gather around one laptop and see how it had all come together. It was still a little rough though - I particularly found that it was too easy to start falling so fast that it was impossible to react in time to obstacles that would scroll up. That evening I logged back in via SVN and decided to add my random LevelChunks, and while I was at it, go ahead and tweak the player physics numbers to the Mario-style feel that I had always envisioned. I put a cap on the maximum velocity (trivial in Flixel), which made the biggest difference. I think the feel ends up being pretty good, though it could probably be tweaked still further.

The result can be played here, on Phil's site; it's far from polished, but it's certainly playable, sometimes fun, and rather promising - though I don't know if I'll have much time to work on it in the future as I have some other projects demanding my attention.

But my day with Terminal Velocity was a happy and exciting one - it's always gratifying to see your ideas embraced, and to see these guys run with it and give it life was incredibly inspiring. I hope that the stars align for me to attend more of these things, it was fairly educational and terrifically fun.

Comments (1) Trackbacks (0)

Leave a comment


No trackbacks yet.