Unity手游实战：从0开始SLG—

1 游戏是一个项目

这是从0开始SLG系列的开篇，但是本篇却不准备讲SLG类型相关的东西。在开始SLG项目搭建之前，想先说下我理解的游戏开发到底是个什么东西。

游戏开发从开发模式上可以理解为一个做一个项目，和各种工程项目相比它们都有一个共同的特征，用PMP里的定义就是：

项目是为创造独特的产品、服务或成果而进行的临时性工作。

对的你没看错，它其实是一个临时性的工作。或许你会拿《魔兽世界》来打比方，05年运行到现在已经10几年了，怎么可能是临时性的呢？那么我要说明两点：

1、即使一个项目持续100年，它也是会结束的，只要会结束，那么它的性质就是临时的。项目虽然是临时的，但是产出的成果可以是长期的。比如建造一座英雄纪念碑，编纂一部法典，比如《史记》。

2、项目和运营是两个不同的概念，某市为地铁项目招标，计划5年完成开通一条新的地铁线路，那么在地铁建成，完成验收的时候，项目就已经结束了（那些建造地铁的工人就会被承包商投入到下一个项目中）。接下来会交给运营团队来运营地铁。

游戏开发也是一样，当游戏交付运营那一刻，它的使命其实已经完成了。那接下来回到刚才《魔兽世界》的例子中，那它运行了10几年了，期间又不停的更新版本是什么操作呢？答曰：每个版本其实是一个新项目。游戏开发与普通工程开发不一样的地方就在于此，地铁建完，人力会释放进行别的项目的建造；如果地铁要进行扩建，那么它需要重新承包给工程队进行新项目的开发。而游戏开发一个版本上线之后，人力大部分时候是不会释放的，会接着投入到下个版本的开发中（每个版本我们都会认为是一个新的项目）。因为游戏开发和工程建造不一样，工程建造设计好图纸，人力的影响并不是太显著；而游戏开发人力却是最大的成本，并且熟练度也是影响项目进度的重要原因，所以大部分时候项目都不会更换核心人员，代价很大。

2 独立制VS中心制

不过也不都是绝对的，早些年经历的项目都是独立编制，但现在游戏开发也慢慢开始转型为中心制和螺丝钉制。中心制的最常见表现就是美术中心制,当然也有策划中心和程序中心，但是相比美术而言后两者较少。

美术中心

美术中心的是通过资源倾斜和内包的形式完成。A项目组对美术中心提出要求，美术中心排期完成。这样不管A项目是否完成，它都不需要释放人力。好处是能够节省成本，如果公司较大，项目较多这种成本节省还是比较明显的，当然坏处也有，前面说了每个项目都是独特的，所以对于独特性的需求响应会比较慢，加上不是一个项目组内协作，在排期和响应速度上也比不上独立编制。一旦出现问题，沟通扯皮也会比较麻烦，最重要的是，因为不归属项目组，所以对于质量把控上要严加审核，不然遇到紧急的时候你只能去求人家给你调度优先级。

和内包对应的是外包，就目前做过的项目来说，美术、音效等资源只会在项目组保留核心的部分，其他都会外包出去。

程序中心

很早以前（尤其是端游时代），商业引擎还没普及的时候，大部分公司都需要自己研发引擎来开发项目。那个时候公司会有独立的引擎组，专门负责解决引擎层面的问题。然后不同的项目里只要有1-2个核心人员（一般为主程）保持和引擎组沟通，其他人只需要根据引擎提供的功能做业务逻辑即可。

后来随着游戏行业发展，出现了免费的商业引擎，那么开发又逐渐的转为项目组独立完成功能开发，因为不再需要有人维护自研引擎了。其实说一句，一般小公司也养不起独立引擎团队。做图形和引擎的都是高级别的大神，入门极难，而且市场的需求度也不是特别高，但是一旦能步入这个行列的话，收入是大于普通程序员的。

这种优势就是去除了公司引擎组的维护成本，但是也带来了人员流动的问题。往往一个核心的人员离职就会带来项目重大的延期，甚至是进行不下去。尤其是一些小团队，能本身也就是拿了小几百万的投资，核心一旦离职会带来灾难性的打击。

