《网络游戏核心技术与实战》读书笔记

零、快速入门

【套接字API】

1. socket()：因为还不会生成新的TCP连接，所以不存在TCP连接状态；
2. connect()：SYN→SYN/ACK→ACK（三次握手）;
- 主动打开 – 客户端调用发起连接;
- 被动打开 – 服务器被动建立连接;
3. bind()：不会生成新的TCP连接，只是设置本地生成的套接字的监听端口号；
4. listen()：“被动打开”后，服务器进入Listen(待机)状态，等收到客户端发来的SYN数据包后就会开始生成新的套接字；
5. accept()：在建立TCP连接(处于ESTABLISHED状态下的新通信链路)后，获取连接的套接字的文件描述符用于通信；
6. read()/write()/send()/recv()/sendto()/recvfrom()：用于实际的数据收发，必须在ESTABLISHED状态下；
7. shutdown()：通知OS不要再写入/读取数据了。
SHUT_WR侧发送FIN→接收方返回FIN并进入CLOSE_WAIT→SHUT_WR侧收到返回FIN/ACK并释放通信链路→接收方收到关闭通信链路;
8. close()：等同于调用shutdown(SHUT_RD|SHUT_WR)来同时关闭读写双方.

【各网络层头信息】

• ocet: 8位位组,因为部分机器”一个字节(byte)不等于8位(bit),以下单位皆为ocet;
• 以太网帧: 前导码(7) + SFD帧首定界符(1) + 目的地址(6) + 源地址(6) + 长度/类型(2) + 数据/LLC(46~1500) + FCS帧检验序列(4);
  
• 4层传输层: TCP(20) + 3层网络层–IP(20) + 2层数据链路层–以太网协议(26) + 物理层(1层) = 66ocet包头大小;
  
  
• 数据块: OSI参考模型,若发送小数据块,则头信息将占据大部分通信,加重物理层负担;若用1400字节的大数据块,则可达理论速度;
• 网络游戏数据块: 数据单位有时不得不20个字节左右,性能只有理论的几分之一.如100Mbit/s发送最小的数据时可达148810次;

【UDP的使用】

• 发送那些与可靠性相比速度更为重要的数据;比如FPS中移动消息,因TCP在数据丢失是会重发从而造成较大的通信延迟,UDP不会重发.
• 为了实现NAT遍历功能;

【多核与线程】

• 客户端:根据音效处理、AI、网络、主循环、渲染等方面，用3~5个线程；
• 逻辑处理最好不要使用多线程。

【提高开发效率】

• Windows下开发，Linux部署；
• 服务端 和 客户端在碰撞检测等方面使用相同的游戏处理代码；
• 使用封装保持源代码级的兼容性；
• 降低OS差异性的封装工作；

二、何为网络游戏

【商业层面的要求】网络游戏是制造业+服务业

• 有趣:
  
  • 尽早开发出原型并迭代;
  • 有效招募玩家尽早测试(解决明显不佳的平衡性; 无趣/引起不满的游戏内容):
    
    • 封测(平衡性,服务器负载等):500~3000名测试2~6月的试玩;必须充分测试(一经发行就遭遇失败的游戏是无法复兴的)
    • 公测(宣传营销目的,不限人数):系统负载与正式服务是等同的
• 不断更新，运营时间久(具有可扩展性)，评价高(提供多种收费选择)
  
  • 定期补丁:常规bug修复,细微的平衡性调整,系统改进等.(公开测试服供尝鲜玩家试玩);
  • 大型扩展:追加与之前有极大差别的游戏系统新玩法等(需准备测试服,为避免泄漏,会严格限制人数);
  • 紧急维护;
  • [分别设置问题修复+新内容开发团队; 尽可能分离源代码和数据内容; 模块化,避免干扰]。
• 降低成本(减少服务器数量；节约带宽；从小规模开始,确保可扩展性);
  从小规模开始–将风险降到最低,不要错过取胜机会;
• 希望有大量玩家参与(适配多个平台;发行多国版)；
• 不给玩家添麻烦：
  
  • 低成本、尽早可靠地消除攻击者，比如防止打金外挂 – 因其占用服务器并产生大量流量；
    
    • 根据情况增加GM巡视;
    • 日志分析;
    • 调整经济系统;
  • 减少停服：”服务器停一次,就会流失%1玩家”; 计划内停服维护影响不大;
  • 游戏平衡和经济缺陷：立刻修复, 回滚, 封号等处理; 一定要即时精准;
  • 服务器崩溃：不可避免,应根据游戏类型充分准备; 实现自动重启机制;
  • 超负荷：设计时要做到部分设备超负荷不会影响到整体; 设法减轻符合; 超负荷时通知运维和用户;
