We opened Fire Hose in September 2008. At the time I was working with Ethan and Sharat, two programmers I knew from MIT. We didn’t have any artists so our skill set was pretty limited. We also didn’t have much in the way of tools or resources, so we were working with stuff commonly available on the interwebs.

Our initial goal was to make a game that was about architecture, and ideally taught the player a bit about construction. We were inspired by the fun of playing with legos and blocks as kids, and felt we could probably make a game that had some interesting roots in that while at the same time allowed players to do things they couldn’t normally do in real life. So we decided to spend a week prototyping some gameplay concepts to illustrate these points. I’m going to share two of them with you now.

The first concept we came up with for Ashdown (our game’s code name) was the Tree Prototype. Our thinking was that it would be cool if we could make a game where buildings organically grew themselves (an idea we would later revisit when with growing weapons out of blocks in SBS). In the game you use the mouse to click and the scroll wheel on the mouse to change the color of the “seed” you are planting – yellow for electricity, blue for water, and green for plant. The goal is to get as many leaves (foliage) as possible. Plant seeds automatically grow when placed on the ground, and yellow electricity seeds grow when there is rectangular steel beams for them to grow on. Blue water just stays on the ground unless it touches electricity and beams, in which case the electricity “pumps” it up the tower. Higher water means the plant can grow taller (meaning more leaves), but plants knock out electricity so you have to be careful. The counters on the bottom display game information.

The game also had a level editor, since at the time we were thinking user generated content (like in Little Big Planet) could be a really cool feature to put in. If you entered the level editor you could draw any shape of background beams to play the game on. It was basic but it showed off the functionality we wanted and was testable. The game itself was written in Python, and we borrowed code from the open source games at www.pygame.org, in particular Balloons by Gonazlo Sanchez.

The second concept we prototyped was the T-Rex Prototype, named after T-Rex from Dinosaur Comics (whom we borrowed as our bad guy). In this prototype the player’s goal was to build the tallest tower possible while preventing T-Rex from destroying it by stomping on it (since hey, that’s what T-Rex does!). The player starred as a flying superhero who could pick up beams and place them in the middle, and could also punch out T-Rex temporarily. As you can see there are a lot of core similarities to the final game, as rudimentary as it was here!

After we had these prototypes we invited our friends over to test, and we got lots of good feedback. Here’s what we found:

Tree Prototype Pros:

• Showed the most early promise for intricate, beefy gameplay.
• Had lots of potential for replay value and interesting level design.

Tree Prototype Cons:

• Mechanics were very difficult to understand
• Lack of clear goals or constraints only added to confusion
• It wasn’t clear what the actual game mechanics would be, or how much design work it will take to discover them. Therefore it seemed very risky.

T-Rex Prototype Pros:

• This game provided a great “first five minutes” experience that people latched onto immediately.
• The narrative was compelling and hilarious, and lended itself well to all sorts of interesting gameplay ideas.

T-Rex Prototype Cons:

• Seemed to be in danger of becoming a complete twitch game, which wasn’t what we were going for.
• It wasn’t obvious how to build it into a community game, and there was no compelling case for a level editor or anything like that.

After talking about it a lot we decided that we would start on another prototype, one that would merge the good points of both prototypes. We liked the idea of fighting while building, and from this point onwards we made it a core principle of our game. We also decided we would make a more polished version of the game that we could potentially shop around to publishers if we needed to.

OK, that’s the end of our story for iteration 1! Tune in tomorrow to find out where we went next with iteration 2.

While we’re obviously ecstatic about the release of our game, there’s some serious stuff going on in the world that is probably a bit more deserving of attention at the moment. By now I’m sure you’re all aware of what happened in Japan the past few days (and what’s going on now with reactor worries). There are some great game led efforts to raise funds going on, and they’re worth a look.

Cat from N4G has put together a good list of sites you can donate to that are doing relief efforts now. Brian Crecente from Kotaku is putting together a concert/auction/party type fundraiser in Denver in a few days too, and we plan on donating some SBS stuff for the auction as well. Definitely a great cause.

Let’s move on to some more fun news now. Our friend Jason McIntosh (the Warbler’s Nest) wrote a great piece about us scrapping (get it? get it?) the early designs for our game here, and it’s a terrific read.

Also, next week I’ll be posting a 5 part series on the design process behind SBS, with each day Monday – Friday exploring in depth a different iteration of the game, what we cut, and what we kept. If you care about game design at all you’re going to love it, so be sure to come back next week! We’ll have videos, images, and lots of details on the tough choices we had to make.

Finally, did you know that there is a fantastic twitter account for Professor Farnsworth? Apparently it’s just a bot that retweets any tweet that starts with “Good News, Everyone!” and it’s awesome.

