For the complete documentation index, see llms.txt. This page is also available as Markdown.

Emparejamiento/juegos hub

Ofrecemos API/configuraciones para gestionar cómo emparejamos a los jugadores con los servidores de tu juego, y permitimos redirigir jugadores a nuevos servidores para soportar escenarios de juegos hub.

Preferencias de emparejamiento

Modo de llenado:

All Out aloja servidores en todo el mundo para ofrecer una experiencia de baja latencia a los jugadores; sin embargo, si tu juego recién está comenzando, quizá quieras hacer concesiones en la latencia para asegurarte de que los jugadores puedan jugar juntos en el mismo servidor. Los modos de llenado están documentados en la página principal del portal del Creador y se pueden cambiar en cualquier momento.

Prioridad de instancia + Modo de requerir alta prioridad

Hay un modo especial de emparejamiento que te permite evitar enviar jugadores a servidores específicos con código.

Los juegos pueden establecer un nivel de "prioridad" para cada instancia según el estado de la ronda, la cantidad de jugadores, etc. usando Server.set_matchmaking_priority(priority).

Opcionalmente, puedes solicitar habilitar el modo "Requerir alta prioridad" para tu juego, lo que solo redirigirá a los jugadores a instancias con prioridad establecida en cero y levantará nuevos servidores si no hay ninguno.

Esto puede ser útil si tienes un juego por rondas en el que no quieres que nuevos jugadores se unan a partidas que ya están en curso.

Esta función está disponible solo bajo solicitud, ya que si tus instancias nunca o rara vez se establecen en la prioridad número 0, ¡levantará una gran cantidad de servidores! Por favor, contáctanos!

Juegos de hub

Los juegos de hub son un patrón común que permite a los jugadores reunirse y hacer cola juntos para un juego por rondas. Algunos ejemplos serían:

  • Un lobby para Red Sun que permite a los jugadores hacer cola para jugar juntos y comprar mejoras mientras esperan

  • El hub de Bed Wars que te permite elegir entre modos de juego (como clases/versus clásico)

Referencia de la API

Server :: struct {
    // Transfiere a un jugador a otro juego (hub -> partida, partida -> hub, etc.).
    transfer_player_to_game :: proc(player: Player, game_id: string);

    // Establece la prioridad de emparejamiento para esta instancia (0 = prioridad más alta).
    set_matchmaking_priority :: proc(priority: int);

    // Expulsa a un jugador del servidor.
    kick_player :: proc(player: Player, reason: string = "Kicked.");

    // Sistema de cola para emparejamiento personalizado. Estas APIs están actualmente obsoletas, pero podrían volver. Prefiere la API transfer_player_to_game.
    queue_add_player           :: proc(queue: string, player: Player);
    queue_remove_player        :: proc(queue: string, player: Player);
    queue_set_server_available :: proc(queue: string, available: bool);

    // Identidad del servidor.
    get_id :: proc() -> string;
    get_private_server_host_id :: proc() -> (string, bool);
}

transfer_player_to_game, set_matchmaking_priority, y kick_player surten efecto en el servidor. Llámalos desde la ruta de juego compartida normal; la llamada equivalente del cliente no tiene efecto.

Las dos consultas de ID solo devuelven datos útiles en el servidor. No hagas ramificaciones de la jugabilidad compartida predicha en función de sus resultados.

Ejemplo: enviar a un jugador a otro juego

Actualmente no hay forma de pasar información adicional al transferir a un jugador a un nuevo juego, ni tampoco hay forma de configurar dinámicamente los servidores al inicio. Si quieres tener diferentes modos (p. ej., 1v1 vs 2v2), tendrás que crear juegos dedicados y enlazarlos con el sistema de parentesco de juegos.

Recomendamos habilitar Productos/datos entre juegos al usar las APIs de teletransporte/hub para asegurar que las compras y los datos guardados de los jugadores puedan reutilizarse fácilmente entre ambos.

Última actualización