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

航天奇侠

程序的逻辑和游戏的类型有关。
基本上是去实现策划的游戏规则。游戏规则每一个游戏都不相同，但是同类型的有很多相似的地方。研究程序逻辑，可能也相当于研究游戏规则（一个是设计，一个是实现）。要先通过设计部分来分析共同点，在实现灵活的对应架构。

对于脚本，我的理解是，因为脚本的语法简单，具有很强的针对性，可以提供给非专业人员使用，因而在游戏开发团队中，便可以利用策划来编写具体的脚本，从而解放程序。

为何不由程序来编写，可能就是考虑到策划对具体游戏逻辑有更深的把握。二者，更新游戏逻辑的时候，比较方便。同时程序设计的角度，将具体的逻辑分离出去（或者一些参数），可能也比较好管理。

sjinny

关于脚本，其实游戏逻辑作为一个个动态链接库，也可以实现与主程序的分离，也比较好管理。而游戏脚本虽然可能语法简单，但是一方面简单的语法使得功能受限，另一方面无论是自己的脚本语言还是lua、python之类的脚本语言，策划仍然要去学习它，既然反正是要学习，不如都去学C++之类的非解释型的语言，再说其实只要是能够编译为动态链接库的语言就都可以。
所以我觉得使用动态链接库来实现游戏逻辑，缺点并不比脚本系统多，但是优点很明显：执行效率高。


其实策划和程序的职责本身就有点模糊，因为具体采用什么样的设计要看是否能实现，而实现什么也要看是怎么设计的，所以程序去研究游戏规则设计也是合适的。

ricyangliu

    现在都有专门的脚本开发包啊 封装一下就拿来写了，一般只是写任务；使用程序提供的脚本系统，我现在就是客串负责这个工作；这个和游戏主逻辑框架，也就是游戏构架，关系不太大，因为这个取决与你的脚本系统所能提供的操作能力；之所以用脚本而不用DLL，一是很多脚本是由策划来做，DLL就不行，2是脚本的重置和临时改变非常方便，DLL也可以做，但是非常麻烦。
    个人比较热衷研究服务器游戏构架，看了一下，这里纠正楼上的一个误区：考虑逻辑的构架就是构架，不要和实际实现混在一起，你的架构清晰了再考虑实现的问题，这里要用到面向对象的分析技术以及你应该具有一定的设计和实现经验。
    之前我曾经提出过行为模型的建立，嘿嘿，但是几乎没有什么人感兴趣。现在大家对逻辑感兴趣了？？我现在研究的就是游戏世界的逻辑构架，所以，有什么问题就问我吧。

kevinlynx

望楼上老大出篇文章，结合着OOP，以及Design Pattern，讲讲游戏程序怎么架构~期待中。。。

sjinny

呵呵，支持ricyangliu老大写文章，介绍游戏逻辑编程的经验～  *^_^*

ethanori

1. 不同意说物理模拟就是游戏逻辑，100%没关系。
2. 不懂13楼的把SCRIPT和DLL作比较，？·#￥·%￥QUAKE2, QUAKE3 里的GAMEX86.DLL是什么？
    PK文件里的脚本是什么？怎样叫“之所以用脚本而不用DLL”.
3. 支持讨论游戏逻辑部分，包括怎样设计脚本。

sjinny

1.我说物理模拟也属于游戏逻辑的范畴，是因为物理是游戏世界中的一个子系统，所不过高度特化了，但是它仍然是针对游戏内容的子系统而不是针对游戏表现的子系统。个人意见，呵呵。
2.Quake虽然玩过不过不懂其中的dll和pk文件里的脚本，介绍一下吧～  *^_^*
3.大家讨论一下游戏逻辑部分的讨论主题吧，想想可以讨论哪些具体的问题。


^_^

vocpp

说清楚是特指客户端逻辑呀

lights

逻辑是完整的，区分开客户端逻辑和服务器逻辑一开始就走进了一个复杂的泥潭。

ricyangliu

1 这里不是要把SCRIPT和DLL混在一起，而是指把用SCRIPT和DLL实现的任务逻辑来做比较。理论上我们可以用分个的DLL模块来实现不同的任务逻辑，再在程序里面实行动态加载（不是用dll import的方法）来完成任务的实时加载，这个想法我以前有过但是没有尝试，但是理论上是可以的，只是对程序的要求比较高，且这样就失去了用脚本写任务的意义。在我接触过的脚本系统中，它都是一个功能操作集，这些功能通过脚本引擎映射成脚本程序用的一个函数集，而这个功能操作集合可以是来自服务器程序的各个模块，所以说非常的灵活，这也是任务逻辑用脚本而不用硬编码的一个重要原因。此外，为脚本添加一个操作函数是很方便的事情。

2 由于网络延迟和服务器负载等的原因，所以会出现有很多游戏逻辑如场景剔除，复杂的碰撞检测，特效的即时计算（理解成需要验证的逻辑运算）等无法在服务器完成所以做在了客户端上。而实际上对于网络游戏来说，一个理论上比较理想化和完美的模型应该是所有的逻辑部分由服务器来做，而客户端只是一个显示和发出消息的工具，当然现在还不可能。

3 如果，我们考虑构架一个游戏世界，那么，这个游戏世界里的场景，MONSTER，PLAYER，物品等等在服务器都可以有一个比较准确的描述；我们可以完全可以考虑一个游戏世界的程序描述，服务器负责对这个世界中的所有的行为做运算，服务器与客户端之间通过消息来互相通知，游戏中的各个对象之间也通过消息（此消息非彼消息）来互相告知。通过这样的设计，客户端是完全没有游戏逻辑可言的，它只负责接收玩家的操作，然后通知服务器以及从服务器获取消息然后显示出来。这样，所谓的游戏逻辑世界就完全和客户端脱离开来。

4 实际上现在大部分2D网游已经是这种实现方式，3D的除了精确场景剔除和一些物理运算之类的东西也基本上是这样实现的（有可能说的不对，请见谅解）。

5 关于结合OOP和设计模式来分析游戏逻辑世界的构架，因为我现在做的还不完善，且这几天确实很忙所以暂时无法放出来。但既然有朋友这么提了，我会尽快整理拿出来献丑。

6 此外，我强烈建议希望做游戏设计师的朋友有OOP和设计模式方面的经验和知识。

        最近和程序打叫道多了，也许说的东西并不能精确表达我的本意思，如果各位有什么疑问，请尽管提出，我每天会上来看一下的。