2023年，游戏行业遭遇前所未有的的萧条，大量游戏公司发布裁员或者调整的公告信息。一边是应届生找不到工作，一边是行业老人被裁员。那么今天，咱就聊聊程序员是怎样从入门开始，一步一步走死游戏开发这条路的。

要想走死得先入门，那咱得先介绍一下 正常的游戏行业是什么样的情况。

1 游戏行业介绍

游戏行业主要分为研发和运营两个大的方向。做一个不恰当的比方就是：

• 研发好比是车间，负责生产。
• 而运营就是各种线上线下门店，负责销售。

一个游戏项目，不是必须同时存在两个大方向部门的。比如：

• 在游戏开发的中早期阶段，如果是国内的话，甚至是在拿到版号之前，都可以没有运营部门。
• 而当游戏发行/发售之后，买断制或者不需要继续研发新内容的，就可以没有研发部门。

对一个公司而言，也不是必须同时拥有两个大方向的部门。因为长期发行的成本并不比研发成本低，再加上术业有专攻，中小型公司并不一定能同时专精两个方向。就国内而言，能同时拥有研发和发行能力的公司 占比是极少的。

比如《刀塔传奇》当年就是莉莉丝研发，而由龙图发行的。

再比如，《战双帕弥什》是由库洛研发，英雄互娱发行的。

这两个部门之间的协作大多是通过数据进行反馈的。运营侧会要求研发侧接入运营数据的打点和分析工具，比如登录，支付，社区，打点等组件。运营侧通过反馈每个版本的数据至研发侧，以帮助研发部门调整后续版本的规划和重心。当然运营侧也可以要求研发侧 提供足够的能力来自由的配置各个版本的运营活动，如果游戏尚不支持该能力，则可以要求研发侧排期进行开发。

对于游戏运营方面，我只懂皮毛，不深入细聊。如果想做游戏技术开发，应该选择研发向的游戏公司。

2 游戏研发介绍

游戏研发追求的是如何将一款游戏按时，按质，按量的完成，如果成本比同类游戏或者竞品游戏低就更好了。

基于以上的诉求，一个游戏的研发过程中大致会有以下较大的职能部门：

1. 美术部门，负责整个游戏的外观表现。角色，场景，UI等各种“看得见”的资源的产出。
2. 策划部门，负责整个游戏的玩法和内容，以及重要的商业化模式。
3. 程序部门，利用美术提供的各种游戏素材，完成策划给出的玩法和内容制作。
4. 测试部门，负责验收程序实现的功能，是否和策划所给定的一致。
5. 项管部门，负责把控开发时间，协调各个部门之间的人力或者资源冲突。

也就是说，时是由项管部门把控的，质是由测试部门把控的，量是由策划把控的，而成本则是由两大专业技术部门：程序部门和美术部门把控的。

一般的协作关系是这样的：

1. 策划将自己的创意或者需求写出来，业内俗称策划案。
2. 策划将该需求分别提到美术，程序，测试等部门，由各部门的负责人指派人员负责该策划案的实现。
3. 在合适的时间，策划和PM（项目经理）召集相关的开发人员一起核对该策划案。无误之后，由各职能的开发人员给出自己完成开发所需要的时间。
4. 在该策划案所涉及的所有内容开发完毕之后，先由策划本人对完成的内容进行验收，之后交到测试部门做更详尽的验收。

不过因为一个版本周期内，每个人会需要同时承接多个开发任务，而这些任务的紧急程度不一样，开发的工作量不一样，比如：做一个英雄展示界面，程序可能5天就完成了功能开发，但美术肯定不可能5天给出所有英雄的资源。

这就需要PM介入，根据多方人员的任务情况，对该功能做出合理的时间安排，比如提早让美术进行开发，或者延后测试的验收时间节点等。

因为开发人员的协作关系是网状的，所以非常考验PM的协调和排期能力。

3 游戏技术开发介绍

视游戏项目开发难度不同，一个游戏研发团队大概从几十人到几百人不等。而程序人员的整体占比约为十分之一左右。但如果是小的游戏团队，程序人员的占比反而会大一些。比如一个300人的研发团队，程序总体加起来差不多是30人左右。而一个100人的团队，程序人员加起来可能有15人左右。

如果以技术人员的规模作为单位的话，那么策划和程序的比例大概为3:1，测试和程序的比例大概为0.5:1，PM一般来说一个团队1-5个。那么同样以300人的团队规模来看：

• 程序大概有30人。
• 策划大概有80~90人。
• 测试大约15~20人。
• PM大约5人。
• 剩下为美术团队，约150人。

