游戏为模型的软件架构续

Posted 2020-10-04

　　Player, NPC, Map, Director, Controller。

 

　　这里map交给谁来做，游戏里是场景设计手，从场景考虑的多方民协调来看有些像给内架构的任务。在游戏制作里，map是比较重要的文化核心，影响了出现在上边的怪和NPC，影响了将要形成的路线和可提供的服务。

　　建模为了解决问题，不一定要锁定到模型本身，可以变化着适应需求。可我觉得这里的map并不能随便改掉。每个map代表着一项服务集合。这个集合的构成应该是有思考的。每个map像是一个服务器，同一个服务器里放什么东西比较不好分配。它本身的构建应该不是考虑如何容易director跑路，而是如何有一个很好的凝聚和主题思想。

　　...脑袋不好用了，这样实用性好差，只能用来帮助理解现行架构面对的问题，这个的理解还是容易走通的，就是map和其它内容的协调，再最后反馈到Player的属性设定还有走路方式。

　　Player，NPC， Director 就是现在的MVC。这模型把分布式的考虑Map（Maps)直接加进软件架构里，还多了个新Controller把它们所有的进行协调。倒是容易让各部分的编码人员理解自己在做什么，有个大局观，好整理思路。

　　因为我自己没有涉及过分布式，只从别人写的文章里来了解到。知道那种暴力的分布方式一看就让人头大，里边缺少进一步思考、组织。

　　在游戏开发里，地图的设定很重要。想起来一个游戏分不清哪个（地图、种族、故事）是先哪个是后。看魔兽世界的过程是，...copy魔兽争霸里的，一步步过滤到早起版本，也就是本来从角色到地图还有故事情节都已经有了一个模型，参照这个被玩家适应好的模型直接过渡到的3D。

　　这里对应的就是从原来的架构过渡到这个模型。从原来的分布重构和扩充。

　　增加更多的思考和立体内容。

　　原来架构里，比较容易懂的是，一个软件是一课大树，树根和树枝都有很多小分叉。开始架构的时候，在理清思路后首先把握的是主树干，用减法思考把主树干瘦身到差不多，再进行两边延伸。虽然生命的实际过程，好像也是这样的吧，种子从发芽的时候同时生长的是根和叶子，还有树干。这个时候树干也有增长。这种建模给人的思考可能只是让人先把握主线，把主线确定出来再下手。

　　小软件编辑的时候没有想过架构和整体性，有什么功能需要增加，然后去写实现就可以了，不怎么想以后的扩用性或者成长。后来考虑到这个的时候，用的想法是尽量解耦，各部分都朝解耦努力，保证代码中的逻辑块容易修改更换，当增加新需求的时候也容易相互调整一些，改起来好找、方便。现在的框架也是在朝更容易解耦努力。解耦本身是一个过程角度的观察，是从处理过程上做修改，而不是回过头来从最开始的架构、整体搭构角度。

　　这样就容易让过程繁琐不容易被理解。

　　面向过程不容易时，编码找到了面向对象，当时只是在编码层次有这个思想。它从看向过程转变到看向需要建造的对象，站在对象的角度里思考这个对象应该有什么、可以做什么。这样把系统功能集合中的一部分功能吸过来到对象里，职责分配有从全局向各点分发，转到各点向总功能集合索要。

　　问题就来了，要设置多少个点、设置多少个对象，每个对象的凭据是什么。

　　最开始的时候搭建这个项目，考虑起来就费事了。不过这些好像都不是架构做的，架构更多是只给了接口，架构里大多都有面向服务的影子，写好了接口，下边去填写相应的功能。在填写的过程中，编码人员建立自己的类，在给自己分配的功能任务中进行类的规划。

　　整个项目就是一个机械的服务，没有多少思考。如果从接口设计角度考虑架构的话，就会是这个样子。这也是现行的解决方式。

　　从顶层到基础有两个二次构建，最下边的那次是面向过程的、在朝着面向过程转变。第一次划分却是简单平铺式的，是一个平面化分，没有多元化起来。

　　所以功能在分配到底层之前，中间有个周折，设计好这个周折就能让项目好过。周折、第一次构建，面对的不是划分功能，而是划分类。不是设计功能接口，而是设计承载类的部门。那么首先大体抽象的是这整个项目有多少个小类去完成...

　　想起了加速度。最原始的是力，把力除掉物体的质量就是加速度。加速度是对速度的观察，速度是对路程的观察。最终导致 力可以用来观察路程。

　　给了一个了力，要如何确定它的路程，不能直接构连，过程中进行了两次构建。速度构建了路程，加速度构建了速度，给加速度包个壳就是力。这里，加速度构建角度有几个基础：速度构建路程的规则确定、力剥壳的规则确定。

　　底层类建立的抽象规则确定、项目需求到架构领域的映射路线确定。

　　抽象规则可以用人的思考进行功能赋予。映射路线就是类似建模方式、思维转变方式。

　　面向对象的抽象规则并不被每个人都掌握，站在对象的角度思考。就像一个部门能做的事情就那些，把人安进这个部门后给这个人分配的职责。靠每个程序员的基本人文意识给安排工作。没有明确的条例，每个都是聪明的程序员的话，这规则勉强可用。

　　建模方式负责需求到编程问题空间的映射，可以是一棵树、一个公司、一个立体的video game或者其它的更合适的模型。

　　选取了video game，游戏模型，基本编码阶段的面向对象也可以用来抽象player和NPC代替。

　　这并不是一个游戏，只是计算机里边的一个3D世界。它提供的是公司服务，划分用户类型和服务类型，以及把它们相连接的路线方式、分布方式。一个玩家从登入到登出所要转的一圈；玩家、NPC、地图和行走路线的包装过程。地图可以是服务器的分布，地图和行走路线都和NPC摆放位置相互影响。也和玩家数量、玩家任务量相互影响。

　　这建模还是有问题。地图和路线是用来协调解决高负载和分布式。分布式也是高负载分离出来的，不过并不是一个很好的解决方案。

　　每个NPC应该有它独特的思考，他们才是整个故事的首先雕刻。雕刻好了NPC再分配给他们需要的地图。每个NPC都要有他的故事内容，于是就很容易知道他需要站在哪里，周围是怎样的地图，还有什么人和他站在一起。也就是每个任务都是人性化的。

　　每个需求都是人性化的，会产生这样的需求是社会交互的结果，所以对项目需求的划分应该从产生原因角度，而不是功能实现角度。也就是对项目需求有进一步的了解和思考。

　　哪个NPC是地区的国王，牵扯出一系列重大任务。哪个NPC是一些平民在生活，给的是一些生活任务。哪些NPC又独特地存在于野外，有自己的跌宕起伏的故事，不在王室里，也开启了一份很重要的任务主线。

　　地图从新手村开始建，再到稍大一点的城市，再到王国，就像一个游戏人的升级路线。有了王国再去周围，随着等级一点一点朝外扩。所以建图的时候先建新手村，随着需求的繁衍一点一点朝外扩。也就是拿到一个需求，思考它的繁衍过程。本来是个小企业，需求就那么单调，慢慢这个企业成长，需求也变多了。围绕需求从小到大 、成长到现行需求 这一角度，来建项目，也来推断并适应项目新需求的发展路线。

　　设计一棵树，从推断出它发芽和成长的过程来描绘出树木现在的样子，预测树木的发展方向。

　　待续。