• 更佳的用户体验：
  
  • 频繁进行各类活动，使玩家能长时间游戏不会厌烦;
  • 反馈游戏结果：游戏元信息 – 排行榜; 成就; 其他统计; 记录并提供给玩家;
  • 促进玩家间的交流;玩家间更易相遇
  • 玩家匹配:”网络游戏是一种交流工具”; 自动选择(根据各种条件快速匹配) 游戏大厅 虚拟世界(可实时交流)

【人员和组织】 开发人员:80% 运维:20%

• 开发（策划,程序,美工,测试,工具制作） 小型2~4人；多数情况20人左右；大型150+；
• 运维（安全,负载,OS管理,数据备份,紧急情况处理）；
• 销售（市场调研,商业调研,资金筹备,质量保证,营业活动,活动举办,商业数据分析等）；
• 开发团队不可或缺的4中职业:项目总监(统筹管理), 程序, 美术, 策划
• 多数20人团队配置:总监2人(技术,美术) 程序4人(架构,底层,逻辑,工具) 美术6(角色,动画,地图)建议外包 策划8人(关卡,剧本,脚本)；
• 不同类型,人员配置不同; 小型企业需避开电影式游戏,选择工具/社交等小型游戏；

【所需技术与经验】

1. 编程基本技术：
   
   • 设计：技术(结构化,模块化,面向对象,设计模式等); 任务(并发性,事件驱动,错误处理,容错性,可用性); 质量(定义, 基准, 检测); UML;
   • 架构: 管理(计划,预算); 编码(多语言,安全模型,内存管理,文档化,优化); 复用(尽量利用已有资源); 质量(单元测试,组合测试);
   • 测试: 功能,性能,负载,安装,可用性等各种检测; 管理(测试计划);
   • 维护: 现有代码的修复,移植,交接,文档化,说明书;
2. 编程基本知识:
   
   • 版本管理,自动化构建/测试;
   • 排序算法; 加密算法; AI(状态机/行为树);
   • 嵌入式脚本Lua Python等;
   • 特定游戏类型的知识(动作,RPG,射击,卡牌,冒险,策略,竞速等不同游戏,基本架构差别很大);
3. 数据库知识: SQL, 查询优化, 高速缓存, 扩展性
4. 系统运维知识: 各种业务流程(通告,数据入库,用户管理,维护等); 服务器部署; 负载均衡; 数据备份/恢复; 服务器监控;

【支持网络游戏主体的3大核心】

1. 数据形式：
   
   • 一次性的(每次初始化后就丢弃)；
   • 持久化的(持续存在于服务端)； 格斗竞速持久性短,MMORPG存续时间长
2. 通信方式：P2P; C/S
3. 响应速度(延迟)：
   
   • 25ms以下(MOBA,格斗等实时对战);
   • 100ms以下(FPS,战略游戏);
   • 300ms(MMORPG等动作性少的C/S游戏中)

三、网络游戏的架构

【游戏编程特性–保持快速响应】

• 游戏编程三大痛苦：
  
  • 游戏数据要在“16毫秒”内持续变化；
  • 大量对象的显示直接关系到可玩性；
  • 不知道会在何时操作,无法事先计算；
• 网游特有要素：通信延迟； 带宽； 服务器(成本,数量估算)； 安全性； 辅助系统；

四、C/S MMO游戏开发

【基本流程】

1. 项目文档：如图根据先后顺序列出的流程所需文档；齐备的文档能大幅降低失败概率。边编文档边聚集必要的程序。
   
2. 开发的进行和文档准备流程;
   概要设计 → 评估 → 详细设计、工作量列表、开发日程、开发原型 → 确定程序和数据形式，开发管理/运营工具 → 筹备服务器，构建运营体制 → 实现收费系统 → 内部测试(不含玩家的多人测试) → 限制人数的内测 → 公测 → 收费 → 每隔几个月内容更新
3. 技术文档：程序(开发工具,单元测试,bot,UML,时序图等) 数据(游戏设定,音视频) 测试(操作手册,性能测试结果) 运营(管理工具,运维操作手册)

