游戏存档与发布

概述

游戏开发进入尾声，两件事决定产品能否"活下来"：存档可靠——玩家关机后进度还在；发布顺畅——用户打开就能玩。本文围绕存档设计与发布适配展开，重点讲解存档数据最常见的坑：版本演进导致的兼容问题。

存档序列化

序列化格式选择

格式	可读性	体积	跨语言	适用场景
JSON	好	中	好	Web 存档、配置、通用交换
二进制/MessagePack	差	小	好	体积敏感、高频保存
压缩 JSON	中	小	好	存档较大时（地图、战报）

Web 端最常用 JSON：浏览器原生 JSON.stringify / JSON.parse，可以直接持久化到 localStorage / IndexedDB。体积敏感时再用压缩（如 pako 的 gzip）。

存档结构设计

一份健壮的存档至少包含三部分：

{
  "version": 2,          // 存档格式版本号（最重要）
  "savedAt": 1754035200000,  // 保存时间戳
  "data": {              // 真正的玩家数据
    "player": { "name": "勇者", "gold": 1280, "level": 12 },
    "inventory": ["铁剑", "药水"],
    "settings": { "sound": true }
  }
}

version 是版本兼容的基石：读取存档时先看版本，再决定用哪套解析逻辑。

版本兼容升级

游戏发新版本时数据结构通常会变化（新增字段、重命名字段、字段类型改变）。永远不要假设存档与新代码结构一致，读取时要做归一化：

function deserialize(text) {
  const raw = JSON.parse(text)
  const from = raw.version || 1
  // 旧版缺失的字段全部补默认值
  return {
    version: 2,
    player: {
      name: raw.player?.name ?? '勇者',
      gold: raw.player?.gold ?? 0,
      level: raw.player?.level ?? 1
    },
    inventory: Array.isArray(raw.inventory) ? raw.inventory : [],
    settings: { sound: raw.settings?.sound ?? true }
  }
}

关键手法是只加不减、缺字段给默认值、类型校验兜底。下面这个可运行示例完整演示了存档的序列化、localStorage 持久化、导出/导入文件，以及 v1 → v2 的自动升级：

存档安全与性能

• 自动存档节流：崩溃/切后台时自动保存，正常操作低频节流（如每 30 秒或关键节点）
• 校验和：存档加 hash/签名，防止玩家手工改 JSON 或文件损坏
• 双份保存：写新档 → 验证 → 覆盖旧档，避免保存中途崩溃导致全丢
• 异步写入：大数据存 IndexedDB，避免 localStorage 同步阻塞主线程

Web 打包与发布

构建产物优化

• 压缩与合并：JS/CSS 压缩、Tree Shaking、按路由分包
• 资源指纹：文件名带 hash，更新版本后浏览器自动拉新资源
• 静态资源内联：小图片/图标转 base64 内联，减少请求数
• CDN 分发：静态资源走 CDN，用户就近加载

离线与加载体验

• PWA / Service Worker：缓存应用外壳，二次进入秒开、可离线玩
• 预加载策略：首屏只加载必要资源，进入后再预加载后续关卡
• 加载进度：分块加载并显示进度，避免长白屏

平台适配

平台	输入	分辨率	存储	发布注意
桌面浏览器	键盘/鼠标	宽屏自由	localStorage/IndexedDB	键盘快捷键、窗口缩放
移动浏览器	触摸	竖屏/横屏	localStorage/IndexedDB	触摸按钮、防误触、视口 meta
微信小游戏	触摸	固定设计分辨率	微信 Storage	分包限制、API 差异
原生（Unity/Cocos）	手柄/触控	多机型	平台文件系统	屏幕适配、包体积

适配的核心原则：逻辑分辨率与显示分辨率分离——游戏逻辑按固定的设计分辨率（如 1280×720）运行，再按设备实际尺寸做等比缩放与安全区适配。

版本管理实践

1. 版本号规则：存档 version 独立于游戏版本号，只随数据结构变化递增
2. 升级路径：支持任意旧版本直接升到最新（链式或跳跃式升级），而不是只支持"上一版"
3. 回滚安全：新版本号出现异常数据时，允许回退到旧版解析逻辑，宁可丢新字段不丢旧档
4. 灰度发布：Web 端可以按用户比例灰度新版本，出现问题快速回滚

存档的版本管理是"代码写一天、维护写一年"的领域——从第一次上线就遵守"缺字段给默认值"的读取规则，后续每次版本迭代都会轻松很多。