基于5层模型&对象的游戏描述法

yii

貌似很久都没看到zfscnu上QQ或者MSN了。。。

lhy2

zfscnu: Re: Re:基于5层模型&对象的游戏描述法


仅仅是因为原创文章才支持吗？ [em11]

不过我的概念在之前已经有人提出了，bigbook2000

http://bbs...

他这种理论，怎么说呢，和面向对象初期那些幻想家一样，当然现在的oo初学者也容易有这种幻想。
他说的如果能实现，就不会有那么多oo理论巨著面试了。

shengkz

有点抢程序的活了，不一定所有程序都乐意你规定好了实现方式

tonycat

类？对象？

记得有本VC++对类和对象的解释特别有趣，有点类似楼主所绘制图的概念。感觉那个就是设计软件的一种基础思维

zfscnu

经常都上qq的，只不过是隐身而已

对象、类之类都是数学建模的概念，专家可以使用，普通应用者也可以使用的，并不是说为专家专用，当然前提是理解正确。

并不是说要抢程序的活，只是对于游戏策划要表达而言，他用“控制对象” 和程序进行沟通，表达出，我需要这么多的“控制对象”，至于程序要怎么实现，是他的事情；之外用对象需要装载的“子图象”与“元图”和美术沟通，表达出，我需要哪些图象。在游戏策划本身描述出“控制对象”和“子图象”与“元图”的联系，那么可以对整个游戏（制作）有整体的把握。

另外，美术也是通过“控制对象” 和程序进行沟通，明确游戏引擎对图象的支持程度。

ahalyb2000

看了，有收获。
不过，这样给程序提供策划案的话，估计不太容易被人理解。
真的可能会被程序或策划头头理解为“狗拿耗子多管闲事”。

回头想想WOW的操作，其实不用看按键了，只需要知道可以攻击、可以选择、可以使用物品、可以键盘8方向移动、可以转动视角、弹出某某界面、使用技能等等……
至于这些功能绑定在什么按钮、按键上，就可以随意定义。
而在此基础上，宏的实现也就有了可能。

zfscnu

最近在看 java的编程思想，其中提到“使变化的事物与不变的事物相互分离”，这个我是很有感触、、、、、、^_^||感触的其中一个来源是我写挂机脚本，怎么在考虑如何用最少的代码应付无穷的需求

上面的文章是以前的粗糙想法，发出来的初衷是希望可以获得认可，可以集众智来完善，但、、、、

比如7楼图中 左键碰撞控制对象，可以命名为 边框选择碰撞控制对象，再关联到左键对象或者左键对象赋值到控制对象等等。这样 边框选择碰撞控制对象 和左键对象 都成为 不变 的设计，那么对于这一块，如果没有大的需求改变，就不需求重新去设计，程序也可以根据对象名字寻找规范的描述来了解程序需求，对于策划而言，要做的只是把 边框选择碰撞控制对象 和左键对象 与其他元素组合搭配出需要的“游戏”

ahalyb2000

去看了一下bigbook2000回复的帖子，发现我们用的方法是相同的。
做MMORPG的AI用流程图能累死自己，而且在当前的MMORPG中还没有必要采用流程来做AI。在单机的即时战略游戏中，是会用流程AI，但他也少不了状态AI，

比如某个种族建造分矿，给你打了，他还会造一个。这算是流程AI。
但一个英雄带一队兵出去与另一个种族对战，也用流程AI？除非设计者疯了。

如果把流程AI视为上层AI，英雄带队是中层AI，英雄战斗中的行为是下层AI的话。那在现在的MMORPG中，能应用到的也只有下层AI，即状态AI。

我曾想过建立一套AI，包含上、中、下三层（或许更多），每层包含军、政、商或其分支，并自我进化获得最大效率……所有的玩家就是在与这个AI对抗。

虽然最终没有实现，但我却发现，流程AI适用面积很小，非常不适合做大范围大数量的AI。流程AI其实是为了更简单的实现一个流程，比如星际，魔兽争霸。而放弃了状态AI。

实际上，流程AI中会有状态的判断，而状态AI中也会有流程的顺序，最大的差别在于状态AI可以让策划在某种程度上脱离程序实现自己的想法，而流程不行。在这点上，状态AI的可调控性要比流程AI强很多。特别是在策划发现问题，或想要实现想法的时候，状态AI的优点就更加明显了。

ahalyb2000

zfscnu：
      刚好我也设计过界面，虽然之前没有用面向对象的方法去做界面设计，但是如果下次还会负责界面的话，我是一定会采用这种方法的。
      另外，建议最好是规划好所有的东西，让游戏内所有的东西都按照面向对象的方法去设计。这样可以用“面向对象的小功能+调用这些功能的脚本”的方式做成宏了。

金时为开

觉得只是刚刚涉及到游戏的最初的上层内容，未能深入的整个过程中。
另外并不认为楼主提到的东西有干涉程序的部分，如果说有，个人觉得应该更深入的去设计一些编程的构思。目的不在干预程序员的工作，而是更好的说明设计的思想和实现的目的作用，帮助程序更好更准确更简练的实现功能，完成目的。

在实际的工作中，碰到过类似的事情，因为策划的知识缺乏未能参与到实现的算法设计中，导致的是服务器端程序的实现，对系统资源的需求非常高，直接影响到了响应服务的品质和容量标准。