【MMO发展趋势和对策】

• 特有游戏内容：处理大量数据; 向玩家严格保密设定信息; 严格维护游戏数据的更改; 设定信息更改容易; 易于结合SNS等其他服务系统;
• 架构的限制：延迟较大; 服务器带宽负荷高; 服务器维护费用高; 服务器停止时间无法游戏;

【策划文档和5种设计文档】

1. 概要设计：简单概括出游戏的核心要素和玩法；
2. 详细设计：没有完备的详细设计开发出来的游戏，最多只能是原型，而非最终产品；
   
   • 核心要素:聊天、公会、战斗、NPC、消遣、地理、拍卖行、排行榜、互动场景、持有物、物品、经济、原来、结构、付费、小游戏、小任务、音乐、玩家PK、婚姻、家园、任务、随机事件、规则、限制、技能、装备 等要素列表；
   • 细化单项:比如(伐木技能 → 树类型; 斧头类型; 技能等级; 关联制造品如弓箭、船等等)；
   • 必要条件:”全部的设定要素有多少?” “各种要素间存在怎样的关系?” “某个数值与另一数值全部被定义”；
   • 技术上,必须准备相关的文档、设法降低程序和数据间的耦合度、开发用于测试数据一致性的工具及用于高效制作大量数据的工具等;
3. 五种设计文档：
   
   • 系统基本结构图;
   • 进程关系图;
   • 带宽/设备资源估算;
   • 协议定义;
   • 数据库设计图;
4. 设计上重要的判断：
   
   • 一概不采用实时性高的策划内容;
   • 并行启动多个内容相同的游戏世界,不与朋友在同一世界游戏也没关系;
5. 延迟200~500ms也无关系(探索,经济活动,战斗等); 不需要频繁发送其他玩家动作方面的数据; 敌人行为调整得较慢,逻辑负荷小;

【系统基本结构图的制定】

• 基础：
  
  • 确定期望的同时连接数,以及收费等商业模式;
  • 确认预想的瓶颈内容,并选择用来避免瓶颈的扩展方式;
• 可扩展性：游戏发布时将服务器限制在最低程度,之后,必须能在不改变程序和设计的情况下,简单地增加服务来加强游戏对大量玩家的支持; 各种瓶颈：
  
  1. 客户端渲染性能瓶颈: 磁盘到主存(非常缓慢,毫秒计); 主存到GPU内存(较慢,微妙计); GPU内存内部传输(非常快,纳秒计);
     
     • 不要”一口气读取所有必需的数据”,而是在保持帧速率的情况下花时间一点点读取;
     • 即使在读取纹理数据的过程中,也尽量只先进行轮廓的渲染,只对所处位置有所了解;
  2. 用户侧带宽瓶颈; 服务器逻辑处理性能瓶颈; 数据库写入性能瓶颈:
     
     • 空间分割法(游戏世界地理分割多服务器/进程处理);
     • 实例法(将负荷高的部分独立到专用服务器处理,如游戏副本实例);
     • 平行世界(即新服。数据库并行化分割,会造成玩家自己无法在各世界间移动,玩家交流也被切断了);
• 估算(实例查看P197)：同时在线数 → 确认瓶颈 → CPU消耗(同时在线数×各玩家面对的敌人数×敌人每秒行动次数×每次行动所需CPU时间×安全系数2 = 1秒) → 数据库处理负荷(同时在线数×各连接的平均数据存储频率×1次存储所需的查询数×安全系数2 = 数据库服务器总共的可查询频率)
  
  • 例子：3万玩家,每人面对20个怪,策划设定玩家速度为5次/秒,测定每次行动需10微秒,代入公式,单核可承载500玩家,则3万/500=60核;
  • 3万玩家1分钟存储1次数据（3万×(1/60)×10×2 = 10000）,假设测定的Mysql实际速度为2000次查询/s,则平行世界所需数量=5;
• 制定系统基本结构图;

【进程关系图的制定】

• (空间分割法)服务器连接的结构:
  
• (平行世界法)服务器连接的结构:
  

【服务器资源估算文档的制定】

• 以进程列表为基础估算：
  
  • CPU频率与核心;
  • RAM内存;
  • 存储器如硬盘;
  • TCP会话数;
