游戏开发纲领

鉴于各个项目开发的游戏类型、开发规模和组织结构等有所差异，下文总结了大部分项目开发会涉及到的纲领性总结。有些内容，不便于详细展开，有需要会另开文章介绍。

本人亲身经历其中大部分事项以及流程改进，少部分内容是个人见解并有待验证。

本人能力有限，半刻之间未能想全，此后一旦想起要点，会逐渐添加和完善，如有不对欢迎指正。

目录

框架开发

网络数据

  • 数据格式
    1. 节点间通信。它不像与前端的通信变动频繁，框架定下来后基本不变，格式不需要较高灵活性。另外署上，这 些节点只在内网通信，理论上也不需要太高的安全性或去掉加密。
    2. 前端延时不敏感的业务。可以牺牲部分性能，来满足读写灵活，比如支持数组和嵌套类型。常见的高序列化库有 msgpack和protobuf等。
    3. 前端延时十分敏感的业务。去掉内嵌类型或限定嵌套层级。或者数据1字节对齐，字段根据预计算的量指针强转。
  • Ringbuffer缓存。单读单写双锁队列，同时也减少内存GC
  • 加密/安全。鉴于游戏的强交互特性，很不看到有项目用非对称加密算法。而对称加密的方案，常见得最多1.Diffie-Hellman密钥交换+随机密钥对称加密 2.RC4 3. DES

网络延时

  • 网络技术层面
    1. 尝试使用udp，降低核心业务的延时。
      1. 大量游戏证明可靠UDP也TCP快（查资源证明）
      2. 一次发多次包，统计上降低失败概率
    2. 参考《英雄联盟手游戏》，同时开启移动与wifi双通道通信。
    3. 根据各个终端的地理位置，匹配到相近的机房
    4. 关闭TCP延时发送
  • 业务层面
    • 优化需要低延时逻辑的性能消耗
      1. 减少频繁的GC调用
      2. 在不影响AI行为树需求的情况下，降低AI更新帧率
    • 部分战斗逻辑，转移到终端上模拟
      1. 战斗陷阱
      2. 战斗AI
    • 牺牲部分通用设计原则。缩减指令数量
  • 协议包设计
    • 合并协议包，减少来回通信次数
      • 设计一个特殊协议，里面包含多个具体的协议包
    • 协议以行为数据单位

本地化管理设计

特别是前端的前期开发，要预先为本地化考虑方案，后期再想解决方案，修改的地方势必很多。

  • 游戏设置有语言选项，只是简单的文本言语切换。
  • 除了文本外，UI界面、模型和音效等差异巨大。本地化版本与主干版本游戏内容没必要保持一致，大多数项目会选择将本地化版本独立出来开发。

业务分层设计

分层设计，另一个角度看，就是可以细化/独立出工作内容，助推开发流程更快地迭代。

  • 前端框架支持隔离界面/动画/数据库/网络等，进行单元测试
  • 后端框架支持游戏GM指令测试/指令拉取角色彩数据（数据中心）

前/后端公共代码

  • 业务通用枚举定义
  • 网络数据序列化逻辑
  • 通用算法及业务方法
    1. 打乱算法
    2. 权重随机算法
    3. 日期函数
  • 业务配置表
    1. 配置字段只读不可改警报
    2. 可配置字段不导出
    3. 配置表本地化接口封装 a. 按语言划分 b. 按渠道划分
    4. 通用字段类型 a. 业务时间格式 b. 物品格式 c. 活动格式 d. 任务条件格式 e. 其它特定业务格式
  • 错误码设计，外部/内部错误分段
    • 外部错误码，要求对应文本内容
      • 模块分段
    • 内部错误码，非必要求对应文件内容。如果没有才用通用内部提示，但是提示内容不要输出与代码逻辑有关的信息。简单地输出就足够“错误码:%s”
      • 节点分段
      • 服务分段
      • 功能分段
  • GC性能
    1. lua配置表，取消内部GC扫描消耗。luajit-table-const

