【游戏存储设计】讨论下关于游戏数据如何存储,更常见高效的方式

简述:

新手接触游戏不久,想讨论下常见的游戏存储和游戏后端设计一般是什么形式的。像是如果是“通关”类的游戏一般在存档点将游戏进度存储起来就行。这种类型对后端设计比较低的

假如模拟经营的类的游戏,是否每一个动作都是对应一个接口以保证游戏数据的安全性呢如果这样网络请求的开销可能相对较大!按照以往设计应用app的思路这个是没什么问题的 但是对于游戏来说感觉并非是常见的做法

举例场景:
假如说一个农场类的经营游戏,从商店购买一个种子,放入背包,在果园将这颗种子种下,浇水一次3分钟之后产出果实,收获后将果实放入背包

那么数据的存储过程应该是:

1.1 获取商店数据(请求后端api)
1.2 获取用户数据主要是货币信息(请求后端api)

2.1 提交商品 ID 执行购买操作(请求后端api)=》返回购买结果
2.2 获取背包信息(请求后端api)
3.1 提交物品 ID 执行种植操作(请求后端api)=》后端创建一条种植记录
3.2 提交种植记录 ID 执行浇水操作(请求后端api)=》后端标记浇水信息
4.1 根据后端返回的种植记录信息确认收获时间
4.2 提交种植记录ID执行收获操作(请求后端api)=》后端将收获的物品自动放入背包

如上所述简单的一个操作就有6个接口请求这肯定不现实
换成存档的形式我的设想是这样

A 游戏初始化阶段
获取游戏配置(请求后端api并缓存)
商店数据(请求后端api并缓存)
存档数据(请求后端api并缓存)
B 操作阶段
1.1 获取用户信息(请求后端api)
1.2 打开商店(读取缓存)
2.1 执行购买根据商店信息创建一个物品放入背包数据(js缓存)
3.1 打开背包(读取缓存)
4.1 根据背包物品执行种植创建一个种植记录(js缓存)
4.2 针对种植记录执行浇水操作(js缓存)
4.3 读取游戏配置缓存确认收获时间
4.3 根据种植记录执行收获操作并放入背包(js缓存)

上述操作时根据操作的重要性,在关闭游戏时和固定间隔时间提交数据到后端存档

在缓存和提交存档时做一些加密处理防止数据异常

希望有兴趣的大佬介绍下常见是怎么做的 感谢!

1赞

@子龙山人 大佬可以请教下嘛?

你用长连接,然后消息精简一点,开销也不是很大。顺带协议加密压缩这些都可以做了。

对有心人无用,想破还是可以破的

这类型游戏其实安全性要求并不高,破解也做不了什么

没有大佬指导嘛~

既然要求不高,为什么不全部本地处理呢?

如果是用服务器存档 用长连接传输这种数据并没有什么性能瓶颈 而且这种属于轻联网 对带宽更没有什么负担

是说第一种方案改成长连接的方式吗

我是做前端的,说下我的想法:
1、商店数据:简单做法就是每次打开请求,因为商品有可能随时更换。想节省开销可以在商品列表带个列表时间戳,前端请求时发时间戳给后端(第一次打开默认不传或发0),时间戳不匹配后端就发完整数据,匹配就只要回个OK什么的就行了
2、用户数据,这个一般登录时后端会随账号信息给过来,前端一般不做加减操作,只做存储和判断,由后端通知刷新即可
3、购买,这个肯定得做个接口,长连接就发个商品ID,短连接还得带信息验证。
4、背包信息,这个可以跟用户数据一起拉下来前端缓存
5、种植操作,这个一般是跟玩家的地来绑定的吧?玩家ID、地的ID、植物ID、种植时间戳、收获时间戳、当前特殊状态(缺水、有虫什么的,一般同时刻就一种状态),有些可能还要加某些有次数限制的特殊物品的使用次数什么的。还有可能会有浇水杀虫次数,一般一个作物成长周期好像只会有最多1~2次操作的机会。
6、执行浇水,发送个地ID、操作类型,后端判断下当前状态,成功后按地ID返回刷新状态(登录成功时会获取所有地块属性,前端自己维护就是)
7、前端根据收获时间戳自己计算剩余时长
8、后端推送地块ID成熟命令,前端执行收获,发送地块ID,后端判断是否成熟,收获成功刷新地块ID数据、刷新背包数据
没做过农场游戏,我是做棋牌的,根据自己以前玩过的农场游戏想的

是的, 只要请求不是非常频繁(每秒几十个请求), 直接用http也都够用了, 甚至不需要长连接, 毕竟长连接每个用户开启一个长连接, 用户多了服务器连接池线程开销会有点压力

其实我测试过一些小游戏 购买了一个设施(消耗了货币)放到场景后 删除小游戏重新进去 设施没了(货币也还给你了) 感觉他是用类似第二个方案去实现,其实消耗是一回事,用户多了也始终会消耗服务器性能,并且每个操作带着请求比没有请求,没有请求的情况下操作反应是更快的。

你这个说的其实就是第一种方案,棋牌跟这种区别还是很大。毕竟是博弈类的安全大于一切

删除小游戏 除非做了云存档 不然基本上都是数据清空 操作反应这个是联网游戏缺陷

如果是这种的话,我先响应然后去请求操作,那我看见种下去植物了就关了游戏,隔段时间上线发现植物压根没种下去,你觉得这种体验好嘛?

你可以看看动物餐厅 我想这是他们的优化手段吧 放弃绝对的数据安全获取更好的体验 在极限网络下也能顺畅的玩

那就不能用联网了 完全单机化 但单机化由于没有一个好的数据库管理 对这种复杂的储存需要设计一个好的数据储存架构

现在有些小游戏是半单机化的,玩家操作隔一段时间存本地,然后再隔一段时间上传服务器(不强制要求上传成功),如果卡在存本地的时候关闭游戏就可能丢失这段时间的操作数据。这种设计最大的难点就是服务器没法验证操作合法性,修改属性作弊变得相对容易,优点就是可以单机玩,服务器仅做数据存储,压力较小

我想说的就是这种
不知道哪里有介绍这种设计方案的,我还是再找找资料吧~~

这种自己设计就是了吧?一般都是小型游戏用这种的,大点的项目都不会这么设计,所以指望别人开源出来不是很现实的样子