Visibilidade e possibilidade de entrada em sessões de jogo

No XBOX One (ou posterior), as configurações de visibilidade e de possibilidade de entrada de sessões de jogo e parties de jogo controlam o acesso a experiências multiplayer. Para oferecer uma ótima experiência ao usuário na entrada em sessões e no convite de jogadores para sessões e parties de jogo, você precisa entender essas configurações. Este tópico analisa as diferenças entre visibilidade e possibilidade de entrada. Ele também discute as configurações específicas que recomendamos que os títulos usem para oferecer aos consumidores o melhor fluxo de usuário multiplayer.

​

Visibilidade da sessão de jogo

O acesso às sessões do Multiplayer Session Directory (MPSD) é controlado por duas configurações: a visibilidade da sessão e a possibilidade de entrada na sessão. Essas configurações podem ser usadas para limitar o acesso às sessões no nível do MPSD. O primeiro aspecto do controle de acesso é a visibilidade da sessão. A visibilidade da sessão é uma constante definida no momento da criação da sessão. A visibilidade da sessão normalmente é definida no modelo de sessão e determina quais tipos de usuários têm acesso de leitura e gravação a uma sessão. Os valores da configuração de visibilidade são os seguintes.

• Open: todos os usuários podem ler e gravar na sessão.
• Visible: todos os usuários podem ler, mas somente os jogadores que ingressaram e os reservados podem gravar na sessão.
• Private: somente os jogadores que ingressaram e os reservados podem ler ou gravar na sessão.

​

Possibilidade de entrada na sessão de jogo

O segundo aspecto do controle de acesso é a possibilidade de entrada. Ela pode ser definida dinamicamente durante a vida útil da sessão e determina quais tipos de usuários podem ingressar em uma sessão. Os valores da possibilidade de entrada na sessão são os seguintes.

• None: (valor padrão) não há restrições sobre quem pode ingressar na sessão.
• Local: somente usuários locais podem ingressar na sessão.
• Followed: somente usuários locais e usuários seguidos por outros membros da sessão podem ingressar na sessão sem reserva.

Um árbitro ou host da sessão pode criar uma sessão “privada” por meio da configuração de possibilidade de entrada: definir a possibilidade de entrada como local ou followed restringe o acesso a uma sessão de jogo e a torna privada. Além disso, o árbitro ou host da sessão deve acompanhar a possibilidade de entrada de uma sessão, para que convites de sessão mais antigos possam ser rejeitados no nível do host, se necessário. Por exemplo, se algum jogador convidado não tiver chegado para ingressar em uma sessão ou party até que a sessão já esteja cheia, o árbitro ou host pode informar a todos os jogadores que estão ingressando que a sessão foi bloqueada. Eles precisam sair da sessão ou da party automaticamente.

​

Possibilidade de entrada na party de jogo

Além de controlar a sessão do MPSD, o título também controla o estado de possibilidade de entrada na party de jogo. Essa configuração pode ser usada para limitar o acesso à party de jogo no nível da party. A possibilidade de entrada na party pode ser alterada dinamicamente quando a party de jogo é criada. O estado da possibilidade de entrada de uma party de jogo é refletido na interface do usuário de convite da Party. O estado de possibilidade de entrada pode ser definido como:

• Invite-only: essa configuração exige um convite para ingressar na party de jogo.
• Joinable by Friends: (valor padrão) essa configuração exige uma relação de amizade para que um jogador ingresse na party de jogo (para ingressar em uma party, um membro da party precisa seguir o jogador que está ingressando).

A possibilidade de entrada pode ser usada para criar uma party de jogo somente para convidados. Para restringir o acesso a uma party e exigir que os jogadores tenham recebido um convite para ingressar, a possibilidade de entrada deve ser definida como “invite-only”.

​

Recomendações

As recomendações a seguir se aplicam aos cenários de títulos mais comuns. Os títulos devem seguir essas configurações, se possível, e devem usar a lógica do título para tomar a decisão final e definitiva sobre a admissão de um novo jogador na sessão.

​

Visibilidade de sessão de jogo recomendada: open

Sessões de jogo abertas não exigem reservas de jogadores. Isso simplifica o fluxo de convites. O árbitro ou host da sessão não reserva jogadores no documento da sessão depois que um convite é enviado. Em vez disso, o árbitro ou host da sessão apenas acompanha localmente os jogadores convidados. Isso permite que os jogadores se conectem imediatamente ao host e determinem se devem ingressar em uma sessão, se foram rejeitados ou se devem aguardar (se houver suporte a jogadores em espera). O árbitro ou host é a autoridade máxima e responde e instrui o novo membro a permanecer na sessão ou sair dela.

