游戏会话的可见性和可加入性
在 Xbox One (或更高版本) 上，游戏会话和游戏群的 可见性 和 可加入性 设置控制对多人游戏体验的访问。 若要给会话加入提供良好的用户体验，以及邀请玩家进入游戏会话和群，需要了解这些设置。
本主题回顾可见性和可加入性之间的差异。 本主题还讨论了我们建议游戏为使用者提供最佳多人游戏用户流的特定设置。
游戏会话的可见性
多人游戏会话目录 (MPSD) 会话访问受两个设置的限制：会话可见性和会话可加入性。 这些设置可以用来限制 MPSD 级别的会话访问。
访问控制的第一个方面是会话可见性。 会话可见性是在会话创建时设置的常量。
会话可见性通常在会话模板中定义，并确定哪类用户具有对会话的读写访问权限。
可见性设置的数值如下值。
开放: 所有用户均可以读取和写入会话。
可见: 所有用户均可以读取会话，但只有加入和保留的玩家可以写入会话。
私人: 仅加入和保留的玩家可以读取或写入会话。
注意
将可见性设置为“私人”可能需要重试受邀请玩家发出的 join() 调用。 如果邀请通过平台 UI 发送，它可以由另一个玩家接收（在该玩家被保留在会话中之前）。 此争用情况可能会导致受邀请玩家的 join() 调用失败，因为“私人”或“可见”会话需要为加入玩家保留。
如果保留不存在，将在会话中引发访问错误 (HTTP/403)。 然后，受邀玩家必须重试 join() 操作。 但是，重试的频率不应超过每 5 秒一次。 我们建议游戏将会话可见性设置为“开放”，以避免玩家的加入流程中出现争用情况。
游戏会话的可加入性
访问控制的第二个方面是可加入性。 它可以在会话生存期内动态设置，并确定哪类用户可以加入会话。
会话可加入性的数值如下。
无 (默认值) 对于可以加入会话的人没有限制。
本地: 仅本地用户可以加入会话。
已关注: 仅本地用户和其他会话成员关注的用户可以在不保留的情况下加入会话。
会话仲裁程序或主机可以通过可加入性设置创建私人会话: 使可加入性设置为本地或已关注，限制对游戏会话的访问，使其变为私人会话。
此外，会话仲裁程序或主机应跟踪会话的可加入性，以便在需要时可以在主机级别拒绝较早的会话邀请。 例如，如果受邀请的玩家在会话已满前未到达并加入会话或群，仲裁程序或主机可以指示任何正在加入的玩家该会话已锁定。 他们需要自动离开会话或群。
注意
游戏会话可加入性不会反映在“群应用” UI 中。 即使可加入性受限，“群应用”邀请 UI 和 ShowSendInvitesAsync 也允许发送游戏会话邀请。
游戏群可加入性
除了控制 MPSD 会话外，游戏还可以控制游戏群可加入性的状态。 此设置可以用来在群级别限制游戏群的访问。
群的可加入性可以在游戏群创建时动态地更改。 游戏群的可加入性状态反映在群邀请 UI 中。
可加入性状态可以设置如下:
仅邀请: 此设置需要加入游戏群的邀请。
可由好友加入: (默认值) 此设置需要玩家拥有好友关系才可加入游戏群 (要加入某个群，群的成员必须关注加入的玩家)。
可加入性可用于创建仅邀请的游戏群。 要限制群的访问权限，并要求玩家必须收到邀请才能加入，应将可加入性设置为“仅邀请”。
注意
群可加入性并不影响会话的可加入性。 但群的可加入性反映在“群应用”UI 中。 玩家可以在游戏之外的“群”应用中手动更改群可加入性。
建议
下面的建议适用于最常见的作品场景。 如果可能，游戏应遵循这些设置，并应使用游戏内逻辑来对是否允许有关新用户进入会话做出最终的权威决定。
建议的游戏会话可见性为: 开放
打开游戏会话不需要玩家预约。 这简化了邀请的流。
会话仲裁程序或主机不会在发送邀请后在会话文档中保留玩家。 相反，会话仲裁程序或主机仅在本地跟踪受邀请的玩家。 这让玩家可以立即连接到主机，并确定他们是否应该加入会话、遭到拒绝，还是应该等待 (如果支持等待玩家)。
仲裁程序或主机是最终授权和响应，指示新成员留在会话中还是离开。
注意
这将需要受邀请的玩家启动游戏并在进行最终决定前连接到仲裁程序或主机。 如果会话已满或邀请遭到拒绝，可以接受向用户显示一条错误消息。
注意
要建立与仲裁程序或主机的连接，需要安全设备地址。 会话中的 HostDeviceToken 应用于指示哪个会话成员是会话当前的仲裁程序或主机，以及受邀请的玩家应该连接到哪个安全设备地址。
建议的游戏会话可加入性为: 默认 (未设置)
目前，游戏会话的可加入性不影响“群应用”UI，且不向用户提供。 要简化游戏流，游戏可加入性应保留为默认值，并且所有加入授权均应通过仲裁程序或主机处理。
建议的游戏群可加入性
游戏群可加入性取决于游戏尝试向用户提供的会话类型。
两个方案为如下所示。
打开游戏： 对于开放游戏，游戏群可加入性应保留为默认值：“好友可加入”。这允许好友在没有邀请的情况下加入游戏群（以及通过扩展、游戏会话）。
专用游戏： 对于专用或关闭游戏，游戏群可加入性应设置为“仅邀请”。这会限制其他玩家在没有邀请的情况下加入群（以及通过扩展、游戏会话）。
注意
玩家可以通过“群应用”手动更改游戏会话的可加入性。
对于两个游戏类型，仲裁程序或主机仍应保留最终权限，以确定谁被接受加入会话。 这可以应对将游戏流从开放切换为私人时发生的任何争用情况。 如果仲裁程序或主机拒绝玩家，被拒绝的游戏实例应将玩家从会话中删除，并应显示游戏内 UI 以允许玩家离开群。
最大会话大小
会话的最大成员人数可用来限制加入游戏会话的玩家数量。
但是，此限制可能会导致在某些断开连接场景下开放式插槽仍显示为已满。 例如，如果玩家由于网络或电源故障而断开连接，延迟不会立即反映在会话中。
一旦“状态”服务检测到断开连接 (最多 20 秒)，成员就会设置为非活动状态。 在非活动超时到期后将移除玩家。
相比之下，使用检测信号检测断开连接的对等网格通常能在两到三秒内得知断开连接，因此可以立即打开玩家空位。 但是，仲裁程序或主机无法删除其他成员。
要解决此问题，应始终将会话的最大成员大小设置为高于游戏实际支持的玩家最大数。 例如，如果玩家数是 8，作品应将最大会话大小设置为 12。 这样，即使之前玩家尚未超时，新玩家也可以加入。
仲裁程序或主机确定会话是否已满，然后设置一个自定义会话属性，用于确定新玩家是否仍可以加入 (IsFull: “true”)。
通过该操作，可在会话为可加入状态时快速确定加入的玩家。
仲裁程序或主机还应维护一个自定义属性，该属性指示已超时的成员以及索引位置 (例如，TimedOutPlayers :“3, 5, 9”)。
这使新玩家能够正确识别当前会话成员。
通知等待玩家
作品可以通过除管理游戏群外还管理排队的玩家列表来支持等待玩家。 当玩家连接到主机且游戏会话已满时，玩家将被添加到主机上的内部等待列表中。
排队的玩家未加入游戏会话，但仍在游戏群内。 要将网络流量降至最低，等待的玩家应在此时与主机断开连接。
当游戏会话为等待的玩家开放席位时，仲裁程序或主机将通过调用 XblMultiplayerSessionAddMemberReservation 为该玩家添加预留。
此时，等待的玩家还不知道此预订。 因此，仲裁程序或主机必须调用
PullReservedPlayersAsync方法。 这会导致 UI 通知或对所有保留玩家的GameSessionReady通知取决于通知配置和游戏焦点状态。收到此通知时，新玩家会重新连接到主机，并将加入该会话。
或者，玩家可以保持与主机的连接，并在主机提示玩家有空位时加入会话。 然而，在这个流程中，无法显示游戏之外的 UI 通知。
注意
如果暂停或终止游戏，玩家将自动从游戏方中删除。 玩家不会收到进一步通知。
客户端多人游戏流
