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

羊驼骑士

流程如下：

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

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

这个思路是否可以实现呢，头目？
如果这个概念能推广，那么地图数据网游化就可以推行了

wyf

如果a某天和b、c一起玩了地图，第二天，a和b玩了地图，第三天，a和c玩了地图；其中二三天b和c没一起玩。这样的话a的存档不是不一致了么？

娜渃卟Ran

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

羊驼骑士

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现在的数据

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

羊驼骑士

娜渃卟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，所以可保存的数据就要限制一下了。

羊驼骑士

四夕水草肃 发表于 2 小时前
突然发现似乎是不错的注意，唯一需要注意的是由于每位玩家会保存数个乃至几十个人的Bank，所以可保存的数据就要限制一下了。

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

yxxiaobin

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

另外一个问题就是如何同步的问题，就如上边提到的，假设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玩时产生的数据永久性丢失。
如果要从根本上解决这个问题。除非连续记录每次游戏的数据，并同时记录这个数据产生的时间，而不是覆盖原有记录。这样可以通过合理的算法还原数据（如果能碰到携带自己丢失部分数据的玩家的话）。不过这样一来，需要记录的数据将呈几何倍数增加，而且只要一直玩，就会一直增加下去，所以肯定是行不通的。

ff1407

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

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

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

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

『四裤全输』

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

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

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

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

娜渃卟Ran

羊驼骑士 发表于 2013-9-23 17:02
那么a会在和b玩的时候，数据先和b里面的档案同步
然后a再和c玩的时候，就和c里面“高于b所记录的数据”的 ...

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

四夕水草肃

作为参考，《怪物猎人》等游戏拥有保存好友“名片”的功能，而这个名片就相当于楼主所说的云Bank。（只不过没有反向恢复功能罢了。）

jiyisp

楼主好聪明哎~ 能想到这种方法.
这是一个去中心化的对等网络, 并不像云~ 所以, 与其叫做CloudBank, 叫它BitBank也许更合适~

yxxiaobin

事实上简单同步的方法在一定程度上可以减小损失，但是无法完美恢复数据，如果有兴趣可以做一下这个功能，反正也不是十分费事，不过一定要声明无法完美恢复这一点，否则做了可能反倒要挨骂，还不如不做，这样丢了数据的也直接死心了。
唯一能解决这个问题的方法就是：连续记录每个玩家每场游戏的具体情况，这样通过比对，就能知道玩家丢失的场次是哪些，甚至在两个记录丢失不同场次的情况下，依然可以通过一定的算法还原数据。
比如。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
只不过，考虑到某些玩家与其他玩家碰面的机会较少，仍然会出现丢失数据的情况。

四夕水草肃

用这种方法保存“历史记录”就是找抽。

正解应该是，在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

以上。

ForAI

上述积分系统在“沙漠风暴（虫群之心）”地图中已经实现，并且有更好的优化，大家可以去看看并提出意见，谢谢。

ip96cns

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

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

东方油瓶

玩家的家用电脑是支撑不住这个云的....

东方油瓶

以T计算比较保险，不然这个就跟微信一个原理，本地储存的话会爆掉的。。。。