找回密码
 点一下
查看: 1600|回复: 20

通过bank的自身算法实现“云bank”的思路,请教头目

[复制链接]
发表于 2013-9-23 15:24:45 来自手机 | 显示全部楼层 |阅读模式
流程如下:

先说最简单,两个人的
a和b进行对抗,于是记录下了a和b的bank
但同时让触发器灵a和b互相记下对方的bank
于是这两个人就会形成一个“云bank”
如果a的数据丢失,那么他再和b玩的时候
因为b有a的备份
在游戏开始时,a可以借机还原自己的数据,还能继续帮b备份
游戏结束后,之前的数据毫无影响,还能继续堆叠

然后扩展到好多人
好多人都在玩这个游戏(比如100人),那么
任何一个新玩家都会自动在其他“已经玩过的人”那里获得这个“云bank”
已玩过的玩家每次对涉及到自己的数据部分,进行增长与刷新
即使丢失数据的玩家也能通过其他玩家那里获得数据
通过“玩家之间的联动”实现“云bank”

这个思路是否可以实现呢,头目?
如果这个概念能推广,那么地图数据网游化就可以推行了
发表于 2013-9-23 16:28:44 | 显示全部楼层
如果a某天和b、c一起玩了地图,第二天,a和b玩了地图,第三天,a和c玩了地图;其中二三天b和c没一起玩。这样的话a的存档不是不一致了么?
回复

使用道具 举报

发表于 2013-9-23 16:41:09 | 显示全部楼层
本帖最后由 娜渃卟Ran 于 2013-9-23 16:45 编辑

a端丢失bank数据,他与b玩过一次,c两次。这种情况该读取哪边的数据?b记录的是a与b对战,c记录a与c对战。目前的bank只要是保存在本地的,都不可避免会有这些问题,只有期待真正的云端Bank。
回复

使用道具 举报

 楼主| 发表于 2013-9-23 16:57:38 来自手机 | 显示全部楼层
wyf 发表于 18 分钟前
如果a某天和b、c一起玩了地图,第二天,a和b玩了地图,第三天,a和c玩了地图;其中二三天b和c没一起玩。这样的话a的存档不是不一致了么?

首先abc一起游戏,那么bank记录成3份子内容
a的数据,b的数据,c的数据

然后a和b玩,会刷新a和b的数据,c的数据保留
然后a和c玩,c的bank直接刷新a和b的最新数据,a也能同步c现在的数据

每一个人在玩的时候,自动记录其他人的最新数据,并刷新在这个房间里的人的数据
这样就能一致
回复

使用道具 举报

 楼主| 发表于 2013-9-23 17:02:42 来自手机 | 显示全部楼层
娜渃卟Ran 发表于 6 分钟前
本帖最后由 娜渃卟Ran 于 2013-9-23 16:45 编辑

a端丢失bank数据,他与b玩过一次,c两次。这种情况该读取哪边的数据?b记录的是a与b对战,c记录a与c对战。目前的bank

那么a会在和b玩的时候,数据先和b里面的档案同步
然后a再和c玩的时候,就和c里面“高于b所记录的数据”的部分同步

核心两点
“游戏开始时每个子档案同步更高玩家所记录的数据”
“游戏结束时刷新自己房间里的数据”

点评

如果说Bank文件记录了玩家的等级呢?a和b玩的时候只有10级,而a和c玩的时候已经是40级了呢?总感觉这种方法可行,但是不完善……  详情 回复 发表于 2013-9-25 14:03
回复

使用道具 举报

发表于 2013-9-23 17:59:07 | 显示全部楼层
突然发现似乎是不错的注意,唯一需要注意的是由于每位玩家会保存数个乃至几十个人的Bank,所以可保存的数据就要限制一下了。
回复

使用道具 举报

 楼主| 发表于 2013-9-23 20:47:28 来自手机 | 显示全部楼层
四夕水草肃 发表于 2 小时前
突然发现似乎是不错的注意,唯一需要注意的是由于每位玩家会保存数个乃至几十个人的Bank,所以可保存的数据就要限制一下了。

这也是最让人担心的,如何能优化这个方案
回复

使用道具 举报

发表于 2013-9-23 21:38:19 | 显示全部楼层
本帖最后由 yxxiaobin 于 2013-9-23 21:49 编辑

数据丢失的情况貌似不常见吧。不过如果需要记录的数据不多的话,倒是可以扩展到很多人,这样用途可能广一些。所以一个优秀的算法或许更重要,这样就可以用尽可能小的体积记录尽可能多的数据。但是关键在于,不同的地图需要的算法肯定不完全相同,而且可以肯定的是,只有一部分作者对算法比较精通,这样多少会限制这一设想的实际应用。

