Since the Penny Arcade post and Sony video a few days back we’ve been getting a lot of questions about our design process. So we decided to kick off a 5 day series on the iterations behind getting to the final design of Slam Bolt Scrappers! If you are at all interested in how games get made or are considering getting into game design yourself then this is the series for you. Enjoy!
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.
