【游戏编程扯淡精粹】工作第三年总结

工作第三年总结

今年仍然是个人成长视角更多一些，额外新学到的重点是，借助团队力量

先介绍两个词：

1. unk-unk：unknown-unknown的简写，即不知道不知道的事情，它们会偷走项目的时间并且阻塞时间表
2. low-hanging fruit : 轻易能达到的巨大提升
3. mere-work : 需要很少创造力并产生很少风险的工作，可以被很容易地评估

#1 做了什么

由于项目保密，笔者开发的一个工具用 ToolX 代称，本文不谈其技术和是什么，其他工作涉密内容也不会讨论

截至目前，正好在当前项目做了一年客户端 Gameplay，半年 QS 天刀引擎，半年 UE5

自研路线

工作的前两年半，笔者下班后一直维护另外一条自研路线

• Zelo Engine：自研客户端玩具引擎，跑通引擎流程，Lua 脚本 + OpenGL 前向渲染 + ImGui 编辑器
• Zelo Engine2：目标是现代玩具游戏引擎，Vulkan + Job System + ECS + Server，实际只写完 C++ 反射系统，其他只做完技术选型和跑通 Demo，由于一些原因搁置了，后面会提到
• Lyra：切 UE5 后，单独维护一个 Lyra 作为 Playground，目前也不太使用了

维护这条路线，在入行前期有非常重要的意义，一个很好的结果是，工作线和自研线互相反哺

• 通过自研一个玩具引擎，获得 C++ 实战基础，进而获得下一份工作 // 如果只是项目工作，那就是一年 Python 脚本，估计就很难获得现在的工作了
• 自研玩具引擎的 Lua 框架和工具链，移植给项目 QS 引擎，让项目的 Lua 变得好用
• QS 引擎的反射系统，看懂了自己写一个，主要原因其实是面试时没答上来
• 自研线只有自己一个人提交，保持干净，快速构建，快速实验各种小功能，再移植到项目引擎

这条线最近半年开始逐渐搁置，主要是：

1. 项目引擎屎山，做实验的效率低，但是切 UE5 DevOps 逐渐完善后，在项目里实验的效率已经足够高，没必要自己维护一个独立环境
2. 自研玩具引擎的学习收益到达瓶颈，这些技术规划很好，但是项目里并不需要
3. 在项目里的工作开始进入好的循环，学习-输出-反馈，逐渐倾向于在项目中输出

Lua 脚本系统

目前项目里的 Lua 模块由笔者一人负责维护

但是实际这个模块的积累早在大二就开始了

• 大二把 Lua 解释器自己从零完整实现过一遍
• 工作第一年，自己从零搭建支持 Lua 的引擎
• 工作第二年，维护 QS 引擎的自研 Lua 模块
• 工作第三年，切 UE 选型并接入维护 UnLua

这个过程是标准化的，可复制的，学院派-自研玩具-维护项目已有模块-为新项目模块选型维护

在大二写解释器的时候，谁能想到后面会在工作里负责这个东西呢？

这块简单说一下对 Lua 模块技术上的浅显理解：

• 不只是接入 UnLua 能跑就完了，要提供一整套脚本解决方案
  • 完善的工具链：Debugger，IDE，内存泄漏，Profiler（CPU 和内存 GC），热更新
  • 文档和培训：项目里前 2k 行 Lua 代码是笔者手工翻译蓝图写的，让其他团队成员抄作业
  • 性能优化：benchmark，常规的优化手段（必须有），以及一些先进技术预研（可以有）
  • 方案对比：puerts，其他项目的使用经验
• Lua 是一个工具，以目前工具链的完善程度，已经比 C++ 迭代 Gameplay 效率高 N 倍，简单来说，就是出活快，不卡版本构建，拿机器时间换程序员时间
• 去框架化，这次的 Lua 笔者选择不预先搭建框架，而是直接写，堆逻辑，并提供若干实用函数
  • 看过若干也写过一个框架，笔者认为搭建框架的坏处在于，预先定义了若干“角色”，用了框架就必须派生某个角色来写，后面再调整角色就很困难，大多是给屎山打补丁
  • 笔者缺乏上线项目的验证经验，开始搭框架时的设计对未来的预测大概率会有偏差
  • bad：和 C++ 没隔离，跨语言边界交互少不了，潜在的性能问题，这是无框架不可避免的
  • good：开发半年，大概有 1w+ 代码，确实是不需要所谓框架的，用 UE 本身的事件回调就够用了

