返回 登录
0

以架构和工具链优化Unity3D游戏开发流水线

本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅2016年《程序员》
作者简介: 樊松阳,梦城互动研发部经理,微软最有价值专家(MVP)。CSDN博客专家。写过书,创过业,乐于追求新浪潮。
责编:屠敏,欢迎技术投稿、约稿,给文章纠错,请发送邮件tumin@csdn.net

曾经有这样的说法:游戏公司没法复制自己的成功。笔者认为这种看法有些片面,至少从技术层面看它不正确。每个项目都会积累经验,有了这些经验帮助,会更容易制作出成功的产品。本文接下来将从制定Unity3D开发架构和制作配套工具链两个方面,分享我的经验。

架构要点


我觉得架构的核心既不在于应用DRY(Don’t Repeat Yourself)来精简代码,也不在于套用设计模式的23板斧来解耦合。当然这些很重要,也很有意义,但这些都是通往最终目标的手段或者有用的副产品。架构终极目的在于:以最低的成本对抗风险。

由于成本的限制,没有这样一发银弹,来满足关于架构的所有需求。在没有限制的情况下,如果能够获得无限的成本,那就可以完全对抗风险,成本包括金钱、人力等等。显然无论从资本的层面,还是实际项目的实行,这种奢望都不切实际。因此我们应将重心调整为:对已知和未知风险的预防,而不是期望拥有更多的成本。

由于架构与项目密切相关,项目的复杂度直接决定了架构的复杂度。要制作一个文字对话游戏,例如《生命线》,架构可以只考虑进度控制与文本信息的读取;如果要做成回合制的游戏,例如三消或养成类,则还需考虑丰富界面的表现效果以及某些特殊逻辑下的玩法;如果做成半回合制半实时的游戏,例如卡牌类游戏,则需要考虑对用户操作状态的阶段性控制;如果要做成实时类型的游戏,例如MOBA,则需要考虑多客户端的同步机制;如果要做成泛实时类型的游戏,例如MMORPG,则还需要考虑到半实时的网络同步,并处理各种由于大量数据引发的性能瓶颈。

架构更像是一门平衡的艺术。好架构不仅要能够应对已知风险,还要处理未知的挑战。最常见的就是,某些游戏有了新颖的玩法,需要引入到现有项目中。为了接入某些渠道,或者不同国家的版本,有时也需要做些定制化的改动,如人事变动当然也会引起项目的风险。未知的风险总会出现,而好的架构应能在多数情况下,给出一个可控的增额成本。

在项目的不同阶段,架构的使命也在发生改变。创建项目初期,开发效率被放在首位。凭借快速迭代的开发方式,可做出许多Demo,展现给不同的人并听取反馈意见,从而改进。随着项目的进行,功能和模块需要量产时,易扩展和易维护逐渐变得重要起来。一方面,系统型的功能需要快速产出,例如商城、排行榜、聊天、好友等。另一方面,美术资源也需要有完善的更新机制,简单的UI改版,要能够实时预览。进入到项目的中后期,游戏运行效率低、某些模块有Bug等问题会逐渐得到重视,这时的架构要保证版本稳定。在这个阶段,需要花费大量时间对性能瓶颈进行优化,并规整各模块代码,以减少Bug。项目上线后,推出周期性活动和玩家数据反馈又成为架构新的关注点。因此,架构的演变还是要审时度势,有点“道可道,非常道”的感觉。

优化技巧


众多的概念仍需应用到实践中。每个人的偏好不同,技术倾向也有差别,但不同类型的项目,优化架构还是有不少共通方法。最常见的要数使用MVC架构,分离界面和数据,如图1所示iOS的MVC架构。

MVC

图1 iOS的MVC架构

常见的方法还包括:通过设计模式解耦代码模块。从浅显易懂的《大话设计模式》到精深的《GoF》,这些好书都值得细细研读。虽然设计模式的修炼不能在一朝一夕达成,但多多修习绝对大有裨益。

具体到项目上,代码架构要适合团队。从宏观上看,每个团队都是独一无二的组合。如果在那个时间点,团队成员不曾相遇,不曾并肩而战,就不会出现那惊世骇俗的作品。从微观上看,每个团队却又有着相似的苦与乐,既有项目起航的干劲满满,又有产品创意对市场需求不得以的妥协。通常来说,团队里会有“孙悟空”,也会有“猪八戒”,每一份子可能会用不同的方式“斩妖除魔”。能力不同,责任不同,每个人推动项目运作的手法也有差异。总的说来,架构的规划要基于项目的周期和成本,并与对应人员能力相匹配。要避免搞没人会用的设计模式,或者让能力有欠缺的人把项目逻辑弄成一团浆糊。

