[问题]关于以MVC模式组织的游戏引擎

rednaxela

我们貌似没说到一起去.我想要说的,正是TJS与KAG Scenario的地位有本质的区别,不应该把高层和底层脚本混为一谈.KAG系统是最初通过TJS实现的,而用于控制KAG的脚本是KAG Scenario.后来出于性能原因将KAG Scenario的实际解析也做成了native的,但大的思路并没有变,KAG Scenario需要下面的TJS支持.它们的地位不应该平等,除非把KAG稍微增强一点,然后绕开TJS为KrKr底层写一个插件去解析KAG.那同一般的两层式引擎就没有太多区别了.

应该这样想,如果KrKr不允许在KAG Scenario中嵌入TJS片段,那么TJS的存在与否就如同黑盒子一般,用户无须知道.完全使用原本的框架,一句TJS也不写,一样能让KrKr跑起来运行游戏,但是功能十分有限.一般来说"易用"意味着脚本的层次非常高,而层次太高就缺乏细微控制的能力;如果一个层次很高的脚本仍然完整但简单的运算能力,那么可以通过在这个高层脚本上去实现有限的扩展,但运行速度也会相应受影响.
而"通用"意味着要么要提供统一的脚本接口,让用户可以编写解释器(或者叫运行时)插件去将一种特化的DSL与底层引擎结合起来;要么要允许现有的脚本得到扩展,同样通过底层插件.区别是,前者完全抛弃引擎原本提供的默认脚本形式去实现一种新的,后者仍保持原有脚本形式并将其扩展.后者在现有的许多引擎上都有所体现,例如说在Windows上许多引擎都允许用户注册并挂接外部的DLL去扩展引擎的功能.

但...LZ看来想要的是我这里说的前者.而「ゲームエンジンプログラミング」(Game Engine Programming)里说的正是这样的一种实现.它使用一种比较flat的架构(与hierarchy相对).先估计大体的需求类别,并设计接口.所有的组件都只实现一个很小很单一的功能,并且编译为动态链接库.这样就得到了每一块的积木.再写一个启动程序,将图象,声音,脚本解释器能粘合到一起.有兴趣的话我可以把那书光盘里的代码传给你,不过因为作者声明了那不是开源代码,所以就不直接放论坛上了.

shawind

反正我现在是搞不清楚什么两个脚本，什么高低层次了.....   [s:8]

现在YY的这个引擎，等作出来时，也就是头文件+lib文件这样的形式。要扩充个功能什么的，可以直接在底层上做。所以通用性多多少少还是会有点的吧。

YY的引擎（嗯，决定了，这个引擎就叫YYGE吧[s:1]）脚本的目的只是用来简化一些需要不断重复的工作，如人物说话，描述关卡，NPC逻辑什么的，并不参予任何和游戏主框架有关的工作。所以要先用类似mvc这样的模式，在底层上把游戏的框架搭好。
特化出来的脚本，当然应该是以最简单直观为准，学习难度几乎不存在的那种。主要就是为了在真正设计游戏本身的时候，能让人更关注游戏本身。不是在想这个窗口效果怎么作，那个自战效果怎么作。面对大众的，能被快速掌握的脚本本来就不应该干这些事。

那个代码，请在QQ上传把代码给我吧（QQ PM 给你），谢谢。

rednaxela

恩行,代码的事在PM上说.

对不起我把主题带跑了,突然想起前面的话题...

引用第4楼shawind于2007-09-24 21:11发表的  :
具体点说，就说挖矿吧，现在日本的那个《牧场物语》系列中，只能有主角一个人孤苦伶仃的在空旷的矿区刨地。而我想实现，如果是主角挖矿赚钱了，会有NPC也效仿主角去挖矿。可这样一来这个NPC的活动列表也就要变更。一个变，还会引发蝴蝶效应，引起更多的NPC改变他们的活动规律。

NPC和主角的行为都是业务逻辑,在model里.如果说他们之间"互动",那恐怕是model层之内的各个对象之间的互动,而你说的observer也存在于这里.