ToolX

ToolX 是笔者切 UE 后两个月开始开发的一个工具，是市面上某个痛点的第一个解决方案

emm，这个说法怪怪的，但是保密没办法，组内分享的时候主要讨论了技术细节，本文这里主要说说非技术因素

ToolX 大致的开发历程是这样的：

• 笔者在切 UE 的第一周，开发过程中就模糊地感觉到有这个需求，有意识地去在空余时间做一些预研和方案选型
• 切 UE 的第二个月，笔者想到了一个绝妙的新解决方法，然后花一天跑通 hello world，周五周会上提了一下，技术总监塔夫哥这块正好有需求，本来在用常规的堆人力 A 方法，需求进度缓慢痛苦，于是开始尝试笔者这条路线，给了一周时间，并且沟通清楚技术创新的风险性，和必须快（速失败)
• 周六，周日加班，20h 肝第一个 Demo，这个 Demo 的效果已经比另一个项目组 T9 做一个月的方案好了
• 第一周，搭架子，跑通核心流程，这时笔者比较确定能做完了
• 第二周，加入一个引擎组同学一起肝，分摊工作量，结束的时候已经能用 ToolX 用于原来需求的生产了，而且需求进度一下子冲到 60%
• 第三周，第四周，继续完善和开发，最终产出结果，需求进度 100%，ToolX 进度 90%

实际大概是 6 周的时间 x 2.5 人力，完成了这个需求，相比 A 方法节约 2+ 人月，ToolX 持续用在项目内

这个过程中，还遇到 UE DS 网络的问题卡住，非常艰难，最后运气好解决了

这个活的真正难点和关键点，并不是想到了那个“绝妙的方法”

技术和原理虽然是第一性的，是技术创新开头的必要条件

但是支撑把这个方法落地，到最后有很好的产出结果，有很多更加关键的因素：

1. 运气好
2. 团队支持
3. Tech Leader 支持
4. 技术开发流程
5. 个人努力和技术积累

运气好，首先是团队有这个需求，没有需求，这个技术是没有业务价值的，Leader 也不会支持

然后是开发过程中，在实际产出一个可用结果之前，任何一个卡点，这个项目就暴死了

这里遇到 UE 网络的问题，就是预料之外的，实际上，当时给的是一个临时方案，笔者后续持续跟进这个问题，半年后也就是最近才彻底解决这个问题，也是运气好，那个时候能在两天内给出临时解决，才让项目进行下去

这里涉及一个风险控制的问题，就是说，技术创新一定是有风险的，风控的核心是在早期排除 unk-unk：

1. 快速失败，知道最坏结果的恶劣影响，产出是 0，浪费了时间，损害团队信用，所以第一周的工作就是快速排雷，验证没有基本的技术卡点，即编码过程不会有实现不了功能的情况
2. 即使没有基础卡点，也会遇到意外，这就是运气问题，要尽快跑通实装流程，遇到意外了有一个快速的临时解决

团队支持，两个人力拉出来做这个分支项目，意味着主线项目需要分摊工作量

Leader 支持，在团队内作为信用背书，这点其实也是出乎意料的

这里可以理解为信誉积分和技术品牌，个人有一个积分，团队也有一个积分，当遇到这个关键事件的时候，笔者抵押个人信用，说“我能解决这个问题”，然后团队支持也抵押了一份，事情做成了，个人和团队的技术品牌都得到了提升

技术开发流程，比较基础，前面提到，ToolX 时笔者自己维护一个 Lyra 开始做 Demo，再移植到项目内，包括技术上倾向于 Python 写快速开发原型，都是日常自研习惯积累

涉及到两个人干活，拉分支，做好任务分配和排期，问题跟踪，因为疫情原因，实际上 ToolX 除了开头一个会，大部分时间都是远程办公

个人努力和技术积累，虽然但是，其实是最不重要的一部分

#2 职业发展

如何做事

个人

笔者在 2019 年实习的时候，翻项目资料，仔细看过毛星云写的周报，其实和他开源的文章和项目笔记一样，简单来说，就是认真做事

国内技术环境是相当恶劣的，急功近利的，个人要保持内核稳定，认真做事，不要受环境影响

按功利的角度，写文章分享，写文档，写书，做 ToB，做纯技术就是不挣钱的，毛走了，还有问题问他做了什么游戏，挣多少钱，实际他的技术影响力，留下的这些资料是非常宝贵的

