TCG游戏中服务端的设计与实现——毕业论文

本本科科生生毕毕业业设设计计 论论文文 TCG 游戏中服务端的设计与实现游戏中服务端的设计与实现 院 系 软件学院 专业班级 软件工程 姓 名 学 号 指导教师 年 月 日 华 中 科 技 大 学 毕 业 设 计（论 文） I 摘摘 要要 随着互联网技术，尤其是移动互联网技术的发展，TCG集换式卡牌游戏在网 络游戏中占据越来越重要的地位，从早期的万智牌、游戏王到如今火热的炉石 传说：魔兽英雄传，越来越多的游戏开发商都在努力打造自己的集换式卡牌游 戏。集换式卡牌游戏以其上手容易，占用时间碎片化的特性以及丰富的趣味性和 对抗性，成功拥有了大批忠实玩家，也成为了游戏厂商盈利的重要手段。 伴随着市场激烈竞争的是游戏研发技术的不断革新，游戏服务端从最初的简 单http服务器，到初成架构的MudOS服务器，再到为MMORPG应运而生的“通信， 逻辑，存储”的模块化服务端，以及时下热门的基于动态负载均衡的分级服务端， 游戏服务端研发技术也趋于成熟。 本文从笔者毕业设计中研发的集换式卡牌游戏星际传说服务端出发，通 过游戏服务端的通信协议、C/S架构、设计模式和数据库技术等方面浅谈当下 TCG游戏服务端的设计与实现。 关键词：关键词：集换式卡牌游戏；服务端设计；设计模式；C/S 架构 华 中 科 技 大 学 毕 业 设 计（论 文） II Abstract With the development of the Internet technology, especially the mobile Internet technology, TCGs(Trading Card Game) are taking a more important position in online games. From Magic The Gathering in the 1990s, the Yu-Gi-Oh Card Game in the early twenty-first century to the Hearth Stone: Heroes of Warcraft in recent years, more and more game companies are developing their own TCGs. For its features of easy to get started, not time consuming, abundant interest and antagonism, TCGs have earned plenty of loyal fans, and also become an important tool for game companies to make benefits. Breakthroughs of game developing techniques come with the fierce competition, from the simple http server, preliminarily structured MudOS server, communication, problem domain, data storage modular server, which is built to meet the need of MMORPG, to the popular hierarchical game server based on dynamic load balancing, the techniques of game server developing have become mature recently. In this paper, I will introduce the design and realization of TCG server through communication protocol, C/S structure, design pattern and database techniques by the game I developed during my graduation project. Key words：TCG; server design; designing pattern; C/S structure 华 中 科 技 大 学 毕 业 设 计（论 文） II 目目 录录 摘摘 要要I Abstract .II 1 绪论绪论.1 1.1 研究背景，目的及意义1 1.2 国内外研究现状1 1.3 研究内容和论文结构3 2 相关技术概述相关技术概述.4 2.1 Cocos2d-x 游戏引擎简介4 2.2 C/S 架构简介.4 2.3 Socket 通信技术简介4 2.4 服务端设计模式概述5 2.5 IntelliJ IDEA 简介.6 2.6 MySQL 数据库引擎简介7 2.7 本章小结7 3 集换式卡牌游戏服务端需求分析集换式卡牌游戏服务端需求分析.8 3.1 系统用户用例分析8 3.2 系统功能性需求分析9 3.3 系统非功能性需求分析14 3.4 本章小结16 4 集换式卡牌游戏服务端设计集换式卡牌游戏服务端设计.17 4.1 系统总体设计17 4.1.1 系统上下文定义.17 4.1.2 系统软件结构设计.17 4.2 系统主要功能模块的设计18 4.2.1 网络通信模块.18 4.2.2 登录注册模块.19 4.2.3 玩家对战模块.20 4.2.4 商城模块.21 4.2.5 卡牌收藏模块.22 华 中 科 技 大 学 毕 业 设 计（论 文） III 4.2.6 好友模块.24 4.3 数据库设计26 4.3.1 数据库概念设计.26 4.3.2 数据库详细设计.26 4.4 系统安全性设计30 4.4.1 网络安全设计.31 4.4.2 数据库安全设计.31 4.5 本章小结31 5 系统实现系统实现.32 5.1 系统开发环境32 5.2 系统各功能模块的实现32 5.2.1 网络通信模块实现.32 5.2.2 玩家对战模块实现.33 5.2.3 数据库访问模块实现.34 5.2.4 商城模块实现.34 5.2.5 好友模块实现.35 5.3 本章小结36 6 系统测试系统测试.37 6.1 功能测试用例37 6.2 性能测试用例38 6.3 测试结果38 6.4 本章小结38 7 总结与展望总结与展望.39 7.1 全文总结39 7.2 展望39 致致 谢谢.41 参考文献参考文献.42 华 中 科 技 大 学 毕 业 设 计（论 文） 1 1 绪论绪论 1.1 研究背景，目的及意义研究背景，目的及意义 TCG 是英文Trading Card Game的首字母缩写，中文学名是集换式卡牌游戏。 1 顾名思义，TCG 需要游戏者购买卡牌扩充包来拓展自己的牌库，然后根据一定 的策略，灵活组合各类型的卡牌来构筑一副符合游戏规则的套牌，玩家之间使用 自行构筑的套牌进行游戏。2因为每个玩家构筑卡组的思路和策略不同，加上每 局游戏中玩家抽到卡牌的顺序也不同，可以给游戏对局带来数不胜数的变数3， 这也是 TCG 吸引玩家的最大玩点。 笔者在 2017 年 1 月至 2017 年 5 月参与了集换式卡牌游戏星际传说的研 发工作，在项目组中负责游戏服务端的设计与实现，游戏出色地体现了 TCG 多 变的策略和丰富的可玩性，而笔者也积累了一定服务端研发的实践经验。为本文 的撰写打下了基础。 本文研究的目的在于通过对当下 TCG 服务端研发的技术的分析和实践，总 结出集换式卡牌游戏服务端设计与实现中实用的项目结构和研发技术，为今后 TCG 的研发者提供可以借鉴的经验。 1.2 国内外研究现状国内外研究现状 美国数学教授查理加菲于 1993 年 8 月设计了世界上第一款集换式卡牌游戏 万智牌(Magic The Gathering)，游戏以西方神话故事为背景，玩家在游戏中收集武 器，魔法和生物等不同类型的卡牌来构筑自己的套牌，4以模拟远古时期魔法师 之间的对决。游戏一经推出便俘获了大量玩家，时至今日，万智牌在全球已拥有 约 600 万名玩家。而日本也在 1999 年推出了游戏王卡牌游戏 ，这款由漫画衍 生出作品在集换式卡牌游戏中拥有里程碑式的意义5，游戏首次将东西方文化元 素巧妙地进行了融合，在卡牌的种类上相对于之前的集换式卡牌游戏也有极大的 丰富，并且首创了卡牌盖伏和正面表示的状态，以及怪物卡在不同的阶段拥有的 反转、启动、永续、诱发、即时诱发和规则改变效果都极大丰富了游戏的策略和 可玩性，因此， 游戏王卡牌游戏也是吉尼斯世界纪录认证的全球最高销量的 集换式卡牌游戏6。美国游戏公司暴雪娱乐于 2014 年 3 月发行的炉石传说：魔 华 中 科 技 大 学 毕 业 设 计（论 文） 2 兽英雄传则开创了集换式卡牌游戏的新时代。游戏将自家热门 IP魔兽世界 作为游戏背景，简化了游戏复杂度和游戏进程，使得集换式卡牌游戏更加平民化， 更加容易上手。同时， 炉石传说：魔兽英雄传也推出了每日任务，让玩家可 以通过完成任务来获取更多卡牌，不断推出的游戏新环境和新机制也使得游戏保 持着经久不衰的活力7。 在我国，由于游戏研发技术和互联网技术起步较晚，集换式卡牌游戏的出现 也比国外迟。在国产集换式卡牌游戏中，最具有代表性的作品就是 2009 年面市 的三国智8了，游戏结合了集换式游戏元素和国内玩家热衷的三国题材，以 卡牌对战的形式展示了三国时期尔虞我诈，群雄逐鹿的风云故事。 在集换式卡牌游戏发展历程中，游戏的研发，特别是服务端的研发技术也经 历了多次的更新换代9。最初的网络游戏借助 HTTP 协议来完成客户端和服务端 之间的简单通信，数据格式，数据量和传输速度都有很大的限制，这一阶段的游 戏服务端通常是一个静态的服务器，只能按照规定好的规则返回简单数据，通常 采用的编程语言是 C 语言，C+或者 Pascal10。在后续的发展中，人们为了简化 服务端程序编译、调试和维护的过程，开始尝试使用脚本语言研发服务端，1987 年 Perl 语言和 1994 年 PHP 语言的问世，使得服务端的研发技术正式进入脚本化 的时代11。随着服务端需求的不断提升和研发技术的完善，多种适用于服务端研 发的语言不断出现，同时也逐渐形成了 Web 应用的行业标准，即 Java 阵营的 J2EE 和 Windows 阵营的.Net 为开发者提供了解决不同需求的服务端的技术标准 和通用解决方案，此时，服务端引擎的概念也逐渐产生，游戏服务端也从弱交互 型服务器不断向强交互型服务器转变12。到了 2000 年前后，网络游戏进入全面 图形化时代，用户的数据量也日益增多，频繁的小文件读写和传输给服务器带来 了巨大挑战，这时人们开始将服务端拆分为逻辑服务端和数据库服务端两部分， 逻辑服务端专门处理用户的各类请求，而数据库服务端专注于数据持久化工作， 一些成功的商用数据库引擎例如 Oracle 和 MySQL 开始被广泛应用于服务端的开 发中13。此时的网络游戏，由于游戏需要经常更新新的内容来留住玩家，服务端 也需要不断换代升级来满足客户端与玩家交互的需求，因此人们开始使用更加利 于拓展和维护的编程语言，如 Python 和 Lua 语言，更加亲近自然语言的面向对象 语言使得开发工作更高效14。服务端引擎也开始运用到开发中，因为 Python 这 样的脚本语言可以很方便的调用编译好的 C 语言程序来执行逻辑操作，因此服务 华 中 科 技 大 学 毕 业 设 计（论 文） 3 端引擎通常由底层的引擎核心、脚本解释器和外层的若干脚本组成，引擎的内核 通常由纯 C 语言或者 C+编写，它不负责任何具体的逻辑需求的处理，只把服务 端的需求分类、抽象为若干个基本借口，每个接口通常只负责一项简单的任务， 并对外层的脚本提供接口15，而外层的脚本则运行在一个高效率的解释器上，负 责有序地组织和调用底层内核提供的开发接口，而解释器则是把 Python 或其他脚 本中的函数调用指向对应的底层引擎借口，并返回执行结果给脚本层，如此一来 服务端的开发进入了全面模块化和分层化的阶段16，它所带来的好处是显而易见 的，首先，引擎内核与任何具体的业务逻辑无关，内核开发人员只需要专注于优 化底层 API 的效率和稳定性，负责业务逻辑开发的人员不需要了解任何引擎实现 的原理，只需要按需调用内核接口来完成业务逻辑的需求，细化了开发人员的工 作范围和简化了开发流程17。其次，由于脚本维护和拓展的便利性，游戏需求更 改时，往往不需要重启服务器，只是将对应业务逻辑的脚本做相应修改，再重新 发 布脚本即可，节省了服务器运营的成本，也方便开发人员快速、精确定位上线 项目 的 bug 并作相应的修改18。 目前，国内游戏研发采用的服务端引擎大致分为 2 类，第一类是自我定制的 开源引擎，如 KBEngine 和 Photon 等。另一类则是自主研发的引擎，通常有较强 研发实力的游戏公司会采取后者，而前者不失为一种节省时间和成本的好选择19。 1.3 研究内容和论文结构研究内容和论文结构 （1）本文内容概述： 本文以笔者参与研发的集换式卡牌游戏星际传说为例，从需求分析，项 目设计，项目实现和系统测试等方面详细阐述了一个集换式卡牌游戏服务端的开 发过程和开发技术总结。 （2）本文的内容组织与结构安排如下： 第一章，介绍本文的课题研究背景、目的和意义，以及国内外研究现状。 第二章，介绍星际传说项目开发用到的开发技术，开发工具和开发环境。 第三章，从系统功能性需求和非功能性需求详细分析项目需求。 第四章，根据需求分析，对系统做模块划分，并详细设计每个模块的功能。 华 中 科 技 大 学 毕 业 设 计（论 文） 4 第五章，详细介绍每个模块功能的实现方式。 第六章，详细介绍系统采取的测试方法，测试结果和由此得出的结论。 第七章，详细描述笔者的论文总结和展望。 华 中 科 技 大 学 毕 业 设 计（论 文） 5 2 相关技术概述相关技术概述 2.1 Cocos2d-x 游戏引擎简介游戏引擎简介 我参与研发的游戏星际传说使用了 Cocos2d-x 3.10 作为游戏客户端引擎。 这是一个跨平台的开源游戏引擎，在 2D 图像图形渲染上有独特的优势。 Cocos2d-x 的一大特性是它的跨平台性，引擎允许开发者使用 C+，node.js 和 Lua 在多个平台上部署项目，并不需要对项目做太多针对平台的修改。Cocos2d-x 引擎采用 OpenGL ES 进行图形渲染，能够充分利用系统硬件性能，同时 Cocos2d-x 目前已集成了大量第三方库，尤其是图形和动画特效的第三方库，为 开发者提供了简介易用且高效的开发模板20。引擎的另一大优势是开源，这使得 有经验的开发者可以根据自己的需求自我修改引擎的模块来提升游戏运行的效率， 自我定制的 Cocos2d-x 引擎在目前国内游戏公司的开发中使用非常普遍，开源社 区也提供了对引擎优化的技术支持21。 2.2 C/S 架构简介架构简介 C/S 架构全称 Client/Server 架构，是将应用程序的逻辑通过合理划分，分别 部署在客户端和服务端，在采用 C/S 架构的游戏中，通常将游戏和用户交互的 UI 部分部署在客户端，而将业务逻辑处理和数据持久化的工作部署在服务端22。 C/S 架构有利于将客户端和服务端的硬件性能，通常客户端机器拥有出色的 图形渲染性能，能够很好的完成 UI 交互的工作，而服务器通常具有较强的运算 性能和并发处理的能力，能够同时快速处理多个客户端的需求。因此，采用 C/S 架构的软件系统通常具有很快的响应速度和高并发能力，但 C/S 架构也有不足， 客户机需要安装并维护客户端程序才能使用，因此运行平台往往受到限制，同时 服务器的研发和维护需要大量成本和复杂的技术支持23。 C/S 开发架构在目前的游戏研发领域有重要的应用，许多大型客户端游戏都 采用 C/S 架构进行开发。 2.3 Socket 通信技术简介通信技术简介 Socket，即程序套接字，是一种实现网络上两个不同的程序进行双向数据通 华 中 科 技 大 学 毕 业 设 计（论 文） 6 信的技术。网络上的服务器通常都提供了多种服务，每一种服务对应一个 socket 通道，并绑定到一个固定的端口上，网络上其他机器通过服务器的 IP 地址和端口 号来访问服务器并使用服务器提供的相应服务24。 Socket 通信起源于 Unix/Linux，它可以看成一个特殊的网络文件，Socket 中 封装的接口，如 bind(),listen(),read(),write()和 close()等提供了一个完整的文件读写 操作的流程。在进行通信时，通信的两个进程间通过 IP 地址和端口号建立一个 socket 连接，即一个文件读写的通道，然后通信双方调用相应的读写操作的方法 将输入写入通道或者从通道中读出，从而实现双向通信25。 Socket 由于其对于 TCP/IP 协议的良好封装性，以及优秀的开发规范，已经 被广泛应用于 C/S 架构开发的系统中。同时，socket 工作在网络协议的传输层， 不依赖特定平台，开发者可以自我定制符合自身需求的解包、发包子协议，可以 方便地对传输数据进行加密，因此有较好的安全性和性能26。Socket 直接在进程 间进行通信，数据以字节流的形式传输，可以自定义数据量的大小，使用灵活， 并 且具有很快的传输速度，适合对网络时延和数据安全性要求的较高的网路游戏开 发 27。 2.4 服务端设计模式概述服务端设计模式概述 所谓设计模式，即是一系列经过前人总结的，在实际开发中得到反复检验的 有效的代码设计经验，强调设计模式的使用，是为了加速开发进程，提高代码的 可读性、可重用性，使得代码编写结构化、工程化，并减少各个模块的耦合度， 易于项目的维护和拓展28。 在 TCG 服务端的开发工作中，常用的设计模式有单例模式，工厂模式和观 察者模式。通常，服务器进程中运行着一个单例的全局服务器对象，它就像是服 务端对外抽象出的代理，所有客户端和服务器的交互工作都通过这个全局的单例 对象代理29。 工厂模式被应用于服务端的各个业务逻辑模块中。一个工厂拥有多个车间， 每个车间负责完成某些专门的任务，同理，在工厂模式中，服务端收到客户端的 请求后，根据解包的内容，将客户端需要的内容分解到各个模块中去处理，再将 处理后的结果返回给客户端。也就是说，工厂模式中有一个总的任务分配器 Handler，当一个“订单”，也就是客户端的请求到达服务端的时候，这个 Handler 华 中 科 技 大 学 毕 业 设 计（论 文） 7 根据客户端所请求的内容调用具体的模块来完成处理30，这些处理可能包括：数 据读取，数据写入数据库，从另一个客户端那里获得数据等等。工厂方法的使用 使得服务端代码重用率和拓展性得到了很好的提高。 在集换式卡牌游戏中，很多卡牌都带有某种特效，例如“战吼”效果，即打出 这张牌时会立刻产生一些效果，如果说有一种设计模式能够简洁高效得实现这一 功能，那就是观察者模式31。观察者模式由被观察的事件和订阅这个事件的对象 所组成，当这个事件发生或者事件的状态产生变化时，所有的订阅者都会得到一 个通知，在上文举到的“战吼”例子中，被观察的事件是“这张牌被打出”，当这个 事件发生时，所有订阅的对象接收通知并调用对应的更新操作来维护自己的状态， 就不需要开发者在每个具体的类中去实现何时会产生这样的效果。 2.5 IntelliJ IDEA 简介简介 IntelliJ IDEA 是一种 Java 开发的 IDE（集成开发环境） ，它是在 Java 开发领 域中被广泛认可的一种高效开发工具。IntelliJ IDEA 提供了代码智能联想、重构， 代码分析，多种版本控制插件，J2EE 标准支持，方便的单元测试 Junit，其超前 的 GUI 设计更得到了众多开发者的青睐32。 IntelliJ IDEA 由捷克的 JetBrains 公司研发，公司开发人员务实，严谨的作风 在 IntelliJ IDEA 中得到了完美体现。IntelliJ IDEA 旨在减少开发人员的工作量， 使得开发者能够专注于解决问题，而非重复劳动，其突出的一项功能是强大的调 试能力，IntelliJ IDEA 可以对 Java，JavaScript 和 Ajax 代码进行调试，开发者可 以方便的跟踪自己代码的执行，快速进行 bug 定位和优化。IntelliJ IDEA 还提供 了多种视图，project 视图方便开发者在不同的工程间进行同窗口切换，structure 视图方便玩家浏览当前.java 文件中全局变量、类和类函数的声明。除此之外， IntelliJ IDEA 还支持丰富的查找和导航模式，查找和替换支持正则表达式，因此 执行查找和替换非常灵活33。IntelliJ IDEA 集成了大量高效实用的插件，开发者 无需额外安装插件就可以完美进行 JSP、EJB、XML 和 ANT 的开发工作，并且 编辑器与文件系统同步，在编辑器之外修改了文件内容，编辑器中可以同步更新， 不需要重新加载工程34。 IntelliJ IDEA 给广大 Java 开发者提供了一个强大的智能、高效开发平台，自 2001 年 1 月发布以来，已经成为众多 Java 开发者首选的 Java IDE。 华 中 科 技 大 学 毕 业 设 计（论 文） 8 2.6 MySQL 数据库引擎简介数据库引擎简介 MySQL 是一种关系型数据库引擎，所谓关系型数据库，是指数据库模型以 关系模型为基础，通过现代数学的概念和方法来处理数据库中的数据。 MySQL 使用结构化查询语言（SQL）作为数据库操作的标准语言，SQL 不 关注数据存放方法，只关注操作的结果，因此拥有不同底层结构的数据系统都可 以使用统一的 SQL 语句作为数据管理的接口，同时，SQL 支持语句嵌套，使其 具有了很强的灵活性35。 MySQL 使用不同的数据表来存放数据，而不是将数据统一放在一个大数据 仓库中，数据表之间通常维护着若干关系，通过这些关系使用者可以快速而精准 地从若干数据表中获取所需的数据集合，对数据表某一字段的更新也会引发关联 数据表的更新，因此数据库的维护工作得到了简化。 MySQL 是一款开源的数据库引擎，开放源码意味着任何开发者都可以在法 律允许的范围内对 MySQL 官方版本做修改，使其更符合自身的需求，这数据库 引擎功能和使用方式的拓展提供了可能36。 MySQL 由于体量小，速度快，资源占用量低以及开源等特性，已经被广泛 应用于中小型网站研发，各类软件系统的研发工作中。集换式卡牌游戏因其数据 存储量不大，数据读写以简单的数据片段为主和数据关联性较强等特性，特别适 合使用 MySQL 作为数据库引擎，事实上，大部分集换式卡牌游戏服务端都使用 了 MySQL 来提高数据持久化的效率，降低研发成本。 2.7 本章小结本章小结 本章以笔者参与研发的星际传说为例，介绍了集换式卡牌游戏开发中常 用的环境及技术，并分析了国内外被广泛认可和使用的开发架构，开发语言和数 据模型等内容。这些理论分析是游戏服务端实现的理论保障。 华 中 科 技 大 学 毕 业 设 计（论 文） 9 3 集换式卡牌游戏服务端需求分析集换式卡牌游戏服务端需求分析 本章通过对星际传说系统用例分析，系统功能性需求分析和系统非功能 性需求分析的深入剖析，逐步确立系统需求和模块划分，以及各模块的研发目标， 为系统的设计与实现提供了理论依据。 3.1 系统用户用例分析系统用户用例分析 星际传说是一款集换式卡牌游戏，因此系统的用户群主要由玩家和游戏 管理员组成。 按照星际传说用户的功能及角色，用户分为以下两类： 首先是普通玩家：普通玩家主要进行用户注册、登录，购买卡包、皮肤，打 开卡包，构筑套牌和进行对战的操作，其用例图如图 3-1 所示。 图图 3-1 普通玩家用例图普通玩家用例图 其次是游戏管理员：除了和普通玩家一样进行游戏外，还可以执行 GM 指令， 例如获得指定数量的卡牌、虚拟货币或皮肤等，其用例图如图 3-2 所示。 华 中 科 技 大 学 毕 业 设 计（论 文） 10 图图 3-2 游戏管理员用例图游戏管理员用例图 3.2 系统功能性需求分析系统功能性需求分析 星级传说游戏服务端从以下 5 个角度实现服务端需求： 账户相关需求：用户通过手机号和密码注册账号，用户通过输入账号和密码 登录游戏，用户设置或者更改自己的昵称。 商城相关需求：用户通过游戏内置商城购买虚拟道具，包括卡包，英雄皮肤， 加成道具卡等。 卡牌收藏相关需求：包括用户浏览个人的卡牌收藏，打开已经购买的卡包， 设置自己英雄所使用的皮肤，使用已拥有的卡牌构筑自定义的卡组等需求。 好友相关需求：包括游戏内玩家相互添加好友，邀请好友进行一场对局，观 看好友正在进行的对局，和好友互相发送即时消息等需求。 玩家对战相关需求：玩家通过选择自己构筑套牌与网络上其他玩家进行匹配 后进行一场游戏对战，对局结束后结算分数并给予玩家相应的奖励。 下面分别论述： 1）账户相关需求 华 中 科 技 大 学 毕 业 设 计（论 文） 11 这部分包括用户账户注册，用户使用账户登录游戏，用户设置获更改账户昵 称，修改登录密码。 图图 3-3 玩家注册用例图玩家注册用例图 首先是账户注册需求分析，玩家被要求使用手机号进行游戏账户的注册，游 戏账户与手机号一对一绑定，通过手机号唯一确定玩家的身份。在玩家输入合法 的手机号后，系统通过第三方平台向玩家的手机发送一条包含注册验证码的短信， 玩家收到短信后输入验证码，验证通过后进入个人信息设置环节，此环节中用户 必须设置自己的账户密码并重复确认，可选设置自己的昵称和上传头像，若不设 置，系统将自动生成缺省的昵称和头像。 图图 3-4 玩家登录用例图玩家登录用例图 其次是游戏登录需求分析，玩家使用自己的账号和密码进行游戏登录，玩家 输入的账户信息将加密发送给服务端进行验证，服务端将数据与数据库中的账户 表进行比对，比对成功后玩家跳转到游戏大厅界面，同时服务端通知玩家所有在 线好友该玩家上线的消息，用来更新客户端好友列表。 华 中 科 技 大 学 毕 业 设 计（论 文） 12 图图 3-5 个人信息维护用例图个人信息维护用例图 最后是个人信息维护需求分析，玩家可以随时更改自己账户的密码，昵称和 头像，在做更改操作前，玩家需要先输入正确的密码并通过服务端验证。如果需 要更改账户密码，在输入新密码后还需要重复输入一次确认。玩家的更改请求被 服务端执行完毕后会返回服务端一条提示操作成功或者失败及失败原因的提示码， 用于客户端和用户的交互。 2）商城相关需求 这部分包括玩家通过游戏内置的虚拟商城购买游戏内的虚拟道具，包括包含 5 张随机卡牌的游戏卡包，改变英雄外观的英雄皮肤和帮助在对局中获得额外收 益的加成卡，如经验加成卡、金币加成卡等。同时也提供玩家进行游戏虚拟货币 充值的接口。其类关系图如图 3-4 所示。 图图 3-6 游戏商城用例图游戏商城用例图 虚拟道具浏览与购买需求，即玩家登录游戏后，从游戏大厅进入游戏商城， 商城道具分为 3 类，即卡牌包，英雄皮肤和加成卡，玩家点击不同的选项卡浏览 对应的商品信息，每种商品的描述和价格标注在商品下方。商城界面会显示玩家 华 中 科 技 大 学 毕 业 设 计（论 文） 13 当前的拥有的虚拟货币数量。玩家选中商品后，可以提供道具预览，例如皮肤的 外观效果，玩家可以选择把商品添加进购物车，然后进行结算。进行结算时，服 务端遵循四步曲原则，即“检查条件-拆条件-重验条件-给奖励”的步骤进行操 作，目的是防止异步操作时条件被意外改变而引发游戏漏洞。购买成功后提示玩 家购买成功的消息，若玩家余额不足，提示充值信息，并引导玩家进入充值界面。 其次，虚拟货币充值需求，即玩家在商城中可以进行游戏虚拟货币的充值， 将人民币按 1：10 的比例兑换为游戏中使用的虚拟货币，玩家在游戏商城中的消 费统一使用虚拟货币进行结算。玩家可以使用网上银行，或者支付宝、微信钱包 这样的第三方支付平台完成支付操作。 3）卡牌收藏相关需求 玩家通过游戏大厅进入个人中心，在个人中心玩家可以浏览自己拥有和尚未 拥有的卡牌和皮肤信息。在个人中心，玩家可以打开已经购买的卡包，每个卡牌 包打开后玩家将随机获得 5 张不同的卡牌，玩家还可以利用自己已拥有的卡牌构 筑若干自定义的符合游戏规则的套牌。其类关系图如图 3-5 所示。 图图 3-7 游戏卡牌收藏用例图游戏卡牌收藏用例图 个人收藏浏览相关需求，即玩家可以在个人中心浏览自己拥有和尚未拥有的 卡牌信息，自己拥有的英雄皮肤，加成卡。对于尚未拥有的卡牌，根据卡牌的品 质，玩家可以通过消耗一定数量的虚拟货币的方式来制作这张卡牌。玩家可以设 置任何已拥有的皮肤作为默认皮肤或者设置是否使用加成卡。 打开卡包相关需求，即玩家可以打开已购买的卡包，打开后获得随机 5 张卡 华 中 科 技 大 学 毕 业 设 计（论 文） 14 牌，服务端将这 5 张卡添加到用户的牌库中。 套牌构筑相关需求，即玩家使用自己拥有的卡牌构筑一副卡组，每副卡组包 含 30 张卡牌，玩家将使用自己构筑的卡组与其他玩家进行在线对战。 4）好友相关需求 玩家在游戏中可以添加好友，好友列表中的好友有在线，离线和对战中三种 状态。玩家可以邀请在线的好友进行一场对局，或者观看游戏中的好友进行一场 对局。玩家也可以给好友发送即时消息。其类关系图如图 3-6 所示。 图图 3-8 游戏好友中心用例图游戏好友中心用例图 玩家在游戏中可以通过搜索其他玩家的昵称或者 ID 的方式来添加好友，在 对方确认后，对方玩家的昵称将会显示在玩家的好友列表当中。玩家的好友分为 在线、对战中和离线中三种状态，每种状态由不同的颜色和图标来标识。玩家可 以发送即时消息给好友列表中的好友，在线的好友会立刻收到消息提示，离线好 友在下次上线时会收到消息提示，通过即时消息，玩家之间可以实现在线交流。 玩家也可以邀请在线的好友进行一场对局，或者选择一名正在进行对局的好友观 看实时对局。 5）玩家对战相关需求 华 中 科 技 大 学 毕 业 设 计（论 文） 15 图图 3-9 玩家对战用例图玩家对战用例图 玩家可以通过随机匹配或者邀请好友的方式进入一场对局，对局开始时随机 产生先手出牌的玩家，先出牌的玩家发 5 张起始手牌，后手玩家发 6 张起始手牌。 每个玩家有 60 秒时间来完成自己的回合，超时视为结束回合，玩家也可以手动 结束自己的当前回合。对局开始，每个玩家拥有 1 个能量水晶，后续每个自己的 回合将会获得 1 个能量水晶，最多持有 10 个能量水晶，打出一张牌需要消耗一 定的能量水晶，在卡牌的左上角标明。卡牌分为随从、法术和武器三类，随从可 以带有某种特殊效果，包括战吼：召唤时即可发动，亡语：该随从死亡时发动， 光环：该随从存在场上时持续生效；嘲讽：强制地方单位攻击这个随从；法术牌 分为 3 类，分别是造成一定伤害，恢复一定生命值或者抽若干数量的牌，部分法 术需要指定目标才能使用，其他法术不需要指定目标；玩家装备牌后可以使用英 雄发动攻击。每个玩家的初始生命值为 30 点，当一方的生命值降为 0 或以下， 或者选择投降则游戏结束，双方将会获得一定经验值奖励，获胜方获得的经验值 更多，并且会获得一定数量的金币奖励。 3.3 系统非功能性需求分析系统非功能性需求分析 非功能性需求在软件系统中扮演十分重要的角色，非功能性需求的实现保证 了系统的多方面性能，起到了完善系统功能，保证系统运行效率的作用。 系统的非功能性需求如下： 首先是安全性，系统的安全性至关重要，良好的安全性能够保障用户的个人 虚拟财产的安全和游戏运营者的利益不受损害，当前网络环境中，各种网络攻击 病毒层出不穷，系统的安全性往往被视为最高级需求之一。 为了保证系统的安全性，在系统的每个环节，尤其是涉及到数据通信和数据 持久化的环节应当增加保全措施。首先，玩家注册账户和登录时，客户端和服务 端之间发送的数据包应当经过高度加密，保证用户的个人信息不被泄露。其次， 服务端数据存盘采用周期自动存盘的方式，服务端向数据库引擎维护一个存盘队 列，每隔 5 分钟将存盘队列中的对象执行存盘操作，对于特别重要的数据，例如 玩家修改密码，充值或购买道具，服务端对此类敏感数据执行即时存盘，而不是 添加存盘队列。所有数据存盘时将同时存入正式数据库和影子数据库，影子数据 库是正式数据库的备份，当正式数据库发生数据丢失等意外状况时，可以利用影 华 中 科 技 大 学 毕 业 设 计（论 文） 16 子数据库恢复出错的数据，防止产生数据丢失。 其次是系统的易用性，游戏系统是为了玩家服务，因此必须要做到让玩家容 易上手。 星际传说在设计时就考虑到了系统易用性，游戏的每个功能模块都 尽量做到界面简洁，每个按钮都有相应的文字说明，在玩家对战时，出牌的操作 与现实中出牌动作类似，将卡牌拖动到手牌区外即可完成出牌。此外，游戏运行 在 win32 平台，游戏的操作风格与 win32 的常用风格保持一致，玩家不需要专门 的学习即可上手。 系统的先进性也至关重要，游戏的需求在不断发展，网络游戏必然会不断推 出新的内容来保持游戏自身的活力。 星际传说在设计时已经考虑到了这一点， 系统采用的 C/S 架构，在未来相当长一段时间内仍然会是主要的游戏架构，因此 系统架构具有较长的生命。服务端各模块之间耦合度较低，每个模块只是底层接 口的组合，因此系统将来的维护和拓展也有很大的空间和自由度。 系统拓展性同样不可忽视，随着游戏玩法的丰富，服务端要提供的功能也要 随之改进或增加。系统在划分模块阶段要注意模块间“高内聚，低耦合”的原则， 模块之间职责划分要清晰，模块功能的实现尽量降低对其他模块的依赖度。系统 应根据功能性需求选择合适的设计模式，并充分考虑未来可能出现的功能拓展， 通常集换式卡牌游戏服务端都使用了工厂模式，其优点之一就是添加一个新功能 就像工厂中新增一个车间一样简单。良好的模块划分和选择合适的设计模式是保 证系统良好拓展性的关键。 另外，系统的容错性也是重要的一环，首先是操作容错性，主要包括数据合 法性检查，即服务端解包获取的数据，需要检查其合法性，包括数据的类型、格 式和长度等。数据合法性在数据持久化工作中十分关键，MySQL 数据库对数据 有严格的格式要求，错误的数据可能使得存盘出错，所以对于数据检验不通过的 数据包应当采取丢弃重传的策略，以此保证数据的合法性。此外，系统客户端中 需要用户输入的数据也需要在控件获取输入时就完成第一道数据检验，不符合格 式的输入要明确提示用户。其次是程序逻辑容错性，即服务端业务逻辑层采取一 系列措施来处理逻辑错误，例如：在数据格式方面，长度越界的整变量自动升为 长整型存储；某些数据出现异常值时，系统会捕获这个异常，并根据与之相关联 的其他数据的值来估算异常数据的正确值，并修改异常数据的值，保证系统不中 断，同时将系统异常报告写在系统日志中，包括异常类型，出现的时间，出错的 华 中 科 技 大 学 毕 业 设 计（论 文） 17 脚本和行数，并提示管理员解决。在数据持久化方面，数据存盘同时存放在正式 数据库和影子数据库，正常情况下系统需要的数据从正是数据库中获取，如果正 式数据库出现故障，则从影子数据库中恢复数据，确保数据能够正常进行读写操 作。 系统的吞吐率同样是服务端设计中不可忽略的一点，游戏服务端需要满足大 量用户同时游戏的需求，因此对数据的吞吐量有一定要求。集换式卡牌游戏服务 端属于弱交互型服务器，每个玩家需要交互的数据量不多，但数据有碎片化的特 点，并且玩家的数量可能较多，因此需要服务端能够快速传输小的数据片段，具 有较好的数据吞吐率。 最后是系统响应速度，系统运行的效率体现在系统的响应时间上，特别是对 于网络游戏而言，游戏响应玩家操作的时间是影响用户体验的一大关键因素。对 于集换式卡牌游戏而言，由于其弱交互性，系统对响应速度的要求不高，通常来 说 150 毫秒之内都是可以接受的范围，但是，快速的响应速度仍然是提升用户体 验的手段之一。 3.4 本章小结本章小结 本章节对集换式卡牌游戏服务端的需求与设计做了深入分析和概括，从系统 的功能性需求和非功能性需求入手详细剖析了系统需要实现的功能和系统在各方 面性能的指标。 华 中 科 技 大 学 毕 业 设 计（论 文） 18 4 集换式卡牌游戏服务端设计集换式卡牌游戏服务端设计 4.1 系统总体设计系统总体设计 4.1.1 系统上下文定义系统上下文定义 图图 4-1 星际传说星际传说系统上下文系统上下文 如图 4-1 所示， 星际传说采用 C/S 架构，运行在 Win32 平台，玩家在终 端上安装游戏客户端来运行游戏，一台服务器负责和多个游戏客户端进行双向通 信。服务端分为业务逻辑层和数据库访问层，业务逻辑层负责处理客户端的请求 并返回结果，数据库访问层通过 MySQL 数据库引擎来管理数据库，负责游戏数 据的增、删、改、查。 4.1.2 系统软件结构设计系统软件结构设计 系统总体结构图如图 4-2 所示。 华 中 科 技 大 学 毕 业 设 计（论 文） 19 图图 4-2 系统总体功能结构系统总体功能结构 4.2 系统主要功能模块的设计系统主要功能模块的设计 4.2.1 网络通信模块网络通信模块 通信模块主要包括发包和解包。发包是将包含有有效数据信息的集合编码为 易于通过网络传输的 JSON 对象，并对其进行 RSA 加密的过程；解包则与发包相 反，是将接收到的数据包通过 RSA 解密，然后将解密后获取到的 JSON 对象解析 为有效数据信息集合的过程。 图图 4-3 通信模块发包时序图通信模块发包时序图 把数据段编码为一个 Json 对象并发送的过程称为发包。发送数据包前，先把 待发送的数据（通常是由若干类型的对象组成的集合构成）复制到一个容器中， 然后对容器作统一格式和数据加密操作，然后通过第三方 Json 库将容器对象编码 为一个 Json 对象，通过 socket 发送给对应的接收方。发送方维护一个发送队列， 待发送的数据包将依到来次序发送。 华 中 科 技 大 学 毕 业 设 计（论 文） 20 图图 4-4 通信模块解包时序图通信模块解包时序图 解包的过程与发包相反，是将接收到的数据包恢复至若干类型对象集合的初 始状态。接收到数据包时，首先从包中拿出需要的 Json 对象，然后调用第三方 Json 库的 API，将 Json 对象解析为加密过的数据容器，然后通过解密算法将加密 后的数据还原成有意义的数据，再根据数据执行相应的操作。 4.2.2 登录注册模块登录注册模块 游戏所有用户的账户信息都保存在数据库的用户表中，客户端发来登录请求 时，服务端从客户端发送的数据包中解析出用户名和密码字段，并与数据库用户 表进行比对，账号和密码都成功匹配则返回登录成功的消息，否则返回登录失败 的消息。 图图 4-5 用户注册和登录类关系图用户注册和登录类关系图 华 中 科 技 大 学 毕 业 设 计（论 文） 21 客户端发来注册请求时，服务端先搜索数据库这个号码是否已经注册过，如 果已注册，则返回账号已存在的消息，若未注册过，则继续注册流程。服务端首 先调用 Bmob 后端云提供的短信验证 API，向用户填写的手机号发送验证码，用 户输入的验证码将直接发送给 Bmob 的第三方服务器，第三方服务器再向游戏服 务端返回验证结果，服务端根据验证成功或者失败分别向客户端返回注册成功或 失败的消息。其类关系如图 4-5 所示。 4.2.3 玩家对战模块玩家对战模块 在游戏服务端，两个玩家的一次对局是通过一个 Game 剧本类对象描述的， 这个对象就像一个沙盘，记录了两个玩家的全部状态信息和操作信息。客户端从 服务端同步这个剧本对象，就能够在多个客户端上展现同一局游戏了。 图图 4-6 玩家对战类关系图玩家对战类关系图 玩家每执行一次操作，服务器接收到操作指令后，计算玩家操作的结果，并 修改剧本对象的数据，然后将修改后的剧本对象返回给这个剧本对象绑定的两个 客户端，客户端接收到剧本对象后，根据操作序列向玩家用动画的形式展示另一 华 中 科 技 大 学 毕 业 设 计（论 文） 22 方玩家的操作，循环这个过程来推动游戏进度，直至这场对局结束。其时序图如 图 4-7 所示。 图图 4-7 玩家对战时序图玩家对战时序图 4.2.4 商城模块商城模块 玩家通过商城购买虚拟物品，玩家进入商城模块时，客户端向服务器请求商 城数据，服务端收到请求后从数据库商城表中读取数据，并将数据打包发回客户 端，客户端将数据包解包后更新商城界面。其类关系图如图 4-8 所示。 图图 4-8 游戏商城类关系图游戏商城类关系图 华 中 科 技 大 学 毕 业 设 计（论 文） 23 图图 4-9 游戏商城时序图游戏商城时序图 玩家购买物品的过程遵循“四步曲”原则，即：“检查条件-拆条件-重验条件 -给奖励”。在玩家申请购买物品时，服务器先检验玩家是否具有足够的条件，例 如虚拟货币数量是否足够，是否有购买权限等，然后再拆条件，即扣除相应费用， 之后再次检验条件的合法性，再次检验条件的目的是防止检验条件之后的异步操 作使得条件发生变化而不符合操作条件，例如：玩家申请购买物品 A 后又立刻申 请购买物品 B，而在服务端，由于进程调度的原因，购买 A 物品的初次条件检验 之后立刻进行了购买物品 B 的条件检验，结果导致玩家没有足够的钱购买 A 和 B 的情况下却成功买到 A 和 B 物品的 bug，在条件重验通过后，服务器将虚拟物 品添加到玩家的资产表，然后回复客户端相应的消息。 4.2.5 卡牌收藏模块卡牌收藏模块 玩家在卡牌收藏模块浏览自己的虚拟财产，包括拥有的虚拟货币，卡牌，英 雄皮肤和道具卡，还可以打开已购买的卡包，设置英雄默认皮肤，通过消耗虚拟 货币的形式合成某张玩家指定的卡牌。 其类关系图如图 4-10 所示。 华 中 科 技 大 学 毕 业 设 计（论 文） 24 图图 4-10 卡牌收藏类关系图卡牌收藏类关系图 图图 4-11 开卡包时序图开卡包时序图 玩家申请打开卡包时，仍然遵循“四步曲”原则，成功打开卡包后，服务器随 机生成 5 张卡牌作为玩家打开卡包所获得的卡牌，添加到玩家的财产表后，再将 对应的消息返回给客户端，客户端以动画的形式向玩家展示所获得的 5 张卡牌。 华 中 科 技 大 学 毕 业 设 计（论 文） 25 图图 4-12 卡组构筑时序图卡组构筑时序图 玩家进入卡组构筑时，客户端生成一个包含现有可选卡牌的列表，玩家每次 从列表中选择一张卡牌加入到卡组中，玩家每添加一张卡，客户端就