MVC模式中的observer模式最主要存在于view与model之间,也就是model的状态变化时可以通知view去更新.恐怕跟LZ描述的例子有点距离.

shawind

我是这么想的，因为游戏的特殊性，它必须有一定的帧率。所以在view须要一个列表，并保有从module传来一些显示用的必须的状态，如位置，大小...，就可以让view按着fps的频率，自我循环。而当module中的这些状态发生改变时，再去通知view改变显示状态。
记得上一次我就在HS问过一个问题，如果AI作的太复杂了，运算的时间远远超过一个FPS的时间，那么按着通常的游戏设计办法弄出来的游戏的正常的刷新也会受到影响。那个时候大家就想过线程来处理的办法，但是同步的同题看上去还是挺吓人的。如果把游戏改成这样的方式来组织引擎，问题应该就很好解决了吧。

在module内部再应用observer组织各个对象的关系，这应该也不是什么问题吧。设计模式是可以组合应用的。

lw

话说用DLL不是很好？？？

另外偶想问，通知是顺序通知么？比如执行若干次进行一次通知（通过检测状态），还是必要时直接把消息发送到消息队列里面？？？

shawind

还是lib好啊，c式的dll只有函数，不能简单的通过继承类的方式来扩展。能提供类接口的dll又让人想起来com，没学过，头疼......

lw

不会啊………………VC内置了一个导出类的范例，完全和COM无关

为什么用到COM其中之一是为了复用同一个对象，以及基于C++进行多对象组合（多继承），多了引用计数，大部分模拟COM也就用了这玩意儿，相对来说像远程过程调用啊，ACTIVEX啊，应该不会用到太多XD对吧？

引用第25楼shawind于2007-09-27 19:44发表的  :
还是lib好啊，c式的dll只有函数，不能简单的通过继承类的方式来扩展。能提供类接口的dll又让人想起来com，没学过，头疼......

其实从你的出发点来看，DLL才是比较适合你的，因为继承本身就相当的藕荷，当然并不是说就不应该用继承的意思，只是个人认为最好把所有的数据成员都不公开，除了暴露方法和HANDLE以外，用过某些很强大的LIB，但是非得熟悉每个部分，不然INCLUDE一堆都不知道是什么……

因此结论，个人更倾向于可以PICKOUT的模式，即模块化设计

看了以前前面所说的，感觉SHAWIND应该打算以C＋代码为主体，实现的是一种结构，而不是想做一个倾向于XX游戏的EG，所以基本和脚本编程可以说没啥太大关系，非得和脚本混在一起有点偏离了巴？当然偶只是猜测意

觉得文字方式还是太啰唆了，不妨请LZ先来个CONSOLE版本的超级简单的结构，也可以没有任何什么实际的意义，先让我们也可以知道具体的意向

有时候开始想的多了，后面会发现（特别是使用C++的话）差一点点结果还得绕圈子实现的事情，所以还是再建议LZ先来个SIMPLE-CONSOLE版本的样子，如果想要什么工具类也可以提，说不定这里以前有SOMEBODY IMPL过了

很忙可以忽略偶最后的一段话……[s:4]XD～

shawind

就是先写一个简单的出来吧，这个肯定是要先写的。等我把整体的图画完，就开始写。
现在我连基本思路还没有理清楚呢......想写都没东西写.....

lw

就是这个时候写，写了一个100行的大家也就知道你的意图了嘛XD～
非得等到直接看成品，虽然也不错……

FantasyDR

引用第14楼lw于2007-09-25 22:41发表的  :
补充个人的观点：先不要考虑任何什么模式……
虽然模式不错，反过来实现反而比较苦闷，先用直观的方法实现巴，模式比较适合调整重构的时候去用……先走模式的路会偏失，除非以前已经做过，那就算是重写，当然可以先考虑模式了……
[s:4]  [s:4]

写之前不考虑就动手么？如果有作考虑的话，某些场合套用模式来作思考量反而小吧。
设计模式是为扩展性和灵活性准备的，并不是为高效的写代码而准备的：）