个人游戏技术选型案例：崩溃日志为什么选择玩家可控的诊断包

写在前面：玩家说“打不开”，你需要更多信息

个人游戏发售后，最让开发者焦虑的反馈之一是：

“游戏打不开。”
“进第二章就闪退。”
“昨天还可以，今天读档崩了。”
“我点开始没反应。”

这些反馈很真实，但信息不够。

没有系统版本、显卡、日志、存档、语言、分辨率和错误堆栈，开发者很难判断问题。

周砚做过一款小型卡牌探索游戏。
玩家在一座不断变形的图书馆里抽取房间卡、事件卡和记忆卡，拼出一条逃离路线。

Demo 阶段，有 3% 左右玩家遇到启动失败或读档崩溃。
周砚一开始只能在评论区追问，效率很低。

他后来在自动崩溃上报、第三方 SDK 和玩家主动诊断包之间做选择。
最终采用“本地日志加玩家主动发送诊断包”的方案。

这个方案不如自动上报实时，但更符合项目规模和玩家隐私预期。

一、先明确要收集什么

周砚列出排查崩溃需要的信息：

• 游戏版本
• 操作系统
• CPU、GPU、内存
• 显示模式和分辨率
• 当前语言
• 最近一次场景
• 最近 200 行日志
• 崩溃堆栈
• 存档元数据
• 配置文件

他也列出不应该收集的东西：

• 玩家系统用户名
• 任意目录文件
• 完整聊天或输入内容
• IP 地址
• 真实姓名或邮箱
• 未经同意的存档全文

这个边界很重要。

诊断不是越多越好。
它应该足够排查问题，同时不越过玩家信任。

二、自动崩溃上报的优势和风险

自动崩溃上报很有吸引力。

玩家崩溃后，堆栈和环境信息自动发到后台。
开发者能看到崩溃排名、影响人数和版本分布。

如果是大型项目，这非常有价值。

但周砚的游戏是 PC 单机，团队只有他一个人。
他担心几个问题：

• 玩家是否知道数据被上传
• 隐私政策要更严谨
• 某些地区合规要求增加
• 后台服务需要维护
• SDK 可能影响启动
• 崩溃发生在 SDK 初始化前仍然拿不到

他不是完全否定自动上报。
只是认为第一版没有必要默认开启。

对个人游戏来说，玩家对“单机游戏自动联网”非常敏感。
如果解释不清，诊断系统本身会变成负面体验。

三、第三方 SDK 为什么暂缓

周砚也研究了几个第三方崩溃服务。

它们功能成熟：

• 崩溃聚合
• 符号解析
• 设备维度
• 版本趋势
• 自定义事件

但接入后，他还要处理：

• 符号文件上传
• 平台配置
• 隐私弹窗
• 离线行为
• SDK 升级
• 数据保留策略

他的当前问题不是每天几千条崩溃需要聚合。
而是少量玩家崩溃时，他拿不到足够上下文。

所以他选择先解决“拿到可用信息”，而不是建立完整崩溃平台。

四、本地日志怎么设计

周砚给日志分了几个级别：

• debug：开发构建使用
• info：关键流程
• warning：可恢复异常
• error：功能失败
• fatal：崩溃前记录

正式版默认只写 info 以上，避免日志太大。

日志内容包括：

• 游戏启动
• 资源加载阶段
• 场景切换
• 存档读取
• 语言切换
• 显卡模式
• 关键异常

他刻意不记录玩家完整操作序列，也不记录任何自由输入文本。

日志采用滚动文件：

• game.log
• game.previous.log

每次启动轮换，避免无限增长。

五、诊断包包含什么

当玩家遇到问题，可以在启动器或游戏设置里点击“生成诊断包”。

诊断包是一个 zip，里面包括：

• 最近日志
• 配置文件
• 游戏版本信息
• 系统和显卡摘要
• 崩溃 dump 或堆栈
• 存档列表元数据
• 最近一次失败原因

如果问题和存档有关，游戏会额外询问：

“是否附带当前存档？存档可能包含你的游戏进度和自定义名称。”

玩家可以选择不附带。

这个交互比自动上传更透明。

开发者拿到的信息足够多，玩家也知道自己发出了什么。

六、启动失败怎么办

诊断功能如果只能在游戏内点击，启动失败时就没用。

周砚做了一个很小的外部启动器。

它只有几个功能：

• 启动游戏
• 切换安全模式
• 生成诊断包
• 打开存档目录
• 重置图形设置

安全模式会：

• 使用窗口化
• 关闭后处理
• 使用默认分辨率
• 跳过上次场景恢复

很多“打不开”的问题，其实来自分辨率、显卡模式或损坏配置。
安全模式能让玩家先进入游戏，再反馈问题。

这比只告诉玩家“删除配置文件试试”更专业。

七、诊断包如何帮助排查

发售后第一周，有玩家反馈第二章读档崩溃。

周砚拿到诊断包后发现：

• 游戏版本是 1.0.2
• 当前语言是英文
• 崩溃发生在加载房间卡描述时
• 日志显示缺少 card.room.archive_burned.description.en
• 存档进入了一个稀有房间

问题不是存档损坏，而是英文文本表漏了一条翻译。
中文玩家不会触发，英文玩家进入该房间才会崩溃。

如果没有诊断包，他可能要花很久才能复现。

诊断系统的价值就在这里：
它把“玩家说崩了”变成“某版本、某语言、某资源缺失导致崩溃”。

八、未来什么时候接自动上报

周砚没有把方案锁死。

他列了几个升级条件：

• 玩家规模显著扩大
• 崩溃数量超过人工处理能力
• 多平台版本增多
• 需要按版本聚合崩溃趋势
• 有时间完善隐私和同意流程

如果这些条件出现，再接入第三方崩溃服务。

但第一版先用本地日志和诊断包，已经解决了大部分实际问题。

结语：诊断系统的目标是可复现

周砚的方案不追求实时看板。

它追求的是：当玩家遇到问题时，开发者能拿到足够信息复现和修复。

个人游戏发售后，排障能力就是产品质量的一部分。
你不可能保证没有 bug，但可以保证遇到 bug 时不完全靠猜。

好的诊断方案应该透明、克制、可控。
它尊重玩家隐私，也尊重开发者时间。

玩家愿意帮你发诊断包，是一种信任。
技术方案要配得上这种信任。