Happy St. Patrick’s Day everyone! This is one of the best holidays of all holidays – you go out, party, and have a good time. And might we suggest playing Slam Bolt Scrappers when you stumble home? The game even has a beverage mode, my friends! Play with one hand!

Something absolutely incredible that just went up on the PlayStation Blog is an incredible video and interview of the steps we went through at Fire Hose to make Slam Bolt Scrappers. I would get into details but really Rey and Sid made such an amazing video that it just speaks for itself. Watch the video below, and check out the full interview on the PS Blog. It’s really amazing.

Over the next few days we’ll be getting into nuts and bolts details of the design phases we went through making the game, and really dive into what we cut and what made it into the final version. It should be a while ride! N4G will be posting these as well, so it’ll be great to interact with that community of gamers.

Last weekend I took part in the Heavy Metal: Amped on Wind Power challenge at the Boston Museum of Science. It’s an incredible one day engineering challenge in which high schoolers from all across the US meet up, are randomly broken into teams, and have to rapidly design, prototype, test, and build a huge mechanical structure to lift a giant metal trash can three stories into the air using nothing but wind power. The competition was a ton of fun, and I was assigned as a mentor to Team Steel, the most hard core group at the event. As such I gave them guidance and advice for what to do, but the team actually came up with and implemented the awesome device you see above. And it’s a good thing too, since they had much better ideas than I would have ever had.

We had few materials (mostly cardboard, duct tape, and pvc piping), and our only power source were two giant fans blowing hurricane gusts. After a lot of discussion and failed designs the team settled on the waterwheel device you see above. The cups on the bottom would catch the wind, spinning the whole device around an axle made out of two cardboard tubes coated with torn up trash bags to decrease friction. As it spun it would wind up a rope which was attached to the trash can through a pulley, hoisting it to the ceiling.

So how’d we do? Pretty damn well! We raised the trash can the full 27.6 feet in only 83 seconds earning us 5th place out of 32 teams. Only 11 teams raised the can the entire distance, so it was quite an accomplishment (the winning team shattered the previous record, finishing in 29 seconds. Wow!). The most impressive part in my mind though was how the team iterated on design after testing, and how quickly they settled on an idea to try instead of debating endlessly. Hopefully some of these super talented kids will wind up getting interested in game development!

Sande Chen recently asked me to a guest post for her monthly blog on game design. I was happy to help, and honestly a little bit flattered/stupefied that she would even ask me to help. Nevertheless I was happy to help, and I’ve copied the entire post below. It’s a bit of a how to on video game prototyping, with emphasis on getting shit done and why this is important. Enjoy!

——

So you’ve got an idea for a game, but you’re missing an artist, you don’t have the design nailed down, you need to find funding, and you don’t know what platform you’re going to develop for, you’re not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!

Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It’s a great way to start making games since it is far less daunting, and during the process you’ll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that’s a good thing since it’ll give you more freedom to experiment in ways you might not normally try.

Starting out

Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it’s important to focus on what you’re good at and (for the time being) ignore the rest.

Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It’s worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.

Let the development begin!

Once you’ve got your team, get to it! Remember, the standard rules of development don’t apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We’ve done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don’t feel bad about taking such shortcuts, remember that it’s all throw away anyway.

The one rule that DOESN’T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you’re probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don’t be leading when you do this!) It’s amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don’t feel bad about asking for feedback.

Finish the job!

It’s easy to stop after making one prototype and calling it a day, but don’t stop there! Analyze testing results and iterate on the prototype, taking what you’ve learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you’re trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.

Deadlines are your friends, so be sure to schedule them in. It’s easy to just keep iterating with prototypes forever, don’t fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it’ll force you to have finished builds that users can play with.

And when you’re done…

Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you’ve spent a lot of time working on it, but you can’t build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.

I wrote this article for Henry Jenkins, and am reprinting it here for you. Enjoy!

Hi Everyone! Henry, thanks for inviting me back for my annual round up of all the interesting things that happened this year at the Game Developer’s Conference (GDC). For those of you who are reading my posts for the first time I’m Eitan, local Boston game nerd and developer. I used to be a grad student at MIT doing games research, and now I’m the founder and creative director of Fire Hose Games.

But enough about me, let’s talk about games! This year I’ll be doing two posts: Talking the Talk, and Walking the Walk. The first (today’s post) will be all about interesting talks, lectures, rants, and totally inappropriate outbursts heard at the conference. The next post will be all about the amazing developers I was lucky enough to meet who are making things happen. So let’s get started – what was awesome?