以上列举的只是一个研发团队的大概配置，仅供参考。其中，偏效果向的技术美术，算在美术团队中。而很多公司的美术资源都会以外包形式转到外部去，所以美术人员的占比情况各家都会有所不同。

就程序团队而言。它往下又会细分为服务器，和客户端两个大方向。而其中人员的比例一般为1:2。即以30人的程序团队来看，服务器开发人数约占10位，客户端开发约占20位。不过这也是仅供参考的数据，视具体项目类型会有所不同。

比如大型MMO的项目，服务器的人数占比会变高，而偏单机向的游戏，服务器人数的占比会变低。同样也会受一些技术选型的结果影响，比如同构的战斗服，服务器人员也会略少。

在客户端的这20人中，又会分为引擎和Gameplay开发。就目前国内游戏团队的现状而言，由于源码价格和权限等问题，Unity项目中，只有极少数一些游戏公司会购买源码，如果没有引擎源码，自然也就不用配备引擎人员了。如果有引擎源码，一般意味着该公司有不止一个Unity的在研项目，那么相关的技术人员数量会进一步提高，用于公司或者工作室级别的引擎技术支持。Unreal团队 参考有Unity引擎源码的团队配置，甚至由于Unreal引擎本身学习和使用难度的因素，人员的配置比Unity团队还会多一些。

引擎向的技术人员，绝大多数是解决渲染管线，渲染性能等问题，还有一些会解决原引擎实现不完美，性能不好的地方，比如动画，模型，物理等。

那么剩下的技术人员就是客户端向的开发了。即便是已经细分到这个方向，大家的日常工作所需要掌握的技术仍然是有较大差异的。

比如一个中等程度的SLG类型的游戏，它就可能分为系统框架，性能，沙盘世界，主城经营，战斗，业务开发，工具效能等多个子的开发方向。

一个做自动化的岗位，并不需要对网络，并发，渲染和性能等方向有较多的认知，他会专注于解决团队内的工具效能问题。

而一个做战斗的岗位，也不需要对剧情，游戏音频，打包或是自动化做过多深入的研究。

人的精力是有限的，我们总是倾向于用最专业的人来做最专业的事情。但这也形成了一个悖论：

• 你的专精程度越高，你在团队中可替代的程度就越低。
• 你的专精程度越高，你的横向知识面相对来说就越窄，那么一旦失去了工作之后，再找到一个同样岗位的难度也就越大。

也就是说，你专精程度不够，就会被那些更优秀的取代，从而失业。而专精越高，下一份工作可选择的面就越低，从而失业。

对于大部分人而言，5-10年这个工作年限是一个技术开发最值钱的时候。这个时候的你，如果一路走来没有划水的话，基本上已经有了自己的技术专精和壁垒，能完成该方向上绝大多数的攻坚任务了，也就是说，该方向上，论技术力已经不输于那些十几年的老家伙们了，但更大的优势在于年富力强，并且价格还低。

4 技术人员打怪升级之路

在游戏开发这个方向上，技术力并不是无上限的，绝大多数的技术上限会被锁死在引擎本身的高度上。一方面是，游戏开发公司没有必要去和游戏引擎公司卷对引擎能力的提升，另一方面是游戏公司是用工具做产品，做内容和“商品”的，性价比和利润是公司首要考虑的东西。

所以基于上面的结论来说，一个不划水的程序员，7-10年就能成为该方向上的开发专家。我们以一个简单的等级模型来分析一下。仅供参考，杠的话就是你对。

首先我们将程序员的能力大致分为5个等级（括号内为大概对应的工作年限），即：

• 初级 （1~3年）
• 中级 （2~5年）
• 高级 （4~7年）
• 资深（6~9年）
• 专家 （8年以上）

之所以会有重叠，是因为每个人的学习能力有差异，再者过往的工作履历也会有较大差异。

然后我们从四个维度来分别定义一下每个等级所需要达到的条件，一家之言，仅供参考。杠的话就是你对。

这四个维度分别为：

• 技术
• 业务
• 团队
• 影响力

首先，不管在哪个等级，一个共有的特质应该是：能独立完成任务，做到事事有回应，件件有着落，不要等别人的催促或者别人来发现你的问题，这对于刚毕业的同学来说，尤为重要。

作为初级人员应当具备的四个象限的能力如下：

