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.
0 comments:
Post a Comment