After the dam level we were very worried – the game wasn’t quite good enough to make a full version, and it wasn’t quite bad enough to warrant a new prototype. On top of that we were running low on money and were concerned that if we didn’t figure something out soon we’d run out of gas before finishing the game. However we knew something had to give, as we weren’t getting the traction we wanted that the core fun was lacking.

We came up with a “last ditch” design for a new level that tried to blend the best bits of prototypes 3 and 4. We figured we’d keep the simpler fighting from the dam level while trying to incorporate more interesting building like in the tangram iteration. We knew we wanted to dial down the confusion from building with triangles and we figured squares could be simpler. After a month or so of jamming we came up with this.

Obviously this eventually morphed into Slam Bolt Scrappers, but it’s worth noting how many differences there were. The gecko bad guys and heroes were ripped straight out of the dam level, and you can see that the dash attack was even still in. The concept of dying and reviving was also lifted from the dam level, as well as the idea of getting blocks from defeated baddies.

The building here looks similar but there are some key differences. Initially the idea was that you had to build rectangles (not squares), with the height determining tower fire rate and the width determining power. Thus you could have a tall, rapid fire weapon or a squat, powerful weapon. The coloring is also different – here green is shields (note the green circles “protecting” stuff underneath it) and blue recharges the player’s dash meter (obviously this got cut in the final game.) The red missiles and purple lasers are somewhat similar, though you can see that the art here is extremely early. It’s also interesting to note how we changed the shields from circles to protecting adjacent weapons to reduce confusion.

The win condition in this game is pretty different too – you’ll note that there are some gold blocks with flags in the corner of each tower. These are “king blocks”, which were analogous to the king in chess; kill it and you win. King blocks didn’t fire but did regenerate quickly, so you had to get a focused attack on it to win. We wound up cutting this feature as it felt bizarre to have a special block that was important and didn’t do anything, but it’s interesting to see how it morphed into SBS’s concept of gold rimmed blocks that slowly regenerate health (we though the regeneration idea was pretty cool).

Once we had this prototype we were faced with a difficult decision. Should we run with the block building prototype (~1.5 months of work), the dam level (~4 months of work), or some combination thereof? We had huge discussions back and forth on the matter, and finally we decided that we had to jettison the dam level due to mediocrity. It was an extremely difficult choice to make as we had to kill our baby and throw out huge amounts of work, but ultimately it was the right decision to make.

After deciding to focus on this direction for the game we knew what we had to do next – start pumping in tons of new bad guys, make interesting new levels, improve fighting, and of course make different and fun types of blocks for players to use. We started jamming on designs and tried out a ton of different things, and by the summer we had narrowed down what we wanted to do to a manageable list. We entered production, and a few months later we finished the game in Feb 2011.

That’s the story of SBS!  We spent a ton of time prototyping and revising our game play mechanics, but ultimately I feel it was worthwhile. Next time though we’d like to do it a big quicker – prototypes 1-4 took us almost a year to do! Knowing when to keep plowing forward and when to ditch what you’ve got is probably one of the hardest things for indie devs (or any developers) to figure out. Thanks for reading this far!

After finishing our work on Dance Central with Harmonix it was late August 2009 and we were trying to figure out what to do next. The prototype we had worked on so many months ago felt stale and unpolished, and we were certain we could do a better job if we started from scratch. Furthermore with the Nintendo greenlight we decided to switch engines to Gamebryo since it was cross platform (i.e. we could switch release anywhere, assuming we got lucky and managed to find a publisher willing to back us).

So we started over in the new engine with the following goals for improvements:

• Make the game easier to just pick up and play
• Combine the fighting and building better. In particular everyone should have to fight and build at the same time, and at no point should you just be doing one thing while your teammate handles the other.
• Make building simpler. People were spending too long thinking about where to put blocks in the tangram prototype so we wanted to decrease mental load for building.
• Make it easier to just dive into the fighting. In particular we wanted to make it feel more like a button mashing brawler.

Here’s what we came up with:

Once again, huge changes. Probably the biggest that you’ll notice is that this version was far more polished than anything else we had done before – we finally figured out (more or less) what direction we wanted to go in artistically. The cartoony look would eventually carry over to Slam Bolt Scrappers, and some parts (like the viking helm and sombrero) are still available in the game now.

The building elements were incredibly simplified – beat up geckos, get material, and then slap it on the dam to try to plug up holes. Doing so caused the material’s color to change to match the builder, but that was it. This was really the simplest direction we could come up with for building, and  in hindsight we went too far. The tangram building may have been too complicated, but swinging this far in the other direction was a mistake too as building never felt very satisfying and was more of a chore than anything else. The game was fun despite the building, not because of it.

The brawling in this game was simplified as well to a simple button masher. This made it very easy to get in to but not especially deep, something we wound up fixing to some degree in Slam Bolt Scrappers. You can also see that the players have a dash attack which consumed energy that gradually restored on its own with time; this wound up getting tweaked into the comet power up. The one power up that did exist in the level, the ice gun, was cut as it was felt that the hero shouldn’t have a ranged attack.

While the level had a cool side scrolling feel you didn’t feel much of a sense of accomplishment when you moved from one area to the next, nor weas there much of a sense of danger at any point. Going underwater felt (and sounded) cool but was super confusing as there was no such thing as drowning and the lose condition was water reaching the top of the screen. Finally the boss fight at the end of the level was just… long. Not especially rewarding, not especially fun, and certainly a grind.

We submitted this build to several competitions like IGF and the Indie Games Challenge in late 2009… and failed to place in any of them. Meanwhile we were hearing grumbles from testers that the game felt mediocre, and that they weren’t sure they would want to play a full game that felt the same as the one level that we had created. We knew something was off, but we weren’t sure how to fix it.

