Procedimientos recomendados y lista de comprobación de lanzamiento

• Haga que el proceso de su servidor de juegos finalice cuando termine su sesión de juego, por ejemplo, cuando termine la partida o cuando se vaya el último jugador conectado. Si su juego permite que los jugadores se vuelvan a conectar, espere primero un breve período de gracia. MPS no finaliza una sesión de juego por usted. Un servidor permanece en estado Active hasta que su proceso finaliza. MPS no quita los servidores Active cuando su compilación se reduce verticalmente, por lo que un servidor que nunca finaliza sigue usando capacidad por la que usted paga. Cuando el proceso finaliza, MPS lo reemplaza por un servidor nuevo. Para obtener más información, consulte Ciclo de vida de un servidor multijugador.
• Inicie un temporizador cuando su servidor pase a estado Active, por ejemplo, cuando el método ReadyForPlayers del SDK de servidor de juegos (GSDK) devuelva true. Si ningún jugador se conecta en unos minutos, finalice el proceso. De este modo, un servidor al que nadie se une, por el motivo que sea, no permanece en estado Active indefinidamente. Base el tiempo de espera en lo que sus jugadores suelen tardar en conectarse.
• Registre una devolución de llamada de apagado del GSDK que realice la limpieza que necesite su servidor y, a continuación, finalice el proceso. El GSDK no finaliza el proceso por usted. MPS llama a su devolución de llamada cuando usted llama a la API ShutdownMultiplayerServer. Llame a esta API solo en caso de emergencia, por ejemplo, para terminar servidores de juegos que se hayan bloqueado. No la use para finalizar sesiones de juego en circunstancias normales. Sus servidores de juegos deben finalizar por sí mismos, como se describe anteriormente en esta sección. Si el proceso sigue en ejecución 15 minutos después de una solicitud de apagado, MPS lo termina de forma forzada. Para obtener más información, consulte Apagado correcto del servidor de juegos.

​

Desarrollo

• Use LocalMultiplayerAgent (LMA) para realizar pruebas iterativas en su estación de trabajo local. Esto ahorra tiempo y dinero, además de simplificar la depuración, ya que todos los artefactos se ejecutan localmente. La herramienta es de código abierto y las contribuciones y mejoras siempre son bienvenidas. Para obtener más información, consulte Depuración local de servidores de juegos e integración con PlayFab.
• Use las programaciones para configurar programaciones concretas y ahorrar en los costos de los servidores en espera (standingBy). Por ejemplo, si todas las pruebas y validaciones se realizan durante el horario laboral, la programación puede configurarse para tener servidores en espera solo durante ese horario. No hay costo adicional por configurar programaciones.
• Use las métricas de VM o sus propios generadores de perfiles para decidir cuántos servidores de juegos ejecutar en una VM del tamaño que haya elegido. Realice pruebas de carga con todos los servidores de la VM en estado Active y llenos de jugadores. Los servidores de la misma VM se pueden asignar e iniciar sus sesiones de juego casi al mismo tiempo, así que incluya ese caso en sus pruebas. Deje margen de CPU: en una VM cuya CPU está saturada, las asignaciones pueden ser lentas o fallar.
• Use los registros del servidor y los volcados de memoria para un análisis más profundo.

​

Preparación para el lanzamiento

