网络即时战略游戏软件开发结构体系分析.doc

网络即时战略游戏软件开发 结构体系分析 前言 本人对网络游戏的技术问题一直比较感兴趣，我认为网络游戏的开发在不远的将来是一个非常庞大的产业。这段时间有空，特地玩了几天网络游戏“破碎银行系”，并分析了一下其中体系结构，有些体会，结合自己多年的软件开发经验，就如何开发一个类似于“破碎银行系”的网络即时战略游戏撰文如下，希望能抛砖引玉，对从事游戏开发的人有所帮助。 网络游戏是我们的机会 单人游戏的开发国外厂商已经积累了丰富的技术基础，各种游戏模式已经基本定型，新款游戏只能在视、听觉的效果上大做文章，主要的竞争领域是3D技术和美工，在这些方面，我们要一下子赶上国外的技术水平还有一定难度。 而网络游戏，其吸引人的地方是多人的交互性和协作性，视听觉效果的作用已经退到次要的位置，例如“破碎银行系”，玩家所希望的是在上面打一场玩家紧密配合，最后成功战胜对方的“国战”，没人关注它是2D还是3D的。 网络游戏，需要引入新的技术，如数据库、通信和服务器端软件的开发，这些技术在国内其它领域（如金融和电信）已经得到相当成熟的应用，并不存在任何技术问题，加上2D游戏的开发，国内成功案例较多，因此，只要把国内的资源有效地组织起来，就能开发一个富有市场前景的网络游戏。 许多人会认为网络游戏的开发是一件技术难度非常高的工作，当然，游戏的开发，其它技术含量要比一个信息管理系统高，但并不是高不可攀，我更愿意用“开发网络游戏是一个系统工程”这样的观点形容网络游戏的开发。 本文的主要内容之一便是分析如何把一个功能复杂的网络即时战略游戏，划分为多个尽量孤立的子系统，并逐一分析每个子系统的技术特点和难点。 游戏功能模块分析 在“破碎银行系”中，可把它的功能划分为以下几类： 交流或作战状态的地图漫游； 属性设定； 聊天； 在地图漫游功能，又分为以下几类： 交流状态，多人在线的地图漫游； 战斗状态，多人在线，人与人之间的战斗，如“国战”、“竞技场”等； 战斗状态，多人在线，人与计算机之间的战斗，如“异形战争”； 战斗状态，单人游戏，人与计算机之间的战斗，如“训练场”； 每个多人在线的地图，都需要一台服务器管理，我们把台服务器称之为地图服务器。 在“破碎银行系”中，同一交流状态地图可以同时容纳128名在线用户，而战斗状态地图则可以同时容纳64名在线用户。 许多功能，如注册、登录、购买武器、修复武器、武器升级、武器物品装备、加入军团、选举领主、拜师和系统内信件等，其实都可以归入属性设定一类的功能，其实质很简单，都是查询或修改数据库中，关于玩家的某些记录。例如拜师，其实就是修改玩家属性数据库中，其上级的字段。 在Internet环境下，客户端（即玩家使用的PC，以下称为游戏端）不可能直接访问数据库服务器，必须通过联机交易这种方式实现。 联机交易首先在金融等行业得到应用，现在所有的核心金融应用系统，都基于联机交易，而且，联机交易已经广泛地应用于其它各个领域中。 联机交易是指客户端根据实际功能的需要，按照规定的格式填写一个数据结构（称之为交易请求报文），然后通过计算机通信发给交易服务器； 交易服务器收收交易请求报文后，执行相应的数据处理工作，多为数据库操作，并把处理结果按照规定的格式填写响应数据结构（称之为交易响应报文），然后发给客户端，通知客户端处理结果。 在游戏软件中，一个属性设定功能，就是一个联机交易，只不过是把操作界面图形化、游戏化而。 这里我们把交易服务器端称为属性服务器。 如果玩家经常使用系统内信件的功能，则有必要让系统内信件功能单独使用一台服务器。 聊天的实现与ICQ类似，也需要一台服务器（至少逻辑上），我把这台服务器称之聊天服务器。 有一种考虑，就是把聊天服务器合并在地图服务器上，这是因为聊天的对象一般都是同一个地图上的人，但某些情况例如，如领主和军团长可以通过“大喊”功能跨地图，把指令发布到整个星球，而上下级之间的聊天也可以跨地图。 因此，同一地图的聊天可在地图服务器中增加一个聊天模块处理，整个游戏分区还应设立一台专用的聊天服务器，处理跨地图的聊天功能。 服务器组织 毫无疑问，游戏端使用Windows平台，使用Wins32 API，服务器则最好使用Linux操作系统。 系统服务器分为两类，数据库服务器和通信数据报文处理服务器。 数据库服务器从稳定性、价格和性能出发，最好选择Oracle，版本不限。Oracle的稳定性和性能自不用多说，而其For Linux的版本，最低价格不到8000元（从分销商那出货），也是非常便宜的。 在“破碎银行系”中，一个游戏分区可以由多个星球，每个昨星球有多张地图，因此，其服务器组的结构可以是这样： 数据库 数据库 服务器 聊天服务器属性服务器 聊天服务器 属性服务器 星球三地图服务器组星球二地图服务器组星球一地图服务器组 星球三地