2022下半年游戏开发心得
接着上篇文章，这里继续谈谈2022下半年游戏开发心得。我们用的是UE4引擎，目前管线内成员变成了9位，2个程序，3个美术同学，2个策划，1个PM，1个翻译同学。下面开始，主要8点：1）完全摸清了UE4多分支开发的正确方式。2022年，带领9位管线成员开发一整年，整个团队在主干没出一次大问题。
2）沉淀出游戏研发领域的三个底层概念。“创意”与“落地”、串行开发与并行开发、“做b修a”。
3）策划案子的中英文关键词。
4）游戏开发中将的2D与3D分开开发。
5）每个迭代三种需求的比例。正常需求、优化需求、插入需求
6）沉淀出四个方法论。“分数论”、“比例论”、”问题收集论“、“认知论”
7）招人、识人和带人的三个字。“诚”、“勤”、“谦”
8）谈谈对国内游戏、大厂职场、学生就业与创业的一些看法。
针对第一条，目前我已使用了3年半左右的UE4，除去前面一年半的摸索阶段（经常把主干搞崩溃，开发效率极低），第二年我个人基本完全摸清UE4的正确开发方式，自己2021年这一整年在主干没出大问题。2022年，带领9个人管线团队，我把自己的方法告诉给其他人，其他人也一整年在主干没出大问题。具体什么方法可以参考我之前写的这篇文章《使用UE4开发游戏心得（一）》，不过除去之前总结的那些多分支开发方法外，去年下半年我又总结了一条，我们内部叫“5号分支”。
目前我们项目中分支有三类：1.主干 2.官方分支（战斗、ui、工具、渲染） 3.私人分支。这里先将1类和2类的分支编个号：0号为主干 1号为战斗分支 2号为ui分支 3号为工具分支 4号为渲染分支，（私人分支先不管）。1-4号为官方分支，有很明确的分支管理规范，可承担大部分功能开发。但现在的问题是，有些中小功能或者中小级别的bug需开发或修复，去0号太危险，去1-4号又太慢，去私人分支的话又太麻烦（毕竟私人分支拉线、合线额外工作太多，且测试也不够充分）。为了解决这个问题可以引入5号分支，5号分支也为官方分支，有专人和明确分支管理规范。5号和1-4号是同一级别的，但有个很重大的区别，即5号分支基本每天或每两天或三天合入一次到主干。这里5号分支可由构建同学管理，且5号分支主要给程序使用，大部分都是提交C++相关代码。根据目前的开发经验，项目崩溃、异常比例大约为：程序：策划：美术 = 8：1：1。其中程序80%的崩溃、异常又都是C++代码造成的。这里引入5号分支就是彻底解决项目中64%的C++造成的问题（1-4号或私人分支只能解决约50%的C++问题，所以依然会有14%漏网之鱼）。所以整体下来分支开发比例为：1-4号（含私人分支） ：5号 ：0号 = 7：2：1（对程序而言）。这里0号还占10%是因为总有些非常紧急的功能和bug需直接往主干提交和修复，且合线后也会直接在主干修复一些冲突。对程序新人而言，去5号分支也比较稳妥，负担较小，虽然麻烦点，但不至于把主干搞崩了。私人分支也可先合入到5号分支，避免因合分支不熟造成主干崩溃。
总结下来就是“5号分支”基本专给程序提交和验证C++相关功能使用（登录、操作等危险模块也可先去5号分支），毕竟UE4开发中，大部分问题都是由C++造成的。开发成本会多一些，但因为只有程序提交，所以合线、解决冲突（都是代码）、测试等负担也相对较小。
针对第二条，游戏研发的3个底层概念：
1.美术的“艺术与落地”、策划的“设计与落地”、程序的“开发与联调”（程序这个有点特殊，因为程序通常就是干落地的事情，联调更多是将所有环节组装起来，且这活通常只有游戏客户端才能全部做好），这三个某种程度上是一个意思，即游戏研发者想做好一个需求，基本上要提两个单子才行（少数任务也可一个），即一个自己独自开发（创作、设计、功能开发），另一个和别人一起开发（美术落地、配数据、功能联调）。目前游戏行业内新增的三个岗位：TA、TD、引擎开发（引擎程序相比游戏客户端更注重T），实际也是上述的一种体现。
2.”串行与并行开发“是针对于工种（视觉、动效、程序、策划、测试、运营）而言的，比如视觉和动效并行开发，等他们开发完了，程序才开始开发；或者视觉、动效、程序一起并行开发。不急的时候就串行开发，急的时候就并行开发。经验不够的时候就串行开发，磨合很好的时候就并行开发。不确定的时候就串行开发，确定的时候就并行开发等等。串行开发和并行开发各有各优缺点、各有各的适应环境，需灵活掌握才行，切记不要一刀切。
3.“做b修a”是针对于个人而言的，通常游戏开发者所有任务都是一个接一个的，比如这周做a任务，下周做b任务，下下周做c任务。但实际情况是，即使我们这周已经做完了a任务，且已经排了2天时间专门收尾完a，且最后也验收通过，没啥大问题了，但到了下周我们在做b任务的同时，a任务依旧会有不断的问题要处理（遗留的a只有多与少的区别，除非你换项目，不然哪怕游戏已经上线，偶尔也会有a相关的问题要处理）。这现象在游戏研发期体现更明显，最后我们不得不一边处理b任务（做b），一些处理a任务（修a），非常痛苦。实际上每个职场人都会面临做b修a的情况，修a没有办法避免，但我们可以尽量减少修a的比例，比如做b:修a=8:2或者9:1。当然有些极端情况下做b:修a=5:5。
这里我重点说下如何修a，我们内部有3种方法，第一种是做b的时间多估点，不要太极限，尽可能保证白天做b，晚上修a；第二种是强制插入新的单子，直接用整块时间修a，其他单子全部延期；第三种是强制加班修a。我个人推崇第一种，但这对领导和PM要求较高，多估多少时间做b是关键。第二种缺点是打乱了整个个人排期计划，如果没人依赖你的单子可能还好点，不然就会牵一发而动全身；第三种副作用太大，偶尔用用可以，长期用对士气危害太大。
最后上面三个底层概念都是一环套一环的，2需要用1来决定哪些可以串行哪些可以并行，3则是对2的补充。理解了上面三个底层概念，那么游戏开发中任何一个单子都可以很清晰提单、拆单、估时、排期、开发、联调、验收、跑查、体验。
针对第三条，前面两条理解起来估计有些难度，这条先来个简单的过渡下。之所以会将策划案子的中英文关键词重点拿出来说，主要是因为我们团队内有个专门的翻译同学，这个同学实际上是给美术大佬（老外）当助手的，所以正好也可以顺便协助翻译一些其他游戏术语。从事游戏行业这几年，我发现大部分国内人对游戏的理解是不够的，有个很明显的现象就是一些专业术语很业余，虽然最后游戏也能做出来，但很多细节都是很粗糙的（60分或70分水平），带来的问题就是整个游戏品质始终无法提升上去（85分或90分水平）。所以这次我在管线内强推这个策划案子的中英文关键词的事情，好处有3个：
1.关键词能够让所有人对策划案子快速了解，分清重点，减少沟通成本。
2.英文关键词能够让美术资源、程序代码、策划表命名统一，避免大量沟通、开发成本以及后续的维护、重构成本。
3.对关键词的提炼也更有助于加深策划或者整队团队对游戏的理解。
对于那些没有专门翻译同学的游戏研发团队，建议这个中英文关键词的任务都交给策划，让策划出案子的时候，顺便出一份中英文关键词对照表。
针对第四条，游戏研发中的2D与3D分别开发，这里2D开发通常指的是UI或者系统业务开发，3D开发通常指的是核心战斗开发。前者比如背包、新手引导、活动、社交等系统玩法基本都是UI开发，后者核心战斗基本都是角色、武器、技能、关卡等非UI开发。但这里我们管线做了一些调整，首先我们发现哪怕核心战斗其实也会涉及UI开发，比如操作HUD、跳字、血条等，这些UI开发交给3D战斗那边的同学，有3个挑战：
1.很多游戏开发不愿开发UI，特别是经验丰富的。
2.哪怕经验丰富，但从没开发UI经验的老司机，你让他去写UI，他也写不好，或者短期很难写好，因为UI虽然较简单，但实际也有一大堆流程和规范。（这里第六条的四个方法论中“认知论”解释了这种现象）
3.UI美术效果经常变，来来回回会占用大量开发时间和精力。
所以我们管线内完全将2D和3D分开开发，只要涉及2D开发的，全部交给UI开发同学（交互、视觉、动效、UI程序）。一个战斗单子如果涉及UI，那必定要拆出一个UI的开发单。核心战斗同学只做底层战斗部分，同时将一些数据接口暴露给UI开发即可。
目前来看，2D和3D分开开发是个皆大欢喜的流程：UI程序是个外包小菜鸟，也乐意做些上手简单、重复的事情；3D开发是个正编老司机，不愿搞UI开发，联调时偶尔指导下UI程序也能接受；UI美术（交互、视觉、动效）也开心，只需和几个固定的UI程序对接工作就行，省心又省力。
针对第五条，通常来说游戏开发都是分成好几个迭代的，比如每两个月一个迭代，开发三年，那么一共就是18个迭代。通常每个迭代需求分为两种，一个是正常需求，另一个是优化需求。前者前6周开发，后者后2周开发。但实际情况是，还有一种需求是插入需求。
首先我们要承认的是，插入需求是无法避免的，因为市场（或者老板）总是变化的，但我们可以控制插入需求的比例，以及将插入需求规范化、流程化。比如研发期，正常需求：优化需求：插入需求=6:2:2；上线期，正常需求：优化需求：插入需求=8:1:1。也就是一个开明的团队是一定能够正确看待插入需求这种事，以及能够将插入需求带来的危害降到最低。就我个人理解而言，越是成熟的团队，插入需求的比例越低；越是靠谱的团队，插入需求的危害越小。这里有的同学可能就要问了，我们这是个新团队，时间紧、任务重，每次迭代必须将8周时间排个满满当当才行，每个迭代也都会有大量插入需求，最后每个迭代都是鸡飞狗跳、乱作一团，最后团队成员都是身心俱疲，这种情况怎么办？
这里我谈谈对插入需求的3种解决方法：
1.建立预备队机制、短期任务与长期任务机制。这里预备队其实和战争中的预备队是一个意思，即保证项目中有一部分人平时是不用参与日常业务开发或者少量参与的。这部分人通常是富有经验的，大部分时间只做长期且难的任务（当然，日常任务必须也得会且熟）。当每个迭代插入需求爆表或有风险时，预备队就必须放下手头的长期任务，去做一些紧急的日常任务，以此来保证每个迭代顺利完成。
2.二八法则。用80%的精力去做插入需求中20%的精华部分，剩下边角且繁琐的需求一律不做。这次迭代只做插入需求最核心的一部分，其他部分下个迭代再说。
3.使用“分数论”解决，即内部实现：60分 外在表现：80分。大部分人能理解上面第一点（加人力），少部分人能理解上面第二点（减需求），那这里的第三点又是个什么意思呢？我举个程序员喜欢争论的例子：同样一个功能，刚毕业的小伙子可能估个一天就能整出来；经验丰富的老司机一看，则是非3天不可，稳妥点5天最好，最后是小伙子嫌弃老司机老油条，老司机责备小伙子不讲武德。其实在我看来，这二人的做法都没错，之所以经常争论这个问题是因为各自看问题的角度不一样：小伙子求快，因为要证明自己能力；老司机求稳，因为以前翻过车。但如果站在更高一个维度看这个问题，你就会发现其实两种做法各有各的适用场景，具体做法就是：如果时间充足，就用老司机的做法，稳着来，一次做到80分，一步到位，后续也不会来来回回经常改；如果时间不足，就用小伙子的做法，速战速决，这次代码先写到60分，点到为止，功能能用就行，且保证外部表现看起来是80分即可，但实际内部实现可能全是硬编码、全是if else，后续维护成本也极高（60分建议下个迭代必须重构到80分）。
针对第6条，这里面“分数论”、“比例论”、“问题收集论”实际在我去年上半年总结的那几条里面有所涉及，不过下半年继续完善和正式使用起来了，且扩大了使用范围。
使用60分、80分、90分除了解决需求的评级，还可以减少其他场景很多沟通和认知问题。这里我依旧举个程序员很容易争论的问题，乔布斯曾说过一个优秀程序员顶50个普通程序员，这句话中如果这个优秀程序员做的需求要求是90分，那么我认为这句话是对的，但如果这个需求仅要求做到60分或70分即可，那我认为这句话是错的。对于一些普通任务或低端任务，普通程序员更具竞争力，性价比更高。实际上这个世界上，大多数东西并不一定都要求最好，或者短期不用要求最好，很多事情都发展都是先到60分，再到80分，最后到90分，只有合理的运用这个规律，才能脚踏实地、有条不紊的将事情做好。
“比例论”除了给职责分工外，还有很多其他的使用场景，实际上我们熟知的一些理论，比如28法则、37开、55开等等都属于比例论的范围。我们使用“比例论”主要为了减少沟通成本、提升认知水平。这里依旧举个例子，比如我们评判一款游戏，经常有些黑粉一个劲说抄袭，实际上这话没错，但不够全面，属于正确的废话。真正用比例论来评判一款新游的话，我们应该重点关注其20%的创新部分，剩下80%抄不抄袭都无所谓，或者很多游戏本来就需要同样的系统或玩法。研发游戏的话实际也是一个道理，团队应该将那20%特色部分做得最好才行。
“问题收集论”这里除了收集容易争论的问题外，我们也应用到其他场景了。目前管线内所有问题我们都记录在一个在线Excel中，有很多表，分门别类，无论bug、优化、难点、分歧点、心得等等，我们全部记录起来。以前有很多问题我们开会的时候会讨论到，会议纪要也有记到，但由于问题过于分散，导致最后总有部分问题遗漏，久而久之，问题越积越多，且这类问题一般处理起来还很棘手，时不时又总会提，但又迟迟无法解决。我们现在将这些问题收集正式化、集中化，且定期处理，比如有时候我们去和别的团队交流，我们就会从平时收集的问题中准备几个，带着问题去交流。最后，这些问题基本由整个团队共同推动、共同想办法解决，避免一人硬抗。
“问题收集论”重点在做好“谦”字和“勤”字，比如容易起冲突的事情尽量记录起来，不要有口舌之争、意气之争，"戒多言少纠缠不争论"；平时易忘之事、难处理之事，则要做到手勤、口勤、心勤，有问题都随手记录起来，时不时多翻看，多思多想多问，最终所有问题一定都会“精诚所至，金石亦开；苦思所积，鬼神迹通”。
“认知论”则是上面三个方法论的一个总结，也更为抽象。任何事情发展都有的4个阶段：完全不了解（0分）、了解（60分）、熟悉（80分）、精通（90分）。任何事情发展都的2种状态：不可控（不确定）与可控（确定）。我们做任何事情都遵循1个原则：我们会做且做过的（可控），就自己自觉做好；我们不会或没做过的（不可控），就大家一起想办法努力做好，一步步来。
针对第7条，工作这么多年，我也招过和带过十几个人，虽然是虚线，但“诚”字我一直是力求做好的，不敢有半分懈怠。对校招生来说，我发现大多数校招生“谦”字都做的不错，交流起来都是恭恭敬敬、虚心求学。在游戏行业，大多数校招生“诚”字也做得不错，他们大多对游戏的确充满了热爱与梦想，从事游戏行业也绝非混口饭吃或一味求高薪。但对大多数校招生来说“勤”字没做好，或者他们压根就不知道怎么做好“勤”字，压根就没意识到“勤”字的重要性。那什么是“勤”字呢？一个体现就是学习成绩“绩点”，另一个体现就是游戏的知识储备或动手能力。我相信大多数成绩好的同学一定都是勤奋好学、吃苦耐劳的，这也是我很喜欢招绩点好的学生重要原因，哪怕游戏专业知识不够也行。这里有的同学可能就要问了，我实在学不下去学校里的那些专业知识（太无聊），我就一心一意想做游戏。那这里我就要问了，你“诚”字是够了，那你“勤”字功夫怎么样呢？
你是否真正花大量时间去了解游戏这个行业了呢？
你是否真正花大量时间去学习和积累游戏相关的专业知识了呢？
你是否真正花大量时间去动手做一款游戏了呢？
我认为当你“诚”字做好了，“勤”字自然也能做好，不然“诚”字肯定是不够的。当然，国内游戏（或者其他行业）目前这种情况，我认为主要还是因为教育不得法，国内大学教育还有很大提升空间，很多学生空有“诚”字和“谦”字，但却没意识到“勤”字的重要性（比如讥讽学霸、60分万岁、逃课挂科等等）。要做好“勤”字，首先就需要投入大量时间，上午4个小时、下午4个小时、晚上4个小时，坚持4年，我就不信找不到好工作。你要说4年太辛苦，那你坚持一年两年也行啊，或者上午2个小时、下午2个小时、晚上2个小时。反正只要稳定的时间投入，我相信肯定有所小成，最怕那种三天打鱼两天晒网。关于如何做好“勤”字，以及如何提升“勤”字的效率，还有大量的细节，比如找到好的前辈引路、找到好的同伴一起学习进步、找到好的教程和好的环境沉下心学习等等。
（这里还有一种坑爹的情况，就是很多大学生直到大三下学期或者大四才知道要找工作、要面试，这时基本已经没有充足的时间准备了，应对这种情况可参考第八条，我下周会继续总结）
对社招生（或者能力强的校招生）来说，我认为最容易犯的一个字就是“傲”，也就是“谦”字没做好（我本人也因为“谦”字没做好，所以在职场“处处寡合、处处不如意”）。很多社招生某些方面能力的确强，来到团队，也的确能够给为团队做出很多贡献，但问题是，你能力强，也许短期能将60分的事情直接做到80分，但让你后面慢慢做到85分或90分，你又开始推脱、开始闹情绪、不好好配合，长远来看，对你个人以及团队都是不利的。与其他同事相处，也总是恃才傲物、居功自傲。庸惰才傲皆致败，有才能的人也需努力修行自己的德行和品性才行（借这条，我也勉励我自己）。
所以，招人、识人和带人，我以后都会遵循“诚”、“勤”、“谦”这三个字。这里再补充一点，对程序来说“谦”字容易做不好（程序容易傲）；对美术来说“勤”字容易做不好（美术容易惰）；对“策划”来说，“诚”字容易做不好（策划有点特殊，策划很容易没理解游戏就开始瞎设计玩法、案子或一味抄袭，很容易陷入自嗨或躺平只求混口饭吃的境遇）。
针对第8条，这条下周继续总结。 你们这9人管线像90人管线。。。 你感觉是对的[捂脸]，主要是因为我们管线内这个PM就是整个项目的大PM，有很多东西都是我们管线内总结，然后由他推广到整个项目（或者反之）。
另外，还有些细节我不便在文章说明，不过评论区应该可以，所以有什么问题也欢迎在评论区一起讨论[大笑] 现实小团队管理经验分享 对新人启发很大了[赞同][赞]
页:
[1]