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

shawind

就是像NS那样的脚本，最后也还是要调用Native的。
那么所有的调用全都共用一个interface，我想这样就不会乱了.
而不是像krkr，rmxp那样的，可以用脚本来写库，这个库再和native的底层加在一起，才构成一个高级的游戏引擎。

我一直都不认为一个易用的游戏引擎应该提供那么高级的脚本语言，而是倾向于在一个共同的接口下，为每一个特定的游戏类型或是单个游戏，提供一个特有的简单直观的命令式脚本。不知道这样可行否？

Miliardo

……呃，呃，呃，呃，呃，我相信Shawind桑是明白Native和Script这个架构的区别的……
如果一定要统一的话就只有用Native来模拟脚本接口，根本上系统理念要统一于脚本了……
（也就是说符号和库一类东西由脚本环境来管理，而不是让Native来管理。因为Native可以很方便的访问脚本相关的任何东西，但反之则几乎完全不可能）
这个可以参见Krkr的那个TJS Script Interpreter。

此外如果要适应不同的类型和层次，那就只能提供一个Interpreter+Binder了，因为API要按照需求导出。

shawind

这个想法是从ruby的c接口获得的。
ruby就可以直接用c语言来写ruby里面的对象，效果和用ruby语言写，两者是完全等效的。
不同的地方只是c写的是直接调用dll中的c函数，而ruby写的还要interpreter。

设计模式里面就有一个interpreter模式。目的就是把发生频率高的问题的各个实例，表述为一个简单的句子。那样是不是可以把MVC中strategy，利用interpreter来实现？老实说，我能实现的也就是这种简单的脚本了。本来还不想去学什么STL，设计模式的，结果还是去看了一点。可不能再去看编译原理了，我的目标可不是去做程序员。OTL

lw

以前XX不是说尽量避免作通用的脚本……不过如果是LZ的意思是作一个C/C++的接口，然后兼顾脚本的实现对吧？
实话说偶也觉得和M大这样去理解了，把接口做的类似于脚本去实现，顶多是两套不同的API而已，其实以前做过一小部分的代码编写关于这种结构－，不过已经忘光了……
PS：这么一说倒是提醒偶了………………忘了这件事情好久了……

lw

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

shawind

差不多就是那个意思，就是写一个通用的接口。因为脚本可以用闭包的方式，当作函数来使用。这和硬编码在形式上是一样的。

本来我也是想先写了再说，然后就跟着直觉，用SDL稀哩哗啦的写了一个，结果发现SDL根本不支持3D音效。于是又要加上openal。这样一来，就得考虑2D音效和3D音效还要能切换什么的，所以一切全都被推翻了重来。
有了这个教训后，我就想，应该在一开始就设计好引擎的框架，并为以后的扩展留下充分的余地。这样才不至于作那些无用功。

lw

原来有经验＝　＝
那就没办法咯～，比较一下究竟做什么来更强大～～～～^^

偶现在只需要最基本的功能就可以了，先做结构样板……
那怎么继续呢……？

shawind

我是定下了一个大致的方向后，便找了个可以画uml的工具，没事画了玩.....
代码一句还没有写呢

<=其实根本不懂uml，只是觉得看那个图比看空框架的代码更直观罢了

rednaxela

关于脚本的问题...这问题太复杂,我也没资格多说.不过...

1. 脚本可以是可编译/可解释共存的.可编译的目标语言也未必一定是中间语言,可以是机器码.
2. "两套API"真要用就会体会到痛苦了.对模式那么执着的话,这里恐怕得adapter了.
3. 易用和通用是永远的矛盾.否则有那么多现成的高级语言,我们不需要为自己的应用设计专门的DSL.或许不要一开始就对"通用"太在意的好,除非那是一个确定的目标.
4. lw说的重构的方式是敏捷的思路,可以考虑
5. 得闪回去做作业了...下次再说.

引用第10楼shawind于2007-09-25 13:40发表的  :
而不是像krkr，rmxp那样的，可以用脚本来写库，这个库再和native的底层加在一起，才构成一个高级的游戏引擎。

我一直都不认为一个易用的游戏引擎应该提供那么高级的脚本语言，而是倾向于在一个共同的接口下，为每一个特定的游戏类型或是单个游戏，提供一个特有的简单直观的命令式脚本。不知道这样可行否？

总觉得LZ是把不同层次的脚本混在一起说了.同样以KrKr为例,它正是为了通用而设计了底层运行时,在这个底层之上使用一种原生于这个底层的DSL(这里指TJS)去定义了"为Novel Game游戏类型，提供一个特有的简单直观的命令式脚本",也就是KAG Scenario (Script).
没错,现在KAG的解释同样是在底层做的,但在某个版本之前,KAG的解析运行就是在TJS上做的,修改到现在的架构是出于性能考虑,而这正是在一个系统已经能顺利运行时考虑的重构问题.原则上说,可以为KrKr编写插件(不是用TJS或者KAG写的那种"插件")来支持别的脚本语言,脚本层次的高低都不重要.

之前在日本的时候,买了本书,叫「ゲームエンジンプログラミング」.LZ想要的引擎,或许就跟那种实现比较接近吧.有兴趣的话可以参考下.
www.amazon.co.jp/ゲームエン ... LOPER/dp/4797331976
而LZ想要的,与Game Scripting Mastery所描述的引擎大概相当不同.

shawind

易用和通用应该不矛盾。用了mvc模式的rails，可以方便的容纳各种插件。如果这样的思路能转到游戏中的话，也应该可以为特定类型提供特化的库。

我原来写的那个就已经弄得很复杂了，好多东西都被写死了，只怕重构会让事情变得更糟糕 [s:6]
现在YY的这个还没开工呢。hoho～

游戏框架是一个整体，kag是底层解析不错，可是，单独一个kag并不能显示windows游戏窗口，也不能实现窗口上的那些菜单及菜单功能。这些功能理所当然应该包含在一个完整的游戏框架内。单独的一个kag实现不了完整的游戏框架，这就说明kag的地位并没有实质上的变化。后来kag的变化也不过是对它的性能的小改动而已。krkr的设计思路并没有随之而变化。还是一惯的提供最容易使用的脚本给多数用户，并允许高级用户通过tjs来增强kag，兼顾高低手的两层次脚本的思路。我认为只有等哪一天kag可以完全不用一句tjs，就写出一个游戏，那才能算tjs和kag的地位就平等了。（纯属个人偏执，还请勿惊勿怪.....）
另外，我同时还举了rmxp的例子，这个应该没有误会吧。 [s:5]

这本是赤坂 玲音的书啊，他的网上教程我看过一些，都是些比较基础的，特别是D语言的那个，很火星了。不过我是在国内，买他的书，应该是相当的麻烦。如果有可能的话，你能把那本书中的大体思路给说说么？不管怎么样，先谢了再说。  [s:1]

Game Scripting Mastery后来把interpreter模式作为一个游戏引擎的主体结构。和我在YY的当然不一样了。