• Dirija sus solicitudes de asignación hacia los alias de compilación. Ayudan a migrar sin problemas los clientes del juego a servidores de juegos más nuevos como parte de las actualizaciones del servidor y también pueden ayudar a gestionar los problemas de cuota (que se tratan más adelante).
• Use las balizas de QoS para determinar la región más cercana para un cliente del juego y usarla para las asignaciones. También pueden combinarse con PlayFab Matchmaking para agrupar clientes con latencias similares y asignarles el servidor más cercano.
• Use toda la amplitud de la cobertura geográfica de PlayFab MPS para garantizar que los servidores de juegos estén siempre cerca de sus jugadores. Considere usar varias regiones en un área geográfica para permitir una mayor disponibilidad en caso de errores regionales. Por ejemplo, tener servidores en NorthEurope y WestEurope y especificar ambas regiones en la solicitud de asignación (en orden de prioridad) permite que una asignación que falla en una región tenga éxito en la siguiente región de la lista.
• Cuando realice asignaciones con un alias de compilación, enumere en PreferredRegions todas las regiones que ofrecen a sus jugadores una experiencia aceptable, por orden de preferencia. MPS intenta sus regiones en ese orden, y los pesos de las compilaciones solo deciden qué compilación atiende una solicitud dentro de una región. Una compilación con un peso de 0 nunca se usa, ni siquiera como reserva. Para obtener más información, consulte Reserva ante errores en otras compilaciones y regiones.
• Si RequestMultiplayerServer falla con el error MultiplayerServerTooManyRequests, ninguna de las compilaciones tenía un servidor StandingBy en ninguna de las regiones solicitadas. A pesar de su nombre, este error no significa que sus solicitudes estén limitadas. Para evitarlo:
  • Enumere varias regiones cercanas en PreferredRegions.
  • Configure sus servidores en espera para el pico previsto.
  • Establezca el número máximo de servidores de cada región de compilación con margen por encima del pico previsto. MPS no crea servidores más allá de ese máximo, aunque se agoten los servidores en espera.
• Solicite cuota con suficiente antelación al lanzamiento, para cada familia de VM y región que usen sus compilaciones. Cuando implemente una compilación nueva, la compilación antigua y la nueva usan núcleos al mismo tiempo hasta que se vacían los servidores de la compilación antigua, así que solicite cuota suficiente para ambas. Para repartir su capacidad, considere colocar compilaciones que usen familias de VM diferentes detrás del mismo alias, de modo que las asignaciones puedan recurrir a otra familia de VM en la misma región.
• Puede haber casos en los que la SKU de máquina virtual para su servidor de juegos no esté disponible en todas las regiones donde se va a lanzar el juego. En esos casos, use alias para dividir las compilaciones por SKU y regiones, o use invalidaciones de región dentro de una sola compilación para elegir una SKU de máquina virtual diferente solo para esas regiones.
• Use el modo de espera dinámico para escalar verticalmente los servidores de juegos en función de la demanda. Esto, combinado con la configuración estática predeterminada de servidores en espera, puede proporcionar una forma rentable de gestionar la alta demanda durante el lanzamiento.
• Configure la supervisión de sus servidores de juegos antes del lanzamiento. Active las métricas de VM para ver las métricas de CPU, memoria, disco y red de sus VM en Game Manager. Para una supervisión más avanzada, use VmStartupScript para instalar sus propias herramientas de supervisión en sus VM. El repositorio VmStartupScriptGallery contiene ejemplos que envían métricas de VM y registros del servidor de juegos a servicios como Azure Monitor, Application Insights y Azure Data Explorer.

​

Día del lanzamiento

• Realice un seguimiento del lanzamiento correcto de su juego con los paneles y las secuencias de eventos de PlayFab Game Manager. Tómese un tiempo para celebrarlo, ¡se lo ha ganado!

​

Después del lanzamiento

• Los juegos tienden a caer en un ritmo de demanda que, de nuevo, puede plasmarse en programaciones. Use las programaciones junto con el modo de espera dinámico para un escalado del juego rentable después del lanzamiento.
• Use los alias de compilación para las actualizaciones del servidor de juegos y para dirigir el tráfico gradualmente hacia la nueva experiencia de juego.
• Cuando mueva un alias a compilaciones nuevas, establezca en 0 los servidores en espera de las compilaciones antiguas para que MPS pueda liberar sus VM inactivas. Elimine las compilaciones antiguas solo después de que se vacíen sus servidores Active. Mantenga también sincronizadas las regiones que solicitan sus clientes con las regiones donde están implementadas las compilaciones del alias. Si ninguna de las compilaciones del alias está implementada en ninguna de las regiones solicitadas, la solicitud falla con MultiplayerServerNotFound.