Designing Slam Bolt Scrappers: Iteration 2 (of 5)

Lost? Wondering what you missed? Read Yesterday’s Post!

September 2008 came and went, and we had a few prototypes for what would eventually become Slam Bolt Scrappers. Now it was time to roll the parts we liked together into a mega-prototype to see if we could actually make something more fun that everyone would enjoy.

The features we wanted to keep were: User generated content for making levels, an architecture theme, and fighting mixed in with the building. We also thought that the electricity and water elements from the tree prototype were interesting as well. The stuff that we wanted to fix was the lack of clear goals and lack of level structure. We spent October 2008 jamming in python, and here’s what we came up with.

Right off the bat you’ll notice a lot of differences. The game play was kind of similar to the T-Rex prototype, with a marauding bad guy (in this case a robot) that you could temporarily knock out so you could focus on building. The building was still centered around the idea of picking up I-beams from piles on the side of the screen, but we increased the complexity, allowing the player to build anywhere and asking them to also make sure that every part of the structure was both powered and watered. We also made the fighting more complex, giving the player a gun to shoot beams and a powerful close range punch attack that was stronger depending on how fast the user was moving. Finally there were two lose conditions; run out of money or have your whole building destroyed and you would fail the level.

Making the game 2 player was a very smart decision, as the game was suddenly much more fun when you had someone else playing the game in the room with you. It also gave rise to all sorts of interesting strategies, like “you fight! I’ll build!” Once we put multiplayer in it was clear that it was going to be a central feature for the game.

Perhaps one of the most interesting points of this game is the controls – you’ll notice the XBox buttons showing up on screen, as we initially envisioned the game as an XBLA title (we had a good contact at Microsoft in that department at the time). The trophies in the bottom right corner of the menu even led to unlockable achievements.

The level editor was a neat feature that people liked but ultimately we decided to cut it. Our Microsoft friend pointed out that we’d have problems with ratings once people started submitting levels that spelled out “Fuck” or had a giant penis in it, and we weren’t convinced that it was worth the hassle of adding a feature that could lead to mediocre level design. Ultimately this was the last iteration that featured the level editor as we dumped user generated content from our core feature set.

We still didn’t have an artist on board until the very end of October so much of the art in this prototype was borrowed. We found sprite sheets online for robots from TwinBee and Mega Man X and repurposed those as our player characters and computer controlled bad guys respectively (it was especially weird for me as I played Mega Man X a lot, this robot was much tougher 🙂 ). To make the background feel like a city we altered the background from SimTower, and to give the game an epic feel we put in some Matrix music by Rob Dougan. The tiles for the building, beams, and pipes were all original art as our artist managed to get us new assets for those at the last second. We were getting close to the point of pitching though, so this would be the last prototype we would make with non-original art assets as we didn’t want to get into legal trouble.

The prototype was neat but our Microsoft contact confirmed our suspicions that it wasn’t strong enough to get a greenlight for XBLA. We therefore set out after this to make an even more polished prototype, and to fix up some of the things we didn’t like about the version we had.

Pros of Construction Robot Prototype:

  • Multiplayer was a lot of fun. We decided it would be neat to try out 4 player mutliplayer next time.
  • Game felt innovative and different
  • Lighting up the building and punching out robots was satisfying, but could get frustrating quickly when it was too hard
  • Achievements were cool, people liked them a lot

Cons of Construction Robot Prototype:

  • User generated content too much of a headache, not compelling enough
  • Building felt too simplistic
  • Going back and forth to the edge of the screen got old quick
  • Money mechanic was too complicated and confusing, and added almost nothing to the game
  • It felt silly to not only have to build but also to have to water and power it, and people weren’t clear on why that was their goal. What was the point?

It’s pretty cool to see how this game is already much closer to Slam Bolt Scrappers than the first attempts. Tune in tomorrow for a run down of iteration 3!


  1. Callahan09

    Cool prototype. Cool insight into the design process and the publication process. I am glad that you guys are doing this blog. I’d actually love to play that prototype some day. It looks like a ton of fun to me.

  2. Ben

    Really enjoying the posts. Its pretty interesting to see how the game evolved and why you made the choices you did. Looking forward to seeing more.

  3. Chris Johnson

    Thanks again for showing us the process. Not only is it really cool to see, but it’s extremely useful to gain insight into others’ development processes.

  4. Thanks guys! Glad you’re enjoying the posts. It’s a weird trip down memory lane for me, especially considering the things SBS could have been.

    But MAN am I glad that we kept trying new stuff until we hit the final version 🙂

Trackbacks for this post

  1. Designing Slam Bolt Scrappers: Iteration 3 (of 5) | Fire Hose Games
  2. Designing Slam Bolt Scrappers: Iteration 4 (of 5) | Fire Hose Games
  3. Designing Slam Bolt Scrappers: Iteration 5 (of 5) | Fire Hose Games
Comments are now closed for this article.