非常感谢大家对上
篇文章
支持
在大家支持下我决定推出浅谈网络游戏开发(2)这篇文章
首先
再次强调下网络游戏开发极为困难技术含量相当高其编程知识涉及网络编程操作系统进程、线程编程图形图像编程(DirectX / OpenGL)WIN32 API编程(Windows下开发)以及各种算法和数据结构同时对设计人员策划能力要求也颇高如不能构思出个吸引玩家游戏世界也必将导致开发失败目前
国内网络游戏市场被韩国游戏霸占情形让人心寒在国内网络游戏编程资源奇缺环境下我希望把自己些经验和想法说出来供大家参考起个抛砖引玉作用对于我在浅(1)中提出
架构如果大家有更好修改建议欢迎大家共同探讨修改把我国网络游戏开发水品提高到世界级标准最起码也要在国内市场是立足！好了
费话就不多说了正文开始在浅(1)中
有关游戏世界管理模块和通讯模块我没有详细介绍说明本篇中将补充介绍游戏世界管理模块:
本模块专门管理游戏世界里
数据模型也就意味着所有游戏里对象基本上都由他来管理所以此模块极为复杂甚至在大型系统里也可以把它再划分成很多子模块来协同工作这个模块该如何封装呢？首先
自然是需要个消息处理类
游戏世界管理模块同样是需要消息驱动此模块每收到个消息后就察看消息类型看是转发类型还是管理类型消息如果是转发类型就将消息转发给消息目地模块如果是管理类型消息就察看管理目标以及管理思路方法然后执行管理思路方法因此我们还需要就是个辨别消息思路方法以及些数据及操作数据思路方法游戏规则模块
本模块按照游戏策划者制定
规则来进行业务逻辑处理同样首先需要封装也是消息处理类然后就是辨别消息按照消息提示进行规则处理随后就是将处理结果封装成消息发给管理模块基本上和游戏世界管理模块模式相同以上谈了两个模块
封装思想但是实际上这两个模块是不可能像上面写得那样运用很多朋友也谈到这个构架并不适合作大型网络游戏那么真正大型网络究竟是怎样架构呢？就像我们
OSI模型和TCP/IP模型样只有后者能真正运用在工业标准中前者固然是好但是他封装得太细了太过于复杂了不适合现在情况使用在真正网络游戏中以上两个模块是合在起！我把它们统称为游戏世界模块请大家注意看下面这个模型(发了几次图片都失败了所以用文本弄了个请谅解)从上图可以看出
实际上游戏规则模块和游戏管理模块被合并在起了也就是说这两个模块的间不需要消息传递他们只是简单
关系![](\"http://www.gamego.cn/upload/article/a2005102922102933.g<img)
\" width=504 border=0>规则判定要做
主要工作就是辨别消息把我们消息翻译成对对象处理方式我们
游戏世界是有很多对象构成个对象同时也可以携带多个对象对象也可以不断增加、扩充每当我们添加或扩充个新对象我们可以把它
进来再在规则模块里加入对他思路方法这里要介绍说明
点就是其实所有对象都是无差别大家都是数据模型不管你是个人还是棵树或者种道具甚至魔法他们都只是些属性而已这些属性统统都存在我们配置文件中甚至可以存在数据库中到时候创建对象时候把属性带入就可以了当然有关游戏世界对象想法有很多好提议我甚至想过可以不要对象思路方法只要它属性反正我们只是改变对象属性而已而把如何改变这些属性按定格式写在文件或数据库中比如inc XX 0.3表示XX属性+30%的类这样就可以很方便改变规则和对象下面
我针对大家问题提出些看法:首先
可能大家会有疑问这样系统架构似乎很慢啊如何维持那么多玩家在线呢？如果有那么多对象要处理话如何可能保持速度？1． 服务器不是大家用
PC机只要你能用下服务器和PC机你就知道他们区别了用unix开发也是为了确保游戏能在小型机的类服务器上运行2． 很多人认为网络游戏应该支持数十万人
玩家同时在线比如说传奇联众他们确实是30-40万人在线哪！实际上大家看仔细了每台服务器到底是多少人有服务器才6XX人就说满了这就是网络游戏真实情况3． UDP和TCP
争议问题有朋友可能认为应该用udp就它快其实这个问题没什么好争我们ftp为什么不用udp呢？如果用udp我们就得自己封装套tcp确认机制出来4． 对于同步问题
般来说客户端确实就是有什么发什么但是要控制发送间隔时间这也是为了防止变速齿轮和解决同步问题比如客户端旦发出移动命令后客户端自己首先判断是否在间隔时间内再判断是否能移动能移动了才发消息给服务器端同时开始移动如果服务器端发回消息移动成功那就成功否则屏幕上人物就会被拉回来连接池技术
很多朋友都比较关心
个问题就是:为每个连接分配个线程是否太浪费了！实际上apache大家都知道吧他为每个连接分配可是个进程呢！线程比进程开销要小得多如果用户数不是很多话那是没有问题但用户数不是很多要如何理解呢:linux6.2下测试每个进程最多能创建1000个线程左右(实际应该是1024)win2000 advance server sp3下测试每个进程最多能创建2000个线程左右(实际应该是2048)这下大家明白了吧不过
再如何说连接线程只是用在网络通讯上要支持更多用户话太不划算因此在这里就介绍下连接池技术所谓连接池
实际上是我们事先创建些线程每次通讯模块要发消息时就找个空闲线程然后把要发消息给它让它去发送这样处理话创建很少线程就够用了这有点类似于apache进程预处理又更像jdbc数据库连接池这就要求封装个连接池控制类总的
如果要用连接池技术话就会使通讯模块复杂化但是它能大量节约系统资源建议大家设计时候可以让用户在配置时选择是否使用连接池技术这样根据区别系统就可以有区别配置方案 小节
这次探讨就到这里
不知这次又要引出多少反对意见不过我真很希望看到大家意见任何软件Software开发本身就是仁者见仁智者见智问题在这里没有绝对标准更没有绝对真理我们要是真正能实现思路方法希望大家在给出意见同时最好能给出好建议
最新评论