在团队内做事

项目组内是需求驱动的，做了有反馈是最重要的，这样才能快速地深入地做好一件事，避免闭门造车，技术自嗨

自研路线搁置的一部分原因，就是要实现真实的需求，不要实现自己想象的需求

每个公司和团队都有一堆问题，强如 Naughty Dog 在做 TLOU2 的时候项目管理也有糟糕的时候，不要抱怨

技术中台化

之前分享过一篇自研引擎 vs UE 的文章，其实也是因为那个时候项目组也从自研切了 UE，非常突然

文章重点当然不在技术细节规格的对拼，而是技术中台化对个人技术路线的影响

从自研切 UE，个人的一部分感受：

降低沟通成本

团队外技术交流多，有问题可以问项目外的人

技术通用化

笔者做的 ToolX 是通用的，UnLua 也是通用的

一份技术能服务更多团队和用户，当然是好事

UnLua 节约了自研 Lua 框架的成本，切 UE 后一周内就把 Lua 开发流程跑起来了，如果是自研。。

自研技术的未来

其实是比较迷茫的，UE 标杆立在这里

技术通用化，意味着一旦有一个标杆立在这里，新项目选型优先选择中台技术，比如 UE 和 UnLua，不会费劲去再造轮子

个人开发和学习路线，其实优先用好 UE，既然是通用的，就学的快一点，广一点，避免造轮子

这个造轮子，不只是写代码，连 TA 也是一样的，某个效果（Shader 或者物理），优先找现成的

反过来，自研技能会失去锻炼的机会，做游戏靠爱发电，现在做引擎也是，光是使用现成的中台技术，会逐渐丧失底层开发的能力

内卷的职业市场

内卷化，大概是 2019 年的一波红利，在 4 年内基本消失殆尽

现在入行门槛非常高，和最近不景气无关

202x 年，Games 系列上架，先是渲染，再是直接一个现成的小引擎

当初面试 Gameplay 都问渲染和引擎，现在大家人手一个

笔者入行的时候，还没有 Games101，不过也没有卷到引擎岗

第二年重新找工作的时候，引擎岗已经彻底内卷化，几乎没有机会了

这种内卷和门槛高，意味着基本只有校招那一次有机会卷到引擎岗（其他岗位也适用），因为不要求经验

跳槽转岗，招聘方要有相关工作岗位 2-3 年经验的，陷入没工作经验 => 没工作 => 没工作经验的套娃

项目内转岗，实际项目里的工作越来越细分和专业化，比如引擎的活也不会给 Gameplay 做，如前所说，没有需求驱动，进步是很慢的

心态的转变

1. 进到岗位里，了解组里引擎岗的实际工作内容和水平，笔者对目前项目的引擎岗评价是，积累确实非常深厚，应该以此为目标，而不是校招八股文面试评价标准的好为目标，下次面试就不需要考八股文刷脸过了
2. 没人能阻拦你学引擎，现在资料开源太多了，不过要谨慎选择路线，避免无用功
3. 把手头的事情做好，自研引擎和其他技术当兴趣爱好学，硬卷引擎的损耗太大，前有非常专业的引擎前辈坐镇，后有校招后浪的后发优势，市场如此，暂且躺平

个人成长

• 整体学习方法，没有太大改变，除了砍掉自研线
• 个人做成了以前做不成的事情，是非常大的突破
• 其他保密

#3 心态建设

心态建设，很重要很重要，比多写几行代码重要

前一年总结中说到，在低压力的环境下持续成长，这一年基本是保持住了，继续保持

Owner vs 打工人

做 ToolX 的时候，有种强烈的不同的感觉，就是作为 Owner 的自治开发体验

日常需求驱动，是打工人身份，是被动的

做 ToolX，是主动的，从发起，到排期每一步做什么，都是笔者控制的

第一年工作，工作中基本是 mere work，打工的被动感非常强，所以通过下班后高强度的自研路线，获得控制感进行中和

mere work 并非完全不好，它非常的稳定，没有创新，没有技术风险，因为都是市面上成熟的需求

这意味着对风险的控制，作为打工人，做 mere work 是不承担风险的，如果有尽力了还做不完做不好的情况，都是 Leader 的责任，对员工能力评估不准，对需求风险评估不准，还有就是 PUA 员工，因此作为打工人，应该心理压力小一点

这两种工作按照一定比例混合对冲一下，整体的工作节奏就很舒服