游戏高度可配置化（二）用“模型抽象”化解游戏策划和程序员的江湖恩怨

游戏高度可配置化（二）用“模型抽象”化解游戏策划和程序员的江湖恩怨

码客 卢益贵 ygluu

关键词：模型抽象、功能抽象、抽象工厂模式、游戏服务端引擎、高度可配置化、恩怨情仇、游戏策划、数据引擎、生产消费模型、订阅-通知模型

一、前言

众所周知，由于游戏策划的丰富想象力导致游戏服务端引擎实现起来非常艰难。因为紧迫的工期和不断变化的需求，在策划和程序之间还上演了不少江湖恩怨。

本文主要介绍模型抽象在游戏服务端引擎开发中的应用。确切的说本文是上篇的补充（游戏高度可配置化（一）[1]）。

二、程序员的脾气和宿命

一般程序员都有者对技术执着的宿命通病，如执着地用技术解决性能问题、执着地用技术解决功能问题。在策划一而再、再而三的改变需求时，多数程序只能“疲于奔命”，所以“没有脾气的程序员不是好程序员”。

图1 RD和PM打起来了（图片来源于网络）

图2 被逼疯的程序员（图片来源于网络）

三、策划的抱怨和冤屈

“你按我说的做就得了，配置要简单要灵活。”

“这个功能很简单啊，什么时候完成？”

“我Kao，这么一个小案子花这么多时间还有这么多Bug。”

“不好意思案子改了，你再改下程序”。（不改案子的策划不是好策划）

图3 被喷的策划（图片来源于网络）

图4 这么多Bug（图片来源于网络）

四、主策和主程的共同目标

主策：案子什么时候出？

策划：#%￥*&#……

   

主程：这个案子什么时候完成？

程序：&@*@#!*&#￥*......

在短期KPI使然下，开发初期欠下的债都会在运营后慢慢地还。游戏是否成功与代码好坏无关，但与开发效率和质量有关。

主策和主程是优秀的管理者，应该联手着重解决开发效率问题，过程优化是决定效率的关键因素。

图5 主策和主程的共同目标

五、什么是模型抽象

抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。抽象的意义在于通过抽象能透过事物的表面现象抓住事物的本质。[2]

【真正的高手,都具备高度抽象能力】高级开发者，能够根据业务的特点，抽象出软件最合理的设计，使得程序具有良好的可读性和扩展性，通常一开始写出的逻辑就为了以后的重用。许多开发框架就是一步步抽象/埋坑/优化而来的。[3]

1、功能抽象

功能抽象在文本定义为：以系统功能特征为基础的低度抽象。

“人”的功能抽象：头、眼、鼻、手、脚......

2、模型抽象

模型抽象在本文定义为：以实现系统功能的模式为基础的高度抽象。

“人”的模型抽象：大脑、神经中枢、感应组织、行动组织，以此形成一个“感知-思维-传导-执行”的模型，它能以“更加广泛的方式”解决“更加广泛的问题”。

3、抽象高度

模型抽象和功能抽象的抽象高度如图6所示。

图6 模型抽象和功能抽象的高度

图6中有3种抽象应用流（箭头流）。第1种比第3种具有更高的抽象高度，相比第3种能更灵活地解决多数需求。众所周知，抽象是不能100%解决问题的，所以第2种是以第1种（模型抽象）为基础的，相比第3种具有更加便捷和高效的特点，用于解决少数特殊的需求问题。

六、ON-DO模型

1、生产-消费模型

人类活动都是一个生产-消费的过程，游戏也不例外（但对游戏数据的处理以生产-消费模型[5]出现的甚少）。

图7 生产-消费模型

2、ON-DO模型

由于在数字信息世界里，消费不等于消耗，如我们从数据仓库里获得（消费）一个数据，仅是这个数据副本而已并没有产生实际消耗，另外生产结果也不一定是正值。所以综合游戏数据特征，将消费-生产模型演进为ON-DO模型，即当什么条件满足时做什么事情（条件对象和执行对象）。如8所示，

图8 ON-DO模型的可配置化

3、模型抽象比功能抽象更有优势

由图9可知，功能抽象的编码工作量远大于模型抽象。

