Don’t Develop a Junk Drawer

As you development trundles on, your various teams will begin to specialize depending on their strengths and project demands.  This specialization will enhance and narrow the basic role of that team – but not preclude them from doing other work in their discipline.

For example, you may have a scripting team (or individual) that excels in boss encounters.  This person or group just has a gift for making exceptional epic battles – Naturally, this team or individual will touch more and more of the boss encounters in the game.  Does that mean they won’t also script a few doors opening and closing too? Of course not, but when it comes down to it, what they’ll be known for is being the “Boss Guy(s)”.

Something similar can happen in the art department. You’ll find someone who just rocks the house with skyboxes.  They’re gonna get and touch more and more skyboxes.  Same with an animator that is gifted in making death animations.

As mentioned above, these specializations will evolve.  They evolve based on the strengths and gifts of your team members as well as the needs of your design and game.  So, if you game does not have any skyboxes, you’re not going to have a skybox specialist.  It’s simply not something that will come up.

All this said, there is one “specialization” that I see arise time and time again – “The Junk Drawer.”  Your junk drawer team is, in reality, going to be one of your most talented and diverse teams, because you’re going to give them a set of diverse (and often painful) tasks.  The more junk you give them, the more junk you WILL give them, because they’ll begin to specialize in crap.  You don’t want this.

How Do You Know if you have a Junk Drawer Team?

You need to look at tasks.  If you have a spawn team that’s responsible for setting down the combat encounters in your game, that’s fine.  If your spawn team sets up encounters… And sets down path nodes,  that’s probably okay.  If your spawn team sets up encounters, sets down path nodes, marks up the roads for the map, lays down bark triggers, calls crunch dinner, sets down weapon drops, and – for some reason – is responsible for making doors work -- then you have a Junk Drawer Team

How Do You Get a Junk Drawer Team?

It’s not something that happens overnight, and it’s not something with a simple singular cause.  The problem develops (as most things) from a storm of problematic situations.

Improper Scheduling

This is the first step – A team will be improperly scheduled – And they’ll likely be improperly scheduled light.  This is the gateway.  What will happen is some emergent task will pop up, and while it’s not “quite” what the team does, it’s close enough and they can do it.  They have the time. They get the assignment “Just for a week or so”.  And thus, your spawning team is suddenly scripting doors “for a sprint” – which really means “forever.”

Improperly Handling Emergent Tasks

This ties into the note above.  You’re not handling emergent tasks well.  Now granted, sometimes something comes up that simply HAS to be fit into the schedule right then and there.  However, all of us, looking to make the best game we can, all too often confuse “Has to be right now” with “It would be really really REALLY good to have right now”.  It’s a fine line, but we must stick to it.

Complicit Team Members

This is a tough one, as it’s a positive thing manifesting itself in a negative way.  Basically it means that you have a team that is willing, eager, and ready to not just do their work, but to go the extra mile.  They WANT to do the extra thing because they believe it will bring them greater renown and, ultimately, help the project.  For the most part they’re right, but this will come at a cost.  That’s why we need to save them from themselves.

Pressure

This is the worst one.  The pressure can come from suits, from publishers, from the director, from a lead, or from the team itself, or any combination of these.  It’s the pressure to make a great game, to get a feature in, to hit a deadline.  Anything. Everything.  The pressure drives us to solve a problem – Namely getting work done – and the solution often seems so simple – Move the work.

What do we do about it?

Prevention is important.  However, let’s be realistic, there’s a REASON that Junk Drawer Teams continue evolve.  They solve a problem.  So, while we can do everything we can to prevent it, we must understand that we’re going to be unlikely to completely eliminate the issue.  So, we need to continue be on the lookout for these teams to rear their head, then act to resolve it.

Identification

This is the first part.  Identify when a Junk Drawer team is developing.  One of the best times to note this is when you’re scheduling.  Take a moment to really look at the task distribution and ask yourself, does this distribution MAKE SENSE.  Not does it work. Not has it worked for the past six months.  Does it MAKE SENSE now?  If not, you’ve got a problem to solve

Redistribution

Once you’ve identified a Junk Drawer Team, the next thing you need to do is put together a plan to redistribute the “Junk.”  Start by clarifying what the team SHOULD be doing.  Next, decide if you actually need them to do what they SHOULD be doing… is that task even viable.  Was the original structure flawed?  Do you need a Spawning Team now that the game has been spawned?  It’s important to look at this within the context of what your game needs now and what your game will need soon.