• 以CPU为中心和以存储为中心的服务器：
  
  • CPU为中心 :CPU较快,内核较多,内存一般,存储量少,容错性低。一次性的;
  • 存储为中心:CPU一般,内核一般,内存高,存储量大,容错性高。使用期长;
• 服务器资源的成本估算,先从初期费用开始;
• 带宽成本的估算：节省方案(策划的调整; 程序上下功夫);

【协议定义文档的制定】

• 协议：进程与进程之间以怎样的顺序交换怎样的内容;
• 协议的基本性质：
  
  • 哪些作为服务器,哪些作为客户端;
  • 永久还是一次性连接;
  • 是否需要在服务器端管理会话状态(是否是有状态的);
  • 是否有必要管理认证状态;
  • 1对1? 1对多? 多对多?
  • 是否需要推送(Push)消息;
  • 连接中断时是否需要立即结束服务;
• 协议、进程间关系的种类：见表4.5(P213); 协议名根据”连接到哪台服务器”来决定,比如dbsv被gmsv、loginsv、msgsv连接,但都称为”dbsv协议”;
• 各进程类型的协议与”协议的基本性质”的对应:
  
  
  • 左侧的列表示[客户端]; 上面的行表示[服务器];
  • 基本所有都是永久性连接,不是的会注明”随时连接”;
  • “stateful” – 需要在服务器管理各个会话的状态;
  • “auth” – 需要管理认证状态;
  • 1对1, 1对多, 多对多 – 1:1, 1:n, n:n;
  • “push” – 表示需要推送消息;
  • “critical” – 连接中断需立即结束服务; 不需要记为”harmful”;
• 协议涉及的基本策略：
  
  • 在与后端通信时应尽可能无状态;
  • 采用永久连接,因为每次开始TCP会话开销很高;

【协议定义文档–协议的基本性质】

• 实现原则：
  
  • 后端实现基本的、通用的功能, 前端实现专用功能;
  • 采用前端依赖于后端的结构;
  • 协议是无状态和简单操作的集合;
  • 在一个地方接受外部异常(比如数据都用dbsv);
  • 优秀API的调用时序：
    
    • 不调用更好;
    • 调用但无返回值;
    • 调用一次后获取返回值的呈三角状的时序图;
    • 呈锯齿状的时序图;
    • 有必要推送吗？好好考虑,尽量不用,若使用,应在调用处的附近管理函数返回。

【协议定义文档–协议的API规范(概要)】

• gmsv协议:负责执行管理敌人行动、事件、角色升级、作弊检测等游戏逻辑;
  
  • [通知]反映了只调用无返回的”单向时序图”,比如来自cli的鼠标移动角色的通知API;
  • [请求]反映了调用1次期望返回1次的”三角状时序图”,比如来自cli打开物品栏获取物品列表的API;
  • [推送]比如敌人行为,即使cli没发任何指示,gmsv仍需每秒发送数次通知;
• loginsv协议:cli登录管理,负责服务整体使用情况的管理、负载控制以及分配会话秘钥;
• msgsv协议:用于使聊天、即时消息、公会等社交活动能跨越平行世界/空间分割来进行消息交换的服务器; 分三种API:
  
  • [通知]聊天输入,好友添加请求等;
  • [请求]获取好友列表等;
  • [推送]好友上线通知; 其他玩家的聊天分发等;
• dbsv协议:对MySQL等DBMS进行统一的连接;在异步访问数据库时,实现必要的负荷降低处理;将各表的CRUD操作作为API来提供:
  
  • [通知]来自前端服务器诸如玩家角色保存等操作,不需要返回值;
  • [请求]来自前端服务器的查询,比如玩家角色的加载;
• worldsv协议:使用【空间分割法】时,属于世界的所有gmsv都连接到该服务器进程上,负责为各个世界提供通用处理:
  
  • [通知]来自gmsv的通知,比如保存所有在线玩家的坐标;
  • [请求]来自gmsv的请求,比如获取包括其他gmsv在内的所有玩家坐标;
• commondbsv协议:使用【平行世界方式】时,对所有世界共同需要的信息进行持久化;比如保存用户ID、密码、好友列表等与世界无关的:
  
  • [通知]比如gmsv通知其当前在线人数;
  • [请求]来自loginsv、msgsv、gmsv的请求,比如获取各服在线人数;
  • 非平行世界不需要commondbsv，而应由dbsv实现;
