You're Going to Have to Go Back

It seems so obvious when you're standing there, at the top of the mountain, your project completed, that you spent the greatest amount of design, rework, and polish time on the first 10 to 20% of your game.


The thing is, it's not obvious.  When you're in the throes of production, you finish a level, an area, a world, or whatever your unit of gameplay space is, and move on as fast as possible to the next.  Regardless of where you’re at in the production cycle, the status of your tools, your team, and your deadlines you do as much polish as you can afford.


Even with this, we all have this idealized “polish time” allocated for the end of the project.  For the precious few projects that actually get to use polish time for actual polish, it’s often wasted because the polish time is either ill-defined or poorly allocated.


Focus on the First
In reality, you need to allocate and plan to spend a significant amount of your polish time (however much or little you have) on the first 10 to 20% of your game.  There's a couple of reasons for this. 


1:  This is the most important part of the game for your Players.  This is where you hook them or lose them.  Yes. Yes. Yes. You need to have a solid product from start to finish, you need to have good pacing, you need tight control, you need an intuitive UI. Yeah. Yeah. Yeah.  All true. All will be covered later, but like any medium we only have a small window to really sink our talons into our audience, so that first 10 to 20% is crucial.


2:  Assuming you're producing your levels/areas/worlds/etc. in some semblance of the chronological order in which they appear in the game, your first 10 to 20% is going to be... Well... Terrible.  That first 10 to 20% is where your design and art departments were thrashing -- trying to find and settle in on what and how to build.  All the concept art, design docs, and prototypes in the world simple won't cover the issue. 


When you transition from preproduction to production, there's going to be thrash.  Thrash is inevitable, and it's important.  It's in that thrash period that the skeleton of your game takes shape.  It's in that period that your game (not as defined in your dreams, your docs, your art, your hopes, your pitch, or anything) that what your game actually is develops.  What you'll find is that as production continues, this definition narrows, and everyone has a much clearer understanding what it really truly being built.  Unfortunately, this clarity is lacking at the beginning, and when you get to the end you'll find that starting point just doesn't really fit with the rest of game.


The Solution
Embrace reality.  If you're going to have polish time (and lucky you if you are) be sure you go into it understanding that you're going to burning most of it on a very small part of your game.  This is not necessarily a bad thing.  It's not perfect, but nothing in our industry is.  If you go into your polish time, fully embracing the fact that you're not just gonna "touch up" those early spots, but you're gonna have to go back and do heavy lifting, real actual "work" and that work is gonna take time, you'll be in a much better position to know how to what to spend the left over polish time on.

Running Better Meetings: Brainstorming

We've all been there. Someone needs an idea -- a good idea -- so he or she calls a brainstorming meeting. A long, useless, mind-numbing, terrible, time-wasting, life-sucking, day-ruining brainstorming meeting.

I hate them. I hate them, because most time, they're not run well. Or, in some cases, run at all.

It doesn't have to be this way. You actually can get some good results from these meetings, provided you structure and execute them well.

Define The Parameters
One of the biggest issues with Brainstorming meetings is that the scope of the meeting is ill-defined. You get everyone in place, ready to go, and the "box" for ideas is simply too large, and you get frustratingly out-of-place ideas. Then you get angry. Then sad. Sometimes a little hungry. Mostly, though, you get frustrated -- and no further to your goal.

This is why it’s critical you tightly define what you're looking for. The more narrow your constraints, the better ideas you will get. I know, at first glance, this seems counter-intuitive. You would think that having a wide-open playing field would be best.

Trust me. It's not.

Creativity thrives on constraint. Remember, what you're really trying to do with this brainstorming session is solve a problem. You can't solve a problem unless you define it -- which means defining your parameters.

Demand Preparation
Many times these meetings get called spur-of-the-moment. This is a mistake. If you give the participants some time to prep and ask that they come to the meeting with a few ideas you get a couple of benefits.

1: You get people's mind on the problem early -- letting them think and create on their own prior to the meeting, effectively "seeding" the idea pool. This will allow you to get some good ideas out early, build momentum, and provide fodder for other people to latch on to and build off of.

2: You get to weed out the tourists. Design is often alluring, it's glamorous, it's intriguing, and it's attractive. People want to feel involved in the direction of their product. This is good and should be encouraged, but when you're looking for ideas, you want people willing to provide them. Demanding preparation means anyone coming to the meeting will be committed, willing, and ready to provide you with ideas.