Usability, Motherfuckers!
Sure, it’s a little self serving to talk about your own session first, but it was a damn good talk and I want you to hear about it. A lot of people out there can’t play video games due to some sort of disability (this applies to computer systems in general). However, with a bit of extra thought and planning game developers can frequently make their titles work for many of these disabled groups, and in the process make their game more usable for everyone. This can even lead to increased sales, so spending money on making a game highly usable will often earn money! I covered a bunch of concrete tips for things that developers can do to make their games more usable, and pointed out examples of games that exemplify this behavior (like Half Life 2 and Peggle) and games that could do so much more (like Trespasser and Puzzle Quest). If this sounds interesting you can grab the slide deck here.

My First Time – Games about Sex
Eric Zimmerman is a smart guy from New York who likes to make game developers think about how much more they could be doing. One of the neat ways he does this is with the annual Game Design Challenge, in which he goes “Iron Chef” on a panel of famous developers and asks them to propose a game with some sort of secret ingredient. This year the theme was “My First Time”, and the panelists had to incorporate their own autobiographical first time having sex. Erin Robinson and Heather Kelley came up with a hilarious Wii title in which you start by point and click your way to make the first move with an especially awkward guy, and culminates with you counting the ceiling tiles in his room. Sulka Harro deviated a bit from the autobiographical nature and proposed a user generated game in which participants tell the world about their first time, like in post secret. Finally, Steve Meretzky was both hilarious and touching as he recounted how he was a late bloomer and it took coming to MIT to find other nerds that were sufficiently weird like him to finally meet girls, and proposed a Second Life text adventure in which users must navigate the isles of awkwardness in a three part act in which you finally, after a long time, get laid. The audience voted and Erin and Heather ultimately triumphed, who were rewarded with a deck of sex cards for their efforts. Lots of fun!

User Generated Content and the Soviet Space Program, 1978 – 1989
This was one of the weirder talks I saw, and that’s really something after that sex panel. Chris Hecker started off by discussing user generated content in games, using Spore as an example. The talk was fairly straight forward, and Chris started walking through the “Sporepedia” to show examples of what people had come up with. Then the screen flashed, music started playing, and a slide with crazy spaceships was shown with the title “Russian Space Minute”. Will Wright (famous for The Sims and SimCity) then gets up and proceeds to give a 15 presentation on the late years of the Russian space program, outlining in detail the counterpart to the US Space Shuttle and the design process that went into making it. He finished by showing how the space program fell apart with the demise of the Soviet Union, and then just as quickly as he started Will sat down and Chris Hecker got back up and continued discussing Spore. The whole experience was especially surreal, as Wright’s appearance was completely unexpected and seemed to have nothing to do with anything. I later discovered that Will apparently likes to intersperse “Russian Space Minutes” into his talk because, well, he’s Will Wright, and he decided to make a guest appearance in this talk because he couldn’t in the next panel he was in, which was…

The (Positive) Future of Games
This star-studded panel featured Will Wright, Peter Molyneux, Lorne Lanning, Bing Gordon, and Ed Fries. Just like the panel moderator I’m not going to introduce these guys since they’re super famous and you have easy access to google if you don’t know. The talk centered around whether or not developers have an ethical responsibility to their users, and if they do how the games that are made can be beneficial to society. The talk was especially hilarious, and the inappropriate comments flew. Among my favorites? Paraphrased: “We should try to make the worst game possible. Perhaps a game about 72 Victoria’s Secret models, and they’re in heaven, and the game is in Arabic.” and “I would love to see a game like Second Life, but good.” The panel was all over the place, but generally they did seem to agree that it was important to make games that were useful in some way, whether by making people think more about the consequences of their actions or by encouraging positive behavior. On a related note, I went to a roundtable at the end of the conference on positive impact in games which was headed up by Rusel DeMaria, the panel moderator. I was pleasantly shocked to see how full the room was, there were many more developers there than I would have expected. Seems like a lot of people are taking this message to heart!

Constraints are your Friends
Perhaps not as flashy as the other talks, but a challenging discussion all the same. Dylan Fitterer (creator of Audio Surf) spoke about the path he took to success, starting with releasing a small game every week for over a year just to find his muse. The games were free, made him no money, and he didn’t get much acclaim, but it did serve to get his mind working about what he really wanted to do. One of the games, Tune Racer, was not especially popular on the site but Dylan felt it was likely one of the more interesting titles he came out with, and eventually it morphed into Audio Surf. He pointed out that unlimited freedom often leads to unlimited failure, as it is very difficult to figure out where to go next. Constraints, on the other hand, makes design much easier as it gives you bounds to work within. He gave the example of famous song writers like Kurt Cobain cuttings words out of newspapers to help write lyrics with the constraint of only using words and phrases they could find. It’s an interesting point, but I personally think that doesn’t apply to everyone – some people like having unbounded room to come up with ideas.

That’s it for today, see you next blog post!