日志

  • 生产环境设置日志输出级别。
  • 支持对指定角色设置日志开关
  • 搭建日志聚合平台。如elk
  • 登录流失统计日志
    • 应用启动main
    • 广告/Logo
    • 版本更新/各种预热流程
    • 第三方SDK初始化流程
    • 登录后端服务流程

热更

  • 基于编程语言特性的代码编写规范。比lua少定local变量，多用元表作抽象层
  • 资源热更打包

文档/规范

主要目的是起到示范的作用，以免具体工作内容各有各的做法。也能方便后期的优化工作实施

  • 代码/脚本/美术等资源的，主干/分支/稳定版本的管理文档。让新入职员工，快速构建工程
  • 业务框架文档。以了解框架的运转流程 a .lua代码规范
  • 业务设计文档。以了解业务初期设计的原意
  • 专项技术文档。分享开发难点，提交各个同成的技术水平
  • 软件打版流程文档。了解开发的对接流程

纯前端：

  • 美术资源性能规格/基准
    1. 按模型/场景顶点、面片、材质划分
    2. 按粒子系统参数划分
    3. 按音频压缩率划分
    4. 按渲染特效划分，如PBR/HDR，后期处理等
    5. 按渲染帧率划分
    6. 设置分辨率划分
    7. 按同屏人数划分
  • 断网重连
    1. 协议重发
    2. 心跳超时判断
    3. 切换后台处理
      1. 返回前台，立即进行一次心跳协议，检查网络
  • 登录加载性能。 经历多几个项目，几乎都出现会有大量登录失败/登录时间太长的日志。这严重影响运营数据，大佬们都非常重视登录的TPS
    1. 踢除登录流程不必要协议请求/返回。
    2. 将优先级不高的请求/返回的全局数据，延后到登录成功之后进行
    3. db数据加载和数据分离处理
      • 避免逻辑顺序依赖
      • 避免中途异常，导致数据&逻辑不一致

  • 配置表加载性能。 不要用xml，Json这类文本格式，太多冗余信息，占用更多的空间。更好的选择有csv，protobuf，msgpack等，或自研更紧凑的二进制格式

  • 内存释放策略
    1. 利用游戏场景切换，释放部分资源
    2. 进行是战斗，释放所有非战斗资源
    3. 定时检查业务内存
  • 图集管理
    1. 按大图片划分
    2. 按透明或非透明划分
    3. 按常驻控件划分
    4. 按战斗与非战斗划分
  • 第三方SDK调用封装
    1. 登录接入
    2. 支付接入
    3. 日志上报接入
    4. 语音接入
    5. 性能分析接入

