The holidays are fast approaching, and with them come days steeped in tradition.  There are plenty of time honored rituals that demand reverence… this is not necessarily one of them.

Instead we will look at the home-spun tradition of Adriel; Fire Hose Programmer and resident Unicorn Tamer.

About ten years ago Adriel’s step-mother thought it would be keen to have her family create Christmas ornaments from scratch. Gathering up glitter, glue, construction paper, and other craft essentials, the family made several ornaments including some terrible looking reindeer, an awful angel (the angel’s head is a gatorade bottle cap with a smiley face drawn on), and some ‘actually pretty decent’ snowflakes.

Enraptured in the merriment of ornament creation, and more than likely tapping into some sort of Martha Stewart magic, the family soon came to the inevitable conclusion that they would construct a paper taco.

“We combined our efforts to create tiny little strips of green for the lettuce, red for the tomatoes, yellow for the cheese, and all sorts of other ingredients.”

-Adriel

The result was a thing of beauty: the Christmas Taco. Every year it is placed front and center on the family Christmas tree.

A teenage Adriel places the angel atop the tree directly above the awesome Christmas Taco. This is an actually old photo. No Instagram here. Photos just used to look like this after they were developed from ‘film’. Weird, right? 

We will be looking at some other Fire Hose staff traditions over the next few weeks. Do you have a wacky holiday tradition that you would like to share? Tell us about it on our Facebook page or send a tweet our way!

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:

This weekend, Boston Game Jams ran Cardboard Jam, a game jam where everyone made board or card games instead of making digital games. I have to say, I think I had way more fun at this game jam than at almost any other digital jam I’ve been a part of for a few reasons.

First, there’s no tech choices or learning curve. At digital Game Jams, the first thing you have to do (once you have a game you want to create) is decide what technology you want to work in. This can be tough when you have multiple people who all come with different tech backgrounds and make them try to work together. Either you end up choosing teams based on tech that people know, or a few people end up working in tech they are unfamiliar with. This can make many digital game jam more about overcoming technical challenges, rather than overcoming design challenges in the game.

Second, other than the theme of the materials, there was no theme for this Jam. Though originally I thought this was a detriment, I am beginning to think that the lack of theme contributed to making this Jam awesome. In every game jam I’ve participated in, the themes have been aesthetic. They’re themes like “immigration,” “extinction,” or “deception,” and although they offer a good constraint on the Jam (and place everyone on equal footing for implementing an idea), they force most Jammers to think in terms of aesthetic first, mechanic last. This is why most Jammers can’t “finish,” because they’re actually pushing for an aesthetic, rather than mechanical goal.

Last, jamming in board games meant that iteration cycles were really, really fast, which meant that you could focus on and tune the game and the mechanics quickly, which resulted in better games across the board. The game I worked on took about 10 minutes to play, and after initial discussion, we did nothing but play it, with short discussions in between. We probably play tested the game 50 times, each time with slightly tweaked rules to attempt to address problems we were seeing in the previous play through. Iteration times like this not only let you learn more about the game you’re creating, but more about game design in general, since you see the results of you actions quickly. This speed of iteration and learning would have been impossible in a digital game jam, since implementing rule changes requires too many cycles. In digital game jams, if you get two to three full playtests in before time is up you’re lucky, and that’s including for teams that use prebuilt engines like Unity.

So in closing, if you get a chance to participate in a board game jam, you absolutely should. There’s less stress, more learning, and way more collaboration. That, and you end up with an actually complete board game at the end, which is super awesome.

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

Hey readers! Now that Slam Bolt Scrappers is out on PSN (didn’t you hear!?), a lot of fascinating, new stuff has been happening at Fire Hose. To quickly touch base with everyone, I decided to pose a simple question: “What’s something you learned today?” Responses were pretty interesting and varied, so they seemed worth posting here. Without further delay, here are a few things people at Fire Hose learned yesterday.

Eitan: No matter how cool it looks in video games, motion blur pretty much always looks terrible in still screen shots. And Amazon web services has a free tier if you want to try out cloud hosting for free: http://aws.amazon.com/free/

Ethan: I learned that putting stars in a level makes it more fun for the players and the developers.

Jacques: Thinking ahead. Organizing and Prepping files for fast turn around, for projects that may be due the same day. If you carefully think ahead, and take the time to know the ins and outs of your current project, you can save your self time and headaches that occur when not being prepared for a deadline.

Alec: TIL that if you have any doubts about how well an image “reads,” you should trust your instincts and take action to improve the clarity of the image.

Jeff: People are doing some interesting things with smart cameras, like the Predator:

Sharat: There is a walking quadruped robot called BigDog:

So, that’s what we learned. What’s something you learned today?

Where do you feel most like yourself?

The best version of yourself. The one where every moment of the day is
a smile because in that place there is no-one else you would rather
be?

Is it strange I feel this way volunteering for a conference?

For the last eleven years, the Conference Associate (CA) program at
the annual Game Developer’s Conference in San Francisco has not only
been the source of all my best opportunities to find contacts and work
in the game industry, it has been where I renew my spirit and love for
this industry and its people.

As a CA volunteer, I have badged session lines, run errands for show
management, managed hordes of t-shirt hungry attendees, and served in
many support capacities for other volunteers. None of this is what
you might call glamorous stuff. At any other show it would be grunt
work–the most boring and uncreative labor this side of leaning on a
wall.

