序
从我进入这个公司到现在，我们花了三年半的时间来制作一款有特色的游戏，直到最终制作人决定项目关闭。在外面的人看来，我们消失了三年而一无所成，确实如此。从我们成员自己的视角看来，失去了人生中的一段宝贵的三年，随着项目的闭关，所有劳动成果都将埋没。唯一积累下来的，只有隐隐作痛的失败经验。
在做商业项目之前，我是不相信真正用心的游戏项目会在上线前失败的，甚至上线后如果反响不佳，也不一定就宣判失败。失败一定是有原因的，我相信只要能够定位到真正的原因，并把它解决，就能够避免失败。我有一句口头禅：问题，就是用来被解决的。但我疏忽了一点，有些时候人们能够发现问题，能够想到解决办法，但并不一定会有意愿去解决问题。有些时候是权衡利弊，觉得解决问题的成本太高而不愿意；有些时候是信心不足，觉得没有足够的能力去正面处理问题而不愿意；有些时候是兴趣不足，单纯地不喜欢做对解决问题而需要展开的行动。在此之前，我也并不拿市场的表现去评判一个游戏的成败，所以有时候我并不清楚项目的“失败”到底代表什么，现在大概有个认识了：失败就是，大多数成员对此失去了信心。
而我是属于少数的那一部分。
这篇文章，我是想总结一下三年项目期间经历的一些事情——会导向失败的事情。并非为了问责或其他目的，仅仅是想为以后或同行的其他项目提供有用的经验，以加大将来项目成功的可能性。从现在回溯过去的开发历程，我认为我们项目中为失败埋下伏笔的有这么几个因素：
- 对游戏终极想象的不一致和不坚定
- 对“好”评价标准不一致
- 对细节的盲目追求
- 决策者与设计者的合作方式问题
- 试图量化设计方案
- 对于不确定因素的虚假自信
下面我将以第三人称视角来叙述这些问题。
对游戏终极想象的不一致和不坚定
项目制作人是一名近50岁的资深引擎程序员，作为玩家和开发者更偏向模拟经营庄园养成类游戏，并非MMORPG游戏类型受众，也从来没有深入玩过现代主流沙盒游戏。兴趣点在于实现有难度有挑战性的技术方案，喜欢实现各种游戏Demo。
项目主策是一名资深的MMO、沙盒游戏玩家，对于传统的开放大世界营造很熟悉，并且也深刻体会到传统MMORPG类型游戏数值无限积累的玩法弊病，希望建立下一个时代的MMO玩法框架。
项目主程，是资深的竞速游戏玩家，对于非竞速类硬核PVP类型游戏经历并不深入。希望建立一个模拟世界，让世界中的NPC如真人一样活动，从而演化出社会。
项目立项的契机是制作人与朋友的交流，碰撞出一个“大世界”+“领地争夺”的想法。从技术上来说，这个想法的实现技术壁垒还是比较高的，市场上几乎没有项目做到。从策划上来说，这个上层玩法能够很自然地解决MMORPG和沙盒游戏的数值积累通病，实现价值很高。当然由于它是同时凌驾于MMO和沙盒之上的，所以设计难度也非常高。
在立项之初大家对于游戏的总体描述还都是一致的：把一群玩家丢进一个大世界里，让他们自己生存、发展，争夺领地，最后游戏在领地的不断争夺循环中进入动态平衡。随着游戏的不断开发，每到一个细节路口，我们都要做一些取舍判断。主策因为有丰富的沙盒游戏经历，所以他更偏重于在沙盒的基础上实现上层玩法，所以许多设计都带着强烈的沙盒风格，比如严酷的生存挑战，高劳动强度的物资采集，真实的死亡惩罚。并且客观推演出游戏要实现上层的领地争夺玩法，最终游戏氛围会是一个周期性军备竞赛，硬核PVP战斗的游戏，并且始终保持这一结论。 制作人由于是模拟经营类出身，在成长上更偏向于田园小镇生活，生动的劳动表现，轻松的生产环节。在PVP战斗上一般持保留意见，随着后期的不断开发，模拟经营的思想基本完全占据了决策上风，开始弱化PVP。
在主策看来，弱化PVP基本就背离的立项的最初的想法：领地争夺。在游戏开发的第三年，期间不断的交流碰撞中，制作人提出了新的方向：大世界+庄园养成。无论是出于对设计难度的考虑，还是出于对开发成本的考虑，方向肯定是一次大改。在改方向的半年后，游戏基本面目全非，十个月后宣布项目关闭。
后面在交流总结的时候，大家也提到对游戏终极想象的不一致，导致在开发过程中对各种细节设定的取舍想法不同。而制作人在开发前期对领地争夺的积极想象，到后期逐渐倾向于庄园养成的转变，进一步提高了终极想象的问题解决成本。
本来人人都是会有不同的经历、不同的思想，在兴趣和偏好上也有自己的一套，这是一个客观现象并不是一个问题。而不同的人凑在一起组成一个团队，去实现同一个目标，这是再正常不过的事情。关键在于，当大家想法不一致的时候，需要有人能够站出来主持大局，让大家心往一处想，力往一处使。有人该妥协的需要妥协，以实现团队目标为第一优先。我们经历的问题在于：团队目标逐渐变成了领导者个人目标，并且个人目标还在发生改变。制作人首先提出“大世界”+“领地争夺”的团队目标。主策坚定地接受这个目标，并客观地去推演实现目标的过程和最终效果，之后在这个路径上做了两年多的设计工作。然后制作人由于某些因素的考虑更改了团队目标，这一决定直接使前面的工作变成沉没成本，间接导致了项目后期的混乱。
因为游戏开发不同于普通的应用程序开发，应用程序会讲究系统解耦，每一个模块相对独立，完成自己需要负责的事务就行，尽量不要与其他模块纠缠，这样在改的时候每次都可以独立修改单一模块。而游戏项目越到后面越讲究模块耦合，把游戏里所有的系统功能、设定全都融汇打通，让它们形成一个有机的整体。两年多时间，主策都已经把各个模块耦合得差不多了，这时候叫改，而且是改大方向。这不是闹着玩么？
如果说早一点，在项目前期几个月，就把方向、体验推演清楚，那时候改方向完全可以。并不是说一定要“大世界”+“领地争夺”才能击穿市场，并不是说“大世界”+“庄园养成”就做不出精致的游戏。只是，大家要从一开始就确定游戏的最终想象，并至始至终坚持它，越到后期越坚持它。这是一种成事的信心。
如果立项的时候，核心成员就信心不足，抱着试一试的心态进来，那时间会证明他多半靠不住。做事还行，拿捏事情就算了。
对“好”的评价标准不一致
每个人都会去追求“好”的事物，为“好”的观点发表言论。 同时每个人也都有自己的价值观，和一套个人的评价体系，去指导我们评价其他事物是不是“好”。
游戏开发的过程，是一个创新、创造的过程，在很多方面它不像标准化的工业流程那样存在具体的指标去判断每个环节处理的好坏。并且我们的项目一边开发游戏业务，一边还开发工具，建立制作流程，同时在内容设计、规则设计上，一些设计原则也是在过程中固定下来的。这个过程走得非常艰难，往往一个小的问题意见不一致，就能把问题上升一级去讨论，追溯到设计理论、设计理念、设计原则层面，仍然会产生不同的意见。
举一些例子，比如说：玩家死亡，装备要不要掉落？
主策思考这个问题的时候，想的是：装备不掉落不损失的话，资源的积累就没法释放，最后还是会走进数值困境。主程会认为：对于现代RPG玩家来说，装备的养成打造是很费心的，如果搞半天掉了没了，玩家会接受不了而退游。一个站在框架完整性的角度去思考，一个站在玩家体验的角度去思考，两个角度都肯定有自己的正当性，那这意见分歧怎么解决。
然后主策提出：对于核心玩家来说，一套装备的损失肯定是不好的体验，但不至于退游，这是一个玩领地争夺的游戏，其他东西都是为核心服务的消耗品。主程也是行业老兵，会提出：一个MMO级别的网游，如果不能保证大众玩家的体验，就不能保证玩家基数，没有这个基数，领地争夺根本玩不起来。所以普通玩家的体验得保证，掉装备核心玩家能承受，普通玩家能承受吗？有些问题一旦提出，它就没有便宜的处理方式。
最后问题可以上升到，我们设计游戏的原则，是“在保证大众玩家的体验上，深挖核心玩家的需求”，还是“在保证核心玩法核心玩家的体验上，尽可能让更多人能玩上手”。主程明显持有前一种设计原则，而主策持有后一种。在原则、理念这个层面，大多数时候我们并不能分出孰是孰非，只是大家的基本思想不一致，这是一个客观事实。这个问题，在日常中的表现就是各种小问题的意见矛盾。
上面说的是“设计理念”不同引向的问题，还有另一个维度的评价标准不一致——做事风格。用专业术语描述就是“设计方法论”不一致。
举个例子：在项目开发的第二年，基本的沙盒生存建造的内容都已经落地了，接下来应该做哪一部分？制作人认为应该做任务系统、引导系统，把前面已经做的内容串起来，做成一个可以体验的游戏流程，后面的开发工作就是在不断地去增加内容延长这个流程。主策认为游戏中最核心的部分“领地争夺”系统还没有落实，它属于框架中最重要的一环，应该先做它以闭环整个玩法循环。
这两个人的设计方法论，一个是“一步一个脚印”型，一个是“先打框架再填内容”型。这个基本做事方法不一致，会导致配合过程中内部产生应力。由于制作人是具有最终决策权的角色，所以第二年还是以做前期流程作为了主要团队工作。后面基本上每个月都会迭代一个版本，来跑一趟前期流程。新手引导是不是顺畅，数值是不是合理，表现够不够生动，任务有没有节奏。“一步一个脚印”的方法最大的问题就是，当你意识到有几步走错的时候，那基本上前面精心踩出来的脚印都得重搞一遍。比如第二年年底，我们流程好不容易搞得有滋有味了，然后制作人出于想轻松生产的意愿，决定要实现自动仓库。然后前面所有的生产环节、天赋加点、机器设施、任务指引都得跟着改，要知道这些玩意儿可是花了几个月精心打磨过的，每一个细节都是经过推敲经过团队共同认可的。
为什么制作人会做这样的决策？从他的角度来说，肯定是因为觉得先做流程体验比完善框架要好呀，流程做了就能让人玩起来了，框架做半天啥也玩不到。改方案也是因为改了之后体验会更好呀，至少他作为玩家来说他的个人体验会更称心意。因为秉持的基本方法论就不一致，所以就算让主策来做最终决策，那结果又会怎么样呢？也是有事实证明的。后期制作人觉得自己把握不了这个项目，让主策来全权主持大局，制作人完全不干预制作。然后主策带着团队花了6个月时间，把游戏所有的框架都搭建完成了。最后呢，6个月阶段验收的时候，制作人一玩，发现这儿也毛糙，那儿也有瑕疵，说是框架搭完了，但游戏体验晦涩不堪根本走不下去，玩不到领地争夺那儿就想退游了。在主策看来，这只一个阶段性验收呀，以前一直没闭环的玩法，总算完成了，接下来就只需要按部就班添加内容，打磨细节就行了。但是在制作人看来：时间给你了，你就拿出这么个表现的东西，别说什么核心玩法，连物品描述这种最基本的内容都没写全，后面还搞个啥。
两个角色在同一时刻对同一轮测试做出完全不同的评价，基本上就是因为做出评价时采用的评价系统不一致，在我们这个案例中就是做事方法论不同。对于先做什么后做什么，在什么时间节点应该完成什么事情，持有不同的观点。设计方法论的问题不同于设计理念的问题，方法论确实是能分出个孰优孰劣的，因为这比较的是谁能把事情做的更好更快更低成本高容错。问题就在于，谁都觉得自己的方法是更好的，对方的不行不行。
对细节的盲目追求
这一节紧接着上一节的“一步一个脚印”式做法继续讲。不知道大家有没有看过网上美术大师画画的视频，如果看过的话你们会发现，他们经常喜欢从一个局部出发画完整幅画。
然鹅当我们去学画画的时候，你如果这么画的话，多半会被老师摁在调色盘里，告诉你先构图，先起形，别抓着个眼睛细节在那儿可劲儿磨。画过画的人都知道，扣细节爽，一直扣，一直爽，扣到最后发现，两个眼睛单独看是挺好看，合到一起，咋是歪的呢？啊？咋办，擦了重来，扣两小时细节白搭。
那都还好，毕竟一幅画的创作时间不太长，不像我们做游戏动不动几年搭进去了，做到第二年发现前面做的不对，得重来，那谁遭得住？
会遇到这种问题的开发者，多半都是有细节癖，当然也可以说自己是完美主义者，自己是自我要求很高的游戏人，作品里容不得瑕疵。
其实这些问题的根源有两种：一种是对项目的把控缺少全局性，心中的不安只能用丰富的细节去弥补；另一种是有了全局观，但是对计划和成本没有把控，放任时间和资源成本的膨胀。前一种是新手上路畏畏缩缩，后一种是大佬飙车放飞自我。但不管是哪一种最后多半都不会有啥好下场。（Rockstar的大佬除外）
不管什么级别什么资历的开发者，我都建议采用框架式设计。就像盖楼一样，要先打地基，然后建楼体框架，然后里外装修，通水通电。一步一个脚印是啥意思，就是先打地基，然后盖第一层，盖的时候直接做到样板间的程度，做好了能住人了，住着舒服了，再开始盖第二层。每一层都要装修完能住人才允许继续往上盖。有开发商这么盖楼的么？
插个题外话，我们立项之初，有个建筑师朋友正好开始施工建一个小楼，我们项目关闭的时候，他们楼已经建好了。
在我们的项目中，第二年制作人一直压着要做前期流程，要把每一个细节打磨到位。并不是说做游戏不该打磨细节，而是要看什么阶段该去打磨细节。楼体没有建好呢，去做装修有什么用？因为制作人长期投入精力在引擎和工具开发上，对游戏全局设计几乎托管给主策，所以他内心肯定是有所不安不确定的，而他能确定的就是那些他能看到能听到能交互的那些游戏细节。另外制作人还把这个项目当作是他的收官之作，所以在成本投入上，几乎是不设指标的，项目不设开发时间表，要问什么时候要做到什么样，不知道；什么时候能做完，不知道。这个浇水的时候，水滴洒下去回弹的感觉必须得加一下。水滴在地上和叶子上的不同层次的声音也也得体现出来（举个栗子）。包括后期主策全权负责项目的时候，在阶段性验收中，也去用细节打磨的问题来做出负面评价。在主策看来：压根没做的事情，也可以被评价做的不好么。就像造一辆车，造到一半，人家说你这车轮子咋就只有个轮毂呀？
不管是做作为个人开发者，还是项目管理者，在聚焦细节的时候都应该先看一眼项目时间表，看一看现在是个什么阶段，做什么工作才能使项目离成功更近一步，而不是盲目地任性地进入细节打磨状态。我们应该不停地审视项目阶段，在开发过程中项目状态是动态的，这个月可能战斗系统是最大的短板，下个月可能战斗系统还没做完善，但是横向比较坐骑系统已经变成最迫切需要落实的模块了。工作计划需要跟随项目状态实时更新，以确保项目是在全局性地推动。
决策者与设计者的合作方式问题
游戏制作人负责制作什么？
可能会有各种答案，但肯定不会是开发工具。
在我认知中，一种游戏制作人就是主策，负责设计游戏的主体内容框架，决策重要内容。另一种游戏制作人更多扮演项目经理的角色，管理项目进度，协调资源。这都是可行的职权方案。
但是很多时候分设了制作人和主策的岗位，却没有明晰两个岗位的工作职责。最典型的问题就是，最大的决策权在制作人那里，但是要主策去全局设计游戏。既然要主策去把控全局，那制作人的决策权，他决策个啥？用什么依据什么视野去做全局决策？要做全局决策，就要思考全局的事情。不然做出正确决策的概率跟抓阄没啥区别。
在我们的项目中，制作人由于是程序出身，本身的兴趣点也在于技术实现上，所以开发期间大部分时间都在思考一些技术难点如何实现，一些开发流程能不能优化加速。主策问及宏观问题的方向时，制作人时不时就避重就轻，把话题引向具体细节展开讨论，最后对原初问题做一个草率决定，并加以说辞“先试试看吧”。慢慢地主策意识到，有些问题是不用问的，自己心里很清楚该怎么做才是对的，问的话反而会得到其他不可知的答案。但是这样，对于重要决策，免不了遭到制作人“中途”问责存在先斩后奏的行为。
然后主策的沟通策略变成，带着问题和答案开启交流，就是报告发现了什么问题，同时也想好了解决方案该怎么做，说一声大家知晓一下。但是这种报告总是会引出“更好”的解决方案。聪明的人都会认为我能比别人想出更好的方案，权力的上游尤其会有这种错觉。然后主策经过数天深思熟虑，平衡利弊得出的方案可能就被五分钟讨论出来的方案替包了，甚至连他自己都觉得新的方案似乎更好。回去冷静下来一思考，刚才我们确定了个啥玩意儿？
再后来主策的沟通策略变成了：引导制作人思考，让制作人想出一个他觉得是他自己想出的，同时符合主策预想的解决方案。这沟通一下就变成一个艺术活的。就像你想让你家孩子认为喝开塞露是错误的，但是你不能直接告诉他那不能喝，他会觉得那玩意儿那么好喝为什么不让喝，我偏要喝。你得想点办法让他“自己”觉得那玩意儿不能喝，让他这个想法产生于他自己的思考，而不是你的灌输。
有些时候，事情本身并不难做，难的是让人做事情。
而上面那些奇奇怪怪的沟通技巧其实可以不用的，因为越是有技巧性的沟通肯定越是消耗心力的，有这些心力留着去思考游戏本身的设计问题它不好吗。一个团队要把职权分清楚，把最终决策权交给做全局思考的职位手里，拿着最终决策权的人也要做好全局思考的工作，不要用任何方式回避宏观问题，也不要妄想交给他人托管。
试图量化设计方案
在评论中看到
其实主程是一个无可指摘的老好人，一直兢兢业业地开发业务逻辑。唯一能说道一下的就是在沟通中，主程会习惯性去量化设计方案。让方案的提出者回答——这个方案有什么好处，会带来什么其他问题，好处与坏处相比哪个更多？是能让游戏更好玩，还是创造更多收入？
当一个方案建立时，它确实应该经历上述问题的审视。这样会逼迫方案提出者考虑更全面，平衡利弊更清晰。
而问题在于，如果这种提问，变成了一种沟通中争夺我方正当性，提升对方回答成本的，话术。那么这个话术的威力可就太大了。可以驳回几乎任何感性的设计方案。因为感性的东西很难用量化指标去评估的，即使方案提出者信誓旦旦回答“好处大大滴”，那大家心里也门儿清不能信。
这种话术经常发生在，主程正在专心看早间新闻，或者正在焦头烂额地处理棘手BUG，然后主策屁颠屁颠去提出他想了好几天上的方案，让对方评估一下准备实现。
对这个问题进行分析，其实深层次的原因并不在与程序员的思维方式问题，而是开启对话时参与者的状态问题。明明人家此刻都不处于Ready to talk的状态，但是非要开启一个方案的讨论，那受害的多半都是无辜的方案。
另外就是忠告，真正抱有量化思维习惯的开发者，游戏的设计不是纯工业性的，是带有一定艺术性的。应该要允许主观表达的存在。如果对每一个设计点都严格地进行量化评估，那么得到的结果要么就是策划人员变成越来越不可理喻，要么就是游戏变成冷冰冰的程序。
对于不确定因素的虚假自信
正如评论中
上面尖锐地指出制作人的问题在于专注细节缺少全局考量。第三年，经过多次交流，制作人也大度地承认了指挥问题客观存在。同时，制作人也把决策权全权交给了主策，给了主策一定时间去挽救项目。
主策自认为对于所做游戏的认知非常深刻，主体框架已经思考很成熟，只要设计完全落实即可保证项目完成。但是在项目的后期，大家逐渐发现，主策的这种自信，是一种带着盲目和掩饰的自信。
在第三年十月的时候，项目1.0决定关闭，大家都心有不甘，觉得付出多年的心血不应该落得如此下场。那时主策为了挽救项目，表示自己对项目有十足的信心，知道如何挽救才能走出困境，并且努力地向团队和制作人传递这种信心和决心。那时大家都非常低落，主策的这种态度作为一道强力的肾上腺素注入团队。大家决定跟随主策再做最后一次努力。但是为了保证项目的续存，主策传递的信心和信息存在过多的水分。其中主要的问题就有：为团队建立了不切实际的预期。
在主策争取项目继续的时候，制作人心里想的是再给两三个月让他改改看。而主策心里明白，项目1.0已经从内容框架和程序框架上都改废掉了，没有挽救方法，只能推到重构。而如此庞大的项目重构至少需要六个月才能搭建完整体框架。但是六个月显然不符合制作人的挽救心态。在那个时刻主策向制作人给出的计划安排是：两个月搭建完核心框架、四个月搭建完主体内容——然后回去就做了六个月开发计划——试图先斩后奏绑架时间周期。
这个行为导致的后果就是在第二个月和第四个月的进行阶段验收的时候，游戏表现远远不如制作人预期。但是由于车轮已经滚起来，大家都被主策裹挟上车，只好硬着头皮继续做下去。
另一个维度的虚假自信是主策对团队成员的不确定信息掩饰。在这个项目中有许多设定是没有先例参考的，在上线和玩家见面之前谁也不能确保方案的有效性。有些问题是主策也不确定的。比如说：我们设计了领地争夺，但是由于动态平衡的需求考虑，我们没有加入对领地争夺的直接利益奖励，期望通过让玩家的团队荣誉感驱动领地争夺行为发生。这种核心玩法的驱动力是否足够？主策并不确定。但是当被团队质问起时主策给出的回答是：这样的驱动力就足够了。类似的对不确定性问题给出虚假确定回答的案例还有很多。事后复盘时他自己也坦白到，是希望传递出确定的态度，因为不确定的开发内容容易引起工作抵触。
但是当不确定的东西最终被识破时，引起不仅仅是工作抵触，那会变成信任危机。在项目2.0的期间，主策就因为多次没有坦诚地说明不确定设计，总是试图塑造一种全知强硬人设，而逐渐失去了团队的信任。
在项目2.0的第六个月阶段性验收时，主策对制作人那边才真正地坦白项目开发的后续计划和成本。出于对阶段性细节表现的失望，对后续开发成本的忧虑，对团队成员信心的丢失，最终我们只能再次做出了艰难而沉痛的决定。
回顾这段游戏开发历程，我确信这是一段极其特殊的经历。立项之初，我们核心成员租了一栋别墅，在里面吃住生活工作。别墅带一个院子，本想着大家没事儿在院子里边乘凉边讨论下方案，嗐，结果忙起来院子里野草都长到人那么高了，也没用过几次。制作人没有给大家施加什么工作压力，希望保持团队有充沛的精力和良好的生活状态，以做好这份创意型工作。不设时间节点，也不走繁琐的商业流程，大家尽可能地去发挥自己的才能，做出心目中的理想游戏。这样的开发心态，在浮躁的游戏行业里算得上是一股清流了。公司曾经有许多项目，但是目前仅靠最早的几款吃老本撑着现金流。每次我们表示担心公司的经营状况的时候，老板就会安抚大家不用考虑资金压力。以做出一个能打动市场的作品为最高目标。
这是真正的游戏人的心态。加入这样的团队我感觉非常幸运和幸福。
三年的游戏开发经验，只是项目没有做成，很可惜。不过能积累下这些经验也算是非常宝贵的。总结一下：
- 立项之初，以及开发过程中，核心成员一定要有统一的游戏想象，并且对最终想象做好全面的推演，想清楚游戏做出来是什么样，玩起来是什么感觉。后面就是坚守这个立项根本，不再动摇。如果一开始就想不清楚，就不要妄想以后会突然开悟。
- 核心成员的设计理念和设计方法论最好要一致，这种基本思想的不同会导致合作的全方面立体性矛盾。如果理念谈不到一起，就不要硬凑CP了，何必互相折腾呢。
- 在不同的阶段做不同的工作，在该打磨细节的时候才打磨细节，不要放任全局不管，一头扎进细节的大坑里。跳坑容易出坑难，出坑发现当初没有解决的大问题，仍旧伫立在那里。
- 不谋万世者，不足谋一时；不谋全局者，不足谋一域。把全局的决策权，交给谋全局者。谋全局者，别天天写代码，代码写多了真的不想去思考宏观的感性的问题。
- 在大家状态合适的时候开启方案的讨论，如果方案不如自己意愿，可以直接表达，可以持保留意见，但不要习惯性用量化提问抬高对方的回答成本。设计者在抛出方案前，应该自己主动评估利弊，做到心里有数，有问有答，不要临时信口开河。
- 决策者应该对团队成员开诚布公，允许不确定因素的存在，但不能允许不确定因素被掩盖。应该提供正确的信息，为团队建立正确的期望。不要等到不切实际的预期被迫破灭时，团队的信任瓦解，再无回天之力。
谢谢大家的客观分析和评论。我想在文末补充一些信息，我们团队中每一位成员都是有能力制作独立游戏的从业者。尤其制作人是从2000年就进入游戏行业的业界资深前辈，亲自带队开发过许多大型项目，其中不乏商业成功的项目。文中对制作人角色进行了许多尖锐刻薄的指责，仅仅限于笔者的主观视角，肯定存在片面和偏激的论断。大家还请客观看待。对于制作人大有冒犯，还请海涵。提笔之意不在于甩锅，也不在于否定具体的人，而是对工作中经历的事情做出反思。我相信不管是谁来当制作人或主策，都或多或少会存在一些问题。因为人本身，不可能是完美的，不可能不犯错误。我们团队的一个良好氛围就在于，大家总能够直言不讳地指出问题，每个人也都能够坦诚大方地领锅。所以项目的成功是大家共同的成功，失败是大家共同的失败。每个人站在不同的视角，能够总结出不同的经验教训，希望这些经验，能对同行和我们今后的项目，有所借鉴之处。
快来评论，快来抢沙发吧~