游戏设计3大误区编辑本段回目录
过去几年来，我发现各类设计团队似乎都面临相同困境。幸运的是，只消稍加练习，开发者们都能轻易获悉和纠正这些问题。
1. 优秀设计师由于无法就某问题达成一致解决方案，纠结于过去并互相挫伤。
很多“糟糕”设计建议是误诊问题的最佳解决方案。
若你曾听到某智者称你的看法是个愚蠢解决方案，那你们两个很可能只是未就某问题达成一致看法。这时常发生在游戏设计中。大家都同意某功能需进一步完善，但关于具体缺陷，大家的看法通常不一致。
解决方案：在集体讨论开始腾出5分钟罗列和排序需解决的问题，这能够避免出现大量误解、挫败感和额外工作。这同时能够缩短会议，提供标准，评估所提议的解决方案。例如，若问题已通过数字罗列和排序，能够完善问题2和3，但会恶化问题1的解决方案无疑会得到一致否决。
2. 匆匆开展集体讨论，草率落实设计，却将其他工作抛置一旁。
在心里、纸上或脑中反复构思内容是极为容易的事情，但重做工作和移除既有功能则非常困难。
游戏设计就像一句老话：你需谨慎表达愿望。通常口头准确把握所表达愿望还是会形成不尽人意、令人沮丧或者能够轻易进行复制的玩法。这在MMO游戏或其他大多机制都能进行奇怪互动的大型游戏中表现得尤为突出。
Superman Game from feneroz.com
有时精心设计的机制会以奇怪方式同玩家体验或IP进行互动。例如，在游戏开始同软弱敌人斗争是个习惯做法，但若你制作的是超人游戏，就需仔细考虑在不构成威胁情况下敌人的强弱程度。也许超人游戏最简单的敌人是持有喷火器的士兵，然而在第二次世界大战游戏中，这些就会成为游戏结尾最难应付的敌人。
解决方案：仔细书写任何新机制或功能的文件说明，即便这个功能“就像我上次制作过的那样”或“就像游戏X中的那样”。即便功能和之前一样，游戏环境也大不相同。记录那些可能同新机制发生奇怪互动的功能，追踪此机制的设计师，确保达成一致理想互动模式，并将其记录于设计文件中。
思考和讨论游戏内容给人感觉如何，而不单单是需投入多少努力落实内容。大声形容游戏内容，将其演示出来，或者绘制于白板上。同时考虑当玩家失败时游戏传递何种感觉（游戏邦注：而不单单是游戏成功给人的感觉）。在超人游戏中，甩出一群银行盗贼感觉不错，但若是其中一个盗贼用手枪杀死超人呢？也许这个敌人根本就不应出现在游戏中，或者也许超人不应在第一次亮相就死去。
3. 认为完善工作只在游戏发行前进行。
真正的完善工作是种习惯或评价，而不是开发阶段。这始于游戏预制作阶段，且从未停止，而非游戏发行前的粉饰工作。
暴雪、维尔福之类的开发商以游戏质量和较长开发周期著称。显然额外投入的时间让他们能够反复进行大量完善工作，但我认为，若是给予较短时间，这些公司也能够在1年内制作出比其他工作室更精致的作品。
草率完工，然后事后再进行润色的做法，通常都会带来以下问题：
* 若原本打算修复内容的人员，或由于忘记，或离开团队，离开公司，内容就得不到修复，或由其他之前未参与制作的人员进行完善，这会耗费更长时间，引发更多问题。
* 若团队原本计划在制作末尾腾出4个月完善内容，但最终却提前4个月发行游戏，游戏将存在众多有待完善的内容。
* 重访内容或机制，进行更多润色，通常需要艺术、编程和QA人员投入更多时间，他们通常会在尚存在问题的情况下，认为自己已完成本职工作。这会使得整个项目的进展流程需重新进行调整（游戏邦注：或导致功能无法获得优化）。
* 若开发者在设计初始阶段从未考虑推出功能优化版本，其所采用的落实方式或许会导致团队无法在随后阶段添加额外功能。唯一两个选择就是拆下机制，重新安装，或者置之不理，放弃完善。
解决方案：确保腾出时间预先优化设计、安装和调整工作。若由于尚未安装技术要件而无法进行合理优化，那么至少确保制作修复所需内容或漏洞，这样修复工作才不会遗漏。
在项目结尾腾出时间完善内容是个好主意，这将大大改进游戏质量，但抓紧时间进行开发工作也同样非常重要，因为时光一去不复返。
游戏邦注：原文发布于2008年11月28日，文章叙述以当时为背景。（本文为游戏邦/gamerboom.com编译，作者：Mike Darga）
3 Common Pitfalls For Design Teams
by Mike Darga
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 a Superman 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 reimplement 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.（Source：mikedarga）
