卢益贵（码客/ygluu）：游戏高度可配置化（二）用“模型抽象”化解游戏策划和程序员的江湖恩怨

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

目录

一、前言

二、程序员的脾气和宿命

三、策划的抱怨和冤屈

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

五、什么是模型抽象

1、功能抽象

2、模型抽象

3、模型抽象和功能抽象的抽象度

六、ON-DO模型

1、消费-生产模型

2、ON-DO模型

3、模型抽象和功能抽象的开发工作量对比

4、数据引擎

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

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

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

十、相关链接

---

一、前言

本文将阐述“模型抽象”在高度可配置化游戏开发中的应用。高度可配置化的游戏框架可以更加从容应对需求的变化。当然高度可配置化必须建立在“广泛和易用”的原则之上，不要盲目为了可配置化而可配置化。

确切的说本文是上篇的补充（游戏高度可配置化（一）通用数据引擎(data-e)及其在模块化游戏开发中的应用构想图解[1]）。

特别备注：抽象是解决多数问题，少数问题解决原则具体问题具体解决（在优秀的抽象基础上解决少数问题会更加便捷高效）。

二、程序员的脾气和宿命

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

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

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

三、策划的抱怨和冤屈

你按我说的做就得了，配置要简单要灵活。 这个功能很简单啊，什么时候完成？ 我Kao，这么一个小案子花这么多时间还有这么多Bug。 不好意思，案子我改了你再改下程序（不改案子的策划不是好策划）。

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

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

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

主策：案子什么时候出？ 策划：今晚出1.0版本（反正案子还可以改的）。 主程：这个案子什么时候完成？ 程序：今晚完成（反正Bug还可以修）。

在短期KPI逼迫下，往往都会有“做假”现象（所见甚多），开发初期欠下的债都会在运营后慢慢还。游戏是否成功与代码好坏无关，但与开发效率和质量有关。

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

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

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

五、什么是模型抽象

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

1、功能抽象

以人为例的功能抽象：头、眼、鼻、手、脚......

2、模型抽象

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

注：本文模型抽象与科学界的模型抽象是由区别的。

3、模型抽象和功能抽象的抽象度

模型抽象和功能抽象的抽象度如图6所示。由图可见，模型抽象的抽象度是非常高的，功能抽象则比较低因而非常接近具象（所以它在应对需求变化的时候会显得非常吃力）。

众所周知，抽象是不能100%解决问题的，所以图6中有3种抽象流：1、抽象—模型抽象—具象，2、抽象—模型抽象—功能抽象—具象，3、抽象—功能抽象—具象。第2种就是以模型抽象为基础的功能抽象，是第1种的补充，用于解决少数特别的需求，相比第3种具有开发便捷和高效的特点。

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

六、ON-DO模型

1、消费-生产模型

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

​图7 消费-生产模型

2、ON-DO模型

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

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

3、模型抽象和功能抽象的开发工作量对比

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

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

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

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

如图10所示，模型抽象把公式建立在了配置层，当数学模型变化时，仅需在配置层修改公式表达式，而代码层无需改变，相比功能抽象它的可配置化程度更高更灵活。

4、数据引擎

由图7和图8所示，消费对象、生产对象、条件对象和执行对象在程序层是没有具体定义的，那么配置层所依赖的数据从哪里来？由此引出数据引擎（下称：数据引擎或de）。

在消费-生产模型中都会依赖一个数据缓冲的中间件[5]，在本人做科研时依赖一个数据交换机的中间件[4]，在此把这个中间件概念称作“数据引擎”[1]，如图11所示。

​图11 数据引擎

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

数据引擎是ON-DO模型的抽象产物（源码下载见参考[6]）

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

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

​图12 递进式数据管理模型的配置实现

​图13 递进式数据管理模型观察者模式的伪代码实现

​图14 并列式数据管理模型的配置实现

​图15 并列式数据管理模型探测者模式的伪代码实现

​图16 其他数据配置样例

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

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

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

​图17 维度空间模型

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

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

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

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

​图20 流程控制表达式样例

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

如前述，在ON-DO模型（数据引擎）支持下，极大的降低了编码成本，并且高度实现了可配置化。同样，依据ON-DO模型，在配置层可以衍生出游戏所需的衍生数据，还可以在配置层实现游戏场景布置所需的流程控制（时间原因暂无样例说明）。所以，依托这样的游戏服务端引擎，策划具有更广阔的想象空间。

游戏服务端引擎特别难做，主要是策划需求多变。游戏服务端引擎应该具备两个特点：1、高度可配置化：能够便捷从容地实现需求配置以应对大多数策划需求；2、模块化编码：可以便捷快速地编码以满足少数部分的策划需求。

十、相关链接

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

卢益贵（码客）：游戏高度可配置化（一）通用数据引擎(data-e)及其在模块化游戏开发中的应用构想图解_ygluu的博客-CSDN博客

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

真正的高手，都具备高度抽象能力_抽象才有高度_Python小行家的博客-CSDN博客

[3]、抽象的概念:

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

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

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

卢益贵（码客）：【数据中台战略】可配置化数学建模的应用案例图解_数据中台建模_ygluu的博客-CSDN博客

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

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

[6] 数据引擎(data-e)下载链接：

GitHub - ygluu/data-e: Data Engine（数据引擎）用于独立模块间数据共享（Data Engine, For data sharing between independent modules）