50万玩家等着和“鬼”交朋友！这个游戏里的 NPC，可不好糊弄了丨Created with Cocos
NPC 是模拟经营游戏中不可或缺的组成部分，但现如今绝大多数 NPC 依然是“工具人”式的存在，脸谱化严重。那么，如果一个游戏里的 NPC，有各自的作息习惯，会衡量生活的“幸福指数”，经历生老病死、死后甚至可能变成“鬼怪”，将会带来怎样一种游戏体验？
即将在年前正式上线的古风模拟经营手游《解忧小村落》（以下简称《解忧》）做出了自己的尝试。游戏由古德工作室基于 Cocos Creator 研发，过去一年先后进行了三轮测试，目前在 TapTap 上已有超50万玩家预约。
《解忧小村落》TapTap 预约开启：
https://www.taptap.cn/app/214345
《解忧》描绘了一个“人鬼共存”的世界。这里有历法、时辰、天气、昼夜，玩家将在这个拟真的自然世界里，作为村落的村长，同此地的居民和鬼怪一起，经历春耕夏耘、秋收冬藏，跟随四季和天气的变化合理开展种田、畜牧、建造工作，逐步打造一个心仪的世外桃源。
《解忧》依然保留了模拟经营的经典玩法——种植收获、采集建造、生产售卖等，而游戏最具差异的，莫过于其对 NPC（居民和鬼怪）的描绘。
每一位居民都有自己的职业，玩家可以“招募”这些居民，根据职业将他们派遣到合适的岗位上工作。游戏加入了“作息管理”，居民们会在不同时辰休息、工作、吃饭、散步、出游，玩家可以调整每一位居民的作息，甚至让他们“996”打工——但是，这些安排会影响居民的“健康值”和“幸福感”，若健康值过低，居民会生病乃至死亡，若幸福感过低，则可能导致居民搬离村落。
在这个游戏里，每位居民都是独立的个体，有各自的生活与经历，随时可能触发不同的事件。反之，也会有访客来到此地引起各种波澜，比如流窜的小偷盗窃居民财富、游历四方的郎中到访等……玩家将和居民一起去经历这些事件，并用自己的方式，应对某些棘手的局面。
鬼怪图鉴
鬼怪则是《解忧》中一个重要且特别的存在。他们看上去一点也不恐怖，甚至还萌萌的，虽然喜欢游走在村子里四处捣蛋，但又有各自独特且可爱的性格。鬼怪和居民一样，都是村落里的一份子，玩家可以“收服”和“招募”自己喜欢的鬼怪一同建设村落。
可以说，《解忧》始终围绕“佛系建设人鬼共存的和谐村落”展开，无论是删繁就简的游戏内容、清新可爱的画风，或是大批有血有肉的 NPC，游戏都在努力营造一种闲适、自由、真实的体验。
这样一款游戏是怎样被创作出来的？其中又蕴藏着哪些巧思与独特之处？C 姐和《解忧小村落》技术总监万骁聊了聊——
1
鬼怪：
“路见有鬼，但不必绕道”
《解忧》立项的契机是什么？
《解忧》的研发团队一共24人，成员们主要来自阿里游戏、百田等，平时都喜欢玩模拟经营游戏。有一次聊天聊到模拟经营的“模拟性”上，感慨现在这类游戏中的 NPC 还是工具人居多。所以我们就想，有没有可能让 NPC 更“动态”或者更“真实”呢？比如，他们是否能有更加复杂的情绪表达、变化的身体状况，会生老病死，甚至在死后成为“鬼怪”（一些中国特色）。
由此衍生了《代号：百鬼》的立项——也就是今天的《解忧》。当时我们计划用1年左右的时间做出这个模拟经营+鬼怪的游戏，现在看来，团队离目标越来越近了。
游戏的“鬼怪系统”在玩法上有哪些亮点？
目前的版本中共有53只鬼怪，之后还会陆续增加。在我们的设定中，鬼怪是人类在生前遭遇不幸后，因执念太深而化身为鬼。每只鬼怪都有自己的故事，科场鬼生前是个落榜多次的书生，墓鬼是个喜欢玩躲猫猫的小女孩……这些前尘往事，将随着“鬼怪传记”的逐步解锁徐徐呈现。
鬼怪们各有各的调皮，会给村落里的建筑、居民等造成影响，比如墓鬼无聊时会把居民抓来墓场同自己玩耍、碰上野鬼会让居民迷路，水鬼会影响渔夫钓鱼等。玩家可以“收服”自己喜欢的鬼怪，通过喂养鬼怪、给鬼怪送礼等方式来提升鬼怪的等级与好感度。等级越高，鬼怪的妖力值越高，工作产生的收益也越高；提升好感度，则可以解锁该鬼怪的传记故事、前生人物等。
在达成一定条件后，玩家可以“招募”鬼怪入住村落，并根据他们生前的职业与技能，派遣他们到不同建筑里工作。由于鬼怪的“特殊身份”，和居民不同，鬼怪不会疲惫劳累，可以不停地干活 （不是。
鬼怪形象都很 Q 萌，和大家分享一下美术设计思路吧。
游戏中所有的鬼怪都是能在古籍里找到原型的。我们查阅了大量的资料，夸张和放大鬼怪的特点，让鬼怪的形象更富记忆点。以“疫鬼”的设计为例，因为是和疾病有关的鬼怪，因此底色是苍白的；手持灯笼，象征其夜行性；符咒束缚和红衣，则是借鉴民间对瘟疫恶鬼的压制手段，代表疫鬼被人们惩戒和封印。
2
风格：
“真佛系，不上班”
除了鬼怪，《解忧》中还有大量的居民，这方面又是如何设计的？
《解忧》整体美术风格为古风 Q 版，我们想在此基础上，结合游戏基调，做出和市场上其他同类型游戏有所区别的美术风格。
居民的设计围绕着“模拟”这个关键词展开，力求真实感。游戏中，不同居民有各自的职业身份，基于此我们又在年龄、性别、体型三个维度做了区别。如上图，一个农夫职业有12个模型，为的就是让玩家感受到《解忧》世界里居民的多样与真实性。
《解忧》中有大量的建筑，怎么避免因建筑种类过多而显杂乱？
结合游戏内容，我们将建筑分为士、农、工、商、民宅、装饰建筑等大类，以中国古代建筑结构为基底，设计其共同的设计语言，包括墙体结构、屋顶造型与颜色、环境植物搭配等。这样既能保证建筑种类丰富，也能让玩家一眼看出建筑所属类型，方便游戏布局。
相对于大场景以绿色为主的主色调，建筑上我们有丰富的颜色类型，这样玩家在发展自己小村落的过程中，能慢慢感受到场景色彩的变化，由乡间林野变成繁华村落，从而获得成就感。
从美术风格到游戏内容，《解忧》给人的感觉都非常轻松治愈。
是的。当下很多模拟经营类游戏都会选择布局长线运营，但实际体验后发现，大多数长线游戏都让人“肝疼”。我们希望《解忧》能让玩家体验到更加纯粹的种田快乐，而不是在游戏里“赛博上班”。
《解忧》始终围绕着“佛系”这一体验去做设计，删繁就简。游戏中没有重复的每日任务，就是想减少玩家“在游戏里打工”的感觉，取而代之的是用“订单”模式，让玩家通过自主决策发展村落。玩家只需思考这个季节种什么或发展什么产业能增大收益，派遣居民和鬼怪去各个生产建筑劳作，在关键元素一步步铺设好后，就可以进入“看海”模式，去和居民、鬼怪交个朋友，看看他们的人生轨迹，探索村庄的发展变迁，或者是享受布置造景的成就感。
目前《解忧》中商业化内容非常少，团队这方面有什么规划吗？
因为是朝着“纯粹”这个基调去的，所以我们对商业上的内容一直很谨慎。目前游戏内已经开始有考虑商业化的内容了，不出意外主要有两个方向：其一是传统基建，前期侧重资源内购，后期再逐渐推出各种风格的建筑让玩家收集；其二是如果能做到的话，我们希望鬼怪本身的形象、情感、故事是可以立起来的，并与玩家产生更深层次的情感共鸣，玩家可以在这个基础上，为自己喜爱的鬼怪花钱进行培养。
3
技术：“优化不停”
能否分享一下游戏的客户端设计方案？
场景多纹理
场景的所有单位均为 Spine，游戏内场景有 2w+ 格子的地图大小，因此我们希望能让所有场景单位都能合批，减少开销。
我们制作了8、16的不同贴图 shader 来进行不同机型适配，再根据 MAX_TEXTURE_IMAGE_UNITS，来确定使用哪一套材质。
重写 MultiSpineAssemble。下面是 web 端的修改，因为要多传一个贴图索引，所以在 vbuf 也要相应的传入数据。
因为原生平台 fillBuffers 重写了，所以原生平台改动就非常多。
原生平台有双 color 、单 color 之分，所以需要在顶点宏这里多一套宏定义。
相应顶点结构体也要在增加贴图索引进去。
最重要的来了。MeshBuffer 需要在接口处区分是多纹理还是常规。
在 Types.h 里定义我们要使用的 shader 常量 ATTRIB_NAME_TEXTURE_IDX。
在 VertexFormat 内加上对应的多纹理顶点定义。
最后，在这几个类做好多纹理跟非多纹理判断和使用。
Label char 模式优化
这部分我们参考了论坛里“乐府-堂主”的实现方法：
https://forum.cocos.org/t/label-1-bitmap/97573
https://forum.cocos.org/t/label-2-char/97766
帖子提供了核心代码，但我们对其中一处进行了必要的修改。
替换旧字体时，一定要记得把 xAdvance 赋值。因为在做横向排版的时候是 xAdvance 进行排版，若按照帖子里的逻辑，旧字体始终要比新替换的字体大，不赋值的话会有间隔。
UI 动态合批
虽然 FairyGUI 是个非常不错的 UI 编辑器，但是在 Cocos 运行时效率确实不太好，同时动态生成的节点有些冗余，我们在做完场景优化完后才意识到 UI 优化一定要重视起来。
所以我们重写了 sprite、label 相关Assembler，目的还是动态合批（多纹理）。
我们准备了4组材质（8、16共享材质和8、16备选材质）。若参与 UI 合批的 sprite 的贴图超过了能合批的最大数量，就要使用备选材质不参与合批。
我们 UI 的 label 都是使用 char 模式，所以只要给共享材质默认设置到第0位置即可。
Sprite 的判断相对复杂点，需要先判断材质中1~8/16中，是否有设置过且不一样（设置完就只能用备选材质了）。
我们写一个 MultiUIBatch 的组件挂在 UI 的根节点上，用于创建共享材质、子节点动态添加、渲染监听刷新子渲染组件的贴图索引。
每个渲染组件（sprite、label）在 onload 都会挂在一个用于检测是否要刷新贴图索引的脚本。
该脚本会发送一个全局实践，用于给 MultiUIBatch 判断是不是自己的子渲染组件。
流程示意：
因为做好了超出共享材质贴图上限的处理，所以理论上应该没什么 bug 吧。
最后就是将 FairyGUI 里使用 Label 和 Sprite 的地方，换成重写的 MultiLabel 和 MultiSprite 即可。注意在 UI 销毁的时候做好材质回收。
理论上，如果 UI 都是图集并且图集复用率高的话，1个 UI 只有1个 DC。
游戏兼顾了高品质的渲染表现和流畅的运行体验，性能优化方面，有什么经验与心得吗？
ECS 模式
大场景多单位的游戏，如 RTS、SLG 等，一定要使用 ECS 模式。
《解忧》有 2w+ 格子，除开建筑是占位格子以外，NPC 是性能压力最大的一部分。我们使用了非严格意义上的 ECS 模式，System 与 ComponentBase（继承于 cc.Component）都有子组件（ChildCompBase），子组件负责的内容各不相同，我们在实现子组件的时候，都是基于通用扩展的目的去实现的，理论上只要给某个 System 添加寻路的 ChildCompBase，它就具备寻路行为；给 ComponentBase 添加 Spine 组件，就具备显示 Spine 的播放动作行为。
Node 的时候我们采用单帧动态，根据 FPS 改变创建数量，让 Node 从对象池添加到场景时更加平滑些。
《解忧》场景驱动逻辑
上图为游戏的场景驱动逻辑，其中黄色部分是性能优化集中的地方，因为使用 ECS 模式，所以会有部分 ChildCompBase 存在 update 的频繁调用情况，我们在处理方面会根据 fps 减少调用次数，判断 sys 是否在相机内并创建。
合理使用对象池
《解忧》自己实现了一套对象池，对象池内实现了对 Node、其他 Class 对象、RenderTexture 回收：
Node 回收：针对场景物件。
其他 Class 回收：针对System、ChildCompBase、行为树。
RenderTexture 回收：针对 RenderTexture 对象。
混合模式
游戏场景的单位都是 Spine。但在美术同学的设计中，夜晚部分建筑会在 Spine 加灯光效果（Add 混合模式），这样就会打断合批。好在白天的时长比晚上要长，美术同学在白天把叠加模式的 alpha 设置为0，所以我们在 spine 取插槽 Slot 的时候，判断 color.a = 0 就用 normal。
上图是我们使用 Spine 时的测试结果。场景建筑没有什么动画，所以使用 RealTime 即可满足需求（主要内存少），而 NPC 有大量的移动、表演及其他动作，如果采用 RealTIme 模式，性能确实堪忧。
如何处理大量的 NPC 行为逻辑？
《解忧》中 NPC 数量比较多，且有很多不同的行为，比如在主场景中 NPC 有派遣、散步等常规行为，而在酒馆、客栈中，行为就更多更复杂了。为此我们自己搭建了一个可视化的 behavior3web 编辑器，方便策划大佬们理顺一个行为是否合理。
游戏后续将重点优化哪些方面？
一个是针对逻辑耗时进行重点优化。目前渲染方面的优化效果还不错，但是因为场景太多单位要运算，所以逻辑耗时比渲染耗时要长，这是目前头疼的事情。
二是同屏单位控制问题，主要需要控制同屏 NPC 数量，或者采用 RenderTexture 把相同 NPC 的画面通过 FBO“复制”到 RenderTexture，并通过特定相机去渲染。
游戏内容方面，由于团队人力比较吃紧，我们在首发版本砍掉了鬼怪小游戏玩法，还有很多特别事件玩法想要增加，这些内容我们都将在后续版本中陆续提供给玩家。
点击文末【阅读原文】即可前往 TapTap 预约/体验《解忧小村落》。Cocos 将持续打磨技术，完善引擎功能特性，推进生态建设，助力更多开发者高效实现创意想法！