But the leadership of the CA program, Tim Brengle and Ian Mckenzie,
make it amazing. They call it an experiment in management; to start by
choosing an exceptionally trustworthy team (of 400!) and then to
explicitly entrust that team with the power to think and act
independently, employing numerous systems to make that trust and
support evident. As a member of the CA team, I feel as creative
supporting a speaker’s talk experience as I would making my own concept art
or animation.

Last week was the 2011 GDC in San Francisco. It was also the 25th
anniversary of the conference. Tim Brengle is one of only two people
who have attended all twenty-five. As one of the founders of the
conference, he initiated the spirit of all future CAs by seeing a need
and diving in, volunteering to create a system to manage attendee
needs. For over twenty years he and then Ian McKenzie have grown this
system with the support and input of their many hands and eyes, the
Conference Associates.

The selection process is famously mysterious. The people chosen to
serve are exceptionally varied in age, background, and physical
ability, with a gender balance and ethnic diversity that is a far, far
better approximation of game player culture than the industry normally
displays. Students work beside industry veterans. After 11 years, I
have seen an extraordinary number of those students become industry
veterans. The selection process is only mysterious to the CAs. Those
around them quickly see why they were chosen in the energy,
inventiveness, and joy they bring to the job.

Many of us at Fire Hose Games has served as CAs. Programmer Jeff Ward
was a CA in 2004, programmers Sharat Bhat and Ethan Fenn in 2009 and 2010, and
Marketer Alec Shobin joined this year. It was our pleasure to supply
evening entertainment to the CAs last Thursday by bringing a PS3 dev
kit and big screen to the CA lounge for them to play Slam Bolt Scrappers.
It was a particular pleasure for me to be able to share our game with
people who have meant so much to me for so many years.

Much thanks to the more than sixty CAs who played SBS last week and to
the many more CAs who said they are looking forward to our release
next week. Special thanks to Jennie who loaned us her TV screen.
Heartfelt thanks to Tim and Ian for supporting our studio by having so
many of us on their team.

See you all next year, CAs!

GDC is over, and my talk “From College To Industry: 20 Lessons Learned for Getting the Most out of Your Early Career” went fairly well I think.  The room was packed, which was no small feat considering how big it was, but I think that was mainly because those attending the Career Seminar had nowhere else to go during that time.  I could be wrong, though.  The title could have been that good.

Regardless, the slides for the talk are now posted and available for anyone.  I’ve been asked to give this talk a few more times, but I think I’m going to revise it a bit.  I really want to emphasize the two points about knowing business and making sure all the founders of a company are on the same page.  Of all the points in my talk, these two feel like the most important, but also the most belabored by other speakers, and also the most ignored.  They may be lessons that you have to learn the hard way, but want to do everything I can to really hammer those points home.  Hopefully I can accomplish that with revisions.

If you attended the talk, I’d love to hear your opinions and feedback. You can also check out my blog (http://www.jeffongames.com/) and follow me on Twitter (@fuzzybinary).

“Should this be moving faster?”
“Is this anticipation long enough to be readable?”
“Can it be more awesome?”

For this post I wanted to discuss how the different departments here at Fire Hose influence each other and how we answer some of the above questions when designing a new feature. It will tend to have a bit of an art-focus since animation is the main thing I contribute to the company. In my next post, I’ll go a little more in depth with the art pipeline and walk through a character from design to implementation.

It all starts with a design pitch. This doesn’t necessarily refer to the way the character looks (although we sometimes worked that way too) but it is usually a discussion on how the character will behave in the context of the game.  Here we just try to work out some very broad strokes and create a rough outline of how we want things to take shape.

Of course an actual design document eventually gets into far greater detail than this, but here is the “skeleton” from which we started:

1. The character will be appearing at point X in game.
2. This character will need the following props/weapons/vehicles.
3. The character will move in this certain way and is in environment Y and we’ll have to consider that in its design.
4. Attacking this character will make use of a special ability or a certain technique.

It’s really important to note that nothing in this design pitch is a concrete mandate. That’s really the beauty of being at a smaller studio; the design process is this totally organic and ever-evolving process that makes use of everyone’s talents.

After this pitch, art, code and design will sit down for an initial brainstorm on what kind of character design and motion would best fit our gameplay thus far. These sessions are usually my favorite part of game development (aside from making stuff move of course!). We just sit down together and blurt out whatever we think might look awesome or feel really cool while you’re playing. It’s like this creative stream of consciousness that is crazy fun and surprisingly productive at the same time.  It’s here where we plan out most of what you’ll see a character do in-game.

These sessions have a huge influence over the entire studio as well.  When we discuss a new idea, we’re potentially inviting many more people into the discussion.  Weapons will need concept, behaviors will need animation, animation will need code support. All of these things get passed back and forth through several iterations as we test. It’s important that we stay aware of the fact that decisions you make can greatly affect someone else’s work and also not to get too attached to certain things, as they can be changed or cut for various reasons.

A major driving force behind the company is everyone’s willingness to give and receive feedback on those ideas. Though not everyone will fancy their selves a designer or an artist, opinions are always welcomed and expected throughout the evolution of the project.  We always try to stay aware of the steps being taken by each other while still allowing people enough “heads-down” time to really crank on the features they’re working on.  Catching that stride in game development is an awesome feeling: when it seems like the bunch of you are moving together as this hive mind, buzzing along and complimenting each other’s genius. It certainly is a huge perk of being at a smaller studio.

So in my next post I’m going to show a bit more of the actual art process here at Fire Hose. Stay tuned!