Servidores de sesiones de juegos independientes con un backend sin servidor - Amazon GameLift

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Servidores de sesiones de juegos independientes con un backend sin servidor

Mediante una arquitectura de servicio al cliente sin servidor, el backend puede ver el estado de los tickets de matchmaking desde una base de datos altamente escalable en lugar de acceder directamente a la GameLift API de Amazon.

El siguiente diagrama muestra un backend sin servidor creado con elServicios de AWS que se conectan los jugadores con los juegos que se ejecutan en GameLift las flotas de Amazon. La siguiente lista proporciona una descripción de cada llamada numerada del diagrama. Para probar este ejemplo, consulta Alojamiento de juegos multijugador basado en sesiones enAWS on GitHub.

Ejemplo de arquitectura sin servidor que relaciona a los jugadores con los juegos que se ejecutan en GameLift las flotas de Amazon.

  1. El cliente de Amazon Cognito.

  2. El cliente del juego recibe credenciales de acceso temporales y solicita una sesión de juego a través de una API de Amazon API Gateway.

  3. API Gateway invoca unaAWS Lambda función.

  4. La función Lambda solicita datos del jugador de una tabla NoSQL de Amazon DynamoDB. La función proporciona la identidad de Amazon Cognito en los datos de contexto de la solicitud.

  5. La función Lambda solicita una coincidencia a través de Amazon GameLift FlexMatch Matchmaking.

  6. FlexMatch empareja a un grupo de jugadores con la latencia adecuada y, a continuación, solicita una ubicación para una sesión de juego a través de una GameLift cola de Amazon. La cola tiene flotas con una o másRegión de AWS ubicaciones.

  7. Una vez GameLift que Amazon Simple Notification Service (Amazon GameLift SNS), la sesión de Amazon Simple Notification Service (Amazon SNS).

  8. Una función Lambda recibe el evento Amazon SNS y lo procesa.

  9. Si el ticket de emparejamiento es unMatchmakingSucceeded evento, la función Lambda escribe el resultado, junto con el puerto y la dirección IP del servidor del juego, en una tabla de DynamoDB.

  10. El cliente del juego envía una solicitud firmada a API Gateway para ver el estado del ticket de matchmaking en un intervalo específico.

  11. API Gateway utiliza una función Lambda que comprueba el estado del ticket de matchmaking.

  12. La función Lambda comprueba la tabla de DynamoDB para comprobar si el ticket se ha realizado correctamente. Si se ha realizado correctamente, la función envía al cliente el puerto y la dirección IP del servidor del juego, junto con el ID de sesión del jugador. Si el ticket no se ha realizado correctamente, la función envía una respuesta para comprobar que la partida aún no está lista.

  13. El cliente del juego se conecta al servidor del juego mediante TCP o UDP mediante el puerto y la dirección IP que proporciona el servicio de backend. A continuación, el cliente del juego envía el ID de sesión del jugador al servidor del juego, que luego valida el ID mediante el SDK de Amazon GameLift Server.