(If you're a Mac user, or just don't like pressing Ctrl, you can use the 'W' key or the up arrow to move your ship in the game. In fact, there are lots of extra controls available if you look for them, to suit all sorts of tastes. See if you can find them all!)

Here's my new game Scataract. I hope you like it.

(Its permanent home is here. I prefer to play it there because this page is a bit too bright.)

Last November I decided to program a little game for the logo of my site. I make games and teach game development for a living, and I thought it would be fun to show a game playing at the top of all my web pages. (It's not on this page, but look here, for instance.)

I whipped together the quickest game I could think of: old-fashioned vector graphics because they're easy to make and nostalgic; a space-shooter theme; simple AI; just two or three enemy types. It took me just an evening or two, but it proved to be pretty fun. (continued below...)

Not fun enough, though. So I disabled player control and made it run in standalone mode in the upper left corner of each page.

Around the same time I got up the nerve to do something I'd wondered about for several years. Ever since I saw the game Blinx, I'd been thinking about how to do time-reversal effects. Actually, I got most interested in it while working on Brothers in Arms, because we often had AI problems that were difficult to debug because by the time you saw them, it was too late to figure out why they happened. We needed a way to go back in time. That way we could pause the game right before the bug happened and examine the situation that caused the bug.

Actually, I first started thinking about time travel in games when we were developing Ultima IX: Ascension. I thought it would be cool to have a situation where the player encounters himself in the game—a version of himself from the future—and the choices he makes in interacting with himself affect how he experiences the event later when he is the Avatar from the future. So if you decide to give your future self money, then later when you encounter your past self, he'll give you money. If you decide to beat your future self to a pulp, then your past self will beat you to a pulp. We didn't end up putting this into the game. Seems like somebody should do something like this eventually, though, shouldn't they?

Anyway, so time travel in games = cool.

So last November after working on the site logo game I got up the nerve—as I was saying—to code up a system for manipulating time in games. It's not rocket science, actually. I do the obvious thing: I save the state of every (significant) object on every tick. This amounts to a lot of data, so I only save the last 30 seconds or so. When it comes time to restore the state of the world, I do three things: (1) update the state of all objects that exist both at the current time and the new time, (2) add any objects that exist in the new time but not the current time, and (3) delete any objects that don't exist in the new time but are in the current time. When I've done all that, I've traveled in time. Pretty simple, really.

I implemented this in Flash, and now the game has the ability to record itself as it plays, then pause, go backward, go forward—it's an in-game VCR.

I decided to take my simple logo game and add this time-warping feature. Like in Blinx (sort of), the player could pick up powerups to cause time to pause, to move slowly, and to reverse. If you play Scataract, you'll see those powerups are in there.

But then I got fancy, and it nearly drove me crazy. I decided it would be neat if one powerup would record the player for several seconds, then rewind the recording and let the player play along with his or her own original actions. Now you can have two players at once—a single-player cooperative game.

This in itself wasn't too hard, and that feature is in there—it's the Record pickup. What was hard was a feature that didn't make it. Let me explain.

In the source code, the "Record" pickup is actually called the "Fork" pickup. The idea is that when you record and playback yourself, you're "forking" a new version of yourself. Fine. What I wanted to do was to allow you to pickup new fork pickups while you were already forked. Then you could make forks of forks, and forks of forks of forks.

Potentially you could have an infinite number of recordings of yourself playing alongside you at the same time. In practice the number would be unlikely to get above a handful because the chances of finding more than a few fork pickups at a time were slim. Still, it would be pretty zany to see two or three versions of what you did in the past all fighting bad guys alongside you.

Well, this "Infinite Forking" feature is what nearly drove me crazy. It proved to be excruciating to manage, and after battling bugs for a couple of days I decided to save it for the sequel. ("We're saving that feature for the sequel" is what game developers say when they mean, "We are cutting that feature and you will never see it again." This is analogous to when publishers say, "We're putting this project on hold," when they mean, "We're canceling this project. Good riddance.") Sorry you can't battle alongside more than one copy of yourself. Your ego will just have to put up with battling alongside one copy of yourself.

I programmed all this time-traveling and -forking stuff over the Christmas break. It seemed like I was nearly done with the game. I always forget: the first 90% of a game's features takes 90% of the time; the last 10% takes the other 90% of the time. There are so many little bits and pieces in a game that you hardly think about but they all add up: the high score table, the main menu, the instruction screen with its little animations, the hints at the beginning of the game if the game senses you're an idiot (seriously, they're in there), the little compass pointers that tell you where everything is, the view shaking when a big explosion goes off, the little particles that fall into the black hole that you'll never notice consciously but that subconsciously tell you "STAY BACK!" These hundreds of little tasks amount to days and days of work.

Plus there are all the features I slaved over that amounted to nothing. Did you know there are asteroids in the game? Yep. The art's there; the audio's there; the code is there. Boy, is the code there. I coded a whole billiard ball collision solution so that asteroids would bounce neatly off of each other as you plowed through them with your ship. For a while, the 4th level out of every 7 levels was an ASTEROID WAVE, and there were dozens of asteroids floating around, ricocheting off each other and generally having a jolly old time. But there were two problems. First, there was an annoying bug that caused asteroids to spiral out of control after time travel had taken place—time sickness, I guess. Second, they just weren't fun. They were a big bunch of obstacles floating around in space. Obstacles—at least obstacles without payoff—aren't much fun. So I got rid of asteroids. Well, I saved them for the sequel.

All told, I spent probably about three weeks on this game, spread out over bits of weekends and late nights (like this one) over the last six months. Why do I do it? I'll make no money from it. You people don't click banners—neither do I—there's no revenue there. As a game developer, this doesn't even look good on my resume. It's a Flash game, for crying out loud—that's like programming in diapers. (Like programming in diapers with a leak, more like. Don't get me started. Well, except actually I love Flash—I once told a Sunday School class I hoped heaven was like Flash. Just, without all the bugs. And the molasses-like performance.) Why do I do it?

The truth is I love to make games. Since I was ten years old, puzzling over assembly on my Atari 800, I've loved to make games. I loved making games enough to give the best part of 12 years to it. But here's what's sad. Frankly, most game developers don't make games: we make bits of games. Little pieces. Fragments. A sound engine. An installer. A weapon system. A jump animation. Thousands—millions—of little pieces that when smashed together become—hopefully—a game. Occasionally, they even become a fun game. And rarely—oh so rarely—they even become a successful fun game. And that, my friends, is a beautiful thing.

But it still leaves thousands of game developers around the world spending their days building pieces instead of ripe, whole games. And there lies the answer to my question. Why do I make weird little Flash games? Because somewhere deep inside me (queue violins), there's still a ten-year-old boy with an urge to make stuff blow up on screen. For him, Flash is the shortest path from here to game-making nirvana.

Look, Ma, I can make a game all by myself.

Labels: games