3 Common Pitfalls of Design Teams
This is a great post via Mike Darga's game design blog. This is a good start and I will be adding to this over time.
Over the past few years, I've noticed 3 difficulties that design teams of all shapes and sizes seem to have in common. Fortunately, these problems are all easy to diagnose and correct, with a little discipline.
1. Good designers talking past and frustrating each other because they've failed to agree what problem they're trying to solve.
Many "bad" design suggestions are actually good solutions to misdiagnosed problems.
If you've ever heard a very smart person suggest what you think is a very stupid solution to a problem, chances are that the two of you simply don't agree on what the problem is. This happens constantly in game development. Everyone may agree that a feature needs some work, but don't assume that everyone is on the same page with regard to what is wrong with it.
Solution: Taking 5 minutes at the beginning of a brainstorming meeting to list and prioritize the problems that need to be solved can save everyone a huge amount of misunderstanding, frustration, and extra work. It will also make the meeting much shorter, and provide a criterion by which to evaluate proposed solutions. For example, if problems have been listed and prioritized numerically, a solution that improves problems 2 and 3 but makes problem 1 worse can be easily discarded without argument.
2. Rushing through brainstorming and design to implementation, only to throw away all that work later.
Iterating mentally, on paper, and in brainstorms is easy and cheap. Redoing work and throwing away features is hard and expensive.
Game design is often like one of those old parables about a mischevious genie: you have to be very careful how you phrase your wishes. Often getting exactly what you said you wanted can result in gameplay that is unsatisfying, frustrating, or easily exploitable. This is especially true in MMOs or other large games where many systems can have strange interactions.
Sometimes an otherwise well-designed system can interact in strange ways with your player experience or IP. For example, it's a common practice to fight weak enemies at the beginning of a game, and work up from there, but if you're making a Superman game, you'll have to think very carefully about how weak those enemies will be before it seems strange that they pose a threat. Perhaps the easiest enemies in aSuperman game should be soldiers with flamethrowers, when in a World War II game those might be the most difficult enemies at the end of the game.
Solution: Fully write out docs for any new system or feature, even if it's one that will be "just like we did it last time" or "just like the one in game x." Even if the feature manages to be the same as it was before, the game surrounding it is not. Make note of features that are likely to have strange interactions with the new system, and follow up with the owners of those systems to make sure an ideal interaction is agreed upon and recorded in the design doc.
Make a point to think about and discuss how aspects of the game will actually FEEL, not just how much effort it will take to implement them. Describe it out loud, act it out, or draw it on the white board. Also make sure to consider how the game will feel when the player fails, not just when they succeed. It may feel fine for Superman to throw around a bunch of bank robbers, but how will it feel if one of the bank robbers actually kills Superman with his pistol? Maybe that enemy shouldn't be in the game at all, or maybe Superman shoudn't be able to die in the first place.
3. Thinking of polish as something that only happens right before the game ships.
Real polish is a mindset or value, not a stage of development. It's something that begins in preproduction and never ends, not a coat of paint to apply right before the game ships.
Developers like Blizzard and Valve are known equally for the quality of their games and for the long amount of time they spend working on them. Clearly the extra time gives them opportunity for lots of iteration, but I'd wager that given a hard deadline both those companies would make a more polished game in one year than many other dev houses.
There are lots of problems with roughing something in and intending to go back and polish it later:
* If the person who was intending to fix it either forgets, moves off the team, or leaves the company, it will either never be fixed, or be fixed by someone who did not originally implement it, taking longer and possibly even introducing more problems.
* If the team was reserving 4 months at the end of production for polish but ends up having to ship the game 4 months early, the game will have lots of unpolished content, instead of less content that is still polished.
* Revisiting content or a system to add more polish often requires more time from Art, Engineering, and QA, all of whom may have considered themselves finished with the element in question. This will either cause the schedule of the whole project to need reshuffling, or result in the feature never receiving the polish at all.
* If a polished version of a feature is never considered during initial design, it's possible that it will be implemented in a way that does not allow the additional functionality to be added in later. Then the only two choices are to tear out the system and re-implement it, or to leave it unpolished.
Solution: Always take the time to polish designs, implementation, and tuning as much as possible right up front. If it's absolutely impossible to get something polished properly due to tech that's not yet implemented, at least make tasks or bugs for each of the fixes needed and hold onto them, so the fixes won't be forgotten.
Planning to spend time at the end of the project to further polish is a great idea, and can make a big difference to quality, but it's important to develop as though that time will never come, because it often won't.
Over the past few years, I've noticed 3 difficulties that design teams of all shapes and sizes seem to have in common. Fortunately, these problems are all easy to diagnose and correct, with a little discipline.
1. Good designers talking past and frustrating each other because they've failed to agree what problem they're trying to solve.
Many "bad" design suggestions are actually good solutions to misdiagnosed problems.
If you've ever heard a very smart person suggest what you think is a very stupid solution to a problem, chances are that the two of you simply don't agree on what the problem is. This happens constantly in game development. Everyone may agree that a feature needs some work, but don't assume that everyone is on the same page with regard to what is wrong with it.
Solution: Taking 5 minutes at the beginning of a brainstorming meeting to list and prioritize the problems that need to be solved can save everyone a huge amount of misunderstanding, frustration, and extra work. It will also make the meeting much shorter, and provide a criterion by which to evaluate proposed solutions. For example, if problems have been listed and prioritized numerically, a solution that improves problems 2 and 3 but makes problem 1 worse can be easily discarded without argument.
2. Rushing through brainstorming and design to implementation, only to throw away all that work later.
Iterating mentally, on paper, and in brainstorms is easy and cheap. Redoing work and throwing away features is hard and expensive.
Game design is often like one of those old parables about a mischevious genie: you have to be very careful how you phrase your wishes. Often getting exactly what you said you wanted can result in gameplay that is unsatisfying, frustrating, or easily exploitable. This is especially true in MMOs or other large games where many systems can have strange interactions.
Sometimes an otherwise well-designed system can interact in strange ways with your player experience or IP. For example, it's a common practice to fight weak enemies at the beginning of a game, and work up from there, but if you're making a Superman game, you'll have to think very carefully about how weak those enemies will be before it seems strange that they pose a threat. Perhaps the easiest enemies in aSuperman game should be soldiers with flamethrowers, when in a World War II game those might be the most difficult enemies at the end of the game.
Solution: Fully write out docs for any new system or feature, even if it's one that will be "just like we did it last time" or "just like the one in game x." Even if the feature manages to be the same as it was before, the game surrounding it is not. Make note of features that are likely to have strange interactions with the new system, and follow up with the owners of those systems to make sure an ideal interaction is agreed upon and recorded in the design doc.
Make a point to think about and discuss how aspects of the game will actually FEEL, not just how much effort it will take to implement them. Describe it out loud, act it out, or draw it on the white board. Also make sure to consider how the game will feel when the player fails, not just when they succeed. It may feel fine for Superman to throw around a bunch of bank robbers, but how will it feel if one of the bank robbers actually kills Superman with his pistol? Maybe that enemy shouldn't be in the game at all, or maybe Superman shoudn't be able to die in the first place.
3. Thinking of polish as something that only happens right before the game ships.
Real polish is a mindset or value, not a stage of development. It's something that begins in preproduction and never ends, not a coat of paint to apply right before the game ships.
Developers like Blizzard and Valve are known equally for the quality of their games and for the long amount of time they spend working on them. Clearly the extra time gives them opportunity for lots of iteration, but I'd wager that given a hard deadline both those companies would make a more polished game in one year than many other dev houses.
There are lots of problems with roughing something in and intending to go back and polish it later:
* If the person who was intending to fix it either forgets, moves off the team, or leaves the company, it will either never be fixed, or be fixed by someone who did not originally implement it, taking longer and possibly even introducing more problems.
* If the team was reserving 4 months at the end of production for polish but ends up having to ship the game 4 months early, the game will have lots of unpolished content, instead of less content that is still polished.
* Revisiting content or a system to add more polish often requires more time from Art, Engineering, and QA, all of whom may have considered themselves finished with the element in question. This will either cause the schedule of the whole project to need reshuffling, or result in the feature never receiving the polish at all.
* If a polished version of a feature is never considered during initial design, it's possible that it will be implemented in a way that does not allow the additional functionality to be added in later. Then the only two choices are to tear out the system and re-implement it, or to leave it unpolished.
Solution: Always take the time to polish designs, implementation, and tuning as much as possible right up front. If it's absolutely impossible to get something polished properly due to tech that's not yet implemented, at least make tasks or bugs for each of the fixes needed and hold onto them, so the fixes won't be forgotten.
Planning to spend time at the end of the project to further polish is a great idea, and can make a big difference to quality, but it's important to develop as though that time will never come, because it often won't.
0 Response to 3 Common Pitfalls of Design Teams
Post a Comment