|
|
rev: Sep 26
参与过国内几款网游的后端研发工作，有mmo，也有web，有感于目前大大小小的游戏公司的开发现状：重复从头开发，项目与项目缺乏共用性，直接导致项目周期变长，成本增加，风险也随之上升。为什么不把共用的部分框架化，平台化呢？ 有点类似于前端的引擎一样。沿着这个思路，我们来统计一下后端有哪些部分是可以平台化的？
1. I/O
网络I/O，磁盘I/O，完全可以做到对上层游戏逻辑透明，不需要关心协议，缓存，也不需要关心到底是用epoll，iocp，逻辑层唯一需要关心的是数据的投递目的地和来源地。
2. 线程模型
线程模型稍微复杂一点，因为关系到游戏逻辑的并行处理，这部分在我看来，可以做到99%的透明。
3. 内存模型
内存模型基本上于逻辑无关，除非自定制内存池，是可以平台化的。
这三个部分，大部分公司都或多或少有一些自己的封装，虽然不够通用，但至少满足需求。
4. 逻辑部分
大部分游戏的逻辑大同小异，至少从技术角度来看是这样的，像Quest, mail, 甚至技能等等，相信制作过游戏的朋友都会有这个感触，那为什么我们要重复劳动呢？虽然这也是我们程序员存在的价值，但可不可以把事情变简单一点，让我们轻轻松松的也能赚一份薪水。
我的初始思路是这样的：
构建一套框架， 有点类似于bigworld的想法，不过不同的是，我只专注于后端，并且我希望这个框架不单单只能应用在mmo这样的特定场合，这个框架应该包括这样几个部分：可定制的服务模型， 通用的逻辑流程和附加工具。
可定制的服务模型： 提供网络服务，线程服务，内存服务，文件服务等基础服务。并且可灵活定制。这个模型让我们立即就有一个高度可用的服务器。
通用的逻辑流程： 提供一整套网游基础功能的框架，比如聊天，ai，任务等等。。。这部分可以使我们摆脱重复编写类似功能的代码，冗长而且杂乱。
附加工具： 就像前端引擎一般都会携带大量工具一样，后端其实也需要各种工具，就性能分析工具，内存分析工具等，功能开发部分还需要表格转换工具，日志分析工具，系统监控工具等等，工欲善其事，必先利其器嘛，完善的工具是必备的。
由这三个部分组成的后端平台，基本上囊括了游戏后端开发的主要工作，设想一下，当后端开发只需要变更一些配置，然后再根据游戏需求编写少量的逻辑代码，就轻松搞定的话，岂不是乐事。
当然，以上只是我的构想，有些朋友可能会认为，光实现这套框架得要多少人力物力呢，再者，这样的平台究竟能节省到多少的开发量呢？毕竟，每款游戏都不太一样的。对于后者，我的回答是现在的游戏大部分都一样，或者换个说法，去看看17173上的top 10，看看他们之间能有多少的差异。所以真有这样的平台，我相信游戏开发，至少后端部分，我初步估算是可以节省70%-80%的开发量的。对于前者，这套平台我其实已实现了部分原型，并且部分也应用在了商业游戏中，业务时间也在持续的研发中，我的总体感受用一句话来概括，那就是：磨刀不误砍柴工！
但愿我的这些粗略想法能给各位同行以启发，共同进步。
---------------------------------------------------------------------------------------------------------------
rev: Oct 09
长假期间，一直远离网络，未及时更新，各位见谅。
正应了上面那位朋友说的那样： “难就难在这套服务端要以什么样的形式出现”。事实上，同样的概念，而不同的实现，其效果可能千差万别。我不是一个喜欢泛泛而谈的人，我喜欢把自己的想法实现，我喜欢看着代码按我的意图运转，所以，接下来我们来谈谈实现层面的问题。
从技术的角度出发，我认为这套平台的应该拥有下面这些特性：
1： KISS原则
简洁的东西未必是优秀的，但优秀的东西一定包含简洁这一特质，世界万物，自然之道，无不透着简洁之美！所以，早有人就说上帝粒子是不存在的，因为理想模型不够简洁，不符合造物主的一贯原则，而实验结果也证实了。 所以，这套平台一定要简洁。易于掌握，易于维护。
2： 高灵活度
既是平台，自然要兼顾到尽可能多的应用场合，尽可能广的设计需求，尽可能大的可操作空间。平台的灵活度决定了它的适用范围。
3： 高并发性
随着技术的发展，并发性受到越来越多的关注，譬如erlang等。很难想象现在设计一个低并发甚至不支持并发的后台系统能有多大的实用价值。
4： 高可用性
再优秀的系统，如果不稳定，经常出错，甚至宕机，那也是白搭。高可用性是一切设计的基石。
5： 高效率
这里说的高效率不仅仅指高运行效率，还有开发效率，在网游生命期越来越短的背景下，从技术角度出发，如何快速的开发一款游戏产品，是一个值得认真思考的问题。
围绕着上述特性，我们来探讨下设计思路，我的思路大致应该是这样的：
平台的原子组成是服务(以下皆用service称呼），也就是说service是系统的最小组成，整个平台由若干个service组合而成，service和service可组合成service，service可运行时增减。这里的service有点类似Erlan里的进程概念，可并行处理，可热替换。service之间由事件来驱动。service拥有标准接口和自定义接口。系统组成大致如下图所示：
图中方框表示单独的service，这些service的划分是很随意的，未仔细斟酌，仅用于说明思路。在service之间就是事件流，由事件流来驱动整个系统运转。看上去又有点像微内核操作系统模型。
service的划分是个小小的难点，事实上我认为没有唯一，除了meta service外，其他的service的划分取决于设计者的思路，而前文提到的通用的逻辑处理模型在这里可以实现，举个小小的例子，比如队伍系统，事实上，绝大部分队伍系统大同小异，无法是人数不同，权限有所不同，然后队伍的加成有所不同而已，而队伍处理流程几乎一致。那完全针对这个功能，完全可以制作一个队伍功能的可定制的原型，在不同的产品中，根据需求修改一些设定来快速达到目标。
service的并发，我的设想是service要自由的支持并发，也就是说可并行处理，可独立部署。service的并发性就要求每一个service编写难度增大，在这方面是可以妥协的，取决于系统设计者。
综合一下我的思路，简单的说就是构建一套以service为单位，以事件流驱动的service模型。在该模型下开发游戏，按我的设想是与游戏逻辑无关的service基本可以保持不变，与逻辑相关的service在9成品的service基础上，通过修改设定，配置，参数等手段，甚至修改service的实现的手段来达到目的。想一想，是不是要比现在的方式要简单？至少，听上去是这样！
抛砖引玉，筑巢引凤！有更好的实现思路，甚至更好的想法，都可以和我交流。这才是我的最终目的，共同进步。
|
|
发表于 2011-9-26 17:36:00
发表于 2011-9-26 20:24:00
