达宇逐鹿七雄游戏软件设计说明书文档格式.docx
《达宇逐鹿七雄游戏软件设计说明书文档格式.docx》由会员分享，可在线阅读，更多相关《达宇逐鹿七雄游戏软件设计说明书文档格式.docx（24页珍藏版）》请在冰豆网上搜索。
需求的调查、分析、定义管理等过程中会产生很多错误，出错误时可以被检查出来的。
需求定义必须满足以下几个方面的要求：
（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。
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项。
然后反馈验证结果，如果是成功的，那么附带用户信息，以及礼物信息。
否则提示用户登录失败。
（如图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中相应的数据。
（如图3.6）
图3.6用户丢弃物品操作流程图
（6）GC已经在某个HS里，用户点击确定按钮确认当前的道具、装备或者角色在船上的配置，HS请求DS进行确认操作。
（如图3.7）
图3.7用户确认物品操作流程图
（7）GC已经在某个HS里，用户点击购买结算，HS请求DS进行结算操作。
（如图3.8）
图3.8用户购买结算操作流程图
（8）GC已经在某个HS里，用户要赠送礼物，HS请求DS进行赠送操作。
（如图3.9）
图3.9用户赠送礼物操作流程图
（9）GC已经在某个HS里，用户在收到礼物界面中，确认接收礼物时，HS请求DS进行接收操作。
（如图3.10）
图3.10用户接收礼物操作流程图
（10）GC已经在某个HS里，用户在收到礼物界面中，确定丢弃礼物是，HS请求DS进行丢弃礼物操作。
（如图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标准的产品和服务后，无需花费力气做大量的市场推广，只要提供的服务或应用出色易用，其他站
升级会员 