网上一个游戏创业者分享了失败经历，小编觉得这个过程中的经验适用于很多行业，因为不管做任何行业，在宏观层面有很多相似性。我们一起来看看，并思考体会。
从我进入这个公司到现在，我们花了三年半的时间来制作一款有特色的游戏，直到最终制作人决定项目关闭。在外面的人看来，我们消失了三年而一无所成，确实如此。从我们成员自己的视角看来，失去了人生中的一段宝贵的三年，随着项目的闭关，所有劳动成果都将埋没。唯一积累下来的，只有隐隐作痛的失败经验。
在做商业项目之前，我是不相信真正用心的游戏项目会在上线前失败的，甚至上线后如果反响不佳，也不一定就宣判失败。失败一定是有原因的，我相信只要能够定位到真正的原因，并把它解决，就能够避免失败。我有一句口头禅：问题，就是用来被解决的。但我疏忽了一点，有些时候人们能够发现问题，能够想到解决办法，但并不一定会有意愿去解决问题。有些时候是权衡利弊，觉得解决问题的成本太高而不愿意；有些时候是信心不足，觉得没有足够的能力去正面处理问题而不愿意；有些时候是兴趣不足，单纯地不喜欢做对解决问题而需要展开的行动。在此之前，我也并不拿市场的表现去评判一个游戏的成败，所以有时候我并不清楚项目的“失败”到底代表什么，现在大概有个认识了：失败就是，大多数成员对此失去了信心。（btsybt这段总结的很好）
而我是属于少数的那一部分。
我是想总结一下三年项目期间经历的一些事情——会导向失败的事情。并非为了问责或其他目的，仅仅是想为以后或类似的其他项目提供有用的经验参考，以加大将来项目成功的可能性。从现在回溯过去的开发历程，我认为我们项目中为失败埋下伏笔的有这么几个因素：
- 对游戏终极想象的不一致和不坚定
- 对“好”评价标准不一致
- 对细节的盲目追求
- 决策者与设计者的合作方式问题
- 试图量化设计方案
- 对于不确定因素的虚假自信
下面我将以第三人称视角来叙述这些问题。
一、对游戏终极想象的不一致和不坚定
项目制作人是一名近50岁的资深引擎程序员，作为玩家和开发者更偏向模拟经营庄园养成类游戏，并非MMORPG游戏类型受众，也从来没有深入玩过现代主流沙盒游戏。兴趣点在于实现有难度有挑战性的技术方案，喜欢实现各种游戏Demo。
项目主策是一名资深的MMO、沙盒游戏玩家，对于传统的开放大世界营造很熟悉，并且也深刻体会到传统MMORPG类型游戏数值无限积累的玩法弊病，希望建立下一个时代的MMO玩法框架。
项目主程，是资深的竞速游戏玩家，对于非竞速类硬核PVP类型游戏经历并不深入。希望建立一个模拟世界，让世界中的NPC如真人一样活动，从而演化出社会。
项目立项的契机是制作人与朋友的交流，碰撞出一个“大世界”+“领地争夺”的想法。从技术上来说，这个想法的实现技术壁垒还是比较高的，市场上几乎没有项目做到。从策划上来说，这个上层玩法能够很自然地解决MMORPG和沙盒游戏的数值积累通病，实现价值很高。当然由于它是同时凌驾于MMO和沙盒之上的，所以设计难度也非常高。
在立项之初大家对于游戏的总体描述还都是一致的：把一群玩家丢进一个大世界里，让他们自己生存、发展，争夺领地，最后游戏在领地的不断争夺循环中进入动态平衡。随着游戏的不断开发，每到一个细节路口，我们都要做一些取舍判断。主策因为有丰富的沙盒游戏经历，所以他更偏重于在沙盒的基础上实现上层玩法，所以许多设计都带着强烈的沙盒风格，比如严酷的生存挑战，高劳动强度的物资采集，真实的死亡惩罚。并且客观推演出游戏要实现上层的领地争夺玩法，最终游戏氛围会是一个周期性军备竞赛，硬核PVP战斗的游戏，并且始终保持这一结论。制作人由于是模拟经营类出身，在成长上更偏向于田园小镇生活，生动的劳动表现，轻松的生产环节。在PVP战斗上一般持保留意见，随着后期的不断开发，模拟经营的思想基本完全占据了决策上风，开始弱化PVP。
在主策看来，弱化PVP基本就背离的立项的最初的想法：领地争夺。在游戏开发的第三年，期间不断的交流碰撞中，制作人提出了新的方向：大世界+庄园养成。无论是出于对设计难度的考虑，还是出于对开发成本的考虑，方向肯定是一次大改。在改方向的半年后，游戏基本面目全非，十个月后宣布项目关闭。
后面在交流总结的时候，大家也提到对游戏终极想象的不一致，导致在开发过程中对各种细节设定的取舍想法不同。而制作人在开发前期对领地争夺的积极想象，到后期逐渐倾向于庄园养成的转变，进一步提高了终极想象的问题解决成本。
本来人人都是会有不同的经历、不同的思想，在兴趣和偏好上也有自己的一套，这是一个客观现象并不是一个问题。而不同的人凑在一起组成一个团队，去实现同一个目标，这是再正常不过的事情。关键在于，当大家想法不一致的时候，需要有人能够站出来主持大局，让大家心往一处想，力往一处使。有人该妥协的需要妥协，以实现团队目标为第一优先。我们经历的问题在于：团队目标逐渐变成了领导者个人目标，并且个人目标还在发生改变。制作人首先提出“大世界”+“领地争夺”的团队目标。主策坚定地接受这个目标，并客观地去推演实现目标的过程和最终效果，之后在这个路径上做了两年多的设计工作。然后制作人由于某些因素的考虑更改了团队目标，这一决定直接使前面的工作变成沉没成本，间接导致了项目后期的混乱。
因为游戏开发不同于普通的应用程序开发，应用程序会讲究系统解耦，每一个模块相对独立，完成自己需要负责的事务就行，尽量不要与其他模块纠缠，这样在改的时候每次都可以独立修改单一模块。而游戏项目越到后面越讲究模块耦合，把游戏里所有的系统功能、设定全都融汇打通，让它们形成一个有机的整体。两年多时间，主策都已经把各个模块耦合得差不多了，这时候叫改，而且是改大方向。这不是闹着玩么？
如果说早一点，在项目前期几个月，就把方向、体验推演清楚，那时候改方向完全可以。并不是说一定要“大世界”+“领地争夺”才能击穿市场，并不是说“大世界”+“庄园养成”就做不出精致的游戏。只是，大家要从一开始就确定游戏的最终想象，并至始至终坚持它，越到后期越坚持它。这是一种成事的信心。
如果立项的时候，核心成员就信心不足，抱着试一试的心态进来，那时间会证明他多半靠不住。做事还行，拿捏事情就算了。
（btsybt认为创业初期，企业核心领导人物至关重要，承担着统一思想和行动的重任）
二、对“好”的评价标准不一致
每个人都会去追求“好”的事物，为“好”的观点发表言论。同时每个人也都有自己的价值观，和一套个人的评价体系，去指导我们评价其他事物是不是“好”。
游戏开发的过程，是一个创新、创造的过程，在很多方面它不像标准化的工业流程那样存在具体的指标去判断每个环节处理的好坏。并且我们的项目一边开发游戏业务，一边还开发工具，建立制作流程，同时在内容设计、规则设计上，一些设计原则也是在过程中固定下来的。这个过程走得非常艰难，往往一个小的问题意见不一致，就能把问题上升一级去讨论，追溯到设计理论、设计理念、设计原则层面，仍然会产生不同的意见。
举一些例子，比如说：玩家死亡，装备要不要掉落？
主策思考这个问题的时候，想的是：装备不掉落不损失的话，资源的积累就没法释放，最后还是会走进数值困境。主程会认为：对于现代RPG玩家来说，装备的养成打造是很费心的，如果搞半天掉了没了，玩家会接受不了而退游。一个站在框架完整性的角度去思考，一个站在玩家体验的角度去思考，两个角度都肯定有自己的正当性，那这意见分歧怎么解决。
然后主策提出：对于核心玩家来说，一套装备的损失肯定是不好的体验，但不至于退游，这是一个玩领地争夺的游戏，其他东西都是为核心服务的消耗品。主程也是行业老兵，会提出：一个MMO级别的网游，如果不能保证大众玩家的体验，就不能保证玩家基数，没有这个基数，领地争夺根本玩不起来。所以普通玩家的体验得保证，掉装备核心玩家能承受，普通玩家能承受吗？有些问题一旦提出，它就没有便宜的处理方式。
最后问题可以上升到，我们设计游戏的原则，是“在保证大众玩家的体验上，深挖核心玩家的需求”，还是“在保证核心玩法核心玩家的体验上，尽可能让更多人能玩上手”。主程明显持有前一种设计原则，而主策持有后一种。在原则、理念这个层面，大多数时候我们并不能分出孰是孰非，只是大家的基本思想不一致，这是一个客观事实。这个问题，在日常中的表现就是各种小问题的意见矛盾。
上面说的是“设计理念”不同引向的问题，还有另一个维度的评价标准不一致——做事风格。用专业术语描述就是“设计方法论”不一致。
举个例子：在项目开发的第二年，基本的沙盒生存建造的内容都已经落地了，接下来应该做哪一部分？制作人认为应该做任务系统、引导系统，把前面已经做的内容串起来，做成一个可以体验的游戏流程，后面的开发工作就是在不断地去增加内容延长这个流程。主策认为游戏中最核心的部分“领地争夺”系统还没有落实，它属于框架中最重要的一环，应该先做它以闭环整个玩法循环。
这两个人的设计方法论，一个是“一步一个脚印”型，一个是“先打框架再填内容”型。这个基本做事方法不一致，会导致配合过程中内部产生应力。由于制作人是具有最终决策权的角色，所以第二年还是以做前期流程作为了主要团队工作。后面基本上每个月都会迭代一个版本，来跑一趟前期流程。新手引导是不是顺畅，数值是不是合理，表现够不够生动，任务有没有节奏。“一步一个脚印”的方法最大的问题就是，当你意识到有几步走错的时候，那基本上前面精心踩出来的脚印都得重搞一遍。比如第二年年底，我们流程好不容易搞得有滋有味了，然后制作人出于想轻松生产的意愿，决定要实现自动仓库。然后前面所有的生产环节、天赋加点、机器设施、任务指引都得跟着改，要知道这些玩意儿可是花了几个月精心打磨过的，每一个细节都是经过推敲经过团队共同认可的。
为什么制作人会做这样的决策？从他的角度来说，肯定是因为觉得先做流程体验比完善框架要好呀，流程做了就能让人玩起来了，框架做半天啥也玩不到。改方案也是因为改了之后体验会更好呀，至少他作为玩家来说他的个人体验会更称心意。因为秉持的基本方法论就不一致，所以就算让主策来做最终决策，那结果又会怎么样呢？也是有事实证明的。后期制作人觉得自己把握不了这个项目，让主策来全权主持大局，制作人完全不干预制作。然后主策带着团队花了6个月时间，把游戏所有的框架都搭建完成了。最后呢，6个月阶段验收的时候，制作人一玩，发现这儿也毛糙，那儿也有瑕疵，说是框架搭完了，但游戏体验晦涩不堪根本走不下去，玩不到领地争夺那儿就想退游了。在主策看来，这只一个阶段性验收呀，以前一直没闭环的玩法，总算完成了，接下来就只需要按部就班添加内容，打磨细节就行了。但是在制作人看来：时间给你了，你就拿出这么个表现的东西，别说什么核心玩法，连物品描述这种最基本的内容都没写全，后面还搞个啥。
两个角色在同一时刻对同一轮测试做出完全不同的评价，基本上就是因为做出评价时采用的评价系统不一致，在我们这个案例中就是做事方法论不同。对于先做什么后做什么，在什么时间节点应该完成什么事情，持有不同的观点。设计方法论的问题不同于设计理念的问题，方法论确实是能分出个孰优孰劣的，因为这比较的是谁能把事情做的更好更快更低成本高容错。问题就在于，谁都觉得自己的方法是更好的，对方的不行不行。
三、对细节的盲目追求
这一节紧接着上一节的“一步一个脚印”式做法继续讲。不知道大家有没有看过网上美术大师画画的视频，如果看过的话你们会发现，他们经常喜欢从一个局部出发画完整幅画。
然鹅当我们去学画画的时候，你如果这么画的话，多半会被老师摁在调色盘里，告诉你先构图，先起形，别抓着个眼睛细节在那儿可劲儿磨。画过画的人都知道，扣细节爽，一直扣，一直爽，扣到最后发现，两个眼睛单独看是挺好看，合到一起，咋是歪的呢？啊？咋办，擦了重来，扣两小时细节白搭。
那都还好，毕竟一幅画的创作时间不太长，不像我们做游戏动不动几年搭进去了，做到第二年发现前面做的不对，得重来，那谁遭得住？
会遇到这种问题的开发者，多半都是有细节癖，当然也可以说自己是完美主义者，自己是自我要求很高的游戏人，作品里容不得瑕疵。
其实这些问题的根源有两种：一种是对项目的把控缺少全局性，心中的不安只能用丰富的细节去弥补；另一种是有了全局观，但是对计划和成本没有把控，放任时间和资源成本的膨胀。前一种是新手上路畏畏缩缩，后一种是大佬飙车放飞自我。但不管是哪一种最后多半都不会有啥好下场。（Rockstar的大佬除外）
不管什么级别什么资历的开发者，我都建议采用框架式设计。就像盖楼一样，要先打地基，然后建楼体框架，然后里外装修，通水通电。一步一个脚印是啥意思，就是先打地基，然后盖第一层，盖的时候直接做到样板间的程度，做好了能住人了，住着舒服了，再开始盖第二层。每一层都要装修完能住人才允许继续往上盖。有开发商这么盖楼的么？
插个题外话，我们立项之初，有个建筑师朋友正好开始施工建一个小楼，我们项目关闭的时候，他们楼已经建好了。
在我们的项目中，第二年制作人一直压着要做前期流程，要把每一个细节打磨到位。并不是说做游戏不该打磨细节，而是要看什么阶段该去打磨细节。楼体没有建好呢，去做装修有什么用？因为制作人长期投入精力在引擎和工具开发上，对游戏全局设计几乎托管给主策，所以他内心肯定是有所不安不确定的，而他能确定的就是那些他能看到能听到能交互的那些游戏细节。另外制作人还把这个项目当作是他的收官之作，所以在成本投入上，几乎是不设指标的，项目不设开发时间表，要问什么时候要做到什么样，不知道；什么时候能做完，不知道。这个浇水的时候，水滴洒下去回弹的感觉必须得加一下。水滴在地上和叶子上的不同层次的声音也也得体现出来（举个栗子）。包括后期主策全权负责项目的时候，在阶段性验收中，也去用细节打磨的问题来做出负面评价。在主策看来：压根没做的事情，也可以被评价做的不好么。就像造一辆车，造到一半，人家说你这车轮子咋就只有个轮毂呀？
不管是做作为个人开发者，还是项目管理者，在聚焦细节的时候都应该先看一眼项目时间表，看一看现在是个什么阶段，做什么工作才能使项目离成功更近一步，而不是盲目地任性地进入细节打磨状态。我们应该不停地审视项目阶段，在开发过程中项目状态是动态的，这个月可能战斗系统是最大的短板，下个月可能战斗系统还没做完善，但是横向比较坐骑系统已经变成最迫切需要落实的模块了。工作计划需要跟随项目状态实时更新，以确保项目是在全局性地推动。
（细节的追求需要适当取舍）
四、决策者与设计者的合作方式问题
游戏制作人负责制作什么？
可能会有各种答案，但肯定不会是开发工具。
在我认知中，一种游戏制作人就是主策，负责设计游戏的主体内容框架，决策重要内容。另一种游戏制作人更多扮演项目经理的角色，管理项目进度，协调资源。这都是可行的职权方案。
但是很多时候分设了制作人和主策的岗位，却没有明晰两个岗位的工作职责。最典型的问题就是，最大的决策权在制作人那里，但是要主策去全局设计游戏。既然要主策去把控全局，那制作人的决策权，他决策个啥？用什么依据什么视野去做全局决策？要做全局决策，就要思考全局的事情。不然做出正确决策的概率跟抓阄没啥区别。
在我们的项目中，制作人由于是程序出身，本身的兴趣点也在于技术实现上，所以开发期间大部分时间都在思考一些技术难点如何实现，一些开发流程能不能优化加速。主策问及宏观问题的方向时，制作人时不时就避重就轻，把话题引向具体细节展开讨论，最后对原初问题做一个草率决定，并加以说辞“先试试看吧”。慢慢地主策意识到，有些问题是不用问的，自己心里很清楚该怎么做才是对的，问的话反而会得到其他不可知的答案。但是这样，对于重要决策，免不了遭到制作人“中途”问责存在先斩后奏的行为。
然后主策的沟通策略变成，带着问题和答案开启交流，就是报告发现了什么问题，同时也想好了解决方案该怎么做，说一声大家知晓一下。但是这种报告总是会引出“更好”的解决方案。聪明的人都会认为我能比别人想出更好的方案，权力的上游尤其会有这种错觉。然后主策经过数天深思熟虑，平衡利弊得出的方案可能就被五分钟讨论出来的方案替包了，甚至连他自己都觉得新的方案似乎更好。回去冷静下来一思考，刚才我们确定了个啥玩意儿？
再后来主策的沟通策略变成了：引导制作人思考，让制作人想出一个他觉得是他自己想出的，同时符合主策预想的解决方案。这沟通一下就变成一个艺术活的。就像你想让你家孩子认为喝开塞露是错误的，但是你不能直接告诉他那不能喝，他会觉得那玩意儿那么好喝为什么不让喝，我偏要喝。你得想点办法让他“自己”觉得那玩意儿不能喝，让他这个想法产生于他自己的思考，而不是你的灌输。
有些时候，事情本身并不难做，难的是让人做事情。
而上面那些奇奇怪怪的沟通技巧其实可以不用的，因为越是有技巧性的沟通肯定越是消耗心力的，有这些心力留着去思考游戏本身的设计问题它不好吗。一个团队要把职权分清楚，把最终决策权交给做全局思考的职位手里，拿着最终决策权的人也要做好全局思考的工作，不要用任何方式回避宏观问题，也不要妄想交给他人托管。
五、试图量化设计方案
在评论中看到猴与花果山，猴叔的深刻分析，感觉非常有启发。但是猴叔表示文中没有反应主程的问题，批评得不够均匀，所以回来特意补充这一小节。
其实主程是一个无可指摘的老好人，一直兢兢业业地开发业务逻辑。唯一能说道一下的就是在沟通中，主程会习惯性去量化设计方案。让方案的提出者回答——这个方案有什么好处，会带来什么其他问题，好处与坏处相比哪个更多？是能让游戏更好玩，还是创造更多收入？
当一个方案建立时，它确实应该经历上述问题的审视。这样会逼迫方案提出者考虑更全面，平衡利弊更清晰。
而问题在于，如果这种提问，变成了一种沟通中争夺我方正当性，提升对方回答成本的，话术。那么这个话术的威力可就太大了。可以驳回几乎任何感性的设计方案。因为感性的东西很难用量化指标去评估的，即使方案提出者信誓旦旦回答“好处大大滴”，那大家心里也门儿清不能信。
这种话术经常发生在，主程正在专心看早间新闻，或者正在焦头烂额地处理棘手BUG，然后主策屁颠屁颠去提出他想了好几天上的方案，让对方评估一下准备实现。
对这个问题进行分析，其实深层次的原因并不在与程序员的思维方式问题，而是开启对话时参与者的状态问题。明明人家此刻都不处于Ready to talk的状态，但是非要开启一个方案的讨论，那受害的多半都是无辜的方案。
另外就是忠告，真正抱有量化思维习惯的开发者，游戏的设计不是纯工业性的，是带有一定艺术性的。应该要允许主观表达的存在。如果对每一个设计点都严格地进行量化评估，那么得到的结果要么就是策划人员变成越来越不可理喻，要么就是游戏变成冷冰冰的程序。
猴与花果山 评论：
主策篇
故事里的主策非常缺乏经验和设计能力，从几个点就能看出来：
首先是在项目内容的设计上，很多人非常天真的认为做游戏就是要设计“对”的东西，可是既然要设计，就不会有“对”的东西，所以当你在一个团队做项目的时候，设计的【绝对重要的基石之一】，就是团队每个人心中的“痛点”，也就是说其实每个热爱游戏的人来做游戏，他心中一定是对某一个细节带有执念的（即使不热爱，也可能对于收费点赚多少钱非常有执念），一个主策划设计游戏的时候，必须把每个核心成员心目中的期许包容进来，这才是完整的设计——就拿股市里的例子来说，其实大世界+领土争夺+庄园养成+竞速元素，这些并不完全冲突，因为这些都只是一个概念（绝大多人的执着的痛点无非是概念级的），并不是不能组合在一起设计的，但是主策固执于自己的想法，认为这些就没法融合，这其实就是太过坚定某个游戏玩法神圣不可侵犯在先了，然后本能的就认为要融入其他的就毁坏了这种“对”的感觉。无论什么原因都不要紧，要紧的是——记住，游戏是为人设计的，至少，每个核心参与者都应该满意这个游戏，而满意的基础之一，是每个人心中的期许得以某种形象的实现（也就是说未必是直接的，也可以是间接的，比如领土争夺本身就会有建造玩法，庄园养成也有，那么庄园养成的建造快乐在哪儿？仔细想想，和领土争夺的建造绝对不共通吗？）。
主策的第二个能力缺陷是对于问题本质的分析能力和解决能力的欠缺。在故事里有一段主策和主程的“意见矛盾”，就是主策固执的认为掉装备是符合核心玩法的，而主程认为掉装备惩罚太严重——说到这里应该看出问题的所在了，根本就不是“不应该掉装备或者不应该掉落什么东西”，没有那么绝对，主程的意见其实是说“装备在游戏里这么重要你让我掉落了我肯定受不了”，讨论的核心不是玩家会不会退游（这是他的话术——夸张），也不是装备掉落不好——装备在这里只是一个代词，本意是“如果这个东西这么难以获得，就不应该让玩家轻易失去”，其实他说的问题直指了“框架”中的致命问题，不该营造一些“珍贵物”的损失，随便举个例子，比如wow里面挂了装备掉10%耐久，花钱修，有人嘴上会心疼，但是没人真的心疼甚至退游，因为钱来得快去得也快，没什么情感；但是如果某个游戏里，玩家养的宠物，伴随自己1年游戏时光，和自己一起战斗、一起冒险，哪怕他不是顶级的，挂了也很难受的，“数据是假的，情感是真的”。当然这里讨论的也不是这个设定好不好（损失有感情的事物本身就不是快乐的东西，是不值得分享的负能量），而是问题很明显——主策不能辨别别人的提的意见的立意和本质，对于别人提的不同意见抱有很大的排斥，这不仅会和上面说的那样设计不好，还会导致人与人之间的信任断裂，最关键的是——问题也根本得不到重视和解决。
主策的第三个能力缺陷是缺乏对于游戏的架构能力。这是国内现在95%以上的主策都有的缺陷，就是说在设计的时候，缺乏一种模块设计意识和抽象能力。故事里的主策，我都不用知道细节，就能知道他为什么改不好游戏——道理很简单，他所设计的“框架”其实是玩家级的，而不是到某个模块（玩法）关注哪些数据，具体流程怎样，如何数据交互，不是这样去架构的，所以当改的时候，从流程到数据都拿捏不准，再由数据获取改变流程，然后改着改着也不重构（程序员士气接近0不愿意了），问题堆问题，然后只能妥协，妥协+问题=做不出来。这个现象我举个栗子，比如我们做回合制RPG，踩地雷后的战斗过程中才有buff，而策划希望战斗开始前能先把这场战斗中怪物会造成的一些buff显示出来，乍一看这需求没什么问题，if else写起来也杠杠的，但是很显然，策划就没理解，在非战斗模式下buff是个冗余数据。
制作人篇
制作人在这个故事里，最大的问题在于他没有做制作人应该做的几个职责：
第一职责是保持团队的士气高昂：这里有几个明细点，制作人都没做好。
第一是团队的思想沟通，或者用大多淌着口水的斗鸡眼的说法叫“画饼”——在项目里的每个人，对于项目的期许都可能是不同的，这是自然现象，没有办法改变的，也就是老人说的“人各有志”。制作人要针对每个人的喜好，时不时给每个人打打气，比如说关注“玩家会不会喜欢”的，你得经常跟他说，这个我们之后这样做，什么样什么样的玩家就会非常激动（是不是？我也没吹牛，爱吃屎的人都有，何况是一个玩法，总有人喜欢的）。再者，就是和主策那个问题一样，不能聆听发现问题，并合理利用身份来权夺问题的解决方案，然后各个击破，也就是挨个去说动每个人妥协（这是真的妥协，因为最终必定不是100%按照每个人想法来了）。
第二是保持团队气氛虎跃——当团队存在意见不同的时候，气氛一定是诡异的，并不是一定要让大家的意见一致，这也是不可能的，但是可以经常转移转移话题，这时候大家一起玩一款游戏之类的都会是很好的新话题。制作人应该在团队气氛诡异的时候，即时去调整团队气氛，并且在人开心的时候各个击破，这跟哄20多岁想谈恋爱的小姑娘是一样的套路（一个制作人要是这点本事都没还是拉倒吧，制作人的主能力是魅力而不是智力）。而且制作人应该让团队中存在一种信任——你有问题去找我，或者找谁谁说，最后都是有反馈的。这个举个栗子比如在灵娱的时候，我们团队里有2个点，一个是我，当然如果觉得我猴叔不好说话，就可以找制作人鲁大师去吐槽，无理论什么吐槽，我们都会去发现一些问题，有些甚至还会开会讨论解决方案，让每个人觉得自己都是被重视的，而不能沉默不语。而我跟鲁大师则都是一看就很逗比的家伙，不是那种充满心计的阴险狡诈之徒，所以才有的沟通，而我们也都会主动出击找不对劲的聊聊（其实我会叫鲁大师去，因为鲁大师有文化，聊起来让人舒服）。
第三是对于项目的把控问题——其实有经验的制作人，在项目进度上都有“阴阳账”，这什么意思呢？就是有一条线专门开发给人看的东西，比如傻了吧唧的老板们，另一条线则是内部真正的开发线，两条并行才是项目开发线。真的做游戏的人都知道，游戏有这么一个开发阶段，可能根本就拿不出“可以看的进度”，比如在搭我的buff机制的时候，可能1、2周就是框架，什么看起来的进展都没，但是2周确实都在做事，但你能不能跟老板也这么说？老板不懂，老子花钱2周没什么新东西可还行？是不是，所以专门得有一条线负责UI、内容录入（这里就有技巧了，比如哪些可以先录入，后期改动甚至做一个脚本就能实现，而不用人工的），是专门看起来的，也就是故事里说的“一步一个脚印”，而另一条线就是搭核心逻辑框架的，也就是故事里说的“先框架再数据”。自己开发当然一定是先框架在数据，没有那么虚伪，但是人多了，总有人会担心进度问题（即便不是老板而是团队里的比如美术人员），所以“面子功夫”也得做足，其实这不算面子功夫，只是项目开发过程的巧妙安排而已。
第四是人事管理问题——制作人也应该有HRBP的职责在内的（HRBP往往是合伙人，也就是人事管理，和HR职责以及责任心是不同的，权力也更大些），也就是当发现团队里有些人无可救药，比如说也说不好，对于项目不抱有认同感和自豪感，整天负能量的时候，应该及时裁撤（当然不一定是开除，这得看公司具体的人事安排，有些大的公司就是转别的项目组了）。这不是一个能力的问题或者人际的问题，“千里之堤毁于蚁穴”。善于发现团队内负能量源，并且及时消灭是制作人的主要工作之一。
这些工作，其实和专心写代码都不冲突。
所以故事里的项目，光目前来看，问题就在于人，从人出发产生了更多的问题，比如因为沟通不顺，开始团队里产生了怪气氛，到后来彼此失去信心，对游戏也失去信心。
六、对于不确定因素的虚假自信
正如评论中东东所说，用盖楼比喻做游戏是不那么恰当的，因为楼房需要从工程图到施工计划每一步都精确设计，完全完工直至交付。而做游戏，特别是有探索性质的游戏，是很难做到早期的“完全设计”的，再牛逼的策划，也不可能在策划案里把每一个细节都考虑到，也不可能对每一个设定方案抱有百分百的确信——在上线后这些预想的方案能发挥期望的作用。
上面尖锐地指出制作人的问题在于专注细节缺少全局考量。第三年，经过多次交流，制作人也大度地承认了指挥问题客观存在。同时，制作人也把决策权全权交给了主策，给了主策一定时间去挽救项目。
主策自认为对于所做游戏的认知非常深刻，主体框架已经思考很成熟，只要设计完全落实即可保证项目完成。但是在项目的后期，大家逐渐发现，主策的这种自信，是一种带着盲目和掩饰的自信。
在第三年十月的时候，项目1.0决定关闭，大家都心有不甘，觉得付出多年的心血不应该落得如此下场。那时主策为了挽救项目，表示自己对项目有十足的信心，知道如何挽救才能走出困境，并且努力地向团队和制作人传递这种信心和决心。那时大家都非常低落，主策的这种态度作为一道强力的肾上腺素注入团队。大家决定跟随主策再做最后一次努力。但是为了保证项目的续存，主策传递的信心和信息存在过多的水分。其中主要的问题就有：为团队建立了不切实际的预期。
在主策争取项目继续的时候，制作人心里想的是再给两三个月让他改改看。而主策心里明白，项目1.0已经从内容框架和程序框架上都改废掉了，没有挽救方法，只能推到重构。而如此庞大的项目重构至少需要六个月才能搭建完整体框架。但是六个月显然不符合制作人的挽救心态。在那个时刻主策向制作人给出的计划安排是：两个月搭建完核心框架、四个月搭建完主体内容——然后回去就做了六个月开发计划——试图先斩后奏绑架时间周期。
这个行为导致的后果就是在第二个月和第四个月的进行阶段验收的时候，游戏表现远远不如制作人预期。但是由于车轮已经滚起来，大家都被主策裹挟上车，只好硬着头皮继续做下去。
另一个维度的虚假自信是主策对团队成员的不确定信息掩饰。在这个项目中有许多设定是没有先例参考的，在上线和玩家见面之前谁也不能确保方案的有效性。有些问题是主策也不确定的。比如说：我们设计了领地争夺，但是由于动态平衡的需求考虑，我们没有加入对领地争夺的直接利益奖励，期望通过让玩家的团队荣誉感驱动领地争夺行为发生。这种核心玩法的驱动力是否足够？主策并不确定。但是当被团队质问起时主策给出的回答是：这样的驱动力就足够了。类似的对不确定性问题给出虚假确定回答的案例还有很多。事后复盘时他自己也坦白到，是希望传递出确定的态度，因为不确定的开发内容容易引起工作抵触。
但是当不确定的东西最终被识破时，引起不仅仅是工作抵触，那会变成信任危机。在项目2.0的期间，主策就因为多次没有坦诚地说明不确定设计，总是试图塑造一种全知强硬人设，而逐渐失去了团队的信任。
在项目2.0的第六个月阶段性验收时，主策对制作人那边才真正地坦白项目开发的后续计划和成本。出于对阶段性细节表现的失望，对后续开发成本的忧虑，对团队成员信心的丢失，最终我们只能再次做出了艰难而沉痛的决定。
回顾这段游戏开发历程，我确信这是一段极其特殊的经历。立项之初，我们核心成员租了一栋别墅，在里面吃住生活工作。别墅带一个院子，本想着大家没事儿在院子里边乘凉边讨论下方案，嗐，结果忙起来院子里野草都长到人那么高了，也没用过几次。制作人没有给大家施加什么工作压力，希望保持团队有充沛的精力和良好的生活状态，以做好这份创意型工作。不设时间节点，也不走繁琐的商业流程，大家尽可能地去发挥自己的才能，做出心目中的理想游戏。这样的开发心态，在浮躁的游戏行业里算得上是一股清流了。公司曾经有许多项目，但是目前仅靠最早的几款吃老本撑着现金流。每次我们表示担心公司的经营状况的时候，老板就会安抚大家不用考虑资金压力。以做出一个能打动市场的作品为最高目标。
这是真正的游戏人的心态。加入这样的团队我感觉非常幸运和幸福。
三年的游戏开发经验，只是项目没有做成，很可惜。不过能积累下这些经验也算是非常宝贵的。总结一下：
立项之初，以及开发过程中，核心成员一定要有统一的游戏想象，并且对最终想象做好全面的推演，想清楚游戏做出来是什么样，玩起来是什么感觉。后面就是坚守这个立项根本，不再动摇。如果一开始就想不清楚，就不要妄想以后会突然开悟。
核心成员的设计理念和设计方法论最好要一致，这种基本思想的不同会导致合作的全方面立体性矛盾。如果理念谈不到一起，就不要硬凑CP了，何必互相折腾呢。
在不同的阶段做不同的工作，在该打磨细节的时候才打磨细节，不要放任全局不管，一头扎进细节的大坑里。跳坑容易出坑难，出坑发现当初没有解决的大问题，仍旧伫立在那里。
不谋万世者，不足谋一时；不谋全局者，不足谋一域。把全局的决策权，交给谋全局者。谋全局者，别天天写代码，代码写多了真的不想去思考宏观的感性的问题。
在大家状态合适的时候开启方案的讨论，如果方案不如自己意愿，可以直接表达，可以持保留意见，但不要习惯性用量化提问抬高对方的回答成本。设计者在抛出方案前，应该自己主动评估利弊，做到心里有数，有问有答，不要临时信口开河。
决策者应该对团队成员开诚布公，允许不确定因素的存在，但不能允许不确定因素被掩盖。应该提供正确的信息，为团队建立正确的期望。不要等到不切实际的预期被迫破灭时，团队的信任瓦解，再无回天之力。
东东 评论：
其实制作人的方向是对的，符合标准的敏捷开发思路。
做游戏不能跟盖楼相提并论，盖楼是瀑布式，因为楼必须完全盖完后才能交付使用，所以整体流程必须从框架到细节。
而游戏不同，前期开发如果已经包含核心玩法（即玩家游玩过程中的积攒与基础释放闭环）那么就应当尽早完成前期整体细节，然后小范围测试，用测试数据来验证后续的所谓“领地争夺”是否需要做以及应当怎么做。
很有可能小范围测试后发现，目标玩家在此类游戏中根本不在意有没有领地争夺，只想像我的世界一样随便盖房子分享自己的成果，那么第二阶段开发重点肯定就不会领地争夺上，而是更加细化建造于生存层面。
用瀑布的思路做游戏本来就是错的，前期设计太多太细，花了大精力做出来，结果发现玩家根本不买账，那是一件非常痛苦的事情。
谢谢大家的客观分析和评论。我想在文末补充一些信息，我们团队中每一位成员都是有能力制作独立游戏的从业者。尤其制作人是从2000年就进入游戏行业的业界资深前辈，亲自带队开发过许多大型项目，其中不乏商业成功的项目。文中对制作人角色进行了许多尖锐刻薄的指责，仅仅限于笔者的主观视角，肯定存在片面和偏激的论断。大家还请客观看待。对于制作人大有冒犯，还请海涵。提笔之意不在于甩锅，也不在于否定具体的人，而是对工作中经历的事情做出反思。我相信不管是谁来当制作人或主策，都或多或少会存在一些问题。因为人本身，不可能是完美的，不可能不犯错误。我们团队的一个良好氛围就在于，大家总能够直言不讳地指出问题，每个人也都能够坦诚大方地领锅。所以项目的成功是大家共同的成功，失败是大家共同的失败。每个人站在不同的视角，能够总结出不同的经验教训，希望这些经验，能对同行和我们今后的项目，有所借鉴之处。
文章部分结束~
摘选部分网友评论
网友1：
出于志趣相投而聚在一起做东西的人，很容易因为有人发现志趣其实不合/有人志趣发生了变化/有人热情被工作消磨殆尽等等原因而散掉，这也是为什么大项目很难有特色，有特色的都是小项目的原因。意见不容忽视的人一多，不是游戏特色被磨平，就是有人热情被磨光。
我尤其认为，一个自己想做出一个什么东西来都没有彻底发自内心地确定的人，是绝对不能去领导一个团队的。连领导者的心都不定，其他所有东西都是空中楼阁。
网友2：
当“主程也要来聊一聊游戏设计理念”的时候，这个项目十之八九要黄。
网友3：
真好的实战总结，虽然带有主观性。
单从本篇文章提到的来分析：
1. 立项没立好。
从过程来看，做了两年游戏方向都没完全定下来，之后又大改？！这说明立项就没立起来啊，哪怕立项立个一年半，有了一致的、完整的且闭合的、可实行的设计方案，再进行开发也不迟啊，这样才能控制好成本且又降低了风险，效率也反而高了，因为方向很明确。
2.决策者不坚定。
干游戏开发这行的基本上都是游戏爱好者，一个项目团队里的每个人当然都会有自己的想法和偏好，活跃且民主的氛围也会让团队里的成员更用心更积极的做好自己的工作。细节上的问题，大家互相商讨，各出招数，这是非常好的现象。
但是在游戏方向游戏框架以及核心玩法这种立项之初就立起来的事上，就不能各抒己见了，决策者应该要有这种说一不二的定力。
而在文章中，我个人非常认同主策的思路，用周期性消耗来打破传统MMO中的数值困境，如果考虑到玩家体验，也有解决思路，那就是再配上一套循环闭合的游戏内金融系统。
3.游戏开发思路。
文中的制作人采取的是从头做起的开发思路，这种思路其实不适合创新游戏项目。
文中提到的项目核心玩法是领地争夺，那就应该围绕这个来进行扩散性开发。
先把领地争夺做出来，之后可以选择先测试打磨核心玩法，也可以直接进行养成系统开发。
因为别的系统其实都是为核心玩法而服务的，玩家进行任务关卡是为了得到奖励来养成，养成角色是为了在核心玩法中取得快感，必须要明确这个逻辑才能分清主次，否则你的游戏只会显得杂乱。
网友4：
从本文作者的角度看，确实是制作人背锅。不过水友们也不必急着下结论，这毕竟是作者的一面之词，至少得让制作人发声，两相比较，我们局外人才能稍微了解一些，才有可能得出稍微客观一些的结论。
作者的每一条都有一定道理，但事实是否是这样，还是要多听听多看看。兼听则明偏听则暗。没有冒犯作者的意思，单纯从理论上讲，作者说的也有道理。
网友5：
挺好的经验分享，赞一个
项目不一定都是成功的，失败带来的经验也十分宝贵，日后会长期受益
高赞评论对敏捷开发理解还不到位
这种长周期且处于功能技术磨合期的项目，是不应该从细节做起的。快速出第一个版本（六个月也蛮长的，也许游戏业就是这么久？），打开讨论思路和定方向，接下来完善细节。
敏捷开发有个重要概念，MVP，minimum viable product，就是纸上空谈不如先出个样品，架子搭起来就在眼前，idea就随之而来了，接下来就是周期迭代。每一期要出个可用，即可以玩的版本，所有人都会对产品有直观概念了。哪怕观念不合，在实物上，磨合调整也可以更快了。
而且团队每个人都发表意见是很重要的，不能谁是金主谁就最大。
做项目的初心如果是打造产品，那就不能以“满足金主”为前提
带团队的人要对这一点有平衡的能力，要不咋做team lead 呢
网友6：
程序大佬写代码的同时兼制作人2333 以前也在这样的公司做过几年 尝试了几个项目。不专精不资深的程序制作人都有一些通病，全局设计想不清楚，有一些感觉就要开始做。很早就陷入细节，要让项目可以玩起来，并且好玩。遇到瓶颈想不清楚，优柔寡断，各种改来改去，美其名曰好的项目都是改出来的，用战术上的勤奋掩盖战略上的无助，一会是玩法，一会是美术，甚至剧情也要改。号召大家一起思考，做项目的主人翁。但有的人天生就是玩家，做不了设计者啊。其实很多事情，职业制作人，策划，都未必能做的很好，更何况不专业的程序大佬。一把辛酸泪
网友7：
简单看了前面2条。
第一，立项没有考虑市场。
市场是什么？有一定规模用户，规模里面愿意有人给你买单，买单后愿意再次复购，以上能让你产生盈利。
沙盒+强竞争，听起来很美好。
积累全掉落？强社交？动态平衡？
请问有多少人买单？
从18年开始，玩家就已经讨厌强pvp了，看一看coklike被率土like打得面目全非就知道了。
制作人的思路才是让你们能活下去的根本。但他一开始没看清市场。而主策只知道自己设计，不考虑玩家。
第二，游戏进程问题。
无论是一步一脚印，还是框架先优化后。
框架结构是立项时定好的。数值结构不会变。
除非增加了改变框架的东西，但这样的情况一定会出现。前两方法无论选择哪个，都是需要重操游戏的。
问题出在版本节点上，版本无休止的开发，必然会出现认知“我觉得需要修改。”有了基础闭环后，尽快见玩家，才能知道什么需要修改。
我们项目研发半年，只做了前3天体验，直接一测。
网友8：
看到扣细节那段想起一句话。
当游戏制作到了结尾的时候，游戏好不好玩已经不太重要了，能不能玩才是最重要的。
总之也给我提了个醒，若一开始就沉迷细节，终究会陷入泥潭，必须注重全局才行。
制作人还是要长点心，干什么事情，中途不断改主意，或者一开始走错方向都是可怕的事情。还是感谢分享经验，以后可以给我提个醒 大家共勉。
网友9：
我曾写过失败项目的总结《又是一年好轮回》，写完初稿后是先发给了主策主程都看了一下，得到他们认可后才公开发布出来。这样可以更客观地进行总结而不是主观色彩浓郁的吐槽文。我那篇文公开当天就被事业部总裁看到，然后他转发给了主策，主策又跟我说总裁把我的文转发给他的事儿……因为我提前都看过了所以大家也不觉得尴尬。可是你这篇文若被制作人看到，会不会很难受呢～稍微一点小提醒，对同事或者领导多一些理解包容，都是打工的谁都不容易。
网友10：
我感觉制作人未必是具体的游戏经历缺乏，而是被过去的经验束缚了。
我知道的程序出生的制作人，很多是换皮时代成长起来的，他们讲究的就是一个快，比如六个月就要体验完整之类，而在普遍抄袭的情况下整体框架确实不被重视，野蛮生长的年代大家都是往上面堆东西，捞一笔就跑。
稍微长线一点，不那么及时的，就会让他们感觉失控，再加上设计策划这类东西好像谁都能说上几句，骨子里是有点看不上策划的。
网友11：
团队意见产生分歧的时候应该由风险承担者做决策。一旦下了决定，就不应该讨论谁对谁错。
全文总结：btsybt认为以上总结还是相当有深度的，创业者完全可以参考。
原创文章，作者：米米，如若转载，请注明出处：https://btsybt.com/600.html