达宇逐鹿七雄游戏软件设计说明书.docx
《达宇逐鹿七雄游戏软件设计说明书.docx》由会员分享，可在线阅读，更多相关《达宇逐鹿七雄游戏软件设计说明书.docx（24页珍藏版）》请在冰豆网上搜索。
达宇逐鹿七雄游戏软件设计说明书
绪论
现如今人们已经离不开网络了。
网络游戏已经成为人们休闲生活的主要方式之一。
网络游戏主要通过网络平台进行交流互动，无论是哪种网络平台，一般都是有服务器，数据库和无数的客户端组成的。
一般的网络游戏都是采用这几种方式运行：
（1）有一个或多个游戏服务器启动特定游戏服务。
（2）游戏用户去游戏网站申请游戏账号ID，并下载游戏客户端。
然后启动客户端程序，通过网络洗衣连接游戏服务器。
（3）客户端程序负责处理客户端显示和操作界面，具有简单的逻辑处理功能，同时负责接收、发送与服务端交互的数据包。
（4）服务器程序负责处理服务器端逻辑，游戏逻辑，游戏用户之间的网络信息传递，以及数据库之间的数据读取和保存工作，同时服务端还要承担游戏用户的客户端数据的接收转发工作。
（5）网络游戏常常用到网络协议，有适用与Internet的TCP/IP协议，适用于局域网的IP协议。
在开发网络游戏时，首先要建立底层的网络通信类，利用网络通信类连接构建客户服务器之间的TCP/IP连接，然后在该链接的基础上利用自己的TCP/IP协议进行客户端登陆，进入大区，开始游戏，换游戏大区，和其他玩家互动等的操作，在以上协议基础同时在服务器端还需要和数据交互，用于读取或保存玩家信息（如玩家密码、个人资料等数据）。
在网络游戏中数据库主要用来保存玩家资料，包括玩家的注册信息，玩家的游戏资料以及其他设置资料【1】。
网络游戏的服务端在处理大量的玩家资料时，必然要用到数据库来进行大量的数据信息的存储和查询，服务器数据库中存储着玩家的注册信息，游戏设置信息等重要信息数据，通过网络游戏的架构也可以了解到网络游戏服务器。
数据库连接着多个游戏客户端进行玩家数据的查询和修改，并且保持玩家数据的同步。
在玩家注册游戏账户，登录服务器，保存游戏结果，退出游戏服务器都必须和数据库服务器进行交互，查询和保存玩家资料，当有大量玩家同时游戏时，所以必须保证数据库服务器的性能，以免造成数据处理缓慢，导致游戏服务器停止响应的后果。
现在的网络游戏，数据越来越多，越来越复杂。
合理地组织这些数据，并为服务器提供便于操作的接口，从而实现快速的数据访问是一个非常重要的工作。
数据库技术为开发人员提供了一个良好的平台。
第一章系统需求分析
1.1需求概述
需求是每个系统必须符合的条件或具备的功能。
需求是人们的期望，探索需求是人们的期望的过程。
开发就是把人们的期望转化成一种能够满足其期望的产品的过程。
需求是指用户要求软件系统必须满足的所有功能和限制。
需求包括：
功能要求、性能要求、安全保密性要求、以及开发费用和开发周期、可使用资源等方面的限制。
其中功能需求是最基本的，包括数据要求和加工的要求。
需求分析是系统开发的一个重要步骤，是整个系统开发的基础。
如果需求定义错误（例如需求不完全、不合乎逻辑、不贴切或使人易于发生误解），那么不论以后各步的工作质量如何，都必然导致系统开发的失败。
因此，系统开发中需求定义是系统成功的关键一步，必须引起足够的重视，并且提供保障需求定义质量的技术手段。
需求的意义有在软件生命周期中，错误发现的越晚，修复错误的费用越高，许多错误是潜伏的，并且在错误产生后很长一段时间后才被检查出来。
TRW公司的一项调查表明：
54%的错误时在编码和单元测试阶段以后发现的，但实际上，这些错误的一半是属于需求和设计阶段的，而编码阶段的错误只有9%；需求的调查、分析、定义管理等过程中会产生很多错误，出错误时可以被检查出来的。
需求定义必须满足以下几个方面的要求：
（1）一致性。
由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。
避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
（2）可理解性。
参加的各方应能以一种共同的的方式来解释和理解需求。
（3）完备性。
所有需求都必须加以适当说明。
（4）可行性。
利用现有资源可以实现系统的需求。
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
（5）必要性。
所规定的需求必须是用户所需求。
（6）正确性。
需求应是准确和完整的。
每一项需求都必须准确的陈述其要开发的功能。
（7）可跟踪性。
每一项需求都应该把客户真正所需要的和最终系统所需遵从的标准记录下来。
（8）可测试性。
需求必须能够验证。
（9）划分优先级。
给每项需求、特性或使用实例分配一个事实优先级以指明它在特定产品中所占的分量【2】。
1.2数据库系统需求
目前的主要任务是：
调查和分析用户们的活动情况和数据的使用情况，明白所有数据的类型，范围，数据量和用户们的使用和交流的情况。
确定用户们对数据库系统的使用要求规则和需求。
游戏服务器数据库系统主要是完成登录游戏服务器，游戏大区服务器，游戏服务器，数据库服务器与数据库之间的交互。
其主要分为两大部分，分别是登录服务器与数据库的交互，大区服务器与数据库的交互。
系统需求大致可叙述为：
（1）用户通过游戏客户端软件登录游戏服务器，服务器通过传递过来的用户名、密码到数据库中心验证，如果验证通过即可登录游戏，否则提示用户密码错误。
（2）通过验证后，从数据库中读取出用户的个人资料如用户名、同时读取用户的游戏资料如积分、等级、金钱等参数。
（3）用户选择游戏大区进行游戏。
在大区里的游戏大区中可以进行物品的查收、装备的配置等的操作。
操作完成后，程序调用数据接口保存用户相应的操作信息。
（4）在用户结束一个游戏后，用户的游戏信息会发生改变。
程序调用数据库接口保存用户游戏信息，如等级变化，金钱变化等资料【3】。
功能特点：
角色信息：
显示您当前角色的等级，经验值，体力，行动力等状态；
活动功能：
显示您可参加的游戏活动和领取的奖励等；
辅助功能和位置坐标：
您的邮件和游戏资料等，以及您的城市坐标；
任务指引：
您当前的任务信息；
系统功能：
系统功能按钮，不同的按钮对应不同的功能；
个人信息：
您的资源和人口的储备情况；
聊天窗：
您当前的聊天内容窗口，可切换不同的频道；
技术特点：
1、全面支持材质LoD（细节层次，mipmapping）技术
2、优化的二进制模型文件格式，同时支持手动和自动LoD生成
3、同时拥有多种从商业或者开源3D模型软件导出到Ogre模型格式和动画格式的插件，其中包括官方以及用户提供的版本。
第二章系统设计
2.1MySQL概述
MySql是一个小型关系型数据库管理系统，Sql是英文AtructuredQueryLanguage的缩写，意思是结构化查询语言。
Sql语言的主要功能是对各种数据库进行管理。
而MySql是一个真正的多用户、多线程的Sql数据库服务器，可以利用Sql语句对其执行很多操作，例如创建数据库、数据库表、操作数据等。
MySql建立在客户服务器结构上的RDBMS，专门为了增强速度和稳定性而设计。
现在有超过400万的网站建立、使用并配置了基于MySql的应用程序，而且网站的数量每天都在增加。
他之所以能快速增长的原因，是相对于像Oracle和MicrosoftSQLServer一样的更商业化、非开放源代码的系统来说，更遵守现有的Sql标准、友好的商业许可原则，都是促成MySql成为可实施的选择因素。
MySql拥有较低的成本和更稳定、更安全的系统特性，使越来越多的企业把他们的系统移植到MySql，并且收获着MySql开放源代码带来的效益。
MySql始终围绕三个基本原则设计的。
分别为性能、可靠性和容易使用。
严格按照这些准则产生了一个价格便宜而富有特色。
适应标准而容易扩展、速度快而效率高的RDBMS，使MySql成为开发者和管理者建立、维护和配置复杂应用程序的完美工具。
现在MySql的主要应用程序出现在网络舞台上，随着网站以及基于Web对分布式应用程序变得越来越复杂，有效管理数据来改善处理率、降低相应和提高用户的全面技能就变得越来越重要了。
因此我们急需一个快速度的，稳定相高和安全的数据库【4】。
2.2数据库设计概念
正确的决策需原要正确的信息，正确的信息源自原始事实—即数据存储于数据库时，才能最有效地管理它们。
数据库是从计算机文件系统演变过来的。
尽管文件系统数据管理已经在很大程度上过时了，但是理解这些文件系统的基本特性仍然很重要。
及时有用的信息需要准确的数据。
这样的数据必须正确地产生，而且必须易于访问和处理的格式适当的存储。
有效的数据管理通常需要计算机数据库的使用。
数据库时一种共享、集成的计算机结构，容纳以下数据的集合：
终端用户数据、借以集成并管理数据的元数据或关于数据的数据元数据提供对数据特性以及连接数据库内数据的关系集合的描述。
在某种意义上，数据库类似组织得非常有条理的电子文件柜，其中被称为数据库管理系统的一种强大软件帮助管理文件柜的内容。
DBMS是程序的集合，这些程序管理数据库结构，并控制对数据库中所存储数据的访问。
DBMS使多个应用程序或用户共用数据库中的数据成为可能。
DBMS支持许多不同的数据库类型。
数据库可以根据用户数量、数据库站点的位置以及预期的使用类型和范围来分类。
概念设计阶段本质上是分析和发现的过程，目标是定义组织机构和用户对系统的数据需求。
【5】要注意的是，将设计作为一个整体来看的话，概念设计阶段（以及后面的所有阶段）除了需要进行数据库设计之外，还要根据需求分析做出如下的表：
Account用户信息：
用于储存玩家账号信息。
玩家注册账号时产生的信息，当玩家结束游戏任务要退出游戏时，玩家可在相应的界面看到自己的这些信息。
该表属性：
Accountid：
玩家注册的账号Id
Username：
玩家的用户名
Password：
玩家用户密码
Experience：
玩家用户经验
Money：
玩家用户的金钱
Level：
玩家用户等级
Thing：
存储用户道具信息，玩家用户买入和接收道具以及对道具进行各种操作时，这些数据将会有更新，玩家用户可以在游戏的相应界面看到这些信息。
该表属性：
Thingid：
玩家的物品Id
Account：
玩家的物品所属玩家Id
Thingtype：
玩家物品类型
Bbind：
玩家物品是否被绑定是否可交易
Activetime：
玩家物品的有效时间
Accessid：
玩家物品在本地脚本数据库表的Id’
Hsgcvrifycode：
临时存储玩家用户登录的验证信息，用户登录时就会产生这些信息，用于用户进入游戏使用。
玩家退出游戏后产生的这些信息将被删除。
该表的属性：
HsgcverifyGodeId：
登录验证Id
AccontId：
登录用户Id
VerifyCode：
验证码
Gift：
储存玩家礼物信息。
用户赠送礼物事，会产生相应信息，被赠送玩家会在相应的游戏界面看到这些信息。
该表属性：
GigetId：
礼物的Id
AccountId：
接收礼物用户的Id
ThingType：
礼物类型
Benefactor：
送礼物的用户
DescText：
礼物附带的描述
以上表都是在游戏过程中与用户交互时生成的。
此外，还有本地脚本数据库中的表（后缀为Access代表为本地数据库里的表），但这些表不在设计范围中，故不做详述。
它们包括：
CityAccess：
存储游戏中城池的信息
城池的资源
城池的等级
城池的繁荣度
RoleAccess：
存储游戏中角色的信息
GunAccess：
存储游戏中装备的信息
ItemAccess：
存储游戏中物品的信息
EmplaceAccess：
存储城池位置信息
后缀为Access代表为本地数据库里的表。
2.3数据库逻辑设计
逻辑阶段是对概念阶段完成的工作进行细化。
本阶段的成果将是关系数据库设计图，并且从本质上看设计图应该是完整的。
要注意的是，一个好的逻辑设计能够建立在任何的RDBMS上。
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。
与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。
这一步设计的结果就是所谓“逻辑数据库【6】。
在数据库概念设计完成之后，我们可进行数据库逻辑设计
（1）创建数据库Ocean
在MySqlCommandLineClient中执行以下命令
CREATEDATABASEOcean；
执行完毕后，数据库Ocean创建成功。
（2）然后连接数据库Ocean。
在MySqlCommandLineClient中执行
USEOcean；
执行完毕后，提示数据库连接成功。
（3）在数据库Ocean中创建表Account。
在MysqlCommandLineClient中执行如下的命令；
CREATETABLE’account’（
‘AccountID’int（10）unsigenednotnullauto_increment,
‘Username’varchar（45）charactersetlatin1notnull,
‘Password’varchar（45）charactersetlatin1notnull,
Experience’int（10）unsignednotnull,
‘Money’int（10）unsignednotnull,
‘Level’int（10）unsignednotnull,
‘CurshipAccessId’int（10）unsignednotnull,
PRIMARYKEY（‘AccountId’）
）ENGINE=InnodbAUTO_INCREMENT=16DEFAULTCHARSET=utf8;
执行完毕后，表Account创建成功。
（4）在数据库Ocean中创建表Gift
在MySQLCommandLineClient中执行如下命令：
CREATETABLE‘gift’（
‘GiftId’int（10）unsignednotnull,
‘AccountId’int（10）unsignednotnull,
‘ThingType’int（10）unsignednotnull,
‘AccessId’int（10）unsignednotnull,
‘Benefator’varchar（45）notnull,
‘DescText’varchar（45）notnull,
PRIMARYKEY（‘GiftId’）
）ENGINE=InnoDBAUTO_INCREMENT=11DEFAULTCHARSET=utf8；
执行完毕后，表Gift创建成功。
（5）在数据库Ocean创建表Hsgcverifycode.
在MySQLCommandLineClinet中执行如下命令：
CREATTABLE‘hsgcverifycode’（
‘HSGCVerifyCodeId’int（10）unsignednotnullauto_increment,
‘AccountId’int（10）unsigenednotnull,
‘VerifyCode’int（10）unsignednotnull,
PRIMARYKEY（‘HSGCVerifyCodeId’）
）
ENGINE=InnoDBAUTO_INCREMENT=8DEFAULTCHARSET=latin1；
执行完毕后，表Hsgcverifycod创建成功。
（6）创建表Thing。
在MySQLCommandLineClient中执行如下命令：
CREATETABLE‘Thing’（
‘ThingId’int（10）unsignednotnullauto_increment,
‘AccountId’int（10）unsignednotnull,
‘ThingType’int（10）unsignednotnull,
‘bBind’int（10）unsignednotnull.
‘bInstalled’int（10）unsignednotnull,
‘ActiveTime’int（10）unsignednotnull,
‘AccessId’int（10）unsignednotnull,
‘CityAccessId’int（10）unsignednotnull,
‘EmplaceIndex’int（10）unsignednotnull,
PRIMARYKEY（‘ThingId’）
）ENGINE=InnoDBAUTO_INCREMENT=67DEFAULTCHARSET=latin1；
执行完毕后，表Thing创建成功。
第三章系统难点技术分析与设计
3.1系统架构设计与分析
根据分析，设计出系统架构图，如图3.1所示。
图3.1系统架构图
从图可以看出系统各个部分的工作情况以及数据的交互情况。
可从两个部分来分析：
（1）登录服务器与数据库服务器的交互。
用户玩家由登录客户端登录服务器时，登录服务器请求数据库服务器执行登录验证操作，数据库服务器在对数据库进行查询操作，并返回查询结果。
（2）大区服务器与数据库服务器的交互。
①用户由客户端登录大区服务器时，大区服务器请求数据库服务器执行登录验证操作，数据库服务器再对数据库进行查询操作，并返回操作后的结果。
②用户更换大区时，大区的服务器请求数据库服务器执行更换大区的操作，数据库服务器在对数据库进行相应的操作，并返回操作后的结果。
③玩家对物品进行查询、配置、升级、丢弃、卖出、买入时，大区服务器请求数据库服务器执行相应操作，数据库服务器在对数据进行相应的操作并返回操作后的结果。
④一场战争结束后，游戏服务器将游戏过程中各种信息的变化传给大区服务器，大区服务器请求数据库服务器执行数据更新操作，数据库服务器再对数据库进行更新操作，并返回更新后的结果。
⑤玩家退出游戏时，大区服务器请求数据库执行退出操作，数据库服务器在对数据库进行相应的删除数据操作。
其中值得注意的一点：
游戏服务器没有直接与数据库服务器进行交互，而是通过大区的服务器与数据库服务器进行数据的传递。
之所以是这样，主要是因为像这中网络对战游戏不需要在游戏过程中实时更新数据，可以通过大区服务器，在一场战争结束游戏后，在进行游戏数据的更新。
下面结合系统需求，对架构图进行详细的分析：
如表3-1术语所示
表3-1术语
缩写
全写
定义
LC
LoginClient
登陆器客户端
LS
LoginServer
登录服务器
GC
GameClient
游戏客户端
HS
HallServer
大区服务器
DS
DBServer
数据库处理服务器
GS
GameServer
游戏服务器
DB
DataBase
数据库
（1）LC登陆LS时，LS请求DS进行验证，验证内容为用户名和密码2项。
DS在DB中查询是否有匹配信息。
如果验证成功，则数据库中产生一个HSGC验证码，并然后反馈验证结果。
否则提示用户登陆失败。
（如图3.2）
图3.2LC登录LS流程图
（2）GC登陆HS时，HS请求DS进行验证，验证内容为用户名和密码、HSGC验证码3项。
DS在DB中查询是否有匹配信息。
然后反馈验证结果，如果是成功的，那么附带用户信息，以及礼物信息。
否则提示用户登录失败。
（如图3.3）
图3.3GC登录HS流程图
（3）GC已经在某个HS里，用户进行更换HS的操作时，HS请求DS进行更换大区操作，DS操作DB产生一个新HSGC验证码，然后返回新的HSGC验证码给HS。
并进行更换大区操作。
（如图3.4）
图3.4用户更换大区流程图
（4）GC已经在某个HS里，用户进行配置时需要激活道具、装备和角色，HS请求DS进行激活操作。
DS操作DB，更改DB中相应数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.5）
图3.5用户激活操作流程图
（5）GC已经在某个HS里，用户点击丢弃按钮丢弃一个道具、装备或者角色，HS请求DS进行丢弃操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.6）
图3.6用户丢弃物品操作流程图
（6）GC已经在某个HS里，用户点击确定按钮确认当前的道具、装备或者角色在船上的配置，HS请求DS进行确认操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.7）
图3.7用户确认物品操作流程图
（7）GC已经在某个HS里，用户点击购买结算，HS请求DS进行结算操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.8）
图3.8用户购买结算操作流程图
（8）GC已经在某个HS里，用户要赠送礼物，HS请求DS进行赠送操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.9）
图3.9用户赠送礼物操作流程图
（9）GC已经在某个HS里，用户在收到礼物界面中，确认接收礼物时，HS请求DS进行接收操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.10）
图3.10用户接收礼物操作流程图
（10）GC已经在某个HS里，用户在收到礼物界面中，确定丢弃礼物是，HS请求DS进行丢弃礼物操作。
DS对DB进行操作，更改DB中相应的数据。
操作完成后，传回更新后的数据给HS，并提示操作成功。
（如图3.11）
图3.11用户丢弃礼物操作流程图
（11）GC已经在某个HS里，用户查询礼物信息时，HS请求DS进行查询礼物信息操作。
DS对DB进行查询，查询完成后，将查询到的数据返回给HS。
（如图3.12）
图3.12用户查询礼物操作流程图
（12）用户一局游戏结束后，用户的各种游戏信息会得到更新，GS将这些数据传给HS，HS请求DS进行数据更新操作并将数据传给DS。
DS对DB进行相应的数据更新操作，操作完成后，将更新后的数据传回HS。
（如图3.13）
图3.13游戏结束后数据更新流程图
（13）GC已经在某个HS里，用户退出游戏时，HS请求DS进行退出操作，DS删除DB中相应的HSGC验证码信息。
（如图3.14）
图3.14用户退出游戏操作流程图
3.2将MySQLCAPI封装成易于使用的数据库接口
3.2.1MySQLCAPI概述
基于互联网的应用正变得越来越普及，在这个过程中，有更多的站点将自身的资源开放给开发者来调用。
对外提供的API调用使得站点之间的内容关联性更强，同时这些开放的平台也为用户、开发者和中小网站带来了更大的价值。
开放是目前的发展趋势，越来越多的产品走向开放。
目前的网站不能靠限制用户离开来留住用户，开放的架构反而更增加了用户的粘性。
在Web2.0的浪潮到来之前，开放的API甚至源代码主要体现在桌面应用上，而现在越来越多的Web应用面向开发者开放了。
具备分享、标准、去中心化、开放、模块化的Web2.0站点，在为使用者带来价值的同时，更希望通过开放的API来让站点提供的服务拥有更大的用户群和服务访问数量。
站点在推出基于开放API标准的产品和服务后，无需花费力气做大量的市场推广，只要提供的服务或应用出色易用，其他站
升级会员 