玩家抱怨丢失进度怎么办？解决小游戏小团队服务器进度存储和外挂问题
上文 6000 字，花了一周构思，6 小时写完。不但会聊清楚 怎么分配精力，怎么寻找合伙人 这两个问题，也会大量串联我近 8 年创业和管理工作中的思考。强烈建议阅读。
下面两篇好文明显被忽略了，游戏创业团队的管理者可以看看：
本篇受到胡扯群友启发，感谢：澤龍，LeolionX，don、楚辽、是三金吖、大菠萝、大城小胖、Bacoo。
昨天有胡扯群友问了这么个问题：
各位大佬，上午好~能否介绍一两个微信小游戏（游戏是让玩家自己选择是否采用的服务器存储或读取数据的），即玩家可以在设置面板那自己上传数据到服务器，否则就是存储本地，单机。
我的第一反应是，这可能是个 X-Y 问题，提问者并不是想找游戏，而是想找解决方案。
什么是X-Y问题？看这篇：重复沟通与内审：提升小微研发团队效率的方法
接着，群里讨论起来，作者讲出了原始想法：
微信小游戏上线的时候是单机游戏，不同端数据不同步，印象中好像有看过有的游戏是让玩家自己选择同步游戏进度到服务器的，想去看看他们是什么方案处理的，学习参考一下，但一下找不到。
玩家进度丢失：数据和观点
我曾经做过游戏后台反馈中，投诉游戏进度丢失的相关数据统计。
丢失率
IAA 游戏的后台，一般有 3‰ 到 1% 的玩家抱怨丢失进度。一般化的原因， 是由于玩家自己清了缓存，删了游戏，或者从抖音版换成抖音lite版本，或者换了手机导致。
面对这种投诉反馈，研发方的态度一般是：解决不了，让他们抱怨去。
屁股决定态度，能力问题本质上是态度问题
但运营和发行，是比较讨厌研发方这种观点的。曾老师也讨厌这种观点，我认为：
凡是技术能解决的问题，都不是问题。
凡是技术不想解决的问题，要么是能力问题，要么是态度问题。
能力问题本质上也是态度问题。
发行和运营有时候觉得研发不处理这些投诉是因为清高，我觉得就是研发屁股位置不对。
发行和运营方，对技术不够熟悉，给不出太好的建议（或者意见）。
研发方，对于运营和发行不太熟悉，绝大多数研发执行层从来不看玩家反馈，甚至不在乎挣钱（反正薪水发了）。研发方老板这边如果不懂技术，就很难推进这类问题。
研发成本
从经营角度看，要思考研发成本。比较问题的主要程度、解决问题的成本、解决问题的收益。
有群友说，看看投诉用户的收入占比，来判断这个事情是否需要解决。
我认为这挺难判断的。毕竟反馈率只有 1% ，大部分进度丢失的玩家可能直接就跑了。
如果游戏不赚钱，就不用费力讨论这件事了。项目关掉做下一个。
所以，游戏是挣钱的，那要看看研发成本是否足够低，增加这个功能带来的收益是否有价值。曾老师的观点是下面三个：
不要给玩家选择（尤其是非游戏层面的选择。自主上传不靠谱也没必要）
服务器存储方案成本极低。
对于服务器程序的能力要求不高。
玩家进度存储方案
美术老师的方式
曾老师之前采用的方式，是开发一套通用的小游戏后台，把玩家的数据传上来，用SDK提供通用的接口实现存储，客户端程序员调用SDK即可。这套机制在 SAGI GAMES 创业初期一直到现在，8年了，经历过几百万 DAU 的冲击，很稳定。整个前后端，也就曾老师一个人。
成本，就是需要养一个服务器程序员。如果需要一些前端统计和管理界面，还需要一个 Web 前端程序员。
但是，很多小团队，没有专门的服务器程序员。大家会觉得服务器特别难搞，服务器程序员特别贵。至于 Web 前端程序员，在游戏公司里没有归属感，很难长期做。
简单粗暴的方法
简单粗暴一点，可以找个OSS服务，或者 CDN 把数据传上去。获取可以用CDN，但需要实时更新的存储只能用OSS。
OSS 有流量限制，可以做个服务器接口转发，缺点就是…… 不太安全罢了。优点就是：不需要服务器程序员。
找个服务器程序员
游戏公司找前端技术，务必要懂游戏和玩游戏。但找后端技术，不需要懂游戏。
后端技术核心，多少年没变过了。如果你的服务器总是出问题，那就是技术人员单纯的菜，换人就行了。
HTTP 短连接架构，非常简单，即使是量级上来，容灾、回档、预警告警，一系列的操作，都有非常成熟的解决方案。
高成本的长连接
有网友提到踩过坑，最初省事用HTTP， 随着游戏的内容变多，需求调整，后面越来越麻烦，最后还是花大力气改成了长连接。
曾老师认为：如果不做付费，小游戏服务器选择长连接是错误且昂贵的。短连接不仅成本低，容错性高，人才好找，技术方案和框架成熟，处理思路和逻辑也简单。
如果做付费另说了，这个架构选型，我可以专门开个课讲讲。
云服务器和云开发
我们公司人员及其不足，接口直接就放在 XX 云函数计算里面，省时省力，也基本不用担心别的问题，并发啥的也不用担心，自动扩缩，价格也便宜。
啥架构都不用管，扔一个 express 把业务接口搞完就行了
买了几次量 并发峰值都轻松顶住 内心毫无波澜 很满意
微信的云开发我们没用，有多平台需求，担心会被限制到，不够灵活，还是用的函数计算弄的 HTTP 接口，各种需求都比较灵活，搭配 XX 云别的服务数据库 Redis OSS 啥的也方便些。
胡扯群友：Bacoo
（广告位招租，欢迎 XX 云厂商和我联系 😄）
分布式数据库思路
分布式数据库的思路
游戏相当于内嵌一个分布式数据库，不过只「分布在两台机器上」，客户端和服务器。对于开发者而言，处理存档就相当于往数据库里存数据。其他的不用关心。
数据完整性 数据同步 版本冲突处理 数据加密 压缩 传输等等 都由嵌入式数据库来处理。
胡扯游戏群友： 打成小胖
防外挂和修改器
既然用到了HTTP来存储数据，就一定会碰到外挂和修改器的问题。
请注意，外挂和修改器是防不住的。无论短连接还是长连接，都会碰到。尤其是对于小厂商，防外挂是极高的成本。
客户端跑核心逻辑，防外挂只能在成本可控的前提下提高修改门槛：
客户端实时存档，定期通过http上传服务器。客户端和服务器版本不一致时 以服务端为主，这个设计是很常见的啊。牛逼如艾尔登法环 也是这种架构
外挂要防抓结合。抓到作弊的进行处罚 比防止作弊更有效，成本更可控。
胡扯群友：打成小胖
曾老师的观点是：
多好的锁也防不住小人，但可以先用一把好锁，防住君子和菜鸟。
干掉外挂的变现途径，是效率最高的方案。某鱼和某宝投诉，不要投诉店铺，直接给平台发律师函。
我觉得还是架构师水平问题，没设计好。说个冷知识。魔兽世界部分纯档数据都是 本地存储 定期总短链接上传服务器的。不过用的不是http。是重写了头信息的自定义协议。
胡扯群友：打成小胖
https://civitai.com/images/24696237
特别介绍
有很多重要内容，公众号发不了，但群里特别能聊。
群里有独立开发者，游戏公司创始人、大厂负责人、量子理论研究者……
关注公众号可以进群一起唠嗑，独立游戏、商业游戏、流量游戏、研发、投放、发行、运营、招人 都能聊，纯唠嗑也欢迎。
下面几个系列文章花了不少精力，可以读一读：
创业系列：
效率系列：
产品分析：
立项系列：
混变系列：
运营系列：
成长系列：
会议系列：
奇技淫巧：
荐号系列：
电子游戏是怎么赚钱的：
再多读几篇：
都刷到这里了，不来个「点赞」「分享」「在看」一键三连吗？