c# - Photon Server新手问题

Question

我已经在Photon Server官方论坛上提出了这个问题，但是它没有本网站那么活跃，所以可能有些人了解我在说什么，因此，如果您有时间和知识，请与我分享。谢谢！

来了...

因此，我在Photon上有一个非常好的工作原型服务器，并且有一个与该服务器对话的基本Unity3D客户端。
它是根据cjrgaming的示例构建的。

客户端可以：连接，发送请求，建立和发送加密的请求
服务器可以：创建对等方，接收操作请求，将操作响应或事件发送给客户端，此外，我的一小段补充是：
如果游戏中有很多操作，则不必使用巨大的switch case语句，而是将操作分为类别（类），并使用委托和字典来调用它们。

当我感觉已经准备好发布它时，我将发布一个工作示例，但是现在，这是我的实际问题。（很长的帖子，很抱歉，我不得不解释一下我所知道的和我到目前为止所拥有的）：

从客户端发送到服务器的操作实际上是什么？
还是服务器向客户端（一次所有客户端？）引发的事件？

起初，我以为每个操作都是游戏中特定的用户流程。例如，操作代码“ 1”表示玩家X要射击玩家Y，请执行某项操作。
但是后来我意识到，不能将所有游戏逻辑按字节数限制仅进行255个操作，而不能将其扩展为short int或其他类型。

然后我发现也有一个channelID，在相同的操作代码请求中它可能是不同的...对于我来说，这意味着操作代码不是用户流，而是客户端之间相同/相似动作的数据流和服务器，并且channelID可用于区分要在服务器上计算的请求操作。

然后...！我意识到（噢，我是个傻瓜），字典中有一些参数从客户端发送到服务器，反之亦然，这又增加了一层可能的用户流。

所以..现在我想了解一些东西，但是它们使我更加困惑。

谁能简要解释一下操作/事件/通道ID的目的？
例如，如果您做一个小型多人游戏，将使用什么来吸引用户（游戏），例如->玩家击中目标，玩家拿起世界上的某个物品，然后玩家发送消息。您会为每个流程使用唯一的操作代码，还是按含义对操作进行分组并使用通道来区分请求，甚至在这里，您对许多用户流使用相同的channelID并在参数内部使用一些ID来区别它们？

希望我有任何道理。

非常感谢你们，至少有时间为您提供帮助！

Answer 1

1）
渠道是一个完全不同的主题，与区分要触发的不同类型的游戏逻辑无关。相反，如果有一项操作依赖于另一个操作，则可以通过这些通道来确定优先级并进行说明。

一种）
如果您发送拍摄操作和2个聊天操作，并且由于客户端的网络连接不是最好的，则第一个聊天消息在途中会丢失，但是正如您所说的那样，它是可靠发送的当服务器不确认时，Photon客户端将自动重新发送它，它已经收到它。现在，其他聊天消息应该由Photon阻止，直到可以成功发送第一个聊天消息为止，否则，来自同一作者的显示聊天消息的顺序将不再是编写它们的顺序。现在的问题是，不仅应该阻止相同类型的操作，而且可能还会有其他操作，这些操作只能在重复丢失的操作后再发送（例如，“用户离开了直到他在离开之前发送的最后一个聊天消息之后，才应该在屏幕上显示“聊天”操作）。另一方面，并​​非所有相同类型的操作都必须保留。例如，播放器可以与两个不同的其他用户私下交谈，并且当其中一个消息无法立即通过时，则没有理由将所有消息保留给另一个。光子解决此问题的方法是通道：在同一通道中发送彼此依赖的所有操作，而在另一个通道中发送彼此独立的操作。如果现在必须重复其中一项操作，则不会阻止其他通道中的操作，但是会重复执行同一通道中的操作。

b）
通道的另一种方法是确定优先级：通道ID越低，优先级越高。因此，如果您有少量的高优先级数据和其他数据，这些数据仅具有较低的优先级，但可能会大量出现，那么将高优先级数据发送到较低优先级的通道上是一个好主意频道ID。这样，它仍然会立即退出，尽管在具有更高ID的通道中，也许很多数据已经排队等待发送，但尚未发送出去。

2）
操作和事件都是消息。实际上，消息有三种类型：operationRequest，operationResponse和event。

一种）
客户端可以通过PhotonPeer.opCustom（）将带有特定操作代码的operationRequest发送到服务器。诸如加入房间和离开房间之类的一些典型操作已经由光子应用程序层（如Lite或LoadBalancing应用程序）中的应用程序实现。如果为Photon应用程序提供了客户端API，则该API可以提供开箱即用的功能，如opJoin（），将调用与opCustom（）的正确参数包装在一起，就像上述应用程序的客户端API一样做。

b）
根据在应用程序级别上实现具有特定代码的操作的方式，服务器可能会向客户端发送一个operationResponse，从客户端接收到该操作的请求。例如，LitePeer.opJoin（）将触发服务器的加入响应，但LitePeer.opRaiseEvent不会触发响应。

C）
根据在应用程序级别上实现操作的方式，服务器可能会也可能不会将事件发送到某些客户端。例如，LitePeer.opJoin（）将触发一个加入事件，该事件将发送给该​​房间中的所有玩家。默认情况下，LitePeer.opRaiseEvent（）将让服务器针对同一房间中除发送方外的所有客户端引发一个事件，该事件包含您传递给它的负载。但是opRaiseEvent（）为它的调用客户端提供了指定接收客户端的可能性。

3）
“玩家击中目标，玩家捡起世界上的物品，玩家发送消息”
如果您需要任何特殊的服务器端逻辑，则可以使用不同的代码将它们实现为自己的操作。如果不是这种情况，则可以使用opRaiseEvent（）发送这些信息，但仍将为每个3指定不同的eventCode。但是，操作码和eventCode旨在用于在不同类型的信息之间有所不同，例如聊天消息，接听命中，位置更新等。因此，玩家a告诉玩家b他已经击中了玩家c，而玩家b告诉玩家d他已经击中了d，他们都将使用相同的代码。有关击中哪个玩家的信息-就像被击打的程度或使用哪种武器相同-都属于该操作的有效载荷。因此，您可以例如将被击中的玩家的玩家ID，弹药类型以及他损失的生命能量作为有效载荷传递给opRaiseEvent（）或opCustom（）。