• 技术上，能遵循现有团队的开发规范，能准确评估功能开发的耗时情况。代码质量高，BUG少。
• 团队上，能配合导师和其他业务组，高效完成任务。
• 业务上，了解自己项目的技术难点和卡点，了解自己正在使用的技术框架的优点与可改进的空间，能主动积极的推进与自己相关的任务进度或者BUG修复。
• 影响力，积极学习组内外技术，敢于提出不同的见解。

总的来说，在这个阶段主要的能力就是，尽量快速融进团队，提升自己的开发能力，积极协助或者配合他人的工作。

作为中级人员，应当具备的四个象限能力如下：

• 技术上，在既有的框架体系下，能快速高效的完成中等难度的任务开发，并考虑扩展，稳定，性能等因素。
• 团队上，能主动总结开发知识，形成技术资产，分享和指导团队低级别成员完成任务开发。
• 业务上，有研发效能思维，敢于挑战过去的流程和规范，维护和更新它们。在自己常涉及的领域，思考化繁为简的方式和工具。
• 影响力，对自己的学员认真负责的指导，对同一个开发任务中的其他职能提供高效的开发、编辑工具，以提高整体开发效能。

总的来说，在这个阶段，应当拥有独当一面的能力了。也许你只是做战斗系统中的技能编辑器，又或者是像登录，背包，公会这样中等复杂难度的功能系统。不管是哪种工作方向，都希望在不需要更高技术人员的介入下 完成高性能，高鲁棒的设计与开发。同时考虑其他职能同学在协同工作时候的效率，用工具缓解他们的人力劳动。

作为高级人员，应当具备的四个象限能力如下：

• 技术上，对某个技术方向有较为完整的理解，知晓某一需求实现上的若干种办法以及它们的代价。能从0完成该方向的技术落地，比如一个完整的战斗系统。
• 团队上，知晓项目整体技术架构，以及自己的工作方向在架构中的位置与作用，能带领小组完成该任务。能有效的将复杂的需求转化为可并行开发的细节任务，并对进度有把控能力。
• 业务上，深度理解产品和技术选型的契合度。较强的拆解任务需求的能力，有短期内需求变化的前瞻性意识，能与其他职能的人员共同探讨和改进该方向的玩法和实现，用最高的性价比来完成业务需求的实现。
• 影响力，高质量的专业分享。技术力或管理能力让组内的其他组员信服。

总的来说，在这个阶段，你已经是项目中这个方向上的技术力的代表了，也可能正在带领一个小组完成某个技术方向上的开发与攻坚任务。起着承上启下的作用，了解整个技术团队和技术架构，然后用自己的技术选型补充和完善它。同时，需要将部分的精力投入团队管理中，既不能让自己组内成员工作太紧，又不能让他们无事可做。

作为资深人员，应当具备的四个象限能力如下：

• 技术上，熟悉整个技术团队的技术架构，在必要的时候可以随时救火和攻坚任意技术方向。代码的规范和质量应成为团队的表率。是项目内技术方向的代表之一。拥有中短期技术规划路线的能力。
• 团队上，可能已经是主程或者带领一只较大的小组完成工作任务了。能有效的审视下级成员给出的技术选型，以团队整体或者项目整体的视角来审视方案的可行性，并对其进行查缺补漏。关注团队工作效能，有效协调资源以解决开发难点。
• 业务上，注重技术资产，对业务的结果负责。能主导重点，难点任务的开发，有合理拆分任务的能力，有协调组内资源的能力。
• 影响力，能制定团队流程和规范，能给团队中的每个开发人员制定工作和成长计划，并对产出结果进行绩效评定或者核定。在研发团队内部成为技术力代表或者代表之一。

总的来说，这个阶段，在中小公司已经是主程或者大方向的技术负责人了，在大公司也已经能独立完成技术和业务攻坚的能力了。技术力会成为项目的技术代表，能制定团队的流程和规范，对业务的结果负责。

作为专家人员，应当具备的四个象限能力如下：

• 技术上，技术力或者带领方向的产出能成为工作室或者行业代表。拥有中长期技术规划路线的能力。能前瞻性的找出中长期内的技术难点和技术攻坚方向。所规划和落地的成果有复用的能力。
• 团队上，技术人才梯队的审核，定向的人才培养。人在事先，提前落子，解决项目未来的难点与卡点。
• 业务上，有大型项目的带队能力，能根据可预见的业务需求提前规划团队的技术人员编制情况。对技术团队整体的落地成果负责。
• 影响力，是团队的技术力代表或代表之一。拥有跨项目或者行业内的的技术影响力。

