game-dev-summary.md

游戏开发 - 记录/总结

技术与规范

框架选择

• [[game-client]]
  • [[cocos2d-x]]，最适合 2d、H5，现也部分支持 3d
  • [[unity]]，最适合 3d 游戏，也支持 2d，H5支持比较弱
• [[game-server]]
  • 自行实现：纯 [[C]]，或纯现代 C++ 或 C/C++ 混搭(better C)开发方式
  • 成熟框架 [[skynet]]，[[kbengine]]，[pomelo]，smart-fox，RakNet ...
  • 其他选择 [[golang]]，[[node.js]]，[[erlang]]

网络模型

• 自实现异步网络库，使用通用C/C++技术，方便跨平台移植，高并发
  • 如: boost::asio，libuv 等
• H5 长链接，使用 websocket
• [[golang]] - CSP(Communicating Sequential Processes)模式
• [[erlang]] - Actor模式

通讯协议

• 使用 msgpack，protobuffer，flatbuffer 等成熟通讯库
• JSON通用简单，但数据包过于庞大，不推荐

数据库

• 老牌 [[SQL]] 数据库 [[MySQL]]，方便与任何运维人员配合
• 考虑使用 [[NoSQL]]：[[mongodb]]，[[redis]] 等

规范

• 代码规范，风格，提前约定
• 版本管理
  • 推荐使用[[Git]]，
  • [[SVN]] 使用分支需要注意!
• 注释可文档化，方便新人了解及旧人交接
  • 考虑 doxygen

设计与实现

玩家数据

• 数据的划分
  • 方便逻辑异步执行，便于多线程化
• 模块耦合度注意
  • 降低关联，减少历史负担，减少编译时间(C/C++ 头文件依赖)...
• 排行榜，擂台挑战等功能，需要在玩家离线的状态下仍要对其信息进行读取与更新
• 提前考虑用户ID设计

资源文件

• 主要包括：excel，csv 等策划数值表格的处理
• 手游改动频繁，尤其是字段的稍有改动牵扯较大，如何简化?
• 建议，资源配置文件类型尽可能简单，只需: 整型，浮点，字符串。枚举值按整数对待

数据库

• [[MySQL]]
  • 一般使用 innodb 引擎
  • 注意调优 MySQL 参数，尤其是 innodb_buffer_pool_size，详见此处
  • 提前准备备份方案，推荐使用 xtrabackup 进行物理备份
• [[mongodb]], [[redis]]
• 部分 游戏角色数据库 所承担功能，考虑同个 GlobalServer 下的所有大区公用一个
  • 无需与其他 游戏角色数据库 相配对，手游频繁更新会造成负担
• 考虑单个实例数据库连接过多问题
  • 划分好单个 GlobalServer 下所承受大区数量，或按其他方式划分
• 数据库表的设计谨慎，
  • 尽可能多的进行时间记录(物品获得，装备变更...)以方便逻辑扩展，以及上线后问题的校对检验
  • 库表的属性列变化，非必要不做删减，只做添加，做到兼容旧表结构
  • 表的命名 tbl_xxx 看上去前缀 tbl_ 比较冗余，但是似乎比较方便代码中检索相关sql信息
    • Loading注：
      • 仅仅为了在代码中方便识别表名完全没必要，code中检索也可以用sql关键字查看或模式匹配。
      • 前缀的重要作用：
      • 一、大型数据库业务中用来区分模块；
      • 二、用来区分大量的表、视图、存储过程、函数等；
      • 三、防止关键字冲突，且方便移植不同数据库，｀分隔符是mysql独有符号，不是sql标准。
      • 综上，在游戏表少、业务简单、sql简单的情况下，可以不用前缀，也可以用简单前缀表示，数据库名和字段名不要用前缀，t_表名，i_视图名，p_过程名，f_函数名。不建议使用｀将表名括起来
• 做好行为日志记录，在数据库表设计的基础上再全面考虑
• 数据库日志，考虑冗余字段会节省很多时间，如：已存在 userid，方便的话，就把 nickname 也记录上
• 尽量不对数据库表的字段进行后续变动，如必须修改，确定好影响范围，以防有存储过程或代码上的遗漏
• 存储特殊字符的字段，在 C++ 侧一定要调用转义函数

日志

• 详细的日志有助于错误排查，日志打印等级需要提前注意约定，慎重考虑
• 实时写入 file 的日志对效率有影响，引入缓冲队列多线程定时刷入 file
• 参考或者引入成熟开源日志库，如: log4j，syslog ...
• 存入数据库的日志

充值

• App Store 的沙盒测试环境与正式环境有差异
  • 如: 某 JSON 字段内容测试环境看上去只有 int32 正式环境却需要 int64

版本更新

• 服务器打包需要根据大区类型分类 (注意考虑分区以及编号问题)
• 服务器的更新是用脚本分开更新的
  • 区多的时候需要时间比较多，启动也依然
• 配置文件也是每个区一份
  • 配置文件需要有方便的生成工具
• 数据库的更新
  • 必须保证语句正确
  • 有条件需要测试确保语义正确，不然回退很麻烦
  • 不要出现 drop 语句，除非必要
  • 对于 update，delete 等语句需要小心，对于交叉查询避免出现笛卡尔乘积(用left join，join等)
• 更新的时间尽量预估多一些，提前通知到相关人员
• appstore审核区和正式区由于提审包不能热更新的关系，需要每次提审的包内设备编码和正式区不同
• 建议下个项目配置文件只保留一个数据库的配置，其他的配置信息从该数据库的某个表内读出来

测试

• 引入自动化测试工具，类似 printf 函数的可变参数对应与否可以提前检测出来

GM

• 简单且必要的功能需要提前做好准备
  • 如: 封号，禁言，踢人...
• 系统功能的管理，需要仔细考虑
  • 如: 功能的状态，不仅仅用于关闭，应该有默认(可能会周期性开启)，关闭，开启

运营与维护

• 玩家行为埋点，以便分析留存统计数据（客户端做主要配合）
• 做好服务器划分:
  • 依照游戏规模大小，注册人数，同时在线人数，CPU占用率，峰值内存消耗 ...
  • 单个物理机开多区? 多个物理机开多区?
• 重要货币的发放设置上限，以免引发类似钻石与金币发送数目交错的问题

远程连接管理:

• [[Linux]] server
  • screen，tmux
• [[Windows]] server
  • 本地与远程无法复制粘贴，重新创建 rdpclip 进程 (任务管理器中利用管理员特权创建)
• zabbix 等 [[DevOps]] 工具

渠道及第三方接入

• 通讯方式通用，简单简洁，可扩展。如：HTTP
• 接入 sdk 一定注意账号取只有数字+英文的ID，不要取中文或特殊字符的名字（oppo先例）

恶意行为防治

• 恶意注册限制
  • 单个设备ID注册限制
  • 单个IP注册数量限制
• 高频请求攻击
  • IP请求频率统计
• 大数据包攻击
  • 包头 size 字段使用2个 byte 表示，最大长度为65535

其他注意

• 合区需求，考虑与逻辑的交融（邀请功能）
• 效率优化
  • 战斗，合成 --> 多线程
• 功能优化
  • 巨型数据包（策划需求膨胀导致）拆分
  • 任务系统优化
  • 完善的定时器系统
  • 带成长的机器人系统 (人数极少区需要，部分需求可以用其他方式实现，如：随机虚拟数据...)
• 逻辑优化
  • 极限数量角色限制？
• 维护优化
  • GameServer -> DBServer 指定玩家信息重加载
  • 友情点日志，方便校对玩家反馈