讨论一点高级话题，游戏逻辑和表现完全分开的问题

qrli

随着游戏越来越复杂，游戏程序的各个部分也越来越模块化，出现了具有一定的通用性的图像引擎、声音引擎、物理引擎、UI引擎等等。但从引擎到真正的游戏，还有一个具体的定制过程，各个方面都是量身定做。但有趣的是，私服的发展很快催生了游戏逻辑引擎，一个ARPG的网游server私服，经过少量代码修改和完全替换资源，就可以当另一个网游的server用。这一方面是因为当前网游的趋同化严重，另一方面是很多处理方式已经公式化。

那么，可不可能设计出比较通用的客户表现端和比较通用的逻辑服务端，让两端互相独立，又可以替换组合呢？当然，在附加一定的限制条件后是可能的，其中包括一个通信协议和一些游戏类型方面的匹配。这不限于网络游戏，局域网游戏和单机游戏都可以。这样，逻辑引擎便可以单独开发，AI因为无法脱离具体的游戏而无法独立的问题也解决了一大半，它可以作为逻辑引擎的一个子模块。

还有一些问题，游戏逻辑可能有部分得在客户端运行，要么就得把这部分逻辑固化在客户端，要么就得像网页那样可以下载脚本运行，但下载脚本又会引入安全性风险。最重要的是，这破坏了逻辑系统的闭合性，必须依赖于客户端的脚本支持。

如果这两端都能有一定的通用性，至少对一个类型的游戏有通用性，那么游戏本身的开发就只需要策划使用逻辑引擎配置规则、美工为客户端添加资源，游戏的生产率可以大大提高。

instemast

游戏逻辑 和 表现，是对立统一。两者可以相互转化。
比如今天中午我思考的，可以让玩家操纵人体骨骼的游戏，那么至少，在逻辑中就需要保存骨骼。
而如果玩家可以操控人体的多边形，那么模型数据就要放在逻辑中。

说说正题：

> 那么，可不可能设计出比较通用的客户表现端和比较通用的逻辑服务端，让两端互相独立，又可以替换组合呢

首先，我，很想这样。不过现在的技术能不能达到这样的水平，还很难说。

具体表现在： (1)接口设计  (2)效果描述  (3) 编码实现

(1)(3)都不需要讲了。我着重说一下(2).
我的观点，只知道接口设计，并不能完全知道怎么去编码实现。这是因为不知道要实现什么效果！
...比如说场景中，关于镜子有"加载镜子""添加镜子""移除镜子"这样的接口设计，但是，仅仅知道这些，仍然不知道需要实现什么，所以应该补充说明“镜子具有反射效果，但是镜子不能递归反射”等具体效果的描述。
...再比如说逻辑中，对于“增加某人的生命”这个接口，我们仍然不知道怎么编码实现，比如需要进一步描述他的效果“在XX秒内线性增加生命”。

做到了(1)和(2)，我想，(3)不算什么问题。


> 最重要的是，这破坏了逻辑系统的闭合性，必须依赖于客户端的脚本支持。

首先，编码实现不是什么大的问题。

不论设计一个通用还是不通用的游戏，都应当先做好(1)接口设计(2)效果描述。而这两者我认为是纯理论上的，不需要考虑计算机平台，网络环境等问题。做好了这两个，才能进行代码的编写。

此外，代码的编写时，我们仍然希望尽量“容易一点”，关于这点，可以：
(a)考虑研究设计模式（不如说“编码模式”）；
(b)从数学上严格推导出一些规律（和(a)类似，都是严格而统一的大方法）
(c)考虑一些函数型语言，看看是否支持这方面。


> 如果这两端都能有一定的通用性，至少对一个类型的游戏有通用性，那么游戏本身的开发就只需要策划使用逻辑引擎配置规则、美工为客户端添加资源，游戏的生产率可以大大提高

上面我也说过，这主要是设计而不是编码的问题。
不过在此我想再补充一点就是，如果设计上做的好，那么就不必再乎编码质量，设计模式，代码的可维护可扩充性等问题了！因为我们今后基本不需要维护，扩充这个“通用游戏”的 EXE 的功能了----我们只需要编写脚本等。

这就意味着，高效地开发游戏，有两条路可以选择：
(甲) 设计一个通用的游戏
(乙) 研究游戏编程中的设计模式