另外代码泄露也是比较大的问题，Unity的脚本化开发决定了它很难对非客户端人员隐藏代码，也很难区分权限让不同的开发拿到不同级别的代码，

所以现在有一些稳定成熟的公司又开始了复古的模式，设立引擎核心组。虽然使用的Unity，但是引擎核心组会架构一套封装的库，配合Lua开发，让项目组的成员只拿到项目相关的Lua代码。这解决了人员流动问题，也能防止资源外泄。当然它也会带来一些问题，比如开发过程非常痛苦，遇到深入的BUG完全没法自己解决，加上层层封装的库，比起原始脚本，性能也会差一些，同时因为封闭的原因，在开发和测试都需要多做很多额外工作。

当然最大的问题为认为人员能力呈现两极分化：引擎组的出去之后个个都是大神，大家抢着要。而项目组的基本就是写Lua逻辑的，干的几年的话，能力和工作年限会呈现严重不匹配的情况。我面试过不少这类公司的程序员，虽然产品在市面上表现非常好，但是他们本身都不熟悉技术实现方式，缺乏核心竞争力，很难再在游戏行业混下去。

策划中心

说实话，遇到的策划中心比较少，毕竟每个项目的玩法差距真的很大，哪怕你是一个换皮的项目，那么也是有IP或者剧情要包装的。游戏的主线是要按照剧情走向的，然后各个玩法系统也要符合IP或者剧情设定，那么策划的方案很难会有共性。比如一个任务系统，换皮项目程序可以稍加修改就能实现复用，但是策划必须的全部更换任务方式，甚至要根据剧情调配和包装。

不过职业生涯也是遇到过的，但不是针对系统，而是数值。数值这个倒确实可以根据类型快速修改，尤其是换皮项目，数值核心是基本不会动的。

另外一个策划中心的表现更像是过程管理，就是出人问你的系统设计目的和潜在收益。就跟答辩一样，你需要讲清楚你的设计目的，通过了才能放你去做。当然这个形式也是双面的，一方面它能让策划真的好好想清楚自己的功能和目的以及各种细节。但是另一方面，如果不通过被打回了，会严重影响项目组内的进度。

3 客户端养成

中心制只是一种项目资源的整合方式，但其实现在独立项目制度的还是占大多数的，一些大公司区分工作室之后，有可能工作室会共用一套，但是不同的工作室之间还是较为独立的。

扯完了一些乱七八糟的东西，接下来讲讲游戏开发中客户端所扮演的角色。

客户端就如字面意思所展示的，就是客户一方所持有的应用，有时候大家也叫前端，而我们说的用户其实就是玩家。

前端所关心的最核心两个方面就是渲染和交互。（所以渲染大神才贵呀。。。）但是从功能层面来说划分的方式又有所有不同。

模块划分
根据游戏类型不同，可划分的模块也不一样。我个人习惯把客户端分为两个模块：单局和外围。两个方面要求的岗位技能也不一样。当然除了这两个部分，现在越来越多的团队会新设一个职能模块：性能。当然一个游戏除了这些之外还会包含一些杂项，可能并不隶属于这三个核心模块，我们暂且叫它其他吧。

所以综上所述我们暂时列一个相关项：

单局
单局可以理解为核心战斗。但是它所包含的内容其实远远不止。一个游戏玩的其实就是搭配了平衡数值的战斗表现。当然这里的战斗其实不是非得是战斗的表现形式，它可以是剧情或者养成等各种核心玩法。比如《王者荣耀》《英雄联盟》《DOTA》的单局就是核心的5V5对战机制。当然它们会出各种衍生模式比如克隆模式，吃鸡模式，或者自走棋模式。但是这些都是吸引用户留存的，也就是说衍生模式我可以一个都不开或者平衡很差，但是5V5他必须要保证不能出问题。一旦一个游戏的核心机制出了问题或者不能被用户接受，那么这个游戏本身也不会坚持太久。

其他类型，诸如《炉石传说》核心就是1v1对局，比如《暗黑》系列就是地下城和野外刷刷刷。吃鸡就是跳伞之后成盒之前。《王国纪元》就是大地图掠夺。