Another big problem we were facing was a rapidly ballooning scope for the project. The game was supposed to have a different building mechanic on every level to keep it feeling fun and interesting, and we had no idea how to actually go about designing that. We had a tentative design for level two but we weren’t even sure how fun it would be, and the task of making a different design for every level was daunting.

We knew that while this game was better than the first versions in some ways (especially in terms of looks) it was probably worse in others (perhaps in terms of game mechanics) and in late December 2009 we weren’t quite sure what we could do to fix it. At the end of the year we all went on break, hoping that in 2010 we would get some ideas for how to turn things around.

After making the robot prototype we felt it was time to work on what we hoped would become the actual game. We decided to switch to flash so that we could release on PC if necessary (i.e. if we couldn’t get a deal to release on the PS3/360/Wii), and we started from scratch with all new assets so that we owned everything.

We also knew what changes we wanted to make as well. We wanted more complex building that felt more involved than simply placing pipes, and we wanted it to have a puzzle-y feel. Fighting and building were too disjoint so a goal became tying the two together better. We also wanted to make the goal more clear (just build a building!) and we were certain that 4 way multiplayer was key. After around 3 months of jamming here’s what we came up with!

Once again you’ll notice some huge changes. A conveyor belt was added with shaped tangram blocks providing the building materials as opposed to just piles of stuff (you can see how this was the precursor for building with blocks that made it into the final SBS version). The tangram blocks could be stacked in any way, and the whole tower had a “squishiness” where things would expand, crunch, and sway a little in the wind. World of Goo was a big inspiration for that.

We tried to tie the fighting in more with the building by making it so that every thing you built with could be used to fight – blocks could be thrown, wires could zap, and we even had an early power up called “anti-freeze” that would kill all the ice monsters (it’s kind of an early analog to our bomb). Even then the fighting and building were pretty separate, and the strategy often broke down into “you build, I’ll fight”.

The game itself was much more polished than the earlier versions, as we spent lots of time getting it to the point where we could pitch it to publishers and to the major console developers. The characters in the game were supposed to be kind of “punk” superheros, and we based their fashion in part off of a crazy fashion book called Fruits. While we got rid of the pipes we decided to keep the electricity as we felt there were interesting opportunities, but even those wires didn’t survive past this iteration.

The goal of the game was to fill a large blueprint in the background, at which point a giant boss would come and fight you. The brick counter on the left side of the screen showed you how you were doing with progress. We ultimately didn’t like this design much, as it felt very contrived and would frequently lead to wars of attrition for new users who would keep playing forever and not quite winning or losing. Also the game got tiring when you played for a long time on the same area and not much changed.

Some features in this prototype wound up getting removed for the fourth iteration and put back in for the final version, like health bars underneath players (here they are just under the enemies) and building with complete block shapes. Other features of Slam Bolt Scrappers were solutions to deficiencies in this prototype, like relatively fixed cameras to avoid the feeling of nasuea people sometimes got from the quick in/out zooming.

We finished this prototype in February 2009, and started pitching it to everyone we could… and it was brutal. More or less everyone said no, and we were heartbroken. For a while we though we would take the game to WiiWare as Nintendo was willing to let us put it on the Wii but with no financial support we didn’t know how we could make it happen. Luckily Harmonix came along and asked us to help out for with a new game they wanted to make that would eventually turn into Dance Central.

Seeing as how we were stuck with a mediocre prototype and no prospects for finishing it we decided to take a break and spent the next 6 months prototyping Dance Central with Harmonix, putting our game on hold in the meantime. When we finished with that we went back to our game and decided we needed to make one more version to address the problems with this iteration, and I’ll tell the story of that tomorrow in part 4.

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.

Gene writes:

Have you ever wondered about the first stage of creating a video game? GAMBIT’s Technical Director Andrew Grant along with GAMBIT’s Lead Game Designer, Matthew Weise lead a group of three game designers (Kevin Laughlin, Alexis Brownell and Sophia Foster-Dimino) through the paper prototyping stage of videogame development. Video Produced by Generoso Fierro, Music and Editing by Garrett Beazley.

PART ONE: Andrew and Matthew present our game designers with a concept for a game. Here begins the process of creating the gameplay! Our designers use markers on paper, blocks, string and a host of other tools to make the game a reality.

PART TWO: Our game designers have decided to abandon the “paper” stage of development and go right for the whiteboard to hash out their game.

PART THREE: Design Consultant Tim Stellmach comes by to play and review the prototype the designers have come up with based on the game concept.

If you like these videos be sure to check out episode 2. Cool Stuff!

If you can’t get enough of Eitan’s talks, you’re in luck! On January 27 at 12pm, Eitan will be presenting an IGDA Webinar on Rapid, Iterative Prototyping.

What do you do if you have no artist, no funding, and the design isn’t even complete? Prototype! In this webinar, Eitan will share some ideas for rapid, iterative prototyping, including how we used it in the development of Slam Bolt Scrappers. You’ll even get to see some of the super early builds we developed using this process. And of course there will be plenty of dinosaurs as well.

Unfortunately, Eitan will not be completing a Super Metroid speed run while giving this talk – but we promise to give you plenty of notice when that does happen.

Today Sharat and I gave a talk at the Singapore MIT GAMBIT game lab on rapidly building video game prototypes. It’s something of a rip off of Ethan’s and my IGCE talk from last month but this has a stronger focus on development and how to make different types of prototypes. I suggest checking it out! For more info on prototyping you can also see my guest blog from last week on Sande Chen’s game design website.

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.