策划工作中的缺陷.docx
《策划工作中的缺陷.docx》由会员分享，可在线阅读，更多相关《策划工作中的缺陷.docx（16页珍藏版）》请在冰点文库上搜索。
策划工作中的缺陷
策划工作中的缺陷
游戏策划工作中的常见问题
导论
我一次次地听到这样的话：
“游戏策划肯定是世界上最好的工作了。
大家坐成一圈，想出游戏点子，接下来就能开始玩自己一直在想的游戏了。
”但是，关于游戏策划如此引人入胜的幻想，与商业工作室里策划人员的真实情景简直没有什么联系。
这一篇短文揭示了游戏策划行业经常出现的一些具体问题。
一方面，这是写给行业外的人，使他们认识到真实的策划工作是做什么的；一方面，这也是写给其他的游戏策划者（或
起来似乎人尽皆知。
但是尽管这种工作如此基本和重要，却没有一个标准的定位可以参照。
对于策划工作，每个工作室都有不同的感知、不同的历史、不同的结构。
即使在同一个工作室内，每个团队因为构成人员不同，他们对策划工作角色的理解也不同。
一个有着过硬策划技术的制作者和那些不想卷入策划过程的制作者，对策划人员的定位就完全不同。
一个技术或美术人员可能会因为他们具有能得到好的策划点子的经验和技巧，而主导整个策划工作。
而事实上策划者承担着队伍中的许多角色，有时候在一次会议上他们就要变换几次角色，这更加重了这种混乱。
在不同的时间，策划被期待成为讲故事人、剧本检测人、效率专家、拉拉队长、市场推广员、仲裁人、宣传者、梦想家、领导人、标准设立者、编剧人、历史学家、社会学家、乃至心理学家。
策划不是一项简单的任务。
作为策划者永远是技多不压身，并且还需要坚持不懈地充实自身的已有知识。
策划究竟应该做哪些工作，策划小组与团队中其它部分的联系是什么，他们的工作成果如何与时间表的其他部分相协调一致，这些都很容易引起混淆。
简单规范策划的可交付成果是很容易做到的。
最坏的解决方案是，采取走到哪里算哪里的方式或是采取临时解决的方法。
这将不但导致混淆也会导致队伍内的冲突，因为人人都提出了他们各自的期待和需要。
第一个不得不解决的问题是策划团队内部的关系。
业界普遍充斥着“共识"、"全队一致"这样的话，但如果没有坚实的结构,这只能是一种理想,而不是工作过程。
设计工作的决策过程必须是明确而清楚。
取得一致是很有价值的,但总会有小组成员不能统一意见的时候,这就需要一个最后的权威。
这个权威可以是主策划、团队领导、制作人、管理者、发行人，总之，谁扮演这个角色并不重要，重要的是大家都知道谁是权威以及如何得到最后的决定。
同样，必须明确团队策划工作的开展时间、地点、以及具体的开展方式。
小组需要知道他们的工作投入已经被收到，已经被考量过，产生了什么样的结果，以及为什么有这样的结果。
工作了但没有任何实际的产出，比无所事事更可怕。
没有一个可靠的工作流程的话，仅仅是时间和资源的无法保障，就会导致团队的工作投入完全没有效果。
团队拥有的关于策划过程的信息越少，策划也就看起来越让人迷惑，而共识和团队一致也就根本不可能达到。
第二个问题是确定任务和完成的最后期限。
没有具体目标的话，最尽职的策划者也将无法有效率地工作。
理想情况下，策划者大多数事情都是单独完成的，但他们又必须清楚团队需要什么以及何时需要。
抓住一个问题或是一个需策划的内容并用整天时间把其解决好是很容易的；从长远来看，所有的这类工作都值得这样做，但是如果团队（或是管理者）在短期内需要些其他的东西，这样做会牺牲掉团队的最终产出。
策划工作的“时间点”或里程碑能否及时完成取决于团队的具体结构，但无论你采取哪种方法，策划任务的交付需要被规划好。
这和项目的其他因素没什么不同。
最后，要明白没有“包治百病”的解决方式。
每个项目都有自己不同的要求、优先顺序和进度表。
同样的，一个点子除非能在整体项目的约束下转化成一个设计，否则是没有真正价值的，一个工作程序是无法脱离整体的项目而独立运作的。
策划是整体项目的一项具体任务，而不是一个抽象的程序。
所以，你需要一份实用的计划，来确定谁来完成它、它有哪些部分组成、何时能完成、以及如何来定稿。
忽视任何这些问题都会使你的工作成为一场注定要输的赌博，会大大的得不偿失。
过多的厨师
当说到策划游戏时，人人都有自己的主意。
这不是好事。
实际上，砍掉那些可能性比提出它们要远远复杂的多。
通过一次头脑风暴，你可以提出100个点子，但是接下来你不得不砍掉这些点子中的一半，因为它们没有任何保留价值；而因为技术和时间的限制，被保留下来的点子中的有一半也很容易流产。
对剩下的那1/4的点子，从中选出少数能与其他设计相协调、符合进度表、具有技术可行性且不超出美术和测试预算资金的点子也是一项艰苦的工作。
只要对设计决策有定义明确的标准这就会很好办，当然这一体系中难免会有些失误。
你曾经与朋友坐下得意地大谈某种游戏策划的可能性吗？
我想你肯定有过。
这种坐而论道很有趣，也很激动人心，使你雄心勃勃地想使这种可能性成为现实。
这就是我喜欢称作“双人鼓动效应”的现象。
正如下面这种情况：
一个人像这样陈述说“设置一个最佳射手不是很好吗，这样你可你追踪一个人的终身游戏纪录”；第二个人立即顺势说“妙极了，这将令人生畏，你可以记录所有曾杀死的人和曾杀死你的人”，于是这鼓动了第一个人继续精心阐述说“好啊，你还可以建立仇杀，在不同的游戏回合中实行追踪报复”，这又会导致第二个人继续说“是啊，你还可以设置决斗，像重量级拳手决赛一样，叫一些人出来打，其他人都来观看，”于是你一句我一句的没完没了。
换句话说,一个人可以通过独立思考想出一个点子，并对此十分着迷。
两个人谈论一个点子时，不管谈的是什么，很快就会认为这是有史以来最妙的一个主意：
这不仅是一个好点子，还是一个伟大的点子，而其他人之所以没有想到只不过是因为他们欲速则不达。
这太常见了，每个人都会相互吹捧其他人的点子，这种飘飘然的自我创造感使人在自建的空中楼阁里越走越远。
现在当一个这样的人来见策划者时，问题就突然出现了。
你看，策划者不得不了解关于这个点子的所有问题：
过去人们曾试图实现这个点子的方法，以及这些方法为什么失败了；玩家将通过游戏系统破坏已有效果的途径；该点子对于项目其它部分的价值局限性；与实现该点子相关的问题，等等。
换句话说，设计者不得不指出正因为它是个有意思的点子，所以在设计上没有可行性。
这真是致命的一击。
现在看来策划者是个糊涂鬼，他刚才谋杀了你的点子。
或者更糟的是，他把你的点子置之不理，根本没认识到它的无限价值
当这样一个人有权力把一个没有可行性的点子付诸实施时，同样会出现问题，此时整个的项目就被突然破坏了。
要么策划者不得不费尽全力让这个点子下马，要么明知其没有可行性也不得不勉强来实现它。
在任何一种情况下，设计者都会对想出这个歪主意的人敬而远之，从而使每个人的工作都变得更加困难。
从许多方面来说，游戏策划象是一张蜘蛛网。
设计工作的每一个因素都需要与其他的所有部分相联系。
因此，策划者不得不担负起建筑师的角色，确保每个部分达到平衡并且作为一个牢固的整体连接在一起。
这相当容易做到（尽管决不是微不足道的工作），条件是项目有足够的灵活性，允许你在事情发展和项目遇到明显的压力时转移重点。
如果没做到这点，游戏中就会留下硬伤，必定使得评论家或游戏迷们对此批评不已。
每项设计任务的完成都会固化游戏的一些设计角度，这意味着其他的系统不得不为此做出补偿。
最终，你可能采取从网中溜之大吉的方式，但如果这样的话，你也是取消了项目，为每个人省却了许多钱和时间。
当然，这也意味着你将失去这份工作。
那么，作为一个策划者你能做些什么呢？
好了，马上行动，决不要以“为什么不能实现”这样的问题来回应任何人的点子。
即使对你来说它的错误可能显而易见，这个点子可能没任何可行性-—但要抵制住这种一上来就批评它的诱惑。
首先，抓住这个点子的实质，试着借助合作的魔力。
更加详述一下它，弄清楚它源于哪里，有什么让人振奋之处。
接着，试着以概括的方式把它回述给提出者。
如果你正确理解了这个点子，他们将清楚你已经花时间弄明白了他们想表达的意思。
接下来，使他们明白你如何试图在现有设计中达成同样的目标。
使他们认识到那个片断如何与所有其它的片断相符合。
如果仍然不符合的话，就确保把点子记录下来以备将来参考。
以后你可能会重新发现它的价值，即使没有这样的话，这也给了点子一个家而不是让它扫地出门。
第二，不要做那样的人。
策划者也会像任何在双人效应中的人那样容易受到鼓动。
不要让你的点子脱离你自己的控制。
自始而终都要保持清醒的头脑：
整个体系会被破坏掉吗？
这个点子能够实现吗？
较之于游戏中需要的其它系统，它能物有所值吗？
它是有益于核心设计还是使你脱离了主体？
你这样诊断完后，再把它拿给另外的人；如果他们的观点与你不同，不像你这样对它一见钟情，那你就需要重新考虑它的价值。
把它这样拿给第二个人后，再同样拿给第三个人看。
并且始终告诫自己有一天可能会放弃这个点子，即使你现在正试图保留它。
再次重申一次，策划流程的结构性越强，你在这个问题上的受鼓动性也就越小。
随着设计工作的进展，它需要经过一道可靠的核准之门。
一旦它得到核准，你就不用再走回头路了。
在这个基础上，破坏现存设计的新点子就能被排除掉。
任何被保留下来的设计成果都应该能通过同一核准过程，如果它们被拒之门外，那么至少大家也都知道它得到了应有的考虑。
你将永远不能断绝来自团队、管理层、发行人、测试者、游戏爱好者等这些人的献计献策。
并且你自己也不想那样做。
所有这些都可能成为伟大的灵感和创新的源泉。
任何时候，他们中的某个人都可能向你提供整体中缺少的一个因素，使整个体系能更好地运转。
要确保的只是不要让对一个点子的热心切断了设计的可行性。
尊重你的团队，建设性地回应他们的点子，那么当他们创造性地思考自己的灵感时你就能成为收获者了。
相信大肆宣传
策划与销售的关联比设计人员愿意承认的要多得多。
常常听到有人抱怨：
策划工作的市场导向破坏了真正创新的可能性。
但这种抱怨抹杀了策划和销售之间这种很基础的联系。
在真正的工作开始之前，设计人员就已经开始兜售将要策划的游戏了。
甚至仅仅是为了项目的启动，就不得不去说服工作室领导、发行人、团队领导等来接受自己的点子。
没有这第一步的销售，项目将得不到任何资源的支持。
等这首要的支持到位了，设计人员还要继续向内部的团队和管理层推销自己的创意。
当游戏设计已经成型的时候，设计师要持续不断地为它的步骤、特征和内容铺路搭桥。
除非你手头的项目小到你可以独立承担所有的工作，那么你除了通过推销拉人入伙外实在别无他途。
与仅仅是为了推动项目前进相比，假如你的策划常常牵涉到预测一年或更长时间以后的状况，那么“卖”就变得更经常了。
“如果这个项目能够实现，它将一飞冲天！
”，读到这样结尾的一份计划书时，你是不是开始呻吟了？
哈，毫不奇怪这种腔调已成为例行公事，因为这正是设计人员兜售他们的游戏时始终采用的方式。
一款游戏之所以开工，大部分情况下正是基于它能够如何成功、将会怎样怎样的“美妙前景”。
在任何对外销售活动开始之前，策划人员从第一天开始就已经在内部兜售他们的项目了。
这样的销售没有什么不对，实际上这是推动项目积极性的必要部分，但是这也存在着危险。
首先，设计师推出的游戏特征可能几个月都还无法实现，实际上这将耗费程序、美术和测试好几个月的时间才能只是在引擎上呈现一下。
从理论上讲工作应该是顺利发展的的。
但是如果已走出好远之后才发现它实际上无法运作又将会怎么样呢？
现在设想一下设计人员平衡了无数的游戏系统——从控制系统到用户界面、到人工智能、到版面设计，其中的任何一项工作都花费了无数人几个月的时间，当你终于在游戏中看到这些成果时，支撑继续干下去的信念就是你所承诺的“美妙情景”将变为现实的期望。
兜售环节对美妙前景铺陈的越多，承诺越大，对游戏的卖点夸大的越多，游戏也就越难于兑现这些目标。
其次，当设计的每个因素都已实现后，为了使之更加完善仍很可能会需要做些改变。
层次需要压缩，特征需要修饰、而且实际游戏环境中如今每个运行的新因素都可能在性能目标上给你带来打击。
一旦你认识到所有的带宽都已被其他的系统所蚕食，那么当你面对无穷无尽改变带宽的工作时，以前听起来不错的想法将会让你尝到碰壁的滋味。
走回头路和放弃已做的工作是不可能的，但你现在又无法整合未完成的其它设计。
现在，如果你已经把所有的赌注压在了以前所鼓吹的方法上，而这种方法明明行之不通的时候你又该怎么办呢？
正是因为这样，前产品阶段中像First-Playable-Publishable模型和原型这样的模型在游戏产业得到了如此的推崇。
这些方法使你在进度表上留有足够的空间来根据教训进行调整，从而从理论进步到产品评估阶段。
这类生产模型的提倡者MarkCerny曾说过，从“前产品阶段”起你就要做好扔掉所有东西的准备。
作为一个设计人员你不得不支持他这样的说法。
换句话说，再伟大的游戏设计理论也得屈尊于游戏生产的实际情况。
设计理论在团队实行的过程中可能可行，也可能不可行。
如果不可行的话这就是个糟糕的设计，就需要被放弃。
不管你在向团队、工作室或发行人兜售这些方法/特征/系统时费了多少唇舌，你现在都不得不忍痛割爱了。
更困难的是，无论你对自己的点子多么情有独钟都只好自愿来除掉它。
这才是兜售自己点子的真正危险。
经过向同事、老板、搭档、游戏迷和各种压力整天、整周、整月、乃至整年地宣扬自己的点子后，你仍然不得不从设计中抽身而退，并且看到事实是：
没有通路、没有梦，有的只是现实。
不管这所有的一切在你头脑中本来设想的如何美妙，如果他们不能被转换成玩家的体验，你都不得不另觅他途，玩家体验才是你工作的最终导向。
好消息是：
失之桑榆，收之东隅。
这些障碍阻止了你到达所想去的地方，但也迫使你变得更有创造性，想出独特高效的方法来。
关键是不要相信自己的自吹自擂。
当然，你需要说服别人事情应该是这样而不是其它那样来做，但你需要经常提醒自己如果没有这个或那个要素你又该来如何进行工作。
一个好的设计不是分毫不差的标出了一条达到目的地的道路，你永远都不可能预知到路上的每个拐角和扭曲。
即使你使其他人确信你是正确的，你也不得不做好应付突发情况的准备，因为它们最终总是会出现的。
特征蔓延成灾
特征蔓延是游戏开发的绝对祸害：
进度表没有作相应的删节和调整，但项目的特征点却日渐增长。
增加了越来越多的工作而又希望进度表保持不变，这最终会导致灾难性的后果。
一般来说，有两种机制导致了特征蔓延。
第一个比较容易理解：
规划开发过程一般都是提前几个月、几年完成的。
但在起始时期，任何人都难于计划出游戏需要具有和需要做的所有具体工作。
即使设计人员能做到这一点，使队伍中的其他人都了解这些因素及它们间的关系也是不可能的；如果其他人乐于做这些了解工作的话，他们不也变成策划人员了吗？
随着开发的进展和游戏开始成形，我们开始清楚地看到，给游戏添加某些系统能提高游戏性，一些修正和增加能起到事半功倍的作用。
程序员、美术人员、测试人员、管理者和设计人员都会对这个问题有所贡献。
毕竟，无论哪个人提出的单个小改变实行起来都不会有什么困难，是不是？
但当把每个人提出的改变都加在一起来实行的话，就不是这样了，你得在产品进度表上加上不是整年也是整月的时间，更不用说还需要额外的查错和更正的测试时间。
[这点是许多外部测试人员没有理解的：
不管你的建议多么有价值，不管你看起来它们有多么简单，你每增加一次改变，都会使其他人投入巨额的资金。
游戏销路不畅的危险（对开发者来说是1—5美元的损失）与做改变所需的投资来比简直不值一提（仅是测试方面每增加一天都会耗费差不多3000美元）。
]这正是有个能够能解决问题的主程的好处。
所有的改变都需要付出特定的代价，因为你要使它们真实地落实。
如果特征将要增加的话，其它的特征就得被削减或者是进度表得被延长。
不管是谁提出的建议，代价总是要付出的。
当然，一个聪明的领导是会在进度表上留下些缓冲时间的，以便于到时加入那些不得不增加的特征。
策划人员比大多数人更容易导致特征泛滥，这也是可以理解的。
“蔓延”的第二个机制往往与设计人员有关（当然这绝不是说队伍中的其他人员与此毫无干系）：
通过增加来修改。
一个在纸上看起来很好的特征或游戏系统可能投入游戏引擎后无法运作。
此时的第一反应不是去砍掉这一系统而是去修改它，因为它毕竟是精心建构的游戏体系的一个要素。
如果团队自身的工具已建立完善，设计人员可以自己独立完成这一工作，但多数情况下他们不得不请程序员来代劳。
没有增加新特征而是增加了现有特征的工作量，同样也是对进度表的破坏。
更糟的是，修改原来的系统还可能导致补充额外的特征。
例如，假设NPC要通过一个存在可移动物体的区域。
多数情况下它们可以把这些物体从路上推开，但有时候这些物体到处都是以至于无法移动它们。
最初的反应是"好,让我们使NPC认识到这一情形并做出应对"。
这看起来很合逻辑，但你已突然自然而然地推出了一项重大任务；你正在谈论的事需要整月的工作，即便是你拥有解决该问题的人才队伍。
你的AI工程师可能畏缩不前，接下来的一招常常是给NPC提出新的规则：
如果你无法举步的话，就试着跳跃吧。
无论如何，你仍是正在推出一个新的特征，这意味着要投入更多的时间、更多的测试等。
通过增加来修改总是会导致特征蔓延。
你最好是通过减法来做修改。
对我们的例子来说，把运动的物体从情境中拿掉就行了。
现在原来的系统就可以运作了，而你也减少了一项不得不测试的东西。
当然，做这些调整可能花费额外的时间，但是这都是进度表上已经应该被考虑进去的时间，并且无论怎么说都比在原系统上另建新系统要合算的多，何况即使新系统损坏了，你最后要做的也不过是增加另一个新系统。
提醒一下大家，增加特征是需要的，但除非这样做是绝对必需，你最好还是减特征而不是增特征。
最后，你必须从核心设计开始向外做起。
高楼是从地基向上建的，而不是从上往下建。
如果你前期就已经担负了进度表上所有的核心设计，那么无论砍掉哪个其余的特征都无需变动任何基本的东西了，并且假如你能在这里或那里增加一些亮点，那就更好不过了。
要是核心设计无法运行，无论如何你都要回到设计桌前重新开始。
一项设计很像是一份菜谱：
把一些这样的滋味和那样的口感相调和，最终推出一些顾客喜欢的东西。
你不能通过加入越来越多的配料来挽救一份糟糕的食谱，设计工作也同样不能采取这种方法。
要牢记每个建筑项目的运行都要经过时间和预算。
建立游戏世界也很大程度上是这样的。
蓝图需要足够的灵活性,以适应变化的需要，而且越能被简化越好。
没有人曾经通过增加一个个的屋檐、一层层的天花板来建成过好建筑。
必须清楚核心的设计，并且通过调整而不是增加来改正问题。
文档中的魔鬼
我阅读过的关于游戏策划职位的说明书中都包括了这样一句话“卓越的口头和书面表达技巧是必备的”，这样确有必要。
除了会议外，设计人员比其他人做得更多的就是写作文档。
那么毫不奇怪，在这种文档中存在着许多危险。
正像详细规范团队任务、结构和策划的角色是最基本的工作一样，对文档做这样的规范也同样十分关键。
因为所有的工作最终都要用文档的形式呈现，了解文档现在是什么及如何做文档从长远看将能减少你许多头疼的时候。
写作文档的首要规则是要了解你的阅读对象。
如果是在向发行人引荐一个概念，就要使它简短迷人。
如果是在为测试写一个游戏特征，要确保考虑到所有可能的交互作用。
没有什么“万能钥匙”式的设计文档。
如果文档过于琐碎，就失去了可读性；如果把细节都摈弃，将会导致团队的人不得不一直跑回来寻求解释。
因此，设计工作的“百宝书”是不存在的。
同时，你需要仔细确保你的目标文档是绝对清楚的。
策划和请愿一样，你只能得到请求的东西，而不是想要的东西，所以你的工作就是力所能及地使这两个事物达到密切相关。
因为每个读者是不同的，你最差也要做到确保人们从你的文档中获得了你想要写的东西。
把草稿放在将使用这个文档的人前面，然后一直追问他们。
不要问他们“你明白了吗？
”。
要问开放性的问题：
“你觉得这个系统怎么样？
”，"你觉得这是否行得通呢?
"，"你希望看到什么变化呢?
""其他你还想知道些什么呢?
"。
也不要停留在内容上。
要乐意于使自己文档的格式适应团队的工作风格。
流程图图表比说明性散文可能会让靠视觉思维的人感到更舒适。
即使文章的内容完全相同，但格式上的差别可能导致让人理解和让人混乱两种不同的效果。
每一个项目都有自己需要的文档。
像我们可能想提出一种格式、一种组织信息的方式、一套可称为"规划过"的文件,但实际情况是只有获得阅读和理解的文档才是有价值。
灵活对待团队的需要，从长远看这将为你节省很大的工作量。
除了如何做文档,你也必须知道什么时候做文档。
设计工作具有虚拟性，要在产品开始之前把所有的工作做好，它们都还没有实现。
直到平衡了各个部分，否则你无法把最终的数字填入数据表；纸上规划好的用户界面可能经过十几次修改后才能开始做测试用的文档。
那么，前产品阶段你能做些什么呢？
首先，所有“大局”的因素需要提前被做好。
在进度表定稿之前，你必须界定游戏的范围，包括系统的种类和数量以及资产的种类和数量。
即使在那些规模更大、更抽象的文档上，你也需要确定应该有多详细，并且要有优先权，根据生产过程来决定那些系统是上升还是下降。
第二，前生产阶段是做背景的主要时间，玩家或许不需要看到背景，但背景有助于你建立一个连贯的世界，并且使工作团队接触到游戏的精神实质。
背景故事、特征界定、世界的规则：
这些主要的片断都要在前生产阶段润色。
应当要记住，这是一件细节繁多的事。
前生产阶段的设计准备越早越好，但这种说法也有限度。
你把一切都润色得太好了，那么在团队开始评估它之前你就变得对其不能自拔了。
任何作战计划在真正面对敌人时都要做出调整，设计文档和作品也同样如此。
无论你多么努力不懈地建立游戏文档，一旦这些东西开始逐渐建立，就会立刻产生偏差、意想不到的后果和需要解答的问题。
你或许能把一个系统详细到n倍程度，但是将会有n+1层次上的一些问题是不得不考虑的，这其中可能有、也可能没有你的输入。
这里的关键是，当这些细节出现后需要把它们拉回来与文档结合为一体。
即使是它们很小、似乎无关紧要，忽略它们继续自顾前行也会是最糟糕的作法。
一方面，是测试工作需要知道这些细节,使他们能够检验功能性;如果你让他们积累下去,到头来会发现自己花费几小时、几天时间来只是写测试文档，而你本应该用这些时间来平衡游戏的。
另一方面，无论你采用了何种决策来解决问题，团队中的其他人都需要加以了解。
局部的知识可能解决某一问题，而全局的知识将能解决更多的问题。
失败的文档将导致人人都因为同一个类似的问题来敲你的门（甚至更糟,他们将自顾自地提出自己的解决方案,而不管它如何与游戏逻辑的其他部分相整合），再一次地，你将花费大量的时间来为不同的人讲解同一个问题。
修改是关键，但同时也会带来问题。
毕竟，如果你持续不断地更新文件，人们就需要不断地检查这种更新，"文档疲劳"将随之出现。
设计者的工作可能只是写作游戏文档，但程序人员和美术人员除了阅读设计文档外还有其它的工作要做。
另一方面，不正常的更新会导致开发过程中错过关键事件的风险，造成更多的工作量，因为事情不得不重新来做。
有各种小窍门，如：
突出强调作出的变动，当关系到有关人员的文档更新时通知受影响的队员，在电子邮件上归纳作出的变动，为所有最近的文档保持一个一致的场所等等。
尽管如此，只是有几点有助于解决问题。
不幸的是，像详细程度这样的问题只能通过一个精确的计划和一个精确的团队来解决。
辉煌、耀眼的对象
大部分我认识的游戏开发者都玩过很多游戏。
在一个层面上，这只是因为最可能进入游戏行业的人是那些热爱玩游戏的人。
在另一层面，玩游戏可以是策划人员本身工作的一个重要部分。
作为设计人员，很明显地，了解其他人如何解决你项目中也可能面临的问题是很重要的，观众对什么积极反应、对什么消极反应，创新在什么地方成功、在什么地方失败，而行业中游戏的一般标准是什么。
然而,在这个过程中有潜在的危险，其中我特别要关注的一个是：
辉煌的、耀眼的对象。
这种情况始终会出现。
有些人进入工作后，滔滔不绝于他们曾经玩过、看过或是读过的一些东西。
这可能是一支枪，或者是一个动作，一个平面设计，一个图形效果，一行对话。
作为设计人员，我们的目的就是在自己游戏中创造出这些动人心弦的时刻；最让你感到高兴的就是有人玩你的游戏并发出“哇”的赞叹。
我们辛辛苦苦花费了无数时间，以试图从手头有限的资源中创造出尽可能多这样的效果。
而且
升级会员 