As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Adicionar o FlexMatch a um cliente do jogo
Este tópico descreve como adicionar a criação de partidas do FlexMatch aos seus serviços de cliente de jogo.
É altamente recomendável que o cliente do jogo faça solicitações de marcação por meio de um serviço de jogo no backend. Ao usar essa fonte confiável para sua comunicação com o serviço do Amazon GameLift Servers, você pode proteger mais facilmente contra tentativas de invasão e dados de jogadores falsos. Se o seu jogo tem um serviço de diretório de sessão, esta é uma boa opção para lidar com as solicitações de criação de partidas. Usar um serviço de jogos de backend para todas as chamadas para o serviço do Amazon GameLift Servers é uma prática recomendada quando usando o FlexMatch com hospedagem do Amazon GameLift Servers e como um serviço independente.
As atualizações do lado do cliente são necessárias se você estiver usando o FlexMatch com hospedagem gerenciada pelo Amazon GameLift Servers ou como um serviço independente com outra solução de hospedagem. Usando a API de serviço paraAmazon GameLift Servers, que faz parte do AWS SDK, adicione a seguinte funcionalidade:
+ Preparar-se para solicitar a criação de partidas para um ou mais jogadores (obrigatório). Dependendo do seu conjunto de regras de criação de partidas, essa solicitação pode exigir certos dados específicos do jogador, incluindo atributos e latência do jogador.
+ Acompanhe o status de uma solicitação de criação de partidas (obrigatório). Em geral, essa tarefa exige a configuração da notificação de eventos.
+ Solicitar aceitação do jogador para um jogo proposto (opcional). Esse recurso requer interação adicional com um jogador para exibir os detalhes da partida e permitir que ele aceite ou rejeite a partida.
+ Obter as informações de conexão da sessão de jogos e entrar no jogo (exigido). Depois que uma sessão de jogo for iniciada para a nova partida, recupere as informações de conexão da sessão de jogo e use-as para se conectar à sessão de jogo.
## Pré-requisito de tarefas do lado do cliente
Antes de adicionar a funcionalidade do lado do cliente ao seu jogo, você precisa realizar estas tarefas:
+ **Adicione o AWS SDK ao seu serviço de back-end.** Seu backend usa a funcionalidade de serviço na Amazon GameLift Servers API, que faz parte do AWS SDK. Consulte [Amazon GameLift Servers SDKs os serviços ao cliente](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift-supported.html#gamelift-supported-clients) para saber mais sobre o AWS SDK e baixar a versão mais recente. Para obter descrições e funcionalidades da API, consulte [Amazon GameLift ServersFlexMatchReferência de API (AWS SDK)](reference-awssdk-flex.md).
+ **Configure um sistema de tickets de criação de partidas.** Todas as solicitações de criação de partidas devem ter um ID de tíquete exclusivo. Crie um mecanismo para gerar tíquetes exclusivos IDs e atribuí-los às solicitações correspondentes. Um ID de ticket pode usar qualquer formato de string com até 128 caracteres.
+ **Colete informações sobre seu criador de partidas.** Obtenha as seguintes informações de sua configuração de criação de partidas e conjunto de regras.
+ Nome do recurso de configuração de criação de partidas.
+ A lista dos atributos do jogador, que estão definidos no conjunto de regras.
+ **Recupere os dados do jogador.** Configure uma forma de obter dados relevantes para cada jogador incluir em suas solicitações de criação de partidas. Você precisa do ID do jogador e dos valores dos atributos do jogador. Se seu conjunto de regras tiver regras de latência ou se você quiser usar dados de latência ao colocar sessões de jogo, colete dados de latência para cada localização geográfica em que o jogador provavelmente será inserido em um jogo. Para obter medições precisas de latência, use os sinalizadores de ping UDP do Amazon GameLift Servers. Esses endpoints permitem medir a latência real da rede UDP entre dispositivos de jogadores e cada um dos possíveis locais de hospedagem, resultando em decisões de posicionamento mais precisas do que o uso de pings ICMP. Para obter mais informações sobre o uso de sinalizadores de ping UDP para medir a latência, consulte [sinalizadores de ping UDP](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html).
# Solicitar criação de partidas para jogadores
Adicione o código ao seu serviço de backend do jogo para gerenciar as solicitações de criação de partidas para um marcador de jogos do FlexMatch. O processo de solicitação de criação de partidas do FlexMatch é idêntico para jogos que usam o FlexMatch com hospedagem gerenciada pelo Amazon GameLift Servers e para jogos que usam o FlexMatch como uma solução independente.
## Para criar uma solicitação de criação de partidas:
Chame a Amazon GameLift Servers API [StartMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_StartMatchmaking.html). Cada solicitação deve conter as seguintes informações.
**matchmaker**
O nome da configuração de criação de partidas a ser usada para a solicitação. O FlexMatch insere cada solicitação no grupo do marcador de jogos especificado, e a solicitação é processada de acordo com a forma como o marcador está configurado. Isso inclui aplicar um limite de tempo, para solicitar a aceitação de correspondências de jogadores, que a fila usará ao criar uma sessão de jogo resultante, etc. Saiba mais sobre os marcadores de jogos e os conjuntos de regras em [Projetar um organizador de partidas do FlexMatch](match-configuration.md).
**ID do ticket**
Um ID de ticket exclusivo atribuído à solicitação. Tudo relacionado à solicitação, incluindo eventos e notificações, fará referência ao ID do ticket.
**Dados do jogador**
Lista de jogadores para os quais você quer criar uma correspondência. Se algum dos jogadores na solicitação não atender aos requisitos de correspondência, com base nas regras de correspondência e nos mínimos de latência, a solicitação de criação de partidas nunca resultará em uma correspondência bem-sucedida. Você pode incluir até dez jogadores em uma solicitação de correspondência. Quando há vários jogadores em uma solicitação, o FlexMatch tenta criar uma única correspondência e atribuir todos os jogadores à mesma equipe (selecionada aleatoriamente). Se uma solicitação contiver muitos jogadores para caber em uma das equipes de correspondência, a solicitação não será correspondida. Por exemplo, se você tiver configurado o matchmaker para criar correspondências 2v2 (duas equipes de dois jogadores), você não poderá enviar uma solicitação de criação de partidas contendo mais de dois jogadores.
Um jogador (identificado pelo ID) só pode ser incluído em uma solicitação de criação de partidas por vez. Ao criar uma nova solicitação para um jogador, todos os tickets de criação de partidas ativos com o mesmo ID de jogador são automaticamente cancelados.
Para cada jogador listado, inclua os seguintes dados:
+ *Player ID (ID do jogador) * Cada jogador deve ter um ID de jogador exclusivo, gerado por você. Consulte [Gerar jogador IDs](https://docs.aws.amazon.com/gamelift/latest/developerguide/player-sessions-player-identifiers.html).
**Importante**
Quando você cria uma nova solicitação de criação de partida que contenha uma ID de jogador que já esteja incluída em uma solicitação de criação de partida ativa existente, a solicitação existente será automaticamente cancelada. No entanto, um evento de `MatchmakingCancelled` não é enviado para a solicitação cancelada. Para monitorar o status das solicitações de matchmaking existentes, use [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html)para pesquisar o status da solicitação em intervalos pouco frequentes (30 a 60 segundos). A solicitação cancelada mostrará o status `CANCELLED` com o motivo `Cancelled due to duplicate player`.
+ *Atributos do jogador*: se o matchmaker usado chamar atributos do jogador, a solicitação deverá fornecer esses atributos para cada jogador. Os atributos necessários são definidos no conjunto de regras do matchmaker, que também especifica o tipo de dados do atributo. Um atributo é opcional somente quando o conjunto de regras especifica um valor padrão para ele. Se a solicitação de correspondência não fornecer os atributos necessários para todos os jogadores, a solicitação de marcação não será bem-sucedida. Saiba mais sobre conjuntos de regras do marcador e os atributos de jogador em [Construir um conjunto de regras do FlexMatch](match-rulesets.md) e [Exemplos de configuração de regras do FlexMatch](match-examples.md).
+ *Latências do jogador*: se o matchmaker em uso tiver uma regra de latência de jogador, a solicitação deverá relatar a latência para cada jogador. Os dados de latência são uma lista de um ou mais valores para cada jogador. Eles representam a latência enfrentada pelo jogador nas regiões da fila do matchmaker. Se nenhum valor de latência for incluídos na solicitação, o jogador não poderá ser correspondido, e a solicitação falhará. Para obter medições precisas de latência, use os sinalizadores de ping UDP do Amazon GameLift Servers. Esses endpoints permitem medir a latência real da rede UDP entre dispositivos de jogadores e um possível local de hospedagem, resultando em decisões de colocação mais precisas do que o uso de pings ICMP. Para obter mais informações sobre o uso de sinalizadores de ping UDP para medir a latência, consulte [sinalizadores de ping UDP](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html).
## Para recuperar os detalhes da solicitação de correspondência
Depois que uma solicitação de partida é enviada, você pode ver os detalhes da solicitação ligando [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html)com o ID do tíquete da solicitação. Essa chamada retorna as informações da solicitação, incluindo o status atual. Quando uma solicitação tiver sido concluída com êxito, o ticket também conterá as informações necessárias para que um cliente de jogos se conecte à correspondência.
## Cancelar uma solicitação de correspondência
Você pode cancelar uma solicitação de matchmaking a qualquer momento ligando [StopMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_StopMatchmaking.html)com o ID do tíquete da solicitação.
# Rastrear eventos de criação de partidas
Configure notificações para rastrear os eventos que o Amazon GameLift Servers emite para processos de criação de partidas. Você pode configurar notificações diretamente, criando um tópico do SNS ou usando a Amazon EventBridge. Para obter mais informações sobre a configuração de notificações, consulte [Configurar notificações de eventos do FlexMatch](match-notification.md). Quando você tiver configurado as notificações, adicione um ouvinte em seu serviço de cliente para detectar os eventos e responder, conforme necessário.
Também é uma boa ideia fazer backup das notificações sondando periodicamente as atualizações de status quando passar um período significativo sem notificação. Para minimizar o impacto no desempenho de criação de partidas, certifique-se de fazer uma sondagem somente depois de aguardar pelo menos 30 segundos após o envio do ticket de criação de partidas ou após a última notificação recebida.
Recupere um tíquete de solicitação de matchmaking, incluindo o status atual, ligando [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html)com o ID do tíquete da solicitação. Recomendamos a sondagem não mais de uma vez a cada 10 segundos. Essa abordagem é para uso somente durante cenários de desenvolvimento de baixo volume.
**nota**
Você deve configurar seu jogo com notificações de eventos antes do uso da criação de partidas de alto volume, como teste de carga de pré-produção. Todos os jogos em versão pública devem usar notificações independentemente do volume. A abordagem de sondagem contínua é apropriada apenas para jogos em desenvolvimento com baixo uso de criação de partidas.
# Solicitar aceitação do jogador
Se você estiver usando um matchmaker com a aceitação do jogador ativada, adicione o código ao seu serviço de cliente para gerenciar o processo de aceitação do jogador. O processo gerenciamento de aceitações de jogadores é idêntico para jogos que usam o FlexMatch com hospedagem gerenciada pelo Amazon GameLift Servers e para jogos que usam o FlexMatch como uma solução independente.
**Solicitar aceitação do jogador para uma correspondência proposta:**
1. **Detectar quando uma correspondência proposta precisa a aceitação do jogador.** Monitore o ticket de marcação para detectar quando o status mudar para `REQUIRES_ACCEPTANCE`. Uma alteração nesse status aciona o evento FlexMatch do `MatchmakingRequiresAcceptance`.
1. **Obtenha aceitações de todos os jogadores.** Crie um mecanismo para apresentar os detalhes da correspondência proposta para cada jogador no ticket da criação de partidas. Os jogadores devem ser capazes de indicar que aceitam ou rejeitam a correspondência proposta. Você pode recuperar os detalhes da partida ligando para [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html). Os jogadores têm um tempo limitado para responder antes que o matchmaker revogue a correspondência proposta e continue em frente.
1. **Relate respostas do jogador para o FlexMatch.** Denuncie as respostas dos jogadores ligando [AcceptMatch](https://docs.aws.amazon.com/gamelift/latest/apireference/API_AcceptMatch.html)com aceitar ou rejeitar. Todos os jogadores em uma solicitação de criação de partidas devem aceitar a correspondência para ela e continuar.
1. **Gerencie os tickets com aceitações falhas.** Uma solicitação falha quando qualquer jogador na correspondência proposta rejeita a correspondência ou não responde até o limite de tempo. Os tickets para jogadores que aceitaram a partida são automaticamente devolvidos ao pool de tickets. Os tickets para jogadores que não aceitaram a partida passam para o status de FALHA e não são mais processados. Para tickets com vários jogadores, se algum jogador do ticket não aceitar a partida, o ticket inteiro falhará.
# Conectar-se a um jogo
Adicione código ao serviço de jogo para processar um jogo formado com êxito (status `COMPLETED` ou evento `MatchmakingSucceeded`) conforme necessário. Isso inclui notificar os jogadores correspondentes e enviar informações de conexão aos seus clientes de jogos.
Para jogos que usam hospedagem gerenciada do Amazon GameLift Servers, quando uma solicitação de criação de partidas é atendida com sucesso, as informações de conexão da sessão do jogo são adicionadas ao ticket de criação de partidas. Recupere um tíquete de matchmaking preenchido ligando. [DescribeMatchmaking](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeMatchmaking.html) As informações de conexão incluem o endereço IP e a porta do jogo, bem como um ID de sessão do jogador para cada um. Saiba mais em [GameSessionConnectionInfo](https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameSessionConnectionInfo.html). Seu cliente de jogo pode usar essas informações para se conectar diretamente à sessão de jogo para o jogo. A solicitação de conexão precisa incluir um ID de sessão de jogador e um ID de jogador. Esses dados associam o jogador conectado aos dados da partida da sessão de jogo, que incluem as atribuições da equipe (consulte [GameSession](https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameSession.html)).
Para jogos que usam outras soluções de hospedagem, incluindo o Amazon GameLift Servers FleetIQ, você deve criar um mecanismo para permitir que os jogadores da partida se conectem à sessão de jogo apropriada.
# Solicitações criação de partidas de exemplo
Os seguintes trechos de código criam as solicitações de criação de partidas para vários marcadores de jogos. Conforme descrito, uma solicitação deve fornecer os atributos de jogador que são necessárias pelo matchmaker em uso, conforme definido no conjunto de regras do marcador. O atributo fornecido deve usar o mesmo tipo de dados, número (N) ou string (S) definido no conjunto de regras.
```
# Uses matchmaker for two-team game mode based on player skill level
def start_matchmaking_for_cowboys_vs_aliens(config_name, ticket_id, player_id, skill, team):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill}
},
"PlayerId": player_id,
"Team": team
}],
TicketId=ticket_id)
# Uses matchmaker for monster hunter game mode based on player skill level
def start_matchmaking_for_players_vs_monster(config_name, ticket_id, player_id, skill, is_monster):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill},
"desiredSkillOfMonster": {"N": skill},
"wantsToBeMonster": {"N": int(is_monster)}
},
"PlayerId": player_id
}],
TicketId=ticket_id)
# Uses matchmaker for brawler game mode with latency
def start_matchmaking_for_three_team_brawler(config_name, ticket_id, player_id, skill, role):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"skill": {"N": skill},
"character": {"S": [role]},
},
"PlayerId": player_id,
"LatencyInMs": { "us-west-2": 20}
}],
TicketId=ticket_id)
# Uses matchmaker for multiple game modes and maps based on player experience
def start_matchmaking_for_multi_map(config_name, ticket_id, player_id, skill, maps, modes):
response = gamelift.start_matchmaking(
ConfigurationName=config_name,
Players=[{
"PlayerAttributes": {
"experience": {"N": skill},
"gameMode": {"SL": modes},
"mapPreference": {"SL": maps}
},
"PlayerId": player_id
}],
TicketId=ticket_id)
```