网络游戏服务器数据库的设计和实现毕业论文Word格式文档下载.docx
- 文档编号:21072642
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:31
- 大小:422.73KB
网络游戏服务器数据库的设计和实现毕业论文Word格式文档下载.docx
《网络游戏服务器数据库的设计和实现毕业论文Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《网络游戏服务器数据库的设计和实现毕业论文Word格式文档下载.docx(31页珍藏版)》请在冰豆网上搜索。
一般的网络游戏都是采用客户/服务器模式的体系结构(见图1.1),包括客户机程序、服务器程序、数据库服务器。
图1.1网络游戏体系结构
网络游戏都是采用如下的方式运行:
1有一个或多个游戏服务器启动特定游戏服务。
2游戏者到游戏网站下载客户端程序并且申请游戏账号ID。
然后启动客户端程序,通过网络协议连接游戏服务器。
3客户端程序负责处理客户端显示和操作界面,具有简单的逻辑处理功能,同时负责接收发送与服务器端交互的数据包。
4服务器程序负责处理服务器端逻辑、游戏逻辑、客户之间的网络信息传递,以及数据库之间的数据读取保存工作。
同时服务器端还要承担客户端数据的接受转发工作。
5网络游戏常常用到网络协议有适用于Internet的TCP/IP协议、适用于局域网的IPX协议。
网络游戏程序的开发一般采用MicrosoftVisualC++作为编译环境,分为客户端程序和服务器端程序。
客户端程序主要负责显示用户界面,为用户提供赏心悦目的操作界面,通过客户端与服务器之间的网络传递数据,实现了多人协同游戏的目的。
在开发网络游戏时,首先要建立底层的网络通信类,利用网络通信类连接构建客户服务器之间的TCP/IP连接,然后在该连接的基础上利用自己设定的协议进行客户端登录、进入大厅、开始游戏、换房间等操作。
在以上协议的基础上,同时在服务器端还需要和数据库服务器交互,用于读取或保存客户信息(如客户积分。
密码。
个人资料等数据)。
[1]
6本项目就是对网络游戏数据库系统的设计。
网络游戏的服务器端在处理大量的客户资料时,必然要使用数据库进行大量数据的永久存储,所以在网络游戏的开发中数据库的设计也是很重要的环节。
1.2课题研究意义
网络游戏的服务器端在处理大量的客户资料时,必然要使用数据库进行大量数据的存储和查询,服务器在数据库中保存客户注册信息、客户积分信息、客户设置信息等信息。
同时因为游戏服务器一般采用多服务器,所以多台游戏服务器同时连接一台数据库服务器,进行客户数据的查询和修改,并且保持客户数据的同步。
在客户注册用户、登录服务器、保存游戏结果、退出游戏时游戏服务器都必须和数据库服务器进行交互,查询和保存客户资料;
当同时有大量用户同时游戏时,所以必须保证数据库服务器的性能,以免造成数据库处理缓慢导致游戏服务器停止响应的后果。
现在的网络游戏,数据越来越多,越来越复杂。
合理地组织这些数据,并为服务器提供便于操作的接口,从而实现快速的数据访问是一个非常重要的工作。
数据库技术为开发人员提供了一个良好的平台。
至今,数据库设计的很多工作仍需要人工来做,除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外,尚缺乏一套完善的数据库设计理论、方法和工具,以实现数据库设计的自动化或交互式的半自动化设计。
所以数据库设计今后的研究发展方向是研究数据库设计理论,寻求能够更有效地表达语义关系的数据模型,为各阶段的设计提供自动或半自动的设计工具和集成化的开发环境,使数据库的设计更加工程化、更加规范化和更加方便易行,使得在数据库的设计中充分体现软件工程的先进思想和方法。
本项目使用的是基于MySQL创建的数据库,还使用了MySQL提供的一个C语言的API,使用该API的功能进行连接管理、实施查询、处理结果集等内容。
为服务器提供操作数据库的函数接口。
通过该课题的研究,能使我了解MySQL相关知识,加深对数据库相关知识的认识,掌握了网游服务器数据库的开发流程与方法。
锻炼并提升自己的能力,丰富自己的专业知识。
为以后就业打下良好基础。
2系统需求分析
2.1需求概述
在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围和定义时所要做的所有的工作。
需求分析是软件工程中的一个关键过程。
在这个过程中,系统分析员和软件工程师确定顾客的需要。
只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
需求分析主要是解决软件产品应该达到的各项功能和非功能要求,即用户要求做什么。
软件需求分析工作是软件开发与用户紧密配合。
充分交换意见,系统在广大的相关人群中谋取平衡与折衷,最终达到相互谅解的过程。
需求分析是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程。
它实际上是一个对用户意图不断进行揭示和判断的过程,其目的在于细化、精华软件的作用范围,确定拟开发软件的功能和性能、约束、环境。
需求分析工作是软件生存期中重要的一步,也是决定性的一步。
软件需求分析工作是一个不断认识和逐步细化的过程。
该过程将软件计划阶段所确定的软件范围(工作域)逐步细化到可详细定义的程度,并分析各种不同的软件元素,然后为这些元素找到可行的解决方法。
[4]
2.2数据库系统需求
本阶段主要任务就是:
调查和分析用户的业务活动和数据的使用情况,弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况,确定用户对数据库系统的使用要求和各种约束条件等,形成用户需求规约。
数据库系统主要完成登录服务器,大厅服务器,游戏服务器,数据库服务器与数据库之间的交互。
其主要分为两大块:
登录服务器与数据库的交互,大厅服务器与数据库的交互。
系统需求大致可叙述为:
1用户通过游戏客户端软件登陆游戏服务器,服务器通过传递过来的用户、密码到数据库中验证,如果验证通过即可登录游戏,否则提示用户、密码错误。
2通过验证后,从数据库中读取出用户的个人资料如账号名,同时读取用户的游戏资料如积分、等级、金钱等参数。
3用户选择游戏大厅进行游戏。
在大厅可进行查收礼物、购买物品、配置自己物品等操作。
操作完成后,程序调用数据库接口保存用户相应信息。
4在用户一局游戏结束后,用户的游戏信息会改变。
程序调用数据库接口保存用户游戏信息,如胜率变化、积分等资料。
3系统设计
3.1MySQL概述
MySQL是一个高性能、多线程、多用户、建立在客户-服务器结构上的RDBMS(RelationalDataBaseManagrmentSysten),专门为了速度和稳定性而设计。
在过去的几年中,它已经成为线上和线下适合于数据库驱动的应用程序最受欢迎的RDBMS之一。
现今,有超过400万的网站建立、使用并且配置了基于MySQL的应用程序,而且网站的数量每天都在增加。
它得到了像Sony,Xerox,HP(HeweltPackard)和NASA(NationalAeronauticsandSpaceAdministration)这样的公司或组织的积极使用。
简而言之,它无处不在,它的应用将会变得更广泛。
我们不难发现这样急速增长的原因。
相对于像Oracle和MicrosoftSQLServer一样的更商业化、非开放源代码的系统来说,快速、健壮和友好的数据库引擎、高级的数据管理和恢复工具、不断改进的特性合集、遵守现有的SQL标准、友好的商业许可原则,都是促成MySQL成为可实施的选择因素。
MySQL的较低总体拥有成本和更稳定、更安全的系统特性,使越来越多的企业吧它们的系统移植到MySQL,并且收获着MySQL开放源代码带来的效益。
MySQL始终围绕三个基本原则而设计,它们是:
性能、可靠性和容易使用。
严格按照这些准则产生了一个价格便宜而富有特色、适应标准而容易扩展、速度快而效率高的RDBMS,使MySQL成为开发者和管理者建立、维护和配置复杂应用程序的完美工具。
今天,MySQL的主要应用程序出现在网络舞台上,这并不令人吃惊。
随着网站以及基于Web对分布式应用程序变得越来越复杂,有效管理数据来改善处理效率、降低响应时间和提高用户的全面技能就变得越来越重要了。
因此,我们迫切需要一个速度快、性能稳定和安全的数据库(可以非常省心地配置和使用它,并且为将来的发展奠定坚实的基础)。
很多原因让MySQL正合需要。
经过证实的记录让它的可靠性和寿命得到保证,开放源代码的根本能够确保迅速调整缺陷和性能持续增强大周期(更不必提及较低的总体拥有成本);
对不同编程语言和技术的可移植性和支持,使它适合多种应用程序。
[2]
基于MySQL的以上优点,我们选择MySQL做为该网络游戏的数据库管理系统。
3.2数据库概念设计
概念设计:
对用户要求描述的现实世界(可能是一个工厂、一个商场或者一
个学校等),通过对其中住处的分类、聚集和概括,建立抽象的概念数据模型。
这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
所建立的模型应避开数据库在计算机上的具体实现细节,用一种抽象的形式表示出来。
以扩充的实体—(E-R模型)联系模型方法为例,第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等,从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。
第二步再将前面得到的多个用户的局部视图集成为一个全局视图,即用户要描述的现实世界的概念数据模型。
[6]
根据需求,我们可设计出如下的表:
1Account:
存储用户账号信息(如图3.1)。
用户注册账号时产生这些信息,每局游戏结束后将更新相应信息。
用户可在游戏大厅中相应界面看到这些信息。
图3.1表Account属性
1)AccountId:
用户账号id;
2)UserName:
用户名字;
3)Password:
用户密码;
4)Experience:
用户经验;
5)Money:
用户金钱;
6)Level:
用户等级;
7)CurShipAccessId:
用户当前战舰id。
2Thing:
存储用户道具信息(如图3.2)。
用户买入、接收道具以及对道具进行各种操作时,这些数据将更新。
图3.2表Thing属性
1)ThingId:
用户物品id;
2)AccountId:
用户物品所属用户id;
3)ThingType:
用户物品类型;
4)bBind:
用户物品是否绑定;
5)bInstalled:
用户物品是否激活;
6)ActiveTime:
用户物品有效时间;
7)AccessId:
用户物品在本地角本数据库表中的id;
8)ShipAccessId:
用户战舰在本地脚本数据库表中的id。
3HSGCVerifyCode:
临时存储用户登陆验证信息(如图3.3)。
用户登录时产生这些信息,用于用户进入、更换大厅时使用,用户退出游戏后,产生的这些信息将被删除。
图3.3表HSGCVerifyCode属性
1)HSGCVerifyCodeId:
登录验证Id;
登录用户的Id;
3)VerifyCode:
验证码。
4Gift:
存储用户礼物信息(如图3.4)。
用户赠送礼物时,会产生相应信息,被赠送用户会在相应界面看到这些信息。
图3.4表Gift属性
1)GiftId:
礼物的id;
接收礼物用户的id;
礼物类型;
4)Benefactor:
送礼物的用户;
5)DescText:
礼物附带的描述
以上表都是在游戏过程中与用户交互时生成的
此外,还有本地脚本数据库中的表(后缀为Access代表为本地数据库里的表),但这些表不在设计范围中,故不做详述。
它们包括:
5ShipAccess:
存储游戏中战舰的信息(如图3.5)。
图3.5表ShipAccess属性
6RoleAccess:
存储游戏中角色的信息(如图3.6)。
图3.6表RoleAccess属性
7GunAccess:
存储游戏中战舰上武器的信息(如图3.7)。
图3.7表GunAccess属性
8ItemAccess:
存储游戏中物品的信息(如图3.8)。
图3.8表ItemAccess属性
9EmplaceAccess:
存储战舰位置信息(如图3.9)。
图3.9表EmplaceAccess属性
后缀为Access代表为本地数据库里的表
以上表的实体关系(如图3.10):
图3.10实体关系图
3.3数据库逻辑设计
逻辑设计:
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式,即适应于某种特定数据库管理系统所支持的逻辑数据模式。
与此同时,可能还需为各种数据处理应用领域产生相应的逻辑子模式。
这一步设计的结果就是所谓“逻辑数据库”。
在数据库概念设计完成之后,我们可进行数据库逻辑设计。
1创建数据库ocean。
在MySQLCommandLineClient中执行如下命令:
CREATEDATABASEocean;
执行完毕后,数据库ocean创建成功。
(如图3.11)
图3.11数据库ocean
2然后连接数据库ocean。
USEocean;
执行完毕后,提示数据库连接成功。
3在数据库ocean中创建表account。
CREATETABLE`account`(
`AccountId`int(10)unsignedNOTNULLauto_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;
Databaseonmysql
执行完毕后,表account创建成功。
(如图3.12)
图3.12表account
4在数据库ocean中创建表gift。
CREATETABLE`gift`(
`GiftId`int(10)unsignedNOTNULLauto_increment,
`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创建成功。
(如图3.13)
图3.13表gift
5在数据库ocean创建表hsgcverifycode。
CREATETABLE`hsgcverifycode`(
`HSGCVerifyCodeId`int(10)unsignedNOTNULLauto_increment,
`VerifyCode`int(10)unsignedNOTNULL,
PRIMARYKEY(`HSGCVerifyCodeId`)
)ENGINE=InnoDBAUTO_INCREMENT=8DEFAULTCHARSET=latin1;
执行完毕后,表hsgcverifycode创建成功。
(如图3.14)
图3.14表hsgcverifycode
6创建表thing。
CREATETABLE`thing`(
`ThingId`int(10)unsignedNOTNULLauto_increment,
`ThingType`int(10)unsignedNOTNULL,
`bBind`int(10)unsignedNOTNULL,
`bInstalled`int(10)unsignedNOTNULL,
`ActiveTime`int(10)unsignedNOTNULL,
`ShipAccessId`int(10)unsignedNOTNULL,
`EmplaceIndex`int(10)unsignedNOTNULL,
PRIMARYKEY(`ThingId`)
)ENGINE=InnoDBAUTO_INCREMENT=67DEFAULTCHARSET=latin1;
执行完毕后,表thing创建成功。
(如图3.15)
图3.15表thing
4系统难点技术分析与设计
4.1系统架构设计与分析
根据分析,我们设计出系统架构图。
(如图4.1)
图4.1系统架构图
从图我们可以看出系统各个部分的工作情况以及数据的交互情况。
可从两个部分来分析:
1登录服务器与数据库服务器的交互。
其中包括:
用户由登录器客户端登陆登录服务器时,登录服务器请求数据库服务器执行登陆验证操作,数据库服务器再对数据库进行查询操作,并返回查询结果。
2大厅服务器与数据库服务器的交互。
1)用户由游戏客户端登陆大厅服务器时,大厅服务器请求数据库服务器执行登陆验证操作,数据库服务器再对数据库进行查询操作,并返回查询结果。
2)用户更换大厅时,大厅服务器请求数据库服务器执行更换大厅操作,数据库服务器再对数据库进行相应操作,并返回操作后的结果。
3)用户对物品进行查询、配置、激活、丢弃、购买、赠送、接收时,大厅服务器请求数据库服务器执行相应操作,数据库服务器在对数据局进行相应的操作,并返回操作后的结果。
4)一局游戏结束后,游戏服务器将游戏过程中各种信息的变化传给大厅服务器,大厅服务器请求数据库服务器执行数据更新操作,数据库服务器再对数
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 网络游戏 服务器 数据库 设计 实现 毕业论文