纯后端

  • 最大注册量，同时在线性能基准。了解开发规模，预先考虑实现方案

  • 机器压测工具

  • 通用重置周期性数据。 游戏中有大量，角色的周期性玩法。如每日任务，玩法次数和周活跃值等。

  • 通用业务数据持久化。 一个简单的办法，父类实现了持久化代码，提供get/set字段接口。子类封闭实际字段数据

  • 通用排行榜。
    1. 非实时榜。考虑上排人数，选择排序算法，常见的有二分插入排序
    2. 实时榜。考虑用redis zset
  • 停服维护的白名单设计
    1. 局域网IP
    2. 账号级而不是角色级，账号名拼接考虑渠道信息

  • 负载排队登录 在线人数超出压测的数值，容易令计算器过载，严重甚至宕机。 提高登录QPS，非角色登录流程必需的网络包延后推送

  • 与前端对接的协议热更

  • 非法请求检查
    1. 频繁的业务请求
    2. 协议包crc检查
    3. 协议包序列号检查
    4. 上游协议处理之间的CD时间，频繁的请求后端主动断开连接
  • 数据库
    1. 分布式ID生成规则
    2. 指定角色的养成数据，需要从线上数据库导进开发环境
      • 如果主键是角色ID，需要在角色ID的生成规则中，考虑在任何情况下唯一
    3. 定时备份数据库
  • 容灾热备服切换
    1. 登录备用服
    2. 聊天备用服
    3. DB备用服
    4. 云服务自动迁移的进程服务器ip地址变更，业务节点间能重新发起重连
  • 跨服玩法设计
    • 跨服业务如果在多个服务进程中存在关联数据，应该考虑在合服/清库其中一个服务的数据时，其它服务进程的数据应能自主纠正/重置
  • 聊天转发服 聊天服与游戏服区分开，以免影响到游戏服
    1. 角色聊天限流
  • 跨服设计
    • 以应用层解决跨服数据保存，而不是数据库层面
    • 以业务功能为主，解决跨服数据合并问，而不是数据库层面
      • 跨服配置变更处理流程
  • 非实时热点推送设计
    • 在线角色，由前端触发拉取信息/后端推送空包触发前端发拉取请求
  • 热更
    1. 进程启动配置热更
  • 运维
    1. IP白名单
    2. 账号白名单
    3. 在架构里面保证模块自动屏蔽，和在线扩容
    4. 特殊道具监控，道具数量超出数值范围监听
    5. 游戏数据与GM后台，的通信协议
      • 读，游戏业务模块需要GM后台展示
      • 写，游戏业务模块需要GM后台修改

软件质量

新人入职

  1. 指派导师（同事），辅助入职
  2. 快速掌握业务开发的demo文档
  3. 账号开通
    1. 工程仓库权限开通
      1. 配置表
      2. 代码工程
      3. 美术工程
      4. 公共资源工程
      5. 策划文档工程
    2. 邮件开通
    3. 打包工程开通
    4. GM后台账号开通

技术考核/绩效

  1. 量化工作任务

静态代码分析。如tscancode、luacheck、Valgrind

  1. luacheck异常责任人工具luacheck_blame_report

性能监控

  • 搭建监控平台。如prometheus, zabbix
  • 性能埋点 操作系统层面的性能过于抽象，不利于分析性能问题。应用程序本身必须要做性能埋点
  • 业务性能
    • 排行榜刷新耗时
    • 跨天任务&活动重置耗时
    • 数据密集处理的逻辑
      • 打散拉取
      • 预先拉取
      • 如小数据包，由另一端主动推送 *框架层
    • 定时器
      • 定时器性能信息收集，记录创建定时器的调用端位置，tick的执行次数，累计耗时
      • 战斗单帧耗时
    • 处理请求
      • 前端请求
        • 请求接口的平均处理耗时
        • 请求接口次数
      • 后端内部请求
        • 内部节点rpc调用耗时
    • 服务实例
      • 累计耗时
      • 协程个数
      • 网络流量
    • 数据库处理耗时
  • 编程语言

配置&数值

  1. 表格对比
  2. 数值表禁止填入测试数值。严格使用GM指令辅助测试 a. 如果不得不引入测试数据，需要区别gm指令与正常流程获取来源码
  3. 物品数据来源
    • 在导出时，增加与表名有联系的字段

测试

  1. 内外网服用例回归

  2. 业务检查清单 a. 跨周期业务是否正常 b. 业务数值临界点是否正常 c. 数值篡改/重发业务接口能否正常

  3. 数据检查清单 a. 数据库落地格式是否正确 b. 协议数据格bcc是否正确

  4. 日志检查清单 a. 检查是否出现warning和error级的日志 b. 检查是否有其它监控功能的日志 - 配置表转换异常 c. 去掉调试用的临时日志

