想请教，skynet做的游戏，怎么设计互相偷菜的场景（互相修改玩家数据），特别是当其中一个玩家离线的状态

[phzzy]

A 和 B 两个玩家都是独立的 agent，各自维护各自的数据
如果 A 要去修改 B 的数据，比如偷了 B 的一棵菜，或者修改 B 的货币
正常应该是 A 发消息给 B 的agent，执行偷菜的操作

但如果 B 不在线，B 的agent不存在呢？ 需要怎么做？

[cloudfreexiao]

离线 就 拉起 B 创建个 agent

[phzzy]

离线 就 拉起 B 创建个 agent

这样新启一个agent，如果agent逻辑比较多，可能需要一定时间，比如1s
那我去看别人家，还需要这个时间，是否太多了？ 并且会不会对系统消耗比较大，毕竟一个玩家上线，是要加载不少数据的

不知道陌陌争霸当时是怎么做的？比如去攻打别人的城

[sniper00]

一般拉起是毫秒级。但还是要好好设计：

1. 玩家经常看的数据，建议直接全部加载内存；
2. 玩家下线不要立马删除 agent, 定个策略，如agent数量大于1000(可以参考活跃同时在线量级), 并且离线时间大于10分钟的才删除。

[phzzy]

好的。非常感谢

[Eniminio]

请教一下，可不可以用直接修改B玩家的数据库数据的做法？

[phzzy]

我也想过这种，但不好弄
1、写起来很麻烦。每种这样的操作，都需要写两套代码。先判断是否在线，再决定是发消息给agent，还是去直接改数据库
2、可能造成数据不同步。 A先把B的数据查出来，到update回去，有一个时差。这个中间如果B上线，会导致数据不一致。要想确保一致，又会增加很多额外的校验

[Eniminio]

好的，谢谢！

[hanxi]

我也提个方案吧，可以用消息队列的方式，每个玩家维护一个离线消息队列，玩家上线的时候去处理消息队列里的消息。不管玩家在不在线都推消息到消息队列里，玩家在线的时候定时消费消息队列里的消息。

[hanxi]

我这方案还是应对不了偷菜的情况，因为偷菜是需要查看对方数据的，如果只是修改不用查看才行。

[phzzy]

这种我也想过。弄一张单独的表，来存中间状态。每次玩家上线时，去查一下这个表，把里面的消息处理完
但比如A和很多人都偷了B的东西，每次偷之前也需要去查这个中间表，需要把这个表的数据和玩家的数据合并后，才是玩家真实的数据。 也很麻烦

[hanxi]

@phzzy 我现在项目的方法是每个玩家有一份离线数据，会被别的玩家操作到的数据放在离线数据。就是一个玩家有在线数据和离线数据，数据也不进行合并。但是做不了事务，可能会引起一方扣了一方加不上这些问题。

[cloudwu]

我认为这个需求本质上就是做一个带特定事务的内存数据库服务。

你可以把“菜” 这个东西从玩家数据中剥离出来，玩家有多少“菜”以及“菜”的状态在集中管理的数据集里，不在玩家各自的数据里。玩家数据中只做一个 copy 用于显示。然后做一个（组）服务用于管理所有玩家的“菜”。这些“菜”的数据和玩家在不在线无关。即，玩家在展示“菜”的时候，再向服务提请求获得状态。它更类似数据库的做法：冷数据放在磁盘，热数据放在内存，服务处理原子事务。

至于是不是一定要用通用数据库处理事务，我认为是可选的。可能自己实现服务的逻辑更简单。

最后设计货币的问题。货币是跨业务的应用，不能绑定在“菜”上面。我觉得可以为“菜”这些系统设计一个子账户放这个玩法的货币，并且允许它为负数。这个设定未必给玩家看到。可以在交易结束后的环节和玩家账户中的货币做合并。也就是说，玩家玩到“菜”的玩法需要货币的时候，把身上的货币充进了“菜”这个系统。系统保证自身的事务都是原子的。如果不出错，货币（子账户）结余都是 0 。如果出错，再和玩家身上的货币合并的时候，多退少补。