尽早制定代码规范也很重要。可以让每个人的代码变得“可以理解”,最理想的状况是,整体代码似乎出自一人之手。对于经常发生人事变动的IT行业,这种规范的效用非常巨大。

如果有可能,将暴露的出的变量减到最少。这里的变量指得是公有变量、静态变量、接口访问到的变量等等。暴露的变量越多,意味着与其他模块耦合越多。另外还有个不起眼的黑洞,就是单例模式。建议尽量不要使用单例模式,它会使得代码无法维护。例如:

public class A {
public static A Instance {
get {
//get func
}
}
public int Value{get;set;}
}
public class B {
private void func1() {
int value = A.Instance.
getValue();
}
private void func2(int value) {
A.Instance.Value = value;
}
}
public class C {
private void func1() {
int value = A.Instance.Value;
}
}

这种情况下,A模块就与B和C模块耦合到一起,如果代码中有很多这样的调用,整个系统中的模块几乎无法分离。当调用类B中的func2时,整个逻辑变得更为复杂。因为全局变量被多处更改。当有多线程加入时,绝对是个灾难。

如果项目刚刚开始,建议创建自己的基类。项目中的基类尽量不要使用系统默认的类,例如MonoBehivor,而使用这样的方式:

public class ActorBase: MonoBehivor {
//some data or func
}
public Hero: ActorBase {
}

这种基类最大的优点是扩展时便于更改。如果直接使用耦合在引擎的系统,很容易破坏引擎本身的封装。若不扩展基类,某些功能的实现会较为麻烦。同时也要防止基类太大,如虚幻中的Actor,也会有些麻烦。

实时交互强的项目,要尽早重写游戏循环。Unity3D采用了一种双时间线循环机制,可应付大多数交互情况。但项目中涉及状态同步,或要求高精度还原现场,(常见类型有MOBA、MMO,战斗回放的SLG等),这类游戏用Unity3D自带的时间循环体系就显得吃力。这种时间循环有基于帧和基于时间的两个update,它们相互独立。渲染在基于帧的时间之后,可以保证渲染不会在双帧之间。而物理与AI系统,放置到定时更新的FixedUpdate中,以保证更新的稳定。但由于没有追赶机制,其无法处理峰值卡顿后的数据同步问题。在高精度的要求下,使用Time.deltaTime做计算也会有很严重的问题。一方面,在限帧的情况下,因为其中包含了限帧的等待时间,无法确定逻辑真正的执行时间,除非这个计算是基于限帧之后的。如果是这样,一旦目标机器掉帧,结果值将出现波动。另一方面,即使不限帧,这各种值也无法使用。因为帧执行时间不稳定,在确定次数的情况下,结果一定不同,确定时间下,运行次数又有差异。因此不能用该值做物理和AI计算。若使用该值计算位移,在确定的时间点,部分机器可能会抽掉最后一次位移计算,而这必然会影响结果。很难想象如果到项目的中后期,再对游戏循环进行改动,会耗费多少时间。

除却上面这些,还有不少影响架构的技术点。常见的有:资源管理,对象池管理,内存管理,编写、规划Shader,渲染优化……它们就像夏夜天幕上的点点星辰很多很杂,虽然只有微弱的光,却架起了整个寰宇。

流水线


架构不是项目的全部。为了整体项目能够正常运转,多角色的合作流程必须完备,传统制造业将它称之为:流水线。它被定义为一种工业上的生产方式,指每个生产单位只专注处理某个片段工作,以提高工作效率及产量。从分工上看,策划产出配表及策划案,美术产出资源,程序产出功能实现,运营产出数据反馈分析意见等等。如何将这些元素更融洽地搭配起来,并能快速推动进度,就是流水线要解决的问题。

流水线包含但不仅限于:美术资源的导出导入预览工具,策划配置游戏元素的工具,多渠道打包工具,资源的管理和上传工具等。这些支撑流水线正常运转的工具,总称为配套工具链。因此,程序的工作除了游戏本身,还包括能够提供出一套配套工具链。通常在没有工具链的情况下,架构是完成的,但不完整。完成意味着能正常运行,但如果想量产,则需要完整。工具链需要能与架构契合,当架构趋于稳定时再着手制作工具链,是比较明智的做法。

打造工具链时,要兼顾自己的项目和团队。因为没有什么比开发了一个工具却没人会用更打击人。更多时候,随手的代码,随意放置的按钮,对特定人员的帮助也许超乎开发者的想像。简单的工具不一定没用,强大的工具未必所有人都熟知。

要强调的是,设计工具是为了解决特定问题,而不是为了完成以工具为中心的项目。工具链的开发很容易陷入对极致的追求中。不断的优化工具是个无底洞。头脑清醒的管理者要控制好开发的程度,不要陷入盲目的工具链开发当中。

配套工具链


