游戏高度可配置化用“模型抽象”化解游戏策划和程序员的江湖恩怨
Posted ygluu
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了游戏高度可配置化用“模型抽象”化解游戏策划和程序员的江湖恩怨相关的知识，希望对你有一定的参考价值。
游戏高度可配置化（二）用“模型抽象”化解游戏策划和程序员的江湖恩怨
关键词：模型抽象、功能抽象、抽象工厂模式、游戏服务端引擎、高度可配置化、恩怨情仇、游戏策划、数据引擎、生产消费模型、订阅-通知模型
目录
一、前言
众所周知，由于游戏策划的丰富想象力导致游戏服务端引擎实现起来非常艰难。因为紧迫的工期和不断变化的需求，在策划和程序之间还上演了不少江湖恩怨。
本文主要介绍模型抽象在游戏服务端引擎开发中的应用。确切的说本文是上篇的补充（游戏高度可配置化（一）[1]）。
二、程序员的脾气和宿命
一般程序员都有者对技术执着的宿命通病，如执着地用技术解决性能问题、执着地用技术解决功能问题。在策划一而再、再而三的改变需求时，多数程序只能“疲于奔命”，所以“没有脾气的程序员不是好程序员”。
图1 RD和PM打起来了（图片来源于网络）
图2 被逼疯的程序员（图片来源于网络）
三、策划的抱怨和冤屈
“你按我说的做就得了，配置要简单要灵活。”
“这个功能很简单啊，什么时候完成？”
“我Kao，这么一个小案子花这么多时间还有这么多Bug。”
“不好意思案子改了，你再改下程序”。（不改案子的策划不是好策划）
图3 被喷的策划（图片来源于网络）
图4 这么多Bug（图片来源于网络）v
四、主策和主程的共同目标
主策：案子什么时候出？
策划：#%￥*&#……
主程：这个案子什么时候完成？
程序：&@*@#!*&#￥*......
在短期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
以上是关于游戏高度可配置化用“模型抽象”化解游戏策划和程序员的江湖恩怨的主要内容，如果未能解决你的问题，请参考以下文章
游戏高度可配置化：通用数据引擎(data-e)及其在模块化游戏开发中的应用构想图解