​

Possibilidade de entrada em sessão de jogo recomendada: padrão (não definida)

No momento, a possibilidade de entrada na sessão de jogo não influencia a interface do usuário do aplicativo Party e não é exibida ao usuário. Para simplificar o fluxo do título, a possibilidade de entrada no jogo deve permanecer no valor padrão, e toda a autoridade sobre as entradas deve ser tratada pelo árbitro ou host.

​

Possibilidade de entrada em party de jogo recomendada

A possibilidade de entrada na party de jogo depende do tipo de sessão que um título está tentando oferecer a um usuário. Os dois cenários são os seguintes.

• Jogo aberto: para um jogo aberto, a possibilidade de entrada na party de jogo deve ser mantida no valor padrão: “Joinable by Friends”. Isso permite que amigos ingressem na party de jogo (e, por extensão, na sessão de jogo) sem convite.
• Jogo privado: para um jogo privado ou fechado, a possibilidade de entrada na party de jogo deve ser definida como “invite only”. Isso impede que outros jogadores ingressem na party (e, por extensão, na sessão de jogo) sem convite.

Para os dois tipos de jogo, o árbitro ou host ainda deve continuar sendo a autoridade máxima para determinar quem é aceito em uma sessão. Isso resolve as condições de corrida que podem ocorrer ao mudar o fluxo do jogo de aberto para privado. Se o árbitro ou host rejeitar um jogador, a instância do título rejeitada deve remover o jogador da sessão e exibir uma interface do usuário no jogo que também permita ao jogador sair da party.

​

Tamanho máximo da sessão

O tamanho máximo de membros de uma sessão pode ser usado para limitar o número de jogadores que ingressam em uma sessão de jogo. No entanto, esse limite pode fazer com que uma vaga aberta ainda apareça como ocupada em determinados cenários de desconexão. Por exemplo, se um jogador for desconectado devido a uma falha de rede ou de energia, o atraso não é refletido imediatamente na sessão. O membro é definido como inativo assim que o serviço Presence detecta a desconexão (até 20 segundos). Em seguida, o jogador é removido após a expiração do tempo limite de inatividade. Em comparação, uma malha de pares que usa um sinal de pulsação para detectar uma desconexão geralmente fica ciente de uma desconexão em dois a três segundos e poderia liberar a vaga do jogador imediatamente. No entanto, o árbitro ou host não pode remover outros membros. Para resolver esse problema, o tamanho máximo de membros de uma sessão deve sempre ser definido acima do número máximo de jogadores que um título realmente oferece suporte. Por exemplo, se o número de jogadores for 8, o título deve definir o tamanho máximo da sessão como 12. Dessa forma, novos jogadores podem ingressar, mesmo que os jogadores anteriores ainda não tenham atingido o tempo limite. O árbitro ou host determina se a sessão está cheia e, em seguida, define uma propriedade de sessão personalizada que determina se novos jogadores ainda podem ingressar (IsFull : “true”). Isso permite que os jogadores que estão ingressando verifiquem rapidamente se é possível ingressar na sessão. O árbitro ou host também deve manter uma propriedade personalizada que indique quais membros, por índice, atingiram o tempo limite (por exemplo, TimedOutPlayers : “3, 5, 9”). Isso permite que novos jogadores identifiquem corretamente os membros atuais da sessão.

​

Notificando jogadores em espera

Um título pode oferecer suporte a jogadores em espera gerenciando uma lista de jogadores na fila, além da party de jogo. Quando um jogador se conecta ao host e a sessão de jogo está cheia, o jogador é adicionado à lista de espera interna no host. O jogador na fila não ingressa na sessão de jogo, mas permanece na party de jogo. Para minimizar o tráfego de rede, o jogador em espera se desconecta do host nesse momento.

1. Quando uma vaga na sessão de jogo é liberada para o jogador em espera, o árbitro ou host adiciona uma reserva para o jogador chamando XblMultiplayerSessionAddMemberReservation.
2. Nesse momento, o jogador em espera ainda não está ciente dessa reserva. Como resultado, o árbitro ou host precisa chamar o método PullReservedPlayersAsync. Isso gera uma notificação na interface do usuário ou uma notificação GameSessionReady para todos os jogadores reservados, dependendo da configuração de notificação e do estado de foco do título.
3. O novo jogador se reconecta ao host quando essa notificação é recebida e ingressa na sessão.

Como alternativa, um jogador pode permanecer conectado ao host e ingressar na sessão quando o host o alertar de que uma vaga está disponível. No entanto, nesse fluxo, não é possível exibir uma notificação na interface do usuário fora do título.

​

Fluxo multiplayer do cliente