常见业务问题点

  • 业务数据各部分数据分别存放在多台不同的物理机，业务时间在物理机不一致的问题
  • 框架若支持执行代码过程中跳出当前状态，注意业务重入问题
  • 上游循环逻辑，防范下游逻辑不可修改上游循环队列
  • 跨服到单服的多个角色数据，必须将同一单服的数据合批发送
  • 尽量避开功能触发时间，重启服务
  • 发送关键数据时，目标服务处理失败。解决：写入离线数据，适时通知目标服务读数据处理。
  • 广播
    • 尽可能由前端主动拉取数据
    • 后端规则要求不能主动推送的大数据包，通过推送空包让前端主动拉取
  • 配置ID修改，导致逻辑异常
    • 数据层，尽可能避免存储配置ID
      • 关卡1-1，比如以”1-1”作为主键引用，而不是配置ID
      • 选择物品/释放技能，以下标序号传送，而不是具体配置ID
  • 尽可能由后端开关控制功能的开启/关闭
    • 渠道审核

外挂安全

  • 内存加密。
    1. 重点业务数据/逻辑加密
      1. 随机魔法数据异或
    2. 协议数据加密
  • 时间加速检查
  • 本地资源加密
  • 下发核心代码
  • 检查后台外挂程序
  • 后台复盘数值
  • 检查关键数值是否超出业务最大上限
  • 软件本体签名检查
  • 软件本体内文件/目录结构检查
  • 签名验证，防hook
  • mono改用il2cpp
  • 用户输入检查
    1. 正负数值检查，如购买数量不可能是负数
    2. 下/上限数值检查，如游戏数值超出策划理论上限
  • 外挂/利用漏洞刷资源的惩罚机制
    1. GM后台给角色设置负值代币
    2. GM后台给角色挂载一段负向buff，如削弱战斗数值，或关键资源或的比例
  • 角色产出物品数量监控

加速开发

第三方工具

  • 网络包拦截/篡改工具/弱网工具Network Emulator For Windows Toolkit
  • 编辑器插件

工程工具

  • 检查代码提示语代码中，还没有本地化的语句
  • 工程创建脚本化
  • 配置转换工具
    1. 数值格式检查
    2. 唯一主键，及外键关系检查
  • 异常监测
    1. 异常上报
      1. 邮件推送
      2. 前端推送
    2. 问题处理人定位及反馈 git工程luacheck异常责任人工具luacheck_blame_report

    纯前端：

    • 冗余资源检查
    • 依据配置表数据，检查资源缺失
    • 应用程序/资源打包工俱
    • fps帧率显示
    • 美术特效耗时排序

    纯后端：

    • 开发服/线上服切换
    • 业务gm指令
    • 远程工具
      1. 跳析机脚本
    • 压测工具
    • 日志聚合
    • 后台管理
      1. 进程重启
      2. 清理数据库
      3. 热更代码 1．业务代码
        1. 配置表数值
      4. 核心游戏数据监控
        • 充值
        • 战斗属性
        • 所有可提供输入的业务数据

  • git开发流 a. SourceTree自定义菜单命令 重置本地Git代码到远端最新版本

  • jenkins开发流 a. Jenkins流水线 ssh-agent执行远端代码

上线开发流程对接

  • 线上更新前准备
    • 研发功能版本内容
    • 运营功能版本内容
    • 运维协调内容

游戏运营&客服对象

  • 数据保存容忍一定程度的数据冗余，方便运营二次提取数据
    • 分库埋点数据。
    • 周期重置数据，尽可能在数据结构设计，尽可能在数据上层以周期索引的形式保留历史数据
      • 每天每周每月
      • 活动玩法
    • 多表关联处理的逻辑，均要在各表都做完成标记
      • 由运营生成的兑换码，需要游戏后端和运营后端，双端标记完成
      • 生产&消费，均要标记完成



原文:
https://lizijie.github.io/2021/10/10/%E6%B8%B8%E6%88%8F%E5%BC%80%E5%8F%91%E7%BA%B2%E9%A2%86%E6%80%BB%E7%BB%93.html
作者github:
https://github.com/lizijie

PREVIOUS排行榜-排序
NEXTlua与c交互笔记