• authsv协议:调用结算公司提供的API,相当于与结算公司间的网关，比如获取是否成功收取了某玩家费用;
• logsv协议:通过TCP收集整个游戏服务中的日志,根据时间顺序罗列,保存在文件中,用于检索; 只提供”日志写入”,只通知无请求和推送。

【协议定义文档–协议的API规范(详细)】P223

• API的函数定义(参考P224)：各个服务所提供的API,也就是函数。这里讲解部分具有代表性的API定义.
• API的调用时序：规范更改不可避免,一开始制定完整的时序图并不划算,但应对最低限度的模式进行确认. 表4.9(P230) <协议尽量无状态>
• 必要的时序图：
  
  1. 验证;
  2. gmsv中角色创建;
  3. 登录gmsv、msgsv;
  4. 从gmsv登出;
  5. gmsv中的角色移动;
  6. gmsv中角色的商业操作(购物、交易);
  7. msgsv中向好友列表添加/删除好友;
  8. 向在线后右发送消息;
• 编程前对这些事务的时序图进行绘制并加以确认,可避免以后发生一些难以更改的时序上的问题;
• 复杂性(条件分支和异常处理等根据情况不同而有所差异的程序所特有的处理)尽可能集中在网络的终端,也就是cli侧;
• 各必要时序图详见(P232-P237);
• 时序图制定的要点：只有gmsv、msgsv、loginsv等前端服务器保持状态,并向作为主体的后端服务器和客户端收发各种消息,后端被动应答;

【协议定义文档–数据包的格式】

• C/S MMO主要采用TCP;
• C/S MMO使用包含专用字节数组的二进制协议(“处理负荷较低”; “耐得住更改和攻击”; “良好的开发效率”)
• 二进制协议的实现(从术语的整理开始)：
  
  1. ”TCP流”由一系列0~1400字节左右不定长的”TCP数据包”组成; 最大长度1460字节;
  2. 记录的大小:用户通过鼠标/键盘输入,字节数不多(数十字节左右),但发送频率高,传输量也不小;
  3. 数据部分的压缩和加密:压缩–虽然会对CPU造成一定负荷,但会大幅降低带宽传输量; Snappy、LZO(压缩解压缩快,消耗CPU较少);
     
     • 加密–用RSA和Diffie-Hellman等方式共享秘钥,会话期间持续使用;
     • 为了提高压缩率，加密一定要在压缩完成后进行;

【数据库设计图】

1. 编程前要对重要的表进行设计;
2. 键值存储数据库KVS:如MongoDB(无模式、只有简单的查询、高速、无事务功能<收费和验证等辅助系统需要事务功能>);
3. 在确认策划内容的同时,记录下需要持久化的要素的特性和内容;
4. 了解保存可变长度数据的必要性; 详见表4.10(P248);
5. 表数量越少越易于管理; 需另外建表的数据特性(1.相关信息的数量对各玩家来说差异很大如物品; 2.条目数会不断增加如任务);
6. 数据库性能预测：
   
   • ①查询类型:a.指定主键,只取1行; b.使用主键在内1个以上索引,以一定条件检索、排序<尽量少用>; c.不使用索引<不要采用!!!>
   • ②各表特性与预测: 详见表4.11(P251)
   • ③对拍卖/邮件等历史信息很重要、需要检索的表中采用[查询类型b];其他都用类型a,对于类型a,具备KVS的功能就足够了;
   • ④read：除了日志,其他表的访问模式都是10分钟/次;
     write：
     
     • 用户表基本不写入;
     • 角色、物品、任务日志1分钟/次,是read频率的10倍;
     • 日志表,10秒/次;
     • 其他表都是1小时~1天/次,频率低,不会成为负荷;
       read注意”拍卖” “邮件”; write注意”角色” “物品” “任务日志”;
   • ⑤拍卖:典型实现方法–分为两个表; “拍卖物品表”(每行对应一个拍卖物); “竞价表”(每行对应艺名买家的竞拍价);
     买家查询拍卖物时显示列表、获取某个拍卖物的竞价列表 这两种处理的负荷较高; 优化,新上架物品延迟10~20秒关系也不大;

【服务器/客户端软件+中间件】

实践中不可或缺的开发基础:ProtocolBuffer等;

【程序开发中的基本原则】