[hanxi]

把 “菜” 这个数据剥离出来是比较好实现逻辑的，跟交易所类似。涉及到玩家之间交互的玩法数据，独立成单独的玩法数据。因为玩家之间能互相操作的数据已经不属于某个玩家了。偷菜的过程中需要扣一方的数据和加一方的数据，这是一个原子事务，在一个服务里实现可以不用考虑跨服务处理两份数据的问题。

[wNakiami]

数据集这种做法有点意思，但是有个后续扩展的疑问。
因为游戏的功能变化很频繁，任何之前不会交互的数据一个功能修改可能就产生交互。这种修改怎么做比较合适呢？

如果一开始就把所有数据都做成数据集来处理的话，玩家agent逻辑就有点web化无状态的感觉了。

[sniper00]

他应该只是举个例偷菜，估计还有更多互相访问的需求。

[zhukunqian]

需要互相访问的数据单独放在一个服务里。只有这一个服务来修改这些数据，就不会存在互相修改。

…

On Mon, May 24, 2021 at 11:45 AM Bruce ***@***.***> wrote: 他应该只是举个例偷菜，估计还有更多互相访问的需求。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1407 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWLMAS42PWJA34NPAX5AADTPHDULANCNFSM45MLNURA> .

[Gowa2017]

菜又不在玩家身上，菜单独放个服务管理所有的菜（可以开多个服务），只是菜属于谁，给他打个标记。。。

[zhangshiqian1214]

刚好手上有一个类似于攻打查看别人的城的需求, 同时攻打下来双方的货币以及攻击方的部队的损失和防守方防御建筑的损失都要计算, 同时还涉及了一些的成就和日常任务以及排行榜等, 所以过来看看大家的做法.

这几种做法我都思考了下, 最终我选的是拉起玩家再操作. 选这个方案的原因是:

1.我们的服务器是1个游戏进程只有一个agent, 整个进程的所有的玩家都在一个lua服务里面, 所以对很多的离线玩家操作, 就只要载入玩家的数据就可以, 不像1个agent1个玩家这种方案, 每个agent都有代码或配置导致的额外开销. 像之前有个讨论讲sharetable的时间开销..

2.因为一些玩法涉及多个模块, 其它的方案要做一些额外的处理, 而拉起来操作会比较简单, 仍旧使用玩家自已的功能模块, 也不用担心数据的一致性问题.

[sniper00]

刚好手上有一个类似于攻打查看别人的城的需求, 同时攻打下来双方的货币以及攻击方的部队的损失和防守方防御建筑的损失都要计算, 同时还涉及了一些的成就和日常任务以及排行榜等, 所以过来看看大家的做法.

这几种做法我都思考了下, 最终我选的是拉起玩家再操作. 选这个方案的原因是:

1.我们的服务器是1个游戏进程只有一个agent, 整个进程的所有的玩家都在一个lua服务里面, 所以对很多的离线玩家操作, 就只要载入玩家的数据就可以, 不像1个agent1个玩家这种方案, 每个agent都有代码或配置导致的额外开销. 像之前有个讨论讲sharetable的时间开销..

2.因为一些玩法涉及多个模块, 其它的方案要做一些额外的处理, 而拉起来操作会比较简单, 仍旧使用玩家自已的功能模块, 也不用担心数据的一致性问题.

创建一个agent其实耗时很少的2ms左右实测 比加载数据库耗时小多了 并且如果你做了我上面说的agent释放策略 是很少出现创建新agent的情况

[zhangshiqian1214]

你说的应该是用agent池吧, 先提前创建好,用的进候加载, 确实能减少加载时间, 不过我看有些配置会对加载有影响, 单个agnet没这个问题 > 还是有影响的。我测试了下，在 8 核 16 G mac 下（开了其他的软件），启动了 2 个 game 进程，每个 game 进程并发启动 150 个玩家 agent，每个 agent 启动完成时间为 0.9s 多，将近 1s，数量越多，时间越长，agent 大概 60 个配置模块。