图9 模型抽象和功能抽象的开发工作量

引用本人之前文章的插图（可配置化数学建模的应用案例图解[5]）：

 图10 模型抽象和功能抽象的可配置化对比

如图10所示，模型抽象比功能抽象的可配置化程度更高，应对需求变化更灵活。

4、数据引擎

如前所述，配置层所依赖的数据从哪里来？在消费-生产模型中都会依赖一个数据缓冲的中间件[4]，在本人做科研时依赖一个数据交换机的中间件[5]，本文把这个中间件称作“数据引擎”[1]（下称：数据引擎或de），如图11所示。

图11 数据引擎

每一款游戏都它特定的基础数据和基础行为，只要将他们进行高度信息化后统一纳入到数据引擎的管理范畴中[1]，就可以满足在配置层的数据所需，并且还可以在配置层衍生出多维度的数据信息[1]。

 图12 游戏基础数据和基础行为的高度信息化

数据引擎源码下载见[6]

七、游戏数据形态的模型抽象

依据游戏数据形态抽象出两种管理模型：1、递进式模型，2、并列式模型。依据数据变化的响应模式抽象出两种模式：1、观察者模式（监听，订阅-通知模型），2、探测者模式（查询）。管理模型和响应模式可以俩俩组合的。

图13 递进式模型的配置实现

图14 递进式模型观察者模式的伪代码实现

图15 并列式模型的配置实现

图16 并列式模型探测者模式的伪代码实现

图17 其他数据配置样例

由图13、图15、图17可知，在ON-DO模型下，各种数据统一了配置格式，减少了配置样式和Load代码的开发成本。由图14、图16可知，在ON-DO模型下，无论是哪种数据管理模式和哪种数据响应模式，编码的成本是非常低的。

八、游戏行为模式的模型抽象（维度空间模型抽象）

每种游戏都它既定的行为模式，每一种行为都可以产生不同维度的数据，把行为模式抽象成维度空间模型[5]，每个维度空间执行不同的配置项，如图18所示。

图18 维度空间模型

图19 维度空间模型的配置实现

图20 维度空间模型的伪代码实现

由图19可知，ExeObj对象支持txt格式的流程控制表达文件(txt)和脚本对象，也可以支持和图13、图15、图17一样的数据运算表达式。由图20可知，维度空间模型的编码成本依然还是非常低。

流程控制表达式样例如图21所示（脚本就不再举例）：

图21 流程控制表达式样例

九、留给策划更广阔的想象空间（游戏服务端引擎）

如前所述，ON-DO模型抽象（数据引擎）有以下特点：1、极大的降低编码成本，2、高度实现可配置化，3、在配置层可衍生数据，4、在配置层可实现游戏场景布置（流程控制，时间原因暂无样例说明）。

综上所述，游戏服务端引擎应该具备两个特点：1、高度可配置化：能够易用灵活地应对多数策划需求；2、模块化编码：可以便捷高效地编码以满足少数策划需求。

当然，高度可配置化必须建立在“广泛和易用”的原则之上，不要盲目为了可配置化而可配置化。

所以，基于模型抽象的游戏服务端引擎，能留给策划更广阔的想象空间（减少策划和程序的冲突概率）。

十、相关链接

[1] 游戏高度可配置化——通用数据引擎(data-e)及其在模块化游戏开发中的应用构想图解:

https://blog.csdn.net/guestcode/article/details/129214458

[2]、抽象的概念:

冯回祥,第100页．思维方法与数学教学 思维方法在小学数学教学中的应用：华中科技大学出版社，2018.01：100-101

抽象（科学学概念）_百度百科

https://baike.baidu.com/item/%E6%8A%BD%E8%B1%A1/9021828?fr=aladdin

[3]、真正的高手，都具备高度抽象能力:

https://blog.csdn.net/weixin_45719624/article/details/102482305

[4] 消费-生产模型参考：

https://www.cnblogs.com/chentingk/p/6497107.html

[5] 可配置化数学建模的应用案例图解:

https://blog.csdn.net/guestcode/article/details/127469191
[6] 数据引擎(data-e)下载链接：

https://github.com/ygluu/data-e