1. 数据结构优先:构成游戏世界的数据结构要在编码前大致确定下来;
2. 维护可玩状态:经常试玩游戏,在对可玩状态确认后继续进行开发;
3. 后端服务器延后:以客户端 → 前端游戏服务器 → 后端服务器的顺序开始开发;
4. 服务器持续测定:经常对延迟、带宽、CPU时间进行测定,将其表示出来,以此为参照进行开发;

【实现–编程开始】

1. 开发安排:
   
   • ①框架阶段:编写cli, gmsv, dbsv, 最低程度能进行测试的1组与游戏本质内容无关的程序; (1名主程1周时间); 详见表4.12(P269);
   • ②原型阶段:保持运行状态,持续扩展和调整;开发1个自动对服务器测试和1个可进行游戏的客户端; (1+1客户端程序); 框架见表P270;
   • ③整体实现:若确认游戏具有可玩性,开始制作开发工具,dbsv以外的后端服务器; (2~4程序)
   • ④量产阶段:进行游戏数据的量产;
   • ⑤收尾阶段:修正Bug,调整平衡性,试玩等开始准备正式运营;
   • ⑥试营后阶段:并行实施用户支持和补丁的追加;
2. 进度管理形式:
   
   • 1~2阶段[文本文件];
   • 2~3[xls文件];
   • 3~+[项目+跟踪管理工具如JIRA]
3. 游戏特殊性:”不实际运行起来是不会理解的!” [可玩,满足性能,通信,数据等开发要素]
4. 框架整体结构:如SDL渲染库; boost; cli, dbsv, gmsv所有源码; proto协议定义文档及生成的原文件; 详见(P276)
5. 首先编写cli与gmsv的协议定义文件,先完善cli测试bot直到通信顺序和参数没什么大问题时再实现客户端;
6. 协议定义要点: ①通信连通确认; ②账号登录; ③账号验证; ④角色创建; ⑤角色登录; ⑥角色移动; ⑦角色攻击;
7. 移动:
   
   • 以方格为单位;
   • 路径搜索和实际移动处理;
   • 移动路径的发送方式(优先发送最终结果);
   • 移动通知范围;
8. 自动测试客户端:(P300);
9. gmsv中线程的使用:(P305);
10. 图形客户端cli的创建和运行确认;
11. 框架之后的开发:
    
    • ①充实游戏设定数据;
    • ②增加影音特效改善界面;
    • ③用于高效的服务器启动和版本管理等的工具;
    • ④用于分析游戏结果/查找问题的日志解析工具;

六、网络游戏的辅助系统

【辅助系统需要的功能】

1. 现有的通用服务,如Steam、Uplay、AppStore等；
2. 功能一览，详见表6.1(P364);

【交流/通信功能】

1. 玩家匹配:P2P MO游戏中查找对手玩家;
2. 游戏大厅:P2P MO游戏中玩家查找对手;
3. 中继服务器:解决有NAT问题的P2P MO游戏玩家通信问题;
4. 聊天功能:客户端 → 聊天服务器 → 服务器推送(1~2秒内)(不要给不在线的玩家发送)(不需要保存日志);
5. 邮件;
6. 好友列表;
7. 玩家状态:登录/退出(绝不能省略), 所在服务器/位置(尽量别省略), HP变化/击杀敌人的名字等(可省略);
8. 加锁服务器:防止双重登录、数据损坏或无限增长的情况;
9. 黑名单:”客户端”服务器消息全发送,客户端决定是否显示; “服务端”聊天邮件等功能结合,会加大处理负荷;
10. 语音:1人发言需10kbit/s左右,向5人发送要占用50kbit/s; 实际游戏中同时发言玩家并不多,可根据该特点设计;

【客户端实现相关的辅助系统】

1. 玩家成绩管理:如何防止作弊、怎样在之后追加游戏成绩;
2. 存储功能:需防止作弊、DB碎片化; 可通过用户ID进行横向分区；
3. 客户端更新:利用现有服务、Bt等工具实现,注意带宽、文件一致性; 访问更新服务器 → 版本对比 → 下载 → 校验 → 更新 → 重启;
4. 排行榜:
   
   • 使用DBMS时,增加”rank”列,排名前100的数据每次都重新排序并实时更新结果,其他数据排序和更新每天1次;
   • 内存中处理,每次都进行排序,但不能处理大于100万行的数据;
   • 临时排名法:找出”在比自己分数低的玩家中,分数最高的玩家的排名”然后加1;

【运营辅助系统】

