Toaster Bro alpha: 10 days later

Did I mention my new game, “Toaster Bro”? Play Toaster Bro alpha version 1!

(You will need Flash Player 10.)

Ten days have elapsed since I shared this version with friends (who are unwittingly being used as play testers). It’s time for a “wrap-up” meeting, because I want to examine what went wrong/right, and instead of a meeting it’s a blog post:

The tile engine has existed for half a year. Toaster Bro began its life as “Roomhack”, one of the pet projects Miles and I dreamed up — could we create a game that was Turing complete? In the tradition of Robot Odyssey, we wanted to create an experience that was both programmable and entertaining.

During the development of Space Kitty, we used its script engine to change the rules of the game at runtime. Once, we configured a cat to act as an “attack cat”, which chased (and kicked) the player. We discovered new modes of gameplay — how long can you say aloft? Can you slingshot yourself around a dense star? (Ultimately, we ran out of time before we could make the Kitty-verse bigger. We’re currently discussing a Space Kitty sequel.)

The script engine whet our appetite — what if the player could modify the rules of the game itself? What happens to the gameplay? Can it remain challenging and fun? We talked about this for days, weeks… Hashing out ideas for an “ultimate” hacker game. I think we’re still talking about it.

I imagined such a game would resemble a dark, apocalyptic 3/4 view basement crawl, reminiscent of:

So I built the tile engine. The plot & aesthetic of the game were still unknown. Tavvv challenged me to invent a “missing” console from the NES-SNES era, devise hardware specs for it, and develop the game in accordance to the hardware specs. Constraints fuel creativity, right? I settled on SNES-era hardware, with a custom color engine, and improved sound. Television artifacts & blur could be exaggerated to make the game creepier; bosses would have extra blur and distortions, so you couldn’t get a clear image of them. The lurking horror. This concept was eventually dropped, once I realized that I’m not ready to develop a Turing-complete game… yet. I’ll come back to this project in the future, I’m sure.

“The tile game” evolved into a shooter, much like Smash TV but with a heavy-handed political bent. That still didn’t feel right, even with “a spider-tank with Richard Nixon’s head” in tow. In the middle of this confusion, we realized that putting hackable terminals in a tile-based game detracted from the appeal of both. Is there a way to allow hacking, within the context of a tile engine? From this fray emerged the Toaster Bro mechanic. I rolled a quick proof-of-concept. It seemed like we were on to something.

Then the game sat in stasis for a few months, while I worked and tended to life. I wanted to finish one solid level, and I imagined a 4-week timeline:

  • Week 1: Engine Malarky. Moving between rooms, easier wire drawing, electricity & fire shouldn’t hurt you, remove crufty code.
  • Week 2: Levels & Art.. Finalize the plot & characters, somewhat. Replace stand-in art with “real” art. On-screen text. Create a bunch of rooms.
  • Week 3: Audio, splash screen, boss fight, begin testing.
  • Week 4: Music, ???

This seemed like a good plan. Work began, but here’s how things really went down:

Week 1: Plugged lots of holes in the engine, but a single week wasn’t enough to tackle everything. There are major structural implications when you modify your game’s core. Still no way to change blocks at runtime, yet. I need a scripting engine, but I want one with infix notation (Space Kitty used various postfix notation languages, before Miles settled on an implementation of the PostScript language I think? It made my brain bleed.) I didn’t allot time for creating a scripting engine, but clearly there was a need for it.

Week 2: I’m not sure how the 8-bit NES aesthetic won out, but I liked it because it entailed fewer artistic decisions. The aesthetic had an entire era of gaming backing it. This seemed like a wise choice, because I’m not an accomplished artist, nor designer. I’m partially colorblind, in fact. Could I still cobble together pixel art?

I bought a Wacom tablet and books on animation, hoping to produce an acceptable look & feel. By the way, nearly every graphic in the game has been redrawn at least once. You should have seen the original sideways animation for Toaster Bro, it took a few tries to make him look non-crippled.

So I had a decent lead on the art, but bugs kept popping up. Fundamental pieces of the puzzle were still missing (no scripting engine, no on-screen text, player can’t die).