当然也不是绝对的只有一个核心玩法，比如COC，核心就有两个部分，攻城和养城。之所以我认为COC是两个核心，是因为攻城涉及到战斗和兵种搭配，而养城则涉及主城内的建筑养成和操作，虽然看似都是一个城市，但是玩法是不一样的。拿个对比，《王国纪元》的核心玩法是资源掠夺，也就是大地图的那部分玩法。虽然它也有主城养成功能，但是那部分是固定的无法自定义的，包括腾讯系的《乱世王者》《真龙霸业》等都是有主城系统的，但是这些更多是根据玩家等级开放的系统入口，本身并不具有策略和自定义性。所以投入并不需要太大。

而战斗本身有时候并不是必须的，比如早起的页游类型的SLG，战斗都是文字方式结算。相反核心却是主城养成和PVP数值。有图为证：

然而对于我们目前的游戏来说，我会将单局部分再拆细变为战斗、主城以及世界地图三个维度。以后的文章里会详细讲述3个部分的技术细节。

外围
除了核心战斗所包含的模块之外，所有其他的功能会归属在外围。外围的定义并不是指功能不重要，而是指他们是支撑核心玩法的外部系统。

简单总结一下：

图中并没有列举完所有的外围功能，大概就是能够从核心战斗剥离出来的部分都叫外围。我们要尽量保持核心战斗的独立，保证不会在不停的迭代开发中越来越臃肿。如果有必要，甚至会从设计层面进行隔离，让两个部分完全没有瓜葛，这样就不会因为不停的迭代外围功能导致核心部分发生莫名其妙的问题。

性能
这个模块是我最近才领悟到重要性的方面，并且在项目里单独设置了独立岗位。能够和单局、外围并行，足够说明了对这个部分的重视程度。以往的游戏开发都是先从0到1，然后项目临近上线的时候，紧急抽调人手，进行突击优化。也是经过了几个项目的洗礼，虐完了之后才觉得性能应该是最优先关注的模块。

一则现在Unity的开发已经趋近于成熟了，各种模式或者解决方案都能找到解决方案，前期尽早介入不会有那么大的阻碍。

二则，如果项目后期介入优化，那么整体的框架已经趋近于完善，要么你要花大代价重构部分框架，但是框架改动就涉及到已经稳定的模块调整，对开发进度和QA团队都是伤害比较大的，要么就是妥协，从实现方式里取巧实现，但这种“小聪明”的方式不仅增加项目里特殊判定（写死）的地方增多不利于维护，对于性能的整体优化作用并不大。

三则，国内的游戏环境导致游戏都会考虑海外发行，而海外的话第一站基本都是东南亚。然后这些地方的机器平均水平比国内低一大截，所以要适配低端机型则必须从开始就接入优化或者性能指标。

我对性能岗位的职能定义是，不参与具体的系统开发，但实际上又必须对每个系统了如指掌。简单说就是两部分工作，指导和找茬。

新的功能模块开始前介入，给出较优的性能方案，过程中对各个性能模块指标进行监控，发现问题然后解决问题。你看，他其实并没有参与功能开发，但是比其他人都知道框架和代码该如何运作。

性能优化是我极度关心的模块，（因为战斗和外围技术选型都稳定了。。。），未来文章的重心也会加大对这方面的讲解，当然既然这是从0开始，我会关注并剖析每一个所需要关注的功能模块和设计。

其他
除了游戏客户端必须要做的部分之外，其实还有很多要做的事情，比如技术预研、人才梯度、技术归档以及各种工具的开发，这虽然不是技术层面本身的东西，但是也是客户端所要做的很重要的一个方面，后面也会慢慢的都讲一点。

4 结尾

作为从0开始的系列，这边先随便聊聊我所理解的游戏开发，如果有理解错误的地方欢迎一起讨论。下一篇的话，先简单介绍一下我们的SLG游戏类型，以及整体的技术方案选型。

知乎文章地址：https://zhuanlan.zhihu.com/p/75653494

公众号文章地址：https://mp.weixin.qq.com/s/YnBPOY06OwbxmrQ3dG3NWA

欢迎关注公众号：壹种念头