Photon Server新手问题

Question

我已经在官方的Photon Server论坛上问过这个问题，但它没有这个网站那么活跃，所以可能有人明白我在说什么，所以如果你有时间和知识，请分享它。谢谢!

来了..。

所以，我在Photon上有一个非常好用的服务器原型，还有一个与服务器对话的基本Unity3D客户端。它是根据cjrgaming上的示例构建的。

客户端可以:连接，发送请求，建立和发送加密的请求服务器可以:创建对等，接收操作请求，发送操作响应或事件到客户端，以及，我的小补充是:如果游戏有很多操作，你不必使用巨大的switch case语句，而是，我已经将操作划分为类别(类)，并使用委托和字典调用它们。

当我觉得它可以发布时，我会发布它的工作示例，但是现在，对于我的实际问题……(很抱歉发了这么长的帖子，我不得不解释我所知道的和到目前为止我所知道的)：

从客户端发送到服务器的操作到底是什么？还是由服务器向客户端引发的事件(同时所有客户端？)？

一开始，我认为每个操作都是游戏中特定的用户流程。例如，操作码"1"，意味着玩家X想要射杀玩家Y，做一些事情。但是后来，我意识到，你不能把你所有的游戏逻辑放在255个操作中，按照字节限制，而不把它扩展到短int或其他什么。

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

然后...！我意识到(哦，哑巴我)，在字典中有参数从客户端发送到服务器，反之亦然，这增加了另一层可能的用户流。

所以..。现在我想要理解一些东西，但它们只会让我更困惑。

有谁能简单解释一下operation/event/channelID的用途吗？例如，如果你做一个小的多人游戏，你将用来使用户(游戏)流，就像->玩家击中目标，玩家在世界上拿起一个物品，玩家发送消息。您是对每个流使用唯一的操作代码，还是按含义对操作进行分组并使用通道来区分请求，或者甚至在这里，您对许多用户流使用相同的channelID，并在参数中使用一些ID来区分它们？

希望我说的有道理。

非常感谢各位，如果有帮助的话，至少要花时间！

Answer 1

1)渠道是一个完全不同的主题，与区分你想要触发的不同类型的游戏逻辑无关。相反，如果一个操作依赖于另一个操作，则通道用于确定优先级和状态。

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

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

2)操作和事件都是消息。实际上有三种类型的消息: operationRequest、operationResponse和event。

a)客户端可以通过PhotonPeer.opCustom()向服务器端发送带有特定操作码的operationRequest。一些典型的操作，如加入和离开房间，已经由Photon应用程序层的应用程序实现，如Lite或LoadBalancing应用程序。如果有为Photon应用程序提供的客户端应用程序接口，则此应用程序接口可以提供像opJoin()这样的开箱即用函数，这些函数将调用与opCustom()的正确参数包装在一起，就像上述应用程序的客户端API所做的那样。

b)根据具有特定代码的操作是如何在应用程序级别上实现的，服务器可能会向从其接收operationReqeust的客户端发送operationResponse。例如，LitePeer.opJoin()将触发来自服务器的加入响应，但LitePeer.opRaiseEvent不会触发响应。

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

3)“玩家命中目标，玩家拿起世界上的一件东西，玩家发送消息”如果你需要任何特殊的服务器端逻辑来实现这些，那么你可以用不同的代码来实现它们自己的操作。如果不是这样，那么你可以用opRaiseEvent()发送这些信息，但是你仍然可以为这3个操作指定一个不同的操作。但是eventCode -和eventCodes是为了在不同类型的信息之间使用不同的操作，比如聊天消息，拾取命中，位置更新等等。所以玩家a告诉玩家b他已经击中了玩家c，而玩家b告诉玩家d，他已经击中了玩家d，这两种操作都将使用相同的代码。关于哪个玩家被击中的信息-就像它被击中的程度或使用的武器一样-属于操作的有效载荷。例如，您可以将被击中的玩家的玩家ID、弹药类型以及他损失了多少生命能量作为有效负载传递给opRaiseEvent()或opCustom()。