After you’ve done this, identify all the “junk” that the team does that needs to get redistributed.  This list will be scary.  You’re not going to like it. 

After you have a list of “junk” you need to look at the game, your teams, and your timeline to determine how best to redistribute the work.  Be realistic.  You’re not going to be able to off-load all those tasks in a sprint or a milestone.  You’re going to have to figure out how to shift the work over time, or you’ll likely end up creating a new, distinct, “junk drawer team” and you’ll only have succeeded in moving the problem from one location to another.

Conclusion

In the end, it comes down to making sure that your teams are doing what the need to be doing, along with what they should be doing.  You need to be vigilant for the warning signs – things like one team putting in excessive crunch, phrases like “Well, let’s give it to X”.  That sort of thing.

In the end, you need to be willing to actually get in and solve the problem.  This is actually more difficult than it sounds.  You’ll face resistance – sometimes from the team themselves, who will think that something is being “taken away from them”.  You’ll face resistance from executives who will rightly question fixing something that doesn’t seem broken.

Still, you need to stand up and fix it anyway.

Welcome!

Production By Design

Games are not made by a single person (well, okay some are… good ones too, but for the most part, they’re made by teams of varying sizes).  The moment you begin to produce something with a team, especially something that is simultaneously art and commercial product, you must deal with problems that arise from a multitude of sources:  Team Dynamics, Product Development, Publisher/Developer Relations, and any number of other issues specific to a company, a team, and a game.  To this end, there are ways and means to help make the whole process better.  Just as we design our game, we can design our production process.

Wait, what’s this all about?

Simply put – Getting your game done.  Designers are in a unique position to help drive the production of a game, as they are the ones creating the overall vision and scope; two key elements in the production process.

Um, don’t we have Producers for this?

Yes. However we, as designers, need to take some responsibility and control in this process as well.  We shouldn’t be afraid to put on a producer hat now and then.  The reason is simple – It puts you in power.  Why wait for an internal/external/or publisher Producer to come in and tell you what you need to cut or change (sometimes with good ideas sometimes with bad ones) when you can take the reins yourself and have a solid plan in place from the beginning. 

When a Designer uses a Producer’s eye, they’re in a better position to see and alter the roadmap of development as problems arise. It gives Designers a chance to react and make better decisions.

So, this is another Design Blog.

Yes and no.  You’re not going to find a lot of pontificating on the advantages and disadvantages of a particular style of feedback loop.  There’s plenty of other blogs that engage in that discourse.  What you will get are thoughts, ideas, and strategies for what you, as a designer, can do to improve the production process.  The idea is to empower designers to think beyond raw mechanics, level flow, or scripting code and see a bigger picture – To help designers improve the overall process, make things run smoother, and as mentioned above, to make better decisions

Sure… And You Are?

My name is Shawn Ketcherside. I’ve been in the industry over ten years and served as a Programmer, a Writer, a Designer, and a Lead. I’ve worked at start ups, I’ve worked at lean independents, and I’ve worked a large corporate powerhouse studios.  Currently, I’m Design Producer at Bioware, where I manage and help drive production on more than 6 separate multidisciplinary teams all working away to deliver Star Wars: The Old Republic – One of the largest games ever developed.

In my time in the industry, I’ve learned that a solid eye for design coupled with a mind for production can mean the difference between success and cancellation and between a mediocre product and a stellar one.

I’m not a “suit.”  I’m a designer focused on production because I need to be, because it helps.  I’ve been in the trenches, and I’ve done “real work” in a variety of disciplines.  The experience has helped me cultivate a broad knowledge base about the industry as whole.

All Right, So What’s Next?

Read. Contribute. Comment. Try Things Out.  Keep in mind that not everything in this blog will be applicable or useful to every team or project.  That’s one of the key ideas of this entire blog – Every project, team, and company is a little different.  Still, hopefully you’ll find some interesting elements you can take and tweak to help your own processes.

As for me, I’m going to do my best to update this blog twice a month, some months may be a little lean as I’m also in the throes of production, so please excuse a light month or two as things ratchet up, for despite all the best efforts and methods, one thing we all know is that stuff still goes wrong.