Week 3: I caught a bad cold, so I spent most of this week supine on the couch. I forced the “game” on a few people, and collected their feedback. All the responses were valuable, and people raised issues that I hadn’t considered. One tester said he couldn’t view the entire window, he was on a MacBook with its standard (small) screen. Oops! Sorry about that… I reduced the console’s “pixel” size.

The upshot of being sick was having lots of quiet time, during which I (slowly, groggily) puzzled out the scripting engine. Here’s what the scripting language looks like now, this is extracted from the first room on the Dark Chocolate level:


function clubDoor_electricity {
	i.isDoorOpen = true;
	call o.setBlock '__' 7 4; // empty space
	call o.setBlock '__' 7 5;
	call o.playSound 'doorOpen';
	call o.emotePlayer 'happy' 75;
}

function clubDoor_stop {
	if(i.isDoorOpen == true) {
		i.isDoorOpen = false;
		call o.setBlock '$L' 7 4; // lock
		call o.setBlock '$L' 7 5;
		call o.playSound 'doorClose';
		call o.emotePlayer 'sad' 75;
	}
}

The interpreter supports a large syntax, including: loops, switch/case statements, tons of operators, enterFrame yields, userInput yields, recursion … You get the idea. Variables are always referenced through a few specific objects, right now these are: thread, interpreter, owner (this is the Room that created the Interpreter instance), level, and global (or game). (These are all dynamic objects except for owner.) The script engine is decoupled from the code, I wrote a harness for it.

Also the 8-bit NTSC artifacts happened during week 3, somehow.

At this point, the game had a mere 3 rooms, all unsightly geometric slogs used for testing. Uh oh.

Week 4: Still a bit sick, and my real-world work schedule poked its head in, and needed some attention. The list of bugs & issues was huge; 30 items, including toughies like art and program flow.

I forced myself to draw the dreaded sprite animations. Infrequently, this was relaxing and zen-like. But in the wrong state of mind, it was taxing and disheartening. I’m using the palette swap trick from Space Kitty, so I stared at grotesque red, green and blue images all day, and felt sorry for myself. Definitely out of my league.

Also I hacked together a level editor using Flex components, accessible through a magic keystroke. It’s buggy and non-intuitive, but it’s better than editing the room layouts as raw ascii! Here’s how the final room in Mom’s Kitchen is stored:


