有没有针对游戏逻辑的编程的研究？

sjinny

感谢ricyangliu老大～

1.关于DLL，我考虑了一下，我是这样想的：
设置少量几个基类，要求DLL里的类都从这些类中的某一个派生出来，比如提供Character、Scene，那么在DLL里的那些角色类都要从Character派生出来，而那些不同的场景系统类都要从Scene派生出来。当主程序载入DLL后，首先按照约定的函数名，从DLL里提取一个getFactory()函数，然后通过这个函数获得DLL中的Factory，之后主程序就可以使用类名从Factory对象那获得相应类的实例了。并且不同DLL的代码都可以从这个Factory获得不同的对象。而这些对象都是某些类的派生类，因此按照约定把获得的对象指针转换为基类指针，这样就可以与这些陌生的对象交互了。这样主程负责设计这些基类，设计基类中应该有哪些接口，在基类中提供最基本的功能服务。然后其他程序员在此基础上编写DLL，把游戏逻辑的基本框架搭出来，然后策划编写剧情DLL，调用前面那些DLL里提供的类，把剧情表现出来。另外策划也可以在编程人员开发的基础上，往函数体里填入一些公式和判定。
另外我觉得，亩前脚本系统相对于DLL并没有多大的优势，但是DLL相对于脚本却有着巨大的运行效率上的优势，并且也可以有比较强大和丰富的功能。

2.我觉得即使网络和硬件发展得再好，以后的网游也不太可能只是面向玩家的输入输出节点。其实把服务器和所有的客户端放在一起看待，这是一个分布式的计算系统，只不过服务器有数据仲裁权，但是各种计算负载仍然会分布在客户端和服务器上，客户端上的游戏逻辑编程总是逃不掉的。所以问题只是怎样设计服务器和客户端的分工与合作。

3.我觉得懂得一些编程上的思想对于策划应该是很有用的。


大家继续讨论～   ^_^

航天奇侠

脚本也并非效率必然低下。

因为脚本很大的一个作用，就是参数外置，比如，将图片目录放在一个文本文件，以后读入，和直接写到代码里面，性能真地与很大差别么？又不是每用一次，就解释一遍脚本。读一遍便可以获得缓冲了。
反而，写在外面的参数比较好修改。

航天奇侠

如果是操作序列，相对来说缓冲后也至少减少了很多优化，增加了很多间接消耗。
不过呢，有很多脚本语言支持编译的。所以说用脚本还是很灵活，适用性很高的。

seer

并且还有一点
脚本可以随时改，改完了不用重新编译
话说VS.net的C++编译那是个慢……

而且要用dll就要求写脚本的得会编程序才行

何况还有安全性问题：如wc3的地图系统，可以看成每个地图自带脚本，如果用dll那么很难保证dll里面没有带上木马

sjinny

大家都说脚本容易修改，我承认这一点，但是，当脚本写好之后，还会经常去修改它吗？即使在脚本内容确定的过程中需要不断修改，我觉得用DLL也是可以的，因为并不需要每次把所有文件都重新编译，而只需要把改动的文件重编译而已，文件组织好了，编译一下并不会花太多时间。
写DLL的确需要学编程，可要使用脚本，对于现在大多数的脚本来说也是需要学习的，要写DLL，有很多种语言可以选择，而脚本则不同了。
如果脚本里只是一些函数的调用，那么效率问题可能并不突出，可是一旦里面包含了一些运算和逻辑判断，那么就必须考虑效率问题了，而很多时候也的确要用脚本来做一些运算和判断的，比如技能，比如剧情、任务……
安全性的确是个问题，不过话说回来，脚本里也可能带病毒……

seer

不用担心脚本带病毒的问题
脚本是解释执行，只要解释程序没有漏洞，那么脚本就不会给系统带来威胁——我们可以禁止脚本对系统资源的操作
这是游戏脚本和VBS,JS的区别

ricyangliu

关键是，一般的脚本都是策划来写的而很少是程序来做。
此外，强烈建议楼主尝试一个简单的用DLL实现的任务逻辑系统。

sjinny

我最近在学用ICE，用它搭服务器端架构的时候我就用了DLL机制，也就是说所有与具体游戏逻辑有关的部分都在DLL里，并且是运行时载入，不过目前还没能好好测试，所以做得到底怎样也不清楚……  *^_^*

liflag888

顶一个