Empaquetado en contenedores de los servidores de juegos
Windows
En Windows, normalmente se empaqueta el ejecutable del servidor de juegos y otros archivos como archivos zip, y se cargan como recursos del juego. Los recursos se combinan con una imagen de contenedor para crear su compilación de servidor de juegos. La imagen de contenedor base proporciona los archivos del sistema operativo Windows y el entorno de ejecución que permite que el juego se ejecute. PlayFab proporciona un conjunto de imágenes de contenedor administradas para usar en compilaciones de Windows. Cuando se crea una compilación de Windows mediante Game Manager o API como CreateBuildWithManagedContainer(), se especifican los recursos y dónde deben montarse dentro del sistema de archivos del contenedor. También se especifica el comando de shell para iniciar el juego (StartGameCommand), que podría ser similar al que se muestra a continuación.
StartGameCommand debe iniciar una aplicación que use el SDK de servidor de juegos de PlayFab, para llamar a ReadyForPlayers cuando esté lista para atender a los clientes del juego. El contenedor se terminará y se reciclará cuando el proceso de la aplicación se cierre.
Linux
En Linux, usted mismo crea la imagen de contenedor empaquetando el ejecutable del juego y los recursos. El uso de recursos que se combinan con la imagen de contenedor en tiempo de ejecución es opcional. Cuando se crea una compilación de Linux mediante Game Manager o API como CreateBuildWithCustomContainer(), puede especificar opcionalmente los recursos y dónde deben montarse dentro del sistema de archivos del contenedor. La especificación del comando de shell para iniciar el juego (StartGameCommand) también es opcional, ya que este comando también puede incluirse en la imagen de contenedor.
Consulte esta página para obtener más información sobre la creación de imágenes de contenedor de Linux para PlayFab Multiplayer Servers
Contenedores administrados para Windows
PlayFab admite actualmente un contenedor administrado: la imagen de contenedor de PlayFab Multiplayer, basada en Windows Server Core. Puede descargar este contenedor a través de Docker Hub para que su entorno local coincida con el entorno de ejecución en Azure. Hay herramientas de depuración que le permiten recorrer paso a paso la máquina de estados del servidor multijugador de forma local en su equipo de desarrollo. Para obtener más información, consulte Depuración local de servidores de juegos e integración con PlayFab. La imagen siguiente muestra los flujos clave para cargar un servidor de juegos y combinar este paquete con un contenedor seleccionado.Actualizaciones de contenedores administrados
Los contenedores administrados son la opción de integración más sencilla para proyectos de Windows y un buen punto de partida si no está familiarizado con los contenedores. Una característica clave de los contenedores administrados es que PlayFab actualizará automáticamente la imagen base con correcciones de seguridad críticas para garantizar un juego confiable. En general, las actualizaciones de seguridad se producen cada mes y no deberían causar interrupciones del servicio. Para obtener más información, consulte Actualizaciones de revisiones del SO para Windows. Durante una actualización, las sesiones en espera que se reciclan de forma natural se reemplazarán con una imagen de contenedor actualizada y el mismo paquete de servidor de juegos. Cuando PlayFab tenga la intención de actualizar una imagen de contenedor administrada que usted esté usando, recibirá eventos de PlayStream.Integración del SDK de servidor de juegos de PlayFab
Obtenga más información en: Integración de servidores de juegos con el SDK de servidor de juegos de PlayFab (GSDK) El SDK de servidor de juegos de PlayFab (GSDK) se proporciona en varios lenguajes de programación, como C++, C# y Java. El GSDK conecta su servidor de juegos con un agente local instalado en la VM. Este agente facilita las interacciones clave del servidor con la infraestructura de control de PlayFab. Cuando su servidor de juegos se inicializa, se coloca en un estado de preparación, mientras PlayFab espera a que su servidor de juegos llame aReadyForPlayers().
Una vez realizada esta llamada, el servidor de juegos se coloca en un estado en espera, y espera solicitudes de asignación desde su servicio de emparejamiento hacia PlayFab mediante el método RequestMultiplayerServer.
La imagen que se muestra a continuación muestra los estados de un servidor multijugador de PlayFab.
En apariencia, llamar a ReadyForPlayers() es el único requisito para que su servidor de juegos se ejecute y siga ejecutándose. Sin embargo, hay varias devoluciones de llamada/eventos que quizá desee procesar para proporcionar la mejor experiencia de usuario.
Scripts de servidor y variables de entorno configuradas por PlayFab
En algunos casos, es posible que desee que los servidores de juegos ejecuten un script de CMD, PowerShell o bash (un “arrancador”), que luego inicie el ejecutable compilado de su servidor de juegos. Este script puede configurar el entorno interno del contenedor, pasar argumentos de línea de comandos al ejecutable o cualquier otra tarea que no desee ejecutar en el propio ejecutable del servidor de juegos. Para su comodidad, PlayFab configura cierta información de la compilación como las siguientes variables de entorno en el contenedor. También se puede acceder a ellas mediante el GSDK, pero usar las variables de entorno puede ser más fácil desde un script.- PF_TITLE_ID: identificador del título para el host de sesión
- PF_BUILD_ID: identificador de compilación para el host de sesión
- PF_REGION: región de Azure para el host de sesión
- PUBLIC_IPV4_ADDRESS: dirección IP pública de la VM
- PF_VM_ID: identificador único de la VM (como ‘xcloudeau4u4yyxj4xymu:AustraliaEast:1E03_6f27ad88-9bc3-4ea3-8d16-75480aba4637:tvmps_0e05c37e0bbdca298a09fb0d597bd666eb7c5fd0ebcf1fed4c52e608a39a7c9c_d’)
- CERTIFICATE_FOLDER: carpeta que contiene los certificados del juego
- PF_SERVER_LOG_DIRECTORY: carpeta que contiene los registros del juego
- PF_SERVER_INSTANCE_NUMBER: número de instancia del servidor. El primer servidor en la VM es 0, el segundo es 1, el tercero es 2, etc.