• 新闻发布:有限定时间、自动更新、已读管理等问题;
  
  • 客户端版本比对时更新显示;
  • 游戏开始时,弹框遮挡开始按钮;
  • 游戏中,如邮件红点/商店购买东西时提示;

【付费相关的辅助系统】

1. 付费认证:a.付费机制(包时/月; 付费道具; 虚拟货币); b.支付序列图(P386图);
2. 虚拟货币管理:功能需求(总额显示; 交易记录; 即使故障也不会轻易丢失);
   
   • 交易日志(交易ID; 玩家ID; 增减值; 原因; 日期);
   • 定期维护历史记录,比如备份数据库,删除过期(如1年前)的数据等;

【其他辅助功能】

1. 游戏数据查询工具:最低要求–能以便于阅读的形式浏览玩家的游戏数据,并具备关键词、时间、项目或角色数值查询的功能;
   
   • 游戏数据的保存:
     
     1. ①划为不同数据列;
     2. ②BLOB;
     3. 两种混用;
   • 需要索引的数据用方式①,其他以方式②保存;
   • 游戏设定数据和数据库–使用KVS这样的ODBMS(对象数据库)更适合;
2. 敏感词过滤:与黑名单的区别–①不需要用户动态增加关键词; ②敏感词用户不可见; ③无需实时更新;

七、支持网络游戏运营的基础设施

【基础知识】

1. 基础设施架构需要进行的工作(从开发整体来看)：
   
   • a.策划概要的决定;
   • b.程序设计;
   • c.基础设施的大体估算;
   • d.程序实现;
   • e.基础设施估算;
   • f.询问报价;
   • g.报价评估、下订单;
   • h.决定日程;
   • i.架构;
   • j.负荷测试,调试,反馈;
   • k.上线;
   • l.开始运营;
   • m.设备和服务更新;
2. 硬件、信息设备:服务器, 存储设备, 路由器/防火墙;
3. 软件：服务器OS(Red Hat / CentOS), 数据库(MySQL / Mongo), 杀毒软件, VMware;
4. 服务费：监控服务; 域名使用费、电子签名服务费;

【架构技巧】

1. 规模扩大/缩小：对于MySQL等数据库服务器,调整风险和成本较高; 对于gmsv等前端服务器,调整容易;
2. 典型环境：
   
   • 初始环境(公司内部搭建的小规模服务器);
   • 数据中心(机柜中设置自己购买的服务器);
   • 云服务;
3. 负荷曲线：初始设计应考虑峰值的应对;
4. 服务器部署:测试服务器程序 → 打包 → 上传 → 暂停用户登录和注册 → 强制退出游戏 → 停止旧版本 → 备份数据库 → 需修正数据库时运行相应的SQL批处理 → 确认数据库 → 启动新版本 → 自动+手工测试 → 开放服务器
5. 登台环境:与正式服环境相似,用于测试新版本; 需注意防止版本发布误操作; a.面向开发者; b.面向特殊设定的一般用户;
6. 监控:
   
   • OS: 设置MRTG, 监控CPU&内存&硬盘使用率, 进程数, 通信量等信息;
   • 数据库: 大小, 进程, CPU, 规定时间内能否执行完特定SQL查询, 是否有慢速查询, 单位时间处理的查询数;
   • 应用: 通过HTTP只返回给监控服务器（同时在线数, 内存中对象数量, 单位时间内主循环的处理次数）;
   • 用户行为: 影响游戏平衡的恶意行为, 不良商家或玩家的行动(比如金币增加最多的10位, 发送过禁止词汇);
7. 日志管理:
   
   • ”尽可能保留所有日志” “原因和结果都保留”:
     
     • 道具交换/获取/使用;
     • 玩家技能使用/获得;
     • 经验/HP等角色状态变化;
     • 对敌人造成的伤害/技能效果;
     • 与商店NPC的所有对话;
     • 登录登出记录;
     • 地图跳转记录;
   • 日志输出方法:
     
     • 通过标准输出中的管道传输给其他进程或在文件中保存;
     • 写入文件并传送给其他工具;
     • 通过网络发给服务器;
     • 写入syslog;

【负荷测试】

1. 筛选关键点测试:
   
   • 超负荷会造成致命影响的部分;
   • 发布后不易修改/横向扩展的后端部分;
   • 关键创新玩法;