总的来说，这个阶段，在小公司可能已经是主程或者CTO的级别了。需要有技术之上的产品视角，需要对成本和效能敏感，需要对项目或者工作室长期的技术方向做把控，知道如何在有限的资源下完成既定的任务。

从资深的等级开始，就有资格走纯技术管理路线了，也就是拿决策，不写代码了。这里我们区分两个概念，Tech Leader 和Tech Manager，即：技术负责人和技术管理者。一般来说，leader还是需要在一线写代码的，但Manager就更多的参与宏观的技术决策，看方向和路线了。

5 越走越窄的技术路

游戏行业总的人才承载力是有限的，并且越往上的职位，开放的就越少，就像一座正立的金字塔。每往上一点就会有一些人要离开。所以在游戏这个行业，各个等级每年都会有很多人离开，当然也会有大量的人加入。

如果一个开发者，在初级阶段划水，那么他可能就晋升不到中级阶段。在中级阶段划水，就可能晋升不到高级阶段。而即使一个人一直都很努力，冲到了塔尖，但最后能够留下来的只有极少数的，符合天时地利人和之后筛选出来的“幸存者”。

但这些幸存者也不见得就会一直这么幸运，当遭遇突发的变故之后，能接住他的职位也会变得极为稀少，从而失去继续向上的机会。

所以，总结一下就是，如果你在技术开发的路上懈怠了，那么大概率就会在懈怠的这个级别出局；如果一直都没有懈怠，一路冲到了行业的顶尖，依然可能会在各种条件因素下出局。中年危机只是一个出局的诱因，在打工的路上，你越优秀，越往上，路就走的越窄。

保持学习和进步只会让这一天晚一点到来，而不是不来。

所以，我们得到的启发是什么呢？

1. 年轻时，得保持努力，工作几年就得拿出几年的本事，让自己在工龄10年以前不掉队，同级有竞争力。
2. 10年以后，做好职业和家庭规划，留足现金，发展稳定的副业，为的是那一天来的时候不会手忙脚乱。

另外还需要提的一个点是，大公司和小公司对于人才的能力要求也是不一样的。大公司希望每个技术人员都有其特色专精的方向，这样将多个方向的专精人才组合在一起就能建立自己的技术护城河，做到别家公司做不到的事情。而小公司则希望人才是全能型的，什么都能做。

简单来说就是，大公司更看重技术深度，而小公司则更看重技术的广度。举个例子，一个百万年薪的技术人员，大公司更希望他是一个方向上的专家，专注于解决某一个方向的技术难点，达到行业的一流水准。而小公司则希望，招了你之后，你就是千军万马。

二者显然是不太相容的，但如果有机会的话，我也建议技术人员能走动一下，体验另外一种公司的工作模式，从而拓展自己的视野以增加更多的岗位适配机会，毕竟收拳是为了更好的出拳。

6 一些建议

个人的一些职场经验，杠就是你对。

1. 如果你是大头兵，不要总觉得你的领导能力不行，想顶替他。正确的做法是，产出好成绩，把他送上去，然后你坐他的位子。
2. 如果你是管理者，不要总是对手下太苛刻。你管理权力虽然是上级赋予的，但是你的口碑是下级给你的。善待他们，为他们争取更多的利益，他们也会努力支持你，配合你的工作。
3. 如果你是管理者，代码本身已经不是你的主战场了，你的战场是在各种会议上。一将无能，累死三军。每一次优秀的技术决策，每一次挡掉不合理的开发需求，每一次顶住老板的压力减少无意义的方向尝试，都能给技术团队减轻极大的负担，减少极多的开发时间。
4. 即便你是高级一点的管理者，最好也能亲自负责一些技术方向，保持基层落地的能力。技术力是技术人安身立命之本，国内的环境下，技术管理是从技术好的里面选取管理能力还不错的人，而不是从管理好的里面选取技术还不错的人。
5. 有些人总是会觉得，上级会把你的产出算在他自己的绩效里而觉得他在抢功，但需要明白的是，之所以你会在这个团队里，是因为你是团队配备给你上级的资源，用来协助他完成目标和工作的。
6. 学会对上管理，这不是一个贬义词。对上管理的意义在于和上级对齐目标和期望，防止发力的方向不一致。同时，对于一些难度较高的任务，提醒上级给足关注度，并协调更多的资源。
7. 对于有绩效和淘汰制度的团队，要知道自己的竞争赛道在哪里，在工作上需要保持和同事的竞争关系，避免因绩效问题被迫N+1。
8. 其他等我想到了，再在评论区补充。

好了今天就聊到这，大家有什么想法，欢迎评论区留言，一起讨论。