很多小伙伴最近在面试或者考虑跳槽,可能工作了3~5年了想涨薪或想做技术总监或主程, 可自己还是个雏，没有做过项目技术管理，怎么办？今天我给大家梳理一下作为一个技术总监或主程你应该如何带好一个游戏项目，做好技术管理。接下来我们将以一个项目的主要流程为主干，分析在每个环节中你应该如何处理和应对,避免踩坑(注:有些小的游戏项目，某些环节可以做精简，具体的根据实际情况来决策)。
1: 游戏项目的技术可行性分析与验证
公司开始决定研发某个游戏，游戏立项后公司的各种资源陆续到位，作为技术管理者，首先要做好技术上的可行性分析验证。如何做呢？我们可以按照从下几个步骤来执行:
(1)列出需要做技术验证的清单与工具验证的清单;
(2)根据清单分配好技术验证工作到对应的开发者;
(3)准备好相关技术可能用到的技术资料与技术储备;
(4)确定好正确的技术攻关的方向;
先来看如何把要做的技术验证都列举出来，这个工作其实是很关键的，项目中可能涉及到技术风险，是否能尽早的公关和得到验证，是后期项目平稳上线的关键。我大概列举了一些常用项目可能要注意的几个方向,供大家参考(更具体的一些细节，可能不同的项目会不一样)。
渲染效果与渲染性能
渲染效果与渲染性能是我们首先要验证的核心方向,比如我们要做卡通类的游戏，我们就要开发出高效的符合游戏项目风格的卡通Shader相关代码和技术验证。比如，我们项目中必须要求实施光照，就可以考虑定制渲染管线来代替传统的向前渲染管线来获得更好的效率和性能,如使用URP渲染管线等。
渲染性能验证是指模拟游戏玩法的极限情况，堆出来可能的极限的场景，角色数目，怪物数目，释放技能等然后运行来验证渲染的性能，看下三角形的面数，渲染性能开销，Drawcall等。
这些验证要特别的注意，一定要上游戏目标玩家的真机来做处理。比如渲染效果，要多测试几组目标玩家的机器，看看渲染效果是否有差异，渲染性能是否能达标,有些由于平台和显卡的原因导致渲染效果有差异,可能要额外的写代码来抹平这些差异。
还有一个很重要的点是要考虑渲染降级,我们在做一些精品的游戏的时候往往考虑的是中高端手机的游戏画面和效果，但是有些低端机，为了玩家的流畅性，我们就要考虑渲染降级，如何来做这个处理，我们也要做好需求分析与技术验证,比如编写一套shader,如果是低端机，就用渲染效果没有那么好但是性能开销小的shader。如果是低端机，可以关闭一些特效等。
总结: 尽快的在玩家目标群体的机器中做好渲染效果和渲染性能的验证与统计,同时在这个过程中摸索出来设计的技术规范，比如模型的面数+细节增强的流程规范等。这里额外再说一点，模型场景的面数规范不是网络上去百度得到的，而是根据真机的实际的场景，游戏中的物体数目, 运行的目标人群的手机等因数综合考虑来得到的美术设计等一些参数规范。
美术策划工具制作与规范化开发流畅
工具制作也是需要优先考虑和做验证的，因为工具制作涉及到了开发协作流程，比如做一个给策划用的关卡编辑器来做关卡编辑。和策划约定好相关的输入规范与输出规范。策划如何做，程序如何用等，具体的可以结合游戏项目来考虑。这个过程完成后，就可以制定出和美术策划协作的一些具体的工作流程。
游戏核心玩法的验证
有一些游戏的核心玩法，需要验证，比如格斗类游戏需要验证一些玩家的手感,AppStore上有一些创意类的游戏，需要组织技术来实现核心玩法，比如《纪念碑谷》等游戏。比如《贪吃蛇》满屏都是长蛇的玩法验证等。比如有些创意类游戏要做Mesh切割等都需要来做技术验证。
经过上面的一些技术验证和摸索，我们对项目的技术难点，团队成员(程序+策划+美术+测试等)协同开发与合作都可以形成初步的认识与流程方案。
2: 参与制定团队协同工作流
游戏项目开发本质是一个工程管理，所以严格的工程项目管理流程是非常必要的，整个项目开发中设计到的有：美术+策划+程序+测试+运营等。接下来大家就会再一起来商量出一个协同工作的流程。大概率上来说都是基于版本管理工具来进行管理与协作(如git, svn等)。策划提交哪些策划案与数值表给程序到项目中用，美术做好资源后如何导出来，导到哪个目录下给程序使用。在这个过程中，Unity主程要考虑的问题主要是：
(1)程序如何与策划的数值表对接起来;
(2)程序如何与策划的关卡地图,关卡数据对接起来;
(3)程序如何应对策划的改动，能让策划马上看到效果等;
(4)程序如何与美术的地图场景对接起来;
(5)程序如何与美术的角色对接起来;
(6)程序如何与美术的一些粒子特效，技能特效等对接起来;
(7)程序最后如何把这些资源数据通过程序拼接成游戏;
(8)程序如何发布版本交付给测试，进行版本测试;
(9)程序如何与测试对接制定测试的case;
(10)项目如何建立bug提交与管理机制;
…
综合考虑完这些问题以后，就会出一些协作规范与协作模式，这样大家就可以各自协同开展工作了。对于程序来说工作是非常重要的，因为最后粘合所有的都是靠程序。所以在团队协作中，我个人比较倾向于以程序为主导来建立开发与协作流程。
3: 框架设计,版本管理,热更新,多渠道打包发布
讲了这么久程序员熟悉的框架设计版本管理，热更新考虑，多渠道打包发布才上场。这里上场前先得要划分好目录结构，这里得目录结构要结合上面得工作流，哪些目录开放给策划，哪些目录开发给美术，策划做好得地图数据放在哪个文件夹等，这些我们做框架得时候要优先定好，来疏通上面得协作流程。这些定好后，美术+策划的工作能正常进行了，这个时候才是程序自己做具体框架代码的时候,才是熟悉的配方熟悉的味道。框架设计本质就是提出一套开发规则与开发流程，所有的程序基于这个开发流程来开发业务功能，与业务无关的代码作为框架代码，下一个项目可以重用，与业务逻辑代码相关的就直接考虑用这个项目就可以了，如果其它项目要用再考虑从这里取。这里要特别说的是资源管理，发布的版本管理，热更新版本管理，以及多渠道打包方案，不过这些方案都是成熟的，相信各位主程们都比较熟悉了。
4: 代码review与稳定性测试
作为一个主程，必须要抽时间来review每天的代码推进，专门找人或自己来review每天代码的实现,把控好团队的实现思路，代码质量等，看是否有走偏, 提前发现各种技术隐患，因为你的团队里面不是每个人都年薪百万，所以必须要做好代码的review与管理，如果项目大，开发者多，可以专门让一个技术管理者review代码。在review代码的过程中可以形成技术架构文档，来为团队的交接做好准备，如果是小项目，而功能都是主程自己开发，这个过程可以根据实际情况来省略。
测试我是强烈建议尽早的引入对多平台，多目标机型的真机测试,这样能今早的发现问题，同时完善测试case。今早的他测试对接流程放日常的开发中。同时管理者对项目过程中遇到过的问题做好review,关键时刻很多改动都在脑袋里面，很多曾今的错误都在，关键时刻能获得灵感。不要等项目快上线了，才做真机测试，到时候一堆的问题。
切记：稳定性是基于严格工程管理与开发设计流程的产物，没有高大上的天马行空的想象,就是一个工程管理问题。
5: 换位思考,能让你获得不一样的视角
程序员本身就很聪明，什么时候能觉悟，完全取决于他看问题的视角，如果他学会多视角来看问题，加上他聪明的才智，一定能很快就觉悟, 获得更好的机会。而多视角看问题，我们不能只在光从程序的角度上去,要从各个角度去审视。所谓不谋全局者,不足以谋一域,不谋万世者,不足以谋一时。只有学会从策划的角度，美术角度，测试角度，运营角度等多角度思考问题，你才能有不一样的视角，才能看到别人看不到的点。才能坦然的去接收，以及后续自己创业时获得宝贵的经验。
6: 对外为团队争取利益，对内不居功自傲
作为团队的管理者，除了要做带好项目，管理好团队还要为团队争取合理合法的利益和权益。权限和利益争取下来以后，对内也不居功自傲，外其身而身存,后其身而身先。很多人说，项目发奖金了，我拿走了大头，自己赚钱了就可以了，苛刻一下小弟又怎么了？说的是没有错，你也可以赚一点小钱，但是你要想你的理想是什么？40岁以后你怎么弄？路越走越宽还是越走越窄。合理合规的分享利益就可以了。这样路才会越走越宽。