[P,d [P,d [P,d [P,d [P,d [f,d ..,d ..,d ..,d ..,d [d,d [P,d [P,d [P,d [P,d [P,d
[P,d [P,d [P,d [P,d [P,d [f,d ..,d ..,a ..,a ..,d [d,d [P,d [P,d [P,d [P,d [P,d
[j,d [P,d [P,d [P,d [P,d [F,d ..,d ..,a ..,a ..,d [D,d [P,d [P,d [P,d [P,d [k,d
[J,d [h,d [h,d [h,d [h,d [i,d ..,d ..,d ..,d ..,d [g,d [h,d [h,d [h,d [h,d [K,d
[f,d ..;n ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;p [d,d
[f,d ..;q ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a #a,a #a,a #a,a #a,a ..,a ..,a ..,a ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a #a,a #a,a #t,a #a,a ..,a ..,a ..,a ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a __,a ..,a ..,a ..,a ..,a ..,a ..,a ..,d ..;q [d,d
[F,d ..;q __,d __,d __,d __,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d __,d ..;q [D,d
[i,d ..;r ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;s [g,d

I resolved to ride my bike every day, to avoid getting sick again. So far so good, but now I ride to coffee shops and spend a metric crapload of money dining out of the house. The hidden price of wellness…

Week 5: The list grew even longer. Lots of bugs, lots of missing features that I didn’t consider — the heart containers, the health bar. Dark Chocolate’s level was half done. The entity behaviors were unstable; the damage system was finicky, every Entity required too much configuration to properly interact with others. This needed an overhaul. I’d started thinking about unit testing, which I’d never tried before.

I drew Dark Chocolate, but with no behavioral code, he didn’t move. Fun fact: I saw his animation in a dream.

Week 6: Dark Chocolate’s level was finished, mostly. The boss fight took a day and a half to get right. You still couldn’t “win” a level. I always joked that the goal was to plug in a toaster. Hmmmmm…

Weeks 7-9: Sound design, on-screen text, Mom’s kitchen (the training level), giant toasters. Redrawing sprites. Bigger croissants (the laser-guards). Spotlights. Refactoring lots of code. The scripting engine is versatile, but not easy to use. In week 7, it was much clunkier than the syntax listed above. There were no switch statements, you had to write a list of consecutive if statements instead.

Days passed. The spit ‘n polish phase took forever. I sympathize with whoever said, “your code is always 85% done”. It sure felt that way.

Also I finally implemented unit testing. I tried ASUnit first, but it’s not very Flash-like; I believe it’s a direct port of JUnit (as evidenced by the Java code in its comments). If I’d realized FlexUnit was still in development, then I would have jumped on it, but… Long story short: I wanted to display failed tests on the stage, and ASUnit made that difficult. So I threw out the ASUnit code, kept my custom TestCase subclasses, and wrote my own Flash-centric versions of a TestRunner and TestCase (they both extend Sprite).

I can compile Toaster Bro in two ways: I have a Main.as class which will compile in the Flash IDE. But there’s also a Roomhack.mxml wrapper which creates a “developer” build, integrating the testing framework and level editor. When the developer build is launched, it runs every TestCase. If a TestCase fails, and if it has added children, then it’s displayed on the stage, with diagnostic messages & an execution trace. Failed TestCases can be dismissed with a click. I’m not “in love” with unit testing yet, perhaps because writing the tests after the code was tedious. I’m sure it will save my butt in the future, tho.

Week 10: Toaster Bro alpha is unleashed on the world!

Overall, feedback has been positive. Like Space Kitty, most people want the game to be longer. The negative feedback has been very helpful, pointing out specific problems which aren’t obvious to me, since I view the application as a whole now.

So, after writing this gigantic treatise, I figured I’d have some insights on how to improve the process. And you know what? I don’t.

Gamasutra had an excellent article on rapid prototyping, and their process echoes what we experienced on Toaster Bro and Space Kitty: Creativity can’t be scheduled, and you’ll spend a huge chunk of time germinating the idea in your head. We had 2 months to develop Space Kitty; we spent almost exactly 1 month dreaming up the idea. After that, the initial prototype took a day or two, and we were rolling.

With Toaster Bro, nearly half of the “serious” development time went towards polishing the game and making it presentable. This was a surprise, even though most of my interactive work has followed this pattern, too. The functional code is fairly easy to develop, but then you must meet the clients’ standards, and hammer the UI to find the rough spots.

Sound effects gave Toaster Bro an air of legitimacy. The difference was like night and day. Without sound effects, it was a shaky graphics demo; with sound effects, it felt alive. Hard to explain unless you’ve witnessed it.

Testers will comment on all the broken windows they find. I still hear about the missing sound effects in Toaster Bro (and yes, there are plenty!) But that’s okay, their feedback is always valuable. Occasionally they’ll have solid ideas on how best to fix a broken window, too.

What happens now? I have to produce more levels, art, and script. I’d like to believe that my productivity will ramp up, with so much of the infrastructure and assets completed. Sadly, I don’t think it works that way. I have big ideas for the remaining Toaster Bro levels, and these involve intense scripting. The second room of Mom’s Kitchen (where Toaster Bro learns how to use a wire, via 4 simple dialogs) is 131 lines of script, and it’s still not done — Mom should rush in and cheer after you activate the toaster, right? I can only imagine the length of the equivalent code in AS3. I want big effects & easter eggs. It will be difficult to develop and test these.

Whatever skills you have, I recommend bringing these into your projects, and emphasizing them, even leaning on them. I produce groovy electronic music, so I made a bunch of chiptunes early on, to help center my thinking. Some aren’t useable for Toaster Bro, they’re too active — they have the pace of Mega Man, rather than Zelda. It was good to realize that, it helped shape my thinking.

More to come?…

One thought on “Toaster Bro alpha: 10 days later

  1. Sound effects gave Toaster Bro an air of legitimacy. The difference was like night and day. Without sound effects, it was a shaky graphics demo; with sound effects, it felt alive. Hard to explain unless you’ve witnessed it.

    I’ve had this experience when editing movies. Rough dialogue and horrible acting will get smoothed over by background music and sound effects. It is literally amazing.

Leave a Reply

Your email address will not be published.