关于基于请求-响应模式下的组队副本设计

[mingjava]

我们的游戏是RPG，单机的PVE玩法为主，战斗也都是在客户端做的，现在想做一个组队副本的玩法，由于通信协议是使用的MsgServer，基于请求和响应模式，这种情况下，如果想在副本场景地图上实时更新其他几个组队玩家的位置，是不是就需要客户端比如每100ms就要将自己的位置发送给服务器，服务器收到之后将其他玩家的位置都发送给客户端。基于请求响应的模式，应该是不能服务器广播给组队的几个客户端的吧。

初次做游戏服务器代码，经验不足，还请大佬给多提一些靠谱的方案，我去学习一下。

[CoolDesert]

这个问题我记得云风在 blog 写过方案，大概是类似 long polling 的做法。

[ericzhanchina]

long pull应该是skynet.response吧。后来我想了一下，还是客户端只上传操作得了，比如玩家点了要去哪个位置，然后这个位置转发给其他的客户端，客户端自己负责去寻路，这样请求就不用那么频繁同步位置了。

[terry8210]

可以参考下原神的私服源码，他们就是做一个类似的模拟战斗和移动，如果只是普通RPG非动作类同步的，完全可以满足需求。

[ericzhanchina]

谢谢指点，我去学习一下

[tangyiyang]

组队副本看起来应该是类似在一个房间里的逻辑，如果客户端是Untiy的话，可以先技术调研一下Unity Network，或者Mirror Networking，服务端基于 redis做一个 match-making 服务就好了。

…

On Wed, May 24, 2023 at 8:51 AM ericzhanchina ***@***.***> wrote: 谢谢指点，我去学习一下 — Reply to this email directly, view it on GitHub <#1751 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDOEN4NOI6DCK5FLE3MLATXHVLSBANCNFSM6AAAAAAYLCPIUE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ericzhanchina]

收到，我们的组队是队长管理的，你可以加入，队长选择批准或者拒绝，您说的match-making是自动匹配组成一队吧。

由于副本场景内需要同步显示其他玩家的动作，我理解客户端需要将自己的操作实时发布给服务器，同时还应该不断地轮训服务器的最新玩家状态，服务器不断地更新数据，不断地回应客户端的轮训。