另外一个问题就是如何同步的问题,就如上边提到的,假设a/b/c一起玩过,然后a/b一起玩,当a再次和c一起玩时,如何知道同步a的数据到c,还是同步c的数据到a呢?比较容易想到的方案是,为每个玩家关联一个游戏场次计数器,这个值只会增加,不会减少(或者如果直接有某个值只能增加不会减少的话,直接采用那个值就可以了,不必单独设立一个计数器),当a和c再次碰面,比较两者存档中a的计数器大小,以大的那个为准,将a的数据同步到所有玩家的bank中,比如上例中,a碰到c,a这里关于a的计数器是2,而c那里关于a的计数器是1,这样a的数据将以a自己这里保存的为准。
但是这仍然不是完美的,因为一旦a在和c玩之前就丢失了数据,当他和c玩时,会把c哪里关于a的数据同步到a的电脑上,而这个记录并不包含a和b一起玩的数据,如果a玩过几场以后再次碰到b,因为此时a自己这里关于a的计数已经比b那里关于a的计数大了,所以会覆盖b那里关于a的数据,结果导致a和b玩时产生的数据永久性丢失。
如果要从根本上解决这个问题。除非连续记录每次游戏的数据,并同时记录这个数据产生的时间,而不是覆盖原有记录。这样可以通过合理的算法还原数据(如果能碰到携带自己丢失部分数据的玩家的话)。不过这样一来,需要记录的数据将呈几何倍数增加,而且只要一直玩,就会一直增加下去,所以肯定是行不通的。
回复

使用道具 举报

发表于 2013-9-24 15:04:59 | 显示全部楼层
其实有个问题是数据丢失可以认为是必然的。星际2的自定义地图的用户数据存储在本地。简单点来的话,换一台电脑进行游戏,那么以前的记录就都不存在于新电脑里。
我以前用过文件管理的软件,每份数据都是通过唯一的版本号来同步的,所有数据都是必须由一个统一核心来管理。云存储本身只是存储资料的分散开来,但资料库的每一个部分都必须时刻链接在一起,而不是可以有多个不同版本相冲突的备份。没有统一管理的话就没有人能识别哪个数据才是正确的数据。

举个例子
第一天我在电脑A上登陆账号并与玩家1进行了游戏,第二天我在电脑B上登陆账号并与玩家2进行了游戏,第三天我在电脑A上登陆账号并与玩家2进行游戏,那么第三天时,电脑A和玩家2的电脑上都各会有一个从0开始进行了一次游戏后的记录,也就是说从0开始的不同分支。这两个记录相冲突,但没有先后次序的关系。这时候选哪个都可以说是合理的,就像重玩游戏产生的不同存档一样。

我认为这东西作为云存储,需要存大量玩家数据,同时又产生大量冲突,能正常工作的概率太低了。

我个人感觉,如果退一步,作为小范围的备份一起玩的朋友的存档数据会不错。玩家可以选择备份哪个战友的存档,当几个战友某天又一起游戏的时候,他们可以选择共享并从中选择一个旧的角色存档来进行游戏。也就是说是玩家主动备份,而不是自动,毕竟玩家在意的战友存档起就可能是那么几个

点评

主动备份这个主意不错,比较实用,但是也有两个问题:1.只适合特定人群,应用面比较窄。2.合作刷记录。  发表于 2013-10-4 19:48
回复

使用道具 举报

发表于 2013-9-25 08:21:40 | 显示全部楼层
本帖最后由 『四裤全输』 于 2013-9-25 08:47 编辑

感觉P2Pbank只有两个问题需要考虑,体积和时限(有效期)。
如果无限体积,那么大可以保存所有玩家的数据,病毒式bank。
如果无限时限(有效期),那么本体保存就好了嘛,完全就是网络游戏的保存方法了。

体积方面的话,可以用一个标准对数据进行过滤,低优先级的去除,高优先级的保存。
比如说bank版本,或者bank内容的等级。
当然也可以加入强制保存同场次游戏玩家的bank,更可以为其加一个安全保护游戏次数。
还可以加入指定某个玩家为其永久保存bank,并且管理这个永久保存玩家表。

时限(有限期)方面,基本只有本地bank丢失和互联网bank被遗忘。
丢失的话无解,不过可以通知玩家bank保存在哪里,或者让玩家备份某个文件夹。
遗忘的话,可以用游戏场次或游戏时间来判断,优先保存游戏次数多的玩家和游戏时间长的玩家。
游戏次数包括正常次数和P2P传播次数什么的。
游戏时间也包括正常游戏时间和P2P传播时间什么的……

甚至当P2Pbank检测到数据覆盖的时候告诉玩家你已经多长时间没更新bank了,还剩多长时间或多少次后你的bank将可能被消除什么的。



回复

使用道具 举报

发表于 2013-9-25 14:03:49 | 显示全部楼层
羊驼骑士 发表于 2013-9-23 17:02
那么a会在和b玩的时候,数据先和b里面的档案同步
然后a再和c玩的时候,就和c里面“高于b所记录的数据”的 ...