Keep It Short
Unless you really get on a roll (which will happen in a few rare and awesome cases) keep your Brainstorming meetings to around 20-30 minutes. Longer than this and ideas tend to degenerate and wander. Typically, in a meeting, everyone will rattle off the "low hanging fruit" ideas in the first 5-7 minutes -- Throwing up the obvious, the easy, and most often the useless. This process is actually important, as it 'clears the pipes' for actual creativity and critical thinking you're looking for. Once the "real" brainstorming begins there'll be a short window of good, productive ideas. Once this window closes, though, ideas will begin to loop back and repeat, and people will start honing in on idea flaws, instead of working on idea synthesis. That's the time to shut it down. Now, 20-30 minutes is not a hard and fast rule. If you're running the meeting, you'll need to go by feel. Sometimes ideas will run dry quickly, other times everyone will keep rolling. Just keep an eye out for when productivity ends and call the meeting -- don't keep going to hit some pre-defined time.

Keep It Small
A large scale brainstorming meeting with many people can be done, but it's very difficult and often not as productive as a smaller scoped meeting. The larger the meeting, the fewer number of people will actually talk. If you can keep the count to 6-10, you'll get a good critical mass -- enough people to generate and build off ideas, but small enough that you'll generally get good participation. The key here is making sure you get the right people in the room: People with ideas, and people who are invested in the outcome.

There Is Judgment in Brainstorming
Most directives on Brainstorming tell you to never judge ideas. This is crap. Fact of the matter is, in any Brainstorming session, you're going to get bad ideas -- those are fine, but what you want to cull out are "derailing" ideas. Ideas so terrible, so off topic, or so inflammatory that they're counter productive. If possible do this with some humor, but however you do it, be sure it gets done. These ideas are meeting killers. They're so bad, that people will fixate on them. You don't want this.

That said, while you want to shut down the idea, you do NOT want to shut down the idea-giver. So, when this situation comes up (and it will) do what you can to encourage the idea giver to turn the derailing idea into something productive, encourage them to participate, but don't write their meeting-killer of an idea up on the board just because some brainstorming book or website said to "write everything down." Again. That's crap.

Get Everyone Involved
On occasion a brainstorming participant is going to dominate a meeting. Every game company has a few strong personalities. These people often have good ideas and should be heard. What you need to keep an eye out for is letting these people run the meeting. Let them have their say, but then ask around the room -- actually call on the quiet ones-- ask them if they have an idea, or if they even have a comment or something to build off another idea. Just as every game company has strong personalities, every game company is going to have quiet ones too -- and these folks have ideas just as good and useful as the boisterous of your crowd. Get them involved, talk to them, encourage them.

Be Ready for a Game-Changing Revelation
I've seen this happen more frequently than people like to admit. Many times, designers -- being problem solvers -- work furiously to come up with brilliant, ingenious, and elegant solutions to the difficult problems that come up on a daily basis. Brainstorming meetings are tool for this. That said, every once in a while, in the course of a brainstorming meeting, as you're all tossing out ideas left-and-right to solve your problem, someone will come up with a particularly profound insight.

You're not solving the right problem.

When this happens, acknowledge it, and shut down the meeting -- even if it's one of those "holy-crap-we-have-to-have-a-solution-today-or-the-planet-will-implode" situations. Shut it down, even for ten minutes, so that people can adjust their mindset to the new revelation, and frame their ideas to address the new situation.

What you don't want to do is keep burrowing down the old, and now obviously wrong, path. Acknowledge and accept that the situation has fundamentally changed.

Wrapping Up
As you come to the end of your meeting, take a minute or two to highlight key ideas or concepts that have filtered up to the top, or that people in the meeting have naturally gravitated towards. While you may not have a solution there, you have some foundational grit to work with. At a minimum, you should have some good material for a follow up meeting, and in a catastrophic worst-case, nothing-remotely-useful-was-produced situation, you can use what's there to go back to step one, and better define your parameters so that the next meeting on the topic will better.

In the end, don't be afraid to experiment with your brainstorming meetings, and if you stick to a shorter timeframe, you can have a few more, allowing you to iterate a bit, and find a mix that works best for your company, project, or team.

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.