[phzzy]

我们现在是一个用户一个agent，和其他用户交互时，比如要修改对方的金币，就要拉起一个对方的agent
现在也没出现什么问题

[zhangshiqian1214]

能达到目的就好办法, 一个用户一个agent我觉得很ok, 你们是全球服的吗? 在一个进程里如果要改另一个进程的玩家数据是怎么操作的, 是不是先发一个请求给agentmgr, 看有没有这个agnet, 然后再请求一次调用? 还是一次请求直接发到agentmgr, 在里面判断有没有这个agent然后拉起调用?

[phzzy]

能达到目的就好办法, 一个用户一个agent我觉得很ok, 你们是全球服的吗? 在一个进程里如果要改另一个进程的玩家数据是怎么操作的, 是不是先发一个请求给agentmgr, 看有没有这个agnet, 然后再请求一次调用? 还是一次请求直接发到agentmgr, 在里面判断有没有这个agent然后拉起调用?

发请求给 agentMgr，获取 B 用户agent的地址。如果agentMgr发现 B agent不存在，就会拉起一个B的agent

[aasdpiao]

其实这个问题的核心在于抽离公共数据与个人数据吧,

[zhangshiqian1214]

确实, 是要看使用场景, 怎么样方便简单就怎么样来

[terry8210]

例如一些好友的数据，对好友进行赠送功能，其实上线不上线没关系，直接操作好友的数据(缓存/或者数据库)，读取频繁的就载入缓存。

[pirunxi]

路过。。请关注 zhugedb 。完美解决这种分布式系统下的事务性以及离线数据的问题。 https://github.com/focus-creative-games/zhugedb

[tangyiyang]

1. 把所有的玩家全部都放在一个agent里，不太好，这里失去了横向扩展的可能。 2. 一个player一个agent，拉起agent的问题在于，要解决，这个时候如果这个玩家登录了，你需要把这个offline-player-agent 转移成一个online-player-agent。处理好这点其他的都ok了。 给每个player agent一个lifetime，超过一定时间没有消息过来，把自己杀掉就可以了。 已经在成熟上线的SLG项目跑了几年了，没有什么问题。 walon ***@***.***> 于2022年4月10日周日 15:38写道：

…

路过。。请关注 zhugedb 。完美解决这种分布式系统下的事务性以及离线数据的问题。 https://github.com/focus-creative-games/zhugedb — Reply to this email directly, view it on GitHub <#1407 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDOENY5AYT2HELY6ZSI2OTVEKAOZANCNFSM45MLNURA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zhangshiqian1214]

1. 把所有的玩家全部都放在一个agent里，不太好，这里失去了横向扩展的可能。 2. 一个player一个agent，拉起agent的问题在于，要解决，这个时候如果这个玩家登录了，你需要把这个offline-player-agent 转移成一个online-player-agent。处理好这点其他的都ok了。 给每个player agent一个lifetime，超过一定时间没有消息过来，把自己杀掉就可以了。 已经在成熟上线的SLG项目跑了几年了，没有什么问题。 walon @.> 于2022年4月10日周日 15:38写道：
   …
   路过。。请关注 zhugedb 。完美解决这种分布式系统下的事务性以及离线数据的问题。 https://github.com/focus-creative-games/zhugedb — Reply to this email directly, view it on GitHub <#1407 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDOENY5AYT2HELY6ZSI2OTVEKAOZANCNFSM45MLNURA . You are receiving this because you are subscribed to this thread.Message ID: @.>

玩家放一个agent并没有失去横向扩展, 只是单个进程开1个agent, 但可以用cluster开多个同样的player进程啊,只要能保证单进程在线玩家数能在合理范围就行了, ggApp 这个也有线上项目用的