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

工作第三年总结

文章目录

  • 工作第三年总结
  • #1 做了什么
    • 自研路线
    • Lua 脚本系统
    • ToolX
  • #2 职业发展
    • 如何做事
    • 技术中台化
    • 内卷的职业市场
    • 个人成长
  • #3 心态建设
    • Owner vs 打工人

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

先介绍两个词:

  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,目前也不太使用了

【游戏编程扯淡精粹】工作第三年总结_第1张图片

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

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

【游戏编程扯淡精粹】工作第三年总结_第2张图片

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

  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 员工,因此作为打工人,应该心理压力小一点

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

你可能感兴趣的:(游戏编程扯淡精粹,游戏,lua,开发语言)