We just got back from PAX, and the show was AWESOME! We had an absolutely amazing time, and I’ll follow up soon with pictures and stories from the show. But first let’s talk GO HOME DINOSAURS! Or better yet, let’s start off with with a video shot by Stephen Totilo, the rock star reporter over at Kotaku that gives voice to all the small indies with awesome games. Take a look and you can see the game in action!

As you can see we’ve been busy – we’ve already got a few levels and the art style locked down, along with most of the core functionality. It’s been a crazy few months! We’re still going hard, and we’ll be adding in tons more content and features over the months to come. So if you live near Boston now is the time to start bugging us about coming in to try it out!

It was incredible seeing so many people playing and enjoying our game. Especially considering how nervous we were about putting it out at the show too early! We had tons of kids mesmerized by dinosaurs, hardcore gamers who were determined to protect their BBQ, and couples who wound up playing together. SO COOL. I can’t wait to post pictures.

And let’s not forget the press! Here’s what other people are saying about the game:

• Kotaku – Tetris Plus Tower Defense, But Better This Time
• Destructoid – Hands On: Go Home Dinosaurs!
• Joystiq – Go Home Dinosaurs Preview – Steak ‘N’ Shake

Crunch does not always mean Quality of Life or Quality of Work has to suffer, it’s just that in most circumstances it does, because of the way it’s implemented. I have gone through two sets of crunch, both mandatory, one long, one mitigated, and both sucked. But there are a few things that I found helped me, and I think would help others, get through any period of crunch:

1. Provide All the Information: Inform everyone how much more you expect them to work, what needs to be done, and where the deadline is. If ANY of this information changes, make sure the team knows. I have been in and heard about crunch situations where information about deadlines or cut features was withheld, and this only makes people angry
2. Allow people to choose their extra hours: People are different and have different home lives. Some people work better in the morning, others at night, others over the weekend. Do not blanket ask everyone to stay late. Instead, let them choose when to work and they will choose times that will not only make them most productive, but will interfere with their lives the least.
3. Allow people to work from home: Set up your infrastructure to let people work from home. Some people can be just as productive at home as they can be in the office, and this removes the stress of a long commute and improves QoL since they can be around for their loved ones.
4. Allow people during longer periods of crunch to take some time off: This is huge for me, and I’ve never been anywhere that does this. If your crunch is going to last a long time, or looks like it will need to be lengthened, give people a day off. Say “Okay, everyone can take a day off free sometime in the next two weeks.” Giving them a time frame allows them to plan for things like short trips, or time with their family. They’ll come back rested, happier and more productive.
5. Make sure they have and know the reward: In a start-up, the reward is in the stock, but in larger companies, make sure people know they will be compensated of extra hours, and then compensate them.

Hopefully this makes sense. I don’t like crunch either, and it is avoidable for companies that have really experienced teams and a certain amount of give, but some companies do not and will not have the luxury to avoid crunch entirely. Obviously, great companies will always avoid crunch, usually because they’ve learned from their mistakes. But realize that a good company may crunch, but will always find a way to mitigate it when and if it happens, and will learn from their mistakes on their way to becoming a great company.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

In this post, I’ll look at what causes management to enforce mandatory crunch.  Everyone looks at crunch as solely a failure of management. I think there are a lot more factors to it than that. Here, in my mind are the general causes of crunch.

1. Company Policy: This is the Epic model. There are no important deadlines coming up, there’s nothing that’s actually requiring crunch, but the company has decided to require everyone always work 60 to 80 hour weeks. Not okay. There is no excuse for this other than management being completely inept. It affects work quality and general quality of life. Don’t do it.
   
2. Bad Information: This is what happened to Team Bondai. They were constantly told (and believed) that the game was almost finished. In such cases, many team members, believing the end is in sight, will do self-imposed crunch, which eventually will lead to de-facto crunch. In addition, this is where a death march starts, and tends to never end.
   
3. Bad Planning: This is the most common cause of crunch, and management gets rightly blamed for it all the time. But there are two types of bad planning:
   
   1. Bad Low Level Planning: Even the best management team can make a mistake, because they can only make decisions based on what they’re told by the people below them. If what they’re told is wrong, their planning will be wrong. So, if you’re at the low level, don’t fudge your numbers. Tell management the truth so they can make the right decisions.
      
   2. Bad High Level Planning: Even with all the right information, managers, especially bad managers, will plan incorrectly.
      
4. Shifting Requirements: Even with good planning and good information, games are a highly creative and highly iterative product, and when something’s not working or isn’t fun, it has to be changed. Unlike other industries where you can work “to spec”, the “spec” of a game is frequently fluid, which makes planning for the long term almost impossible. This, unlike the other causes, isn’t anyone’s fault, per-se, since a team can come to the mutual decision that something needs to be reworked, but it’s something that frequently gets ignored while doing planning
   