目前我所供职的公司主要负责一款MMOARPG游戏,在开发过程中,我们制作和使用了以下配套工具链。

图2 角色编辑工具

图2 角色编辑工具

图2所示是我们开发的一个角色编辑工具,主要用于配置不同角色触发事件的时间点。为了调整出更加细致的动作表现效果,不同的事件点可能会有细微差别,这些都需要慢慢优化调整。因此便设计了这样的预览与编辑工具,方便相关人员调整配置。

整个工具被放置在一个名为AnimConfigWindow的窗口中,选中角色身上的对应子节点可开启工具。它可以预览角色动作,并编辑对应动作事件的触发点。点击左上角的按钮可以切换动作,选好动作后,再点击三角形的播放按钮,可以按标准速度播放动作。在右上角可以更改播放速度,或设置循环方式。在播放条中拖动鼠标,可以更改红色的时间线,模型会依照时间线位置实时更新动作,操作方式与Unity3D自带的动画预览很相似。点击左侧的事件类型区域按钮,可以切换当前类型,例如编辑攻击产生的时间点,或特效产生的时间点。切换类型后,白色轴线会移动到对应行的位置。选好事件类型和触发时间点后,点击Inspector中的按钮可以插入和删除事件。与事件相关变量也可以在Inspector中编辑,其中不同类型事件的可编辑信息是不一样的。插入的事件会在事件帧区域用绿色的方块标志。在右侧区域列出了当前类型事件帧的所有的触发时间点,点击它可以控制时间轴直接切换到对应位置,同时模型也切换到事件触发的动作的状态。最终这些动作相关的信息会保存到预设上,供运行时触发。

图3 关卡配置工具

图3 关卡配置工具

如图3所示是关卡配置工具。游戏中包含了副本的玩法,策划需要一个工具来配置不同的关卡。怪物分组会直接影响其出现逻辑,而这些怪物又形象一样,很难分清每个怪物的分组,因此可以将每组怪物,用不同颜色的标签标注。分组的配置错误一目了然。工具中还可以查看的警戒范围,配置怪物巡逻路线、角色触发剧情、陷阱、机关等功能,是整个流水线中的重要一环。核心代码如下:

public enum LabelIcon {
Gray = 0,
Blue,
Teal,
Green,
Yellow,
Orange,
Red,
Purple
}
public static void SetIcon( GameObject
gObj, LabelIcon icon ) {
if ( labelIcons == null ) {
labelIcons = GetTextures( "sv_
label_", string.Empty, 0, 8 );
}
SetIcon( gObj, labelIcons[(int)
icon].image as Texture2D );
}
private static void SetIcon( GameObject
gObj, Texture2D texture ) {
var hack = typeof( EditorGUIUtility
);
var f = hack.GetMethod(
"SetIconForObject", BindingFlags.
NonPublic |BindingFlags.
Static );
f.Invoke( null, new object[] { gObj,
texture } );
}

图4 UTomate插件

图4 UTomate插件

上面说了两个自研工具,接下来说大家可下载到的插件。如图4所示是一个流程化执行任务的工具,名叫UTomate,可在AssetStore中找到。它能够很好地完成打包,批量渲染场景,移动上传文件之类的繁琐操作。在项目中,我们使用它制作了自动打包流程,大致如下:

  1. 编译AssetBundle;
  2. 将AssetBundle拷贝到StreamingAsset目录下;
  3. 生成各平台的安装包;
  4. 打开到生成安装包的目录。

这一系列流程如果用代码硬写出来估计需要耗费大量时间,而且万一流程有变动,更改起来需专人维护。有了这个神器,只需要重写几个关键的执行流程,然后再拖拽就可以了,如图5所示。

图5 打包流程图

图5 打包流程图

这样是不是很方便呢?如果后期有分渠道SDK的打包需求,只需要在该基本的打包流程上做少量更改,增加一些文件的复制删除,更改一些编译宏,即可制作不同渠道的版本出包流程。

管理


最后浅谈项目管理。策划、运营提出改进需求,美术实现效果,程序实现功能,测试保证质量。这样一个看似简单的迭代,通常不会一帆风顺。如何调配这些步骤,成为项目管理的难点。我供职过上市公司,自己也创过业,经历过几种不同的组织管理结构,但在管理方面上,我依然没能总结出真知灼见,唯一的体会是,管理上的问题比技术更棘手。特意提到管理的原因在于:有些技术经理认为,自己只负责技术,而管理层面应该完全推掉。这种错误的行为,很容易导致团队涣散。建议技术经理或主程多花些时间在代码审校、进度监管、需求审核,以及与团队成员沟通,这些管理相关的事务上。


了解最新移动开发相关信息和技术,请关注mobilehub公众微信号(ID: mobilehub)。

mobilehub

评论