如果说Bank文件记录了玩家的等级呢?a和b玩的时候只有10级,而a和c玩的时候已经是40级了呢?总感觉这种方法可行,但是不完善……
回复

使用道具 举报

发表于 2013-9-25 17:52:05 | 显示全部楼层
作为参考,《怪物猎人》等游戏拥有保存好友“名片”的功能,而这个名片就相当于楼主所说的云Bank。(只不过没有反向恢复功能罢了。)
回复

使用道具 举报

发表于 2013-9-28 11:39:26 | 显示全部楼层
楼主好聪明哎~ 能想到这种方法.
这是一个去中心化的对等网络, 并不像云~ 所以, 与其叫做CloudBank, 叫它BitBank也许更合适~
回复

使用道具 举报

发表于 2013-10-4 19:55:20 | 显示全部楼层
本帖最后由 yxxiaobin 于 2013-10-4 20:17 编辑

事实上简单同步的方法在一定程度上可以减小损失,但是无法完美恢复数据,如果有兴趣可以做一下这个功能,反正也不是十分费事,不过一定要声明无法完美恢复这一点,否则做了可能反倒要挨骂,还不如不做,这样丢了数据的也直接死心了。
唯一能解决这个问题的方法就是:连续记录每个玩家每场游戏的具体情况,这样通过比对,就能知道玩家丢失的场次是哪些,甚至在两个记录丢失不同场次的情况下,依然可以通过一定的算法还原数据。
比如。a这里关于c的数据是这样的:
2013-10-1 11:30 本场得分=10
2013-10-1 20:00 本场得分=11
2013-10-3 10:00 本场得分=11
总分=32
b这里关于c的数据是这样的:
2013-10-1 11:30 本场得分=10
2013-10-2 17:10 本场得分=12
2013-10-2 18:00 本场得分=10
总分=32
然后他们再次遇到,就可以还原c的数据如下:  
2013-10-1 11:30 本场得分=10
2013-10-1 20:00 本场得分=11
2013-10-2 17:10 本场得分=12
2013-10-2 18:00 本场得分=10
2013-10-3 10:00 本场得分=11
总分=54
如果没有一个明确的历史记录,那么他们同步后,c的总分肯定也是32分。只不过,这样一来数据会显得臃肿,而且这种臃肿程度会随着时间越来越严重。当然,也可以设置一个时限,比如1个月,超时限的记录会被删除,只记录传下来的的数据是多少,比如记录成这样:
2013-9-1 17:12 历史得分=35
2013-10-1 11:30 本场得分=10
2013-10-1 20:00 本场得分=11
2013-10-2 17:10 本场得分=12
2013-10-2 18:00 本场得分=10
2013-10-3 10:00 本场得分=11
总分=89
只不过,考虑到某些玩家与其他玩家碰面的机会较少,仍然会出现丢失数据的情况。

回复

使用道具 举报

发表于 2013-10-4 21:35:08 | 显示全部楼层
用这种方法保存“历史记录”就是找抽。

正解应该是,在a的Bank中保存有
a->20|2013-9-1;17:10:15
b->30|2013-8-25;20:07:43
当a和b下次游戏是双方更新记录,a的Bank变为:
a->26|2013-9-10;18:40:02
b->34|2013-9-10;18:40:02

以上。
回复

使用道具 举报

发表于 2013-11-3 11:00:07 | 显示全部楼层
上述积分系统在“沙漠风暴(虫群之心)”地图中已经实现,并且有更好的优化,大家可以去看看并提出意见,谢谢。
回复

使用道具 举报

发表于 2013-11-14 01:24:39 | 显示全部楼层
本帖最后由 ip96cns 于 2013-11-14 01:33 编辑

楼主忽略考虑了一点,类似这种数据可以表述为:累计等级,累计时间之类的概念.
而这往往是能刺激玩家玩下去的动力,那么它一定要是"实时"的.
比如我在A电脑玩,然后又换到B电脑玩,那么我一定希望上一盘的记录能够立刻体现当前这一盘.这一点就做不到.

而且,这种方式是不可能让每个人都完美恢复的,能够让数据恢复的条件很苛刻,楼上好几位都说明了就不说了.........
回复

使用道具 举报

发表于 2013-11-14 11:09:45 | 显示全部楼层
玩家的家用电脑是支撑不住这个云的....
回复

使用道具 举报

发表于 2013-11-14 11:10:11 | 显示全部楼层
以T计算比较保险,不然这个就跟微信一个原理,本地储存的话会爆掉的。。。。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 点一下

本版积分规则

Archiver|移动端|小黑屋|地精研究院

GMT+8, 2024-11-24 12:47 , Processed in 0.131114 second(s), 21 queries .

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表