2. 具体测试场景:
   
   • 创建大量用户,保存游戏信息;
   • 用户登录;
   • 随机移动、发送消息5秒/次;
   • 用户退出;
3. 测试的分解:
   
   • 测试后台服务器负荷时使用多台游戏服务器;
   • 在1台游戏服务器上测试最大同时在线数;
4. 监控命令：①vmstat; ②/proc/interrupts; ③ps; ④top; ⑤netstat;

【游戏上线】

1. 上线前：
   
   • ①防止系统外部攻击的安全设定:
     
     • 数据包内容检测(固定字段);
     • 每个IP地址的连接/带宽限制(路由器防DoS);
   • ②系统内部管理相关的安全设定:
     
     • 远程连接服务器用SSH登录;
     • 只对部分人员开放服务器访问权限;
     • 参考网络安全相关书籍;
2. 上线后：
   
   • ①服务器进程因Bug当机–准备好自动启动的脚本;
   • ②服务器进程在高负荷下无法访问–管理程序通过HTTP连接查看运行状态,若无反应或超负荷,SSH登录服务器Kill进程(脚本化);
   • ③服务器不能访问–一旦不能访问立即重启;准备好预备服务器,可随时更改路由器的NAT设定进行快速切换;
   • ④因Bug原因保存了异常数据:
     
     • 简单回滚数据;
     • 运行问题解析脚本修复;
     • 手动执行SQL修复;
3. 服务器组群化：使用脚本、容器等方法减少操作,降低失误;
4. 故障应对:
   
   • 程序: a.等待; b.重启程序/数据库/OS/服务器; c.更改设定文件; d.发布更新; e.修改数据内容; f.修改程序;
   • 非程序: a.搜索日志; b.查看/修改数据库内容; c.更改设定文件; d.重启;

八、网络游戏开发体制(团队管理的挑战)

【特有的挑战】

1. 游戏数据的持久化：
   
   • ①运营刚开是的3个月最困难,运营可持续5~10年;
   • ②游戏的运营和技术人员–合理安排工作和计划,防止频换更替人员;
   • 要点:
     
     • 希望长期参与项目的人是否有相关技能;
     • 如何合理使用项目完成后想立马参与新项目的人员;
     • 运营后团队的休假计划如何安排;
     • 项目奖金该如何设置;
2. 游戏中玩家关系：
   
   • 对抗–可互相攻击/破坏,如对战/即时战略类游戏;
   • 竞争–如赛车等竞速游戏;
   • 合作–不合作无法取得进展,不存在胜负;
   • 共享–共享少量数据,比如好友送礼或在游戏空间小破坏,基本单人也可玩;
3. 游戏结果的共享范围：
   
   • 只展示给自己;
   • 可逐个发送给别的玩家;
   • 互相关注的好友;
   • 展示给粉丝;
   • 公会、粉丝团;
   • 游戏服务器的范围;
   • 不限范围的全体玩家;
4. 聊天系统的类容：①没有聊天; ②有固定句子; ③自由输入;
5. 维护和升级的计划：每周、隔周、每月或不定期; 一般更新越频繁,玩家的留存率或回头率越高;
6. 代码规模：如果需要迭代的代码过多会遇到问题;

【网游开发团队的实际情况】

1. 工作分配：
   
   • 横向分配 – 客户端和服务端开发工作分开;
   • 垂直分配 – 根据游戏策划内容分配(如战斗,赌博,钓鱼等);
2. 程序员提升：
   
   • ①守[从模仿开始]:
     
     • 参考模仿现有游戏(要模仿经典);
     • 要使用标准的、争议少的库;
   • ②破[技术研讨会]:
     
     • 参加如GDC等技术讲座了解自己与业界资深人员间的技术差距并学习;
     • 多参与不同技术领域的游戏开发,比如Web,手游,教育游戏,数据挖掘等项目;
     • 关注Blog,看书学习,共同提高等;
   • ③离[最高级阶段]: 带领团队开发全新游戏,发表书刊论文等等;
3. 项目管理：比如采用Scrum进行敏捷开发; OA流程工具管理等;
4. 项目的移交：
   
   • 测试的准备 – 实际移交前,首先更新游戏的自动化测试工具并添加尽可能多的操作;
   • 缩短环境搭建时间 – 如OS、必要程序库、开发工具的安装等（推荐使用容器）;
   • 设定合适的访问权限 – 交接过程中应”逐渐”开放最大访问权限;