开发者网络

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 79|回复: 3

2022下半年游戏开发心得

[复制链接]

2

主题

4

帖子

8

积分

新手上路

Rank: 1

积分
8
发表于 2023-3-13 17:23:22 | 显示全部楼层 |阅读模式
接着上篇文章,这里继续谈谈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.美术的“艺术与落地”、策划的“设计与落地”、程序的“开发与联调”,这三个实际上是一个意思,即游戏研发者想做好一个需求,基本上要提两个单子才行(少数任务也可一个),即一个自己独自开发(创作、设计、功能开发),另一个和别人一起开发(引擎落地、配数据、功能联调)。
2.”串行与并行开发“是针对于工种(视觉、动效、程序、策划、测试、运营)而言的,比如视觉和动效并行开发,等他们开发完了,程序才开始开发;或者视觉、动效、程序一起并行开发。不急的时候就串行开发,急的时候就并行开发。经验不够的时候就串行开发,磨合很好的时候就并行开发。不确定的时候就串行开发,确定的时候就并行开发等等。串行开发和并行开发各有各优缺点、各有各的适应环境,需灵活掌握才行,切记不要一刀切。
3.“做b修a”是针对于个人而言的,实际上每个职场人都会面临做b修a的情况,修a没有办法避免,但我们可以尽量减少修a的比例,比如做b:修a=8:2或者9:1。当然有些极端情况下做b:修a=5:5。关于如何修a,我们内部也有三种方法,这里先不展开。
理解了上面3个底层概念,那么游戏开发中任何一个单子都可以很清晰提单、拆单、估时、排期、开发、联调、验收、跑查、体验。
针对第三条,前面两条理解起来估计有些难度,这条先来个简单的过渡下。之所以会将策划案子的中英文关键词重点拿出来说,主要是因为我们团队内有个专门的翻译同学,这个同学实际上是给美术大佬(老外)当助手的,所以正好也可以顺便协助翻译一些其他游戏术语。从事游戏行业这几年,我发现大部分国内人对游戏的理解是不够的,有个很明显的现象就是一些专业术语很业余,虽然最后游戏也能做出来,但很多细节都是很粗糙的(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条、第7条、第8条,这三条下周继续总结。前五条都是一些可操作性较强的心得,偏务实;后三条则是一些认识论相关的心得,偏务虚。
回复

使用道具 举报

0

主题

2

帖子

0

积分

新手上路

Rank: 1

积分
0
发表于 2023-3-13 17:24:12 | 显示全部楼层
你们这9人管线像90人管线。。。
回复

使用道具 举报

1

主题

3

帖子

6

积分

新手上路

Rank: 1

积分
6
发表于 2023-3-13 17:25:10 | 显示全部楼层
你感觉是对的[捂脸],主要是因为我们管线内这个PM就是整个项目的大PM,有很多东西都是我们管线内总结,然后由他推广到整个项目(或者反之)。
另外,还有些细节我不便在文章说明,不过评论区应该可以,所以有什么问题也欢迎在评论区一起讨论[大笑]
回复

使用道具 举报

0

主题

3

帖子

4

积分

新手上路

Rank: 1

积分
4
发表于 2023-3-13 17:25:16 | 显示全部楼层
现实小团队管理经验分享
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|开发者网络

GMT+8, 2025-6-7 22:50 , Processed in 0.093220 second(s), 23 queries .

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表