5. Deadline: When all is said and done, this is the real cause of crunch. When a deadline is involved any amount of error in planning or requirements hits a head when the deadline looms. Some studios are in a position where the deadline can be pushed, but not all, especially when dealing with a multi-game publisher that has to allocate resources at various times (QA, marketing, operations, etc) to make sure the game launches without a hitch, so they can move on to the next one. In these situations, moving the deadline is impossible. 
   

The Myths: Crunch is a Given and Crunch is Always Avoidable

Both of the above statements are wrong. If the causes of crunch are listed above, avoiding crunch is as simple as avoiding those mistakes. Don’t make crunch company policy, always give your employees all the information, plan well at all levels, have a solid design document, and don’t have a hard deadline. Simple. But, if any of those slip, you have to make a hard decision: cut features, cut polish, or crunch.

If your company has a lot of experience or a lot of leeway, you can always avoid crunch. However, if you’re a start-up working for a publisher, on a hard launch deadline, under contract, and you want to make the best game possible, chances are someone, and it’s not necessarily management, is going to make a mistake, and that mistake is going to cause some amount of crunch.

Was it avoidable? Yes, probably at some point it was, and yes someone made a mistake somewhere. Crunch is always a failure somewhere down the line. But at some point in the project, it will become obvious that some amount of crunch will be needed. The next step is to mitigate it.

In the final part, I’ll look at ways a company can mitigate crunch, if it becomes a necessity.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

Crunch has been coming up in the news again, mostly because of the Team Bondai issues.  As a disclaimer, I have never gone through what anyone would call a “death march,” which is what Team Bondai had to deal with. I’ve had to do crunch, but never on a huge magnitude, which I’ll get to. I’m also going to take what some would say is a “controversial” stance on crunch. Here’s the not controversial part: crunch is always bad, never required, and always avoidable, and a team should do everything it can to avoid it. But it’s not always that simple.

Types of Crunch

The thing is, there are lots of types of crunch. And they’re all different, and affect the team in different ways, and on different levels. In my mind, there are three major types:

1. Self-imposed crunch: This is the crunch that some people in the game industry do on their own accord. They stay late every night because they want to. They want to get that one last thing in, they want to polish the hell out of whatever, or get that one last boss battle in. This is a personal choice, and there’s really not much you can do about it. However, it should be clear to other team members that this type of behavior is not condoned or required. Don’t reward them for this behavior. Otherwise you get into the second type of crunch.
2. Team de-facto crunch: This is where the team “decides on its own” that it’s going to crunch, when the culture necessitates it, or when management does nothing to stop it. When too many people start self-imposing crunch, other people at the team will start to look down on those that “aren’t working as hard,” and peer pressure will cause them to stay later, or work longer. This is particularly true in companies with lots of younger workers who are not only particularly vulnerable to this type or peer pressure (they really want to impress their superiors) and also believe that this is just the way the game industry is. If this bubbles up to management, there becomes this situation where long hours are expected, and people that don’t do them are considered less valuable employees. Don’t let this happen. As a manager, it is your job to make sure self-imposed crunch is seen as an anomaly, and to do your best to keep people from doing it.
3. Mandatory Crunch: Just what it sounds like. Management, for some reason, requires longer hours. This is the most common form of crunch we hear about, and the worst. To producers / managers out there, just because you do the same hours does not make mandatory crunch okay. Actually, nothing really makes mandatory crunch okay. There are no excuses here. Mandatory crunch is always a failure somewhere down the pipe.

The first two types of crunch are cultural and occur at all studios, but can be mitigated once you recognize the warning signs.

In addition there are three levels of crunch:

1. Mitigated crunch: The increase in hours is not huge, maybe 10 extra hours of work during the week, the length is known and can be planned for.
2. Long crunch: The increase in hours is high. Working 60 to 80 hours during a week with no break. The length can still be known, but may be a long way off.
3. Death march: The increase in hours is high, and there is no end in sight, or the end is repeatedly pushed back.

A Mandatory Death March is the worst type of crunch, and when we talk about “crunch” we’re usually talking about mandatory long crunch or mandatory death march. There are no excuses for them

In part 2, I’ll take a look at the causes of crunch to figure out if crunch is avoidable.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

Ever wonder what we think of Slam Bolt Scrappers? What we feel we did well, and where we think we goofed? Well, today is your lucky day! Last night I spoke at the monthly video game developer meet up here in Boston and gave a run down of what went well and what didn’t go well while we were making Slam Bolt Scrappers (what is called a post mortem in the vernacular), and it was really interesting!

In the talk I discuss how we messed up (tutorial problems, too chaotic), how we did well and got lucky (working with SOE, getting the game out early and often), and what was bittersweet (not putting in networked multiplayer, being especially innovative). If you are a SBS fan or interested in how games are made I highly suggest checking it out, it’s a fun watch!

Also, here are the slides if you want to check them out:

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.

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!

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.