Configuración de las operaciones en tiempo de ejecución del emparejamiento SmartMatch
Toda la configuración del emparejamiento SmartMatch se realiza a través de Partner Center.Configuración de la plantilla de sesión de emparejamiento
El emparejamiento tiene dos tipos de sesiones relacionadas.- La sesión de vale de partida, que es la entrada al servicio de emparejamiento
- La sesión de destino de partida, que es la salida
La sesión de vale no debe tener habilitadas las comprobaciones de calidad de servicio (QoS) y no debe estar marcada con la funcionalidad “gameplay”.
Configuración básica de tolvas para el emparejamiento
Esta sección define los campos que se usan para configurar los campos básicos de una tolva. Después de esta configuración, debe configurar las reglas de la tolva, tal como se describe en la sección Configuración de reglas de tolva más adelante en este tema. La siguiente captura de pantalla muestra el editor de tolvas. Se describe en las secciones siguientes.Name
El nombre de la tolva que se usa al enviar una sesión al emparejamiento. Este nombre debe coincidir con el valor pasado como parámetro al método XblMatchmakingCreateMatchTicketAsync durante la creación del vale de partida.Min/Max Group Size
Los tamaños mínimo y máximo del grupo de jugadores que se creará a partir de las sesiones de la tolva. El servicio de emparejamiento intenta crear un grupo emparejado lo más grande posible, hasta el tamaño máximo del grupo. Sin embargo, sí crea un grupo emparejado si puede reunir suficientes jugadores para alcanzar el tamaño mínimo del grupo.Should Rule Expansion Cycles
Para una regla SHOULD, si no se encuentra una coincidencia correcta, el servicio de emparejamiento intenta aumentar el espacio de búsqueda y relajar las reglas de emparejamiento proporcionadas con el tiempo. Este proceso se realiza a lo largo de varios ciclos, según lo especificado mediante el campo Should Rule Expansion Cycles. En el último ciclo de expansión, las reglas SHOULD se descartan para que ya no impidan que los vales coincidan. Sin embargo, se siguen usando para determinar la mejor coincidencia si hay varios vales disponibles. Solo los tipos de número y QoS se expanden antes de descartarse. Para obtener más información, consulte la sección Configuración de reglas de tolva más adelante en este tema. Aumentar el valor de la configuración Should Rule Expansion Cycles proporciona más ciclos para la expansión de reglas SHOULD. Sin embargo, este aumento también incrementa la duración del emparejamiento. El valor predeterminado es 3, que suele ser suficiente para la mayoría de las configuraciones.Los ciclos de expansión se producen en intervalos de tiempo fijos de cinco segundos. En el último ciclo de expansión, todas las reglas SHOULD dejan de tenerse en cuenta durante el resto del intento de emparejamiento.
Ranked hopper
Normalmente, SmartMatch impide que los jugadores bloqueados se emparejen. Si se selecciona Ranked Hopper, esta lógica se omite para evitar que los jugadores usen este sistema para eludir a jugadores de mayor habilidad.Configuración de reglas de tolva
Esta sección define los campos que se usan para configurar las reglas de una tolva.Campos de regla comunes
Los campos definidos en esta sección son comunes a todas las reglas de tolva.- Rule Name: El nombre descriptivo que se muestra para la regla con fines de configuración.
-
Rule Type: El tipo de regla. Las opciones son MUST y SHOULD.
- Las reglas MUST deben cumplirse para que el emparejamiento se realice correctamente.
- Las reglas SHOULD se pueden relajar o quitar para encontrar una coincidencia correcta. Para obtener más detalles sobre este proceso, consulte la sección Should rule expansion cycles anteriormente en este tema.
-
Data Type: El tipo de datos del atributo de la regla de emparejamiento.
Los valores posibles son los siguientes.
- Number: Especifica un valor numérico simple de 32 bits.
- String: Especifica una cadena Unicode de hasta 128 caracteres.
- Collection: Especifica una matriz de cadenas. Use este valor para identificar contenido descargable (DLC), pertenencia a escuadras o preferencia de rol de los jugadores.
- Quality of Service: Especifica un tipo de datos personalizado para incluir datos de QoS de latencia en el emparejamiento. Solo se debe usar una regla de este tipo por cada tolva de emparejamiento.
[!NOTE] Si este límite resulta problemático para su título, póngase en contacto con su administrador de cuentas de desarrollador (DAM).
- Total Value: Especifica un tipo de datos personalizado que suma los valores de emparejamiento enviados. Puede usar este valor para asegurarse de que la suma resultante esté dentro de un intervalo específico o sea un valor exacto.
- Team: Especifica un tipo de datos personalizado para los equipos de jugadores incluidos en las solicitudes de emparejamiento. Puede usar este valor para evitar dividir a los jugadores de un mismo vale de partida entre varios equipos.
Campos de regla específicos del tipo de datos
Esta sección define los campos que se usan para definir reglas que se aplican a algunos tipos de datos, pero no a otros. La interfaz de usuario debería poder aclarar qué tipos de datos se aplican a reglas concretas.- Allow Wildcards: Un valor que indica si el atributo puede omitirse en el vale de partida. Si se omite, el vale se vuelve compatible con cualquier otro vale, independientemente del valor de este atributo.
-
Attribute Source: El origen del valor del tipo de datos. Los orígenes posibles son los siguientes.
- Title provided: El valor de datos se envía en el vale de partida.
- User stat instance: El valor de datos se recupera automáticamente del servicio
UserStatistics.
- Attribute Name: El nombre del origen del valor del atributo. Es el nombre de la propiedad en el vale de partida o el nombre de una estadística de usuario.
- Default Value: El valor predeterminado del tipo de datos, si no se especifica ningún valor o no hay ninguno disponible para la solicitud de emparejamiento. El valor predeterminado no se aplica cuando el campo Allow Wildcards está seleccionado y no se especifica ningún valor.
- Weight: La importancia de la regla. El peso se puede usar para indicar qué reglas se priorizan durante el emparejamiento y la expansión de reglas. El valor de peso debe ser un número positivo y su valor predeterminado es 1.
-
Flatten Method: Solo para tipos de datos de número.
Un valor que indica cómo se combinan varios valores para satisfacer una coincidencia.
Se aplica a varios valores de distintos jugadores dentro de un mismo vale de partida y entre varios vales. Los valores posibles son los siguientes.
- Min/Max: Usa el valor mínimo o máximo de varios valores de distintos vales de partida.
- Average: Usa el valor promedio de varios valores de distintos vales de partida.
- Max Diff: Solo para tipos de datos de número. La diferencia numérica máxima aceptable entre dos valores comparados para satisfacer una regla. Para una regla SHOULD, este valor es el punto de partida de la expansión de la regla.
-
Set Operation: Solo para tipos de datos de colección.
La operación que se realiza al hacer coincidir el grupo de valores del conjunto. Las opciones posibles son las siguientes.
- Intersection: Hace coincidir dos colecciones en función de la cantidad de intersección entre ellas. Esta configuración da como resultado valores de colección similares o idénticos.
- Difference: Hace coincidir dos colecciones en función de la cantidad de diferencia entre ellas.
- Role Preference: Hace coincidir colecciones en función de las preferencias del rol de un jugador en modos de juego basados en roles.
- Target Intersection: Parte de la configuración de Set Operation. La intersección mínima o la diferencia máxima entre dos colecciones para que se emparejen.
- Network Topology: Solo para el tipo de datos Quality of Service. La topología de red que se usa para QoS. Los valores posibles son Peer to Peer, Peer to Host y Client/Server.
-
Maximum Latency/Scaling Maximum: Solo para el tipo de datos Quality of Service.
La latencia máxima para un emparejamiento correcto dentro de la topología de red especificada.
Este valor se trata como un valor de escala (en lugar de una latencia obligatoria) cuando se usa una regla SHOULD de Quality of Service de tipo Client/Server.
[!NOTE] Además, también se aplican a la tolva reglas de reputación predeterminadas. Estas reglas no se pueden quitar y se usan para garantizar el manejo correcto de la reputación durante el emparejamiento.
- Allow Waiting for Roles: Solo para el tipo de datos Collection Role Preferences. Especifica si el servicio de emparejamiento retiene el vale de emparejamiento para cubrir todos los roles disponibles.
Delta de expansión
El valor que indica cuánto se relaja la regla enviada en cada generación de expansión. El delta de expansión se aplica además del valor Max Diff. Para obtener más detalles, consulte el Ejemplo 1 (expansión de reglas) más adelante en este tema. También puede usar el delta de expansión para expandir varios valores numéricos a distintas velocidades. Esto no es posible mediante la configuración de ciclos de expansión porque se aplica a todas las reglas. En su lugar, el enfoque consiste en usar valores de expansión decimales; por ejemplo, 0,4. Una expansión solo se produce cuando se alcanza un nuevo entero, lo que permite distintas velocidades de expansión, incluso para el mismo número de ciclos de expansión.Expansión de QoS (de par a par, de par a host)
Para la expansión de tipo QoS en juegos entre pares, el delta de expansión no se puede configurar. En su lugar, debe usar una de las siguientes estrategias de expansión.- MaxLatency menor que 256 La expansión se realiza a MaxLatency × ciclo de expansión. Por ejemplo, si el valor inicial es 200, se usa 200 en el primer ciclo y 400 en el segundo ciclo.
- MaxLatency mayor o igual que 256 La expansión se escala linealmente de 50 a MaxLatency - 256. Por ejemplo, si el valor inicial es 556, el valor se escala linealmente de 50 a 300 a lo largo del número de ciclos. Es decir, si se eligieran seis ciclos, los valores serían 50, 100, 150, 200, 250 y 300. Si se eligieran cinco ciclos, los valores serían 50, 112,5, 175, 237,5 y 300.
Expansión de QoS (cliente/servidor)
Cuando se usan servidores dedicados, la expansión se basa en la preferencia relativa. Solo los servidores más preferidos se consideran en los primeros ciclos de expansión. Con el tiempo, se usan otros servidores menos preferidos. Para garantizar una expansión adecuada, se requiere un valor similar a MaxLatency, denominado Scaling Maximum. Igualmente, debe establecerse en el tiempo de ping máximo aceptable. Sin embargo, este valor proporciona una escala relativa para los distintos tiempos de ping de servidor proporcionados por un jugador, en lugar de establecer un requisito absoluto para los tiempos de ping. Puede excluir servidores con tiempos de ping inaceptables quitándolos de la lista de la solicitud. Volver al principio de este tema.Ejemplo 1 (expansión de reglas)
El nivel del jugador se usa para el emparejamiento, y los jugadores se emparejan de forma flexible, según la proximidad de sus niveles. Se prefiere a los jugadores con la menor diferencia entre sus niveles.- Player Level Rule
- Rule Type: SHOULD
- Data Type: Number
- Max Diff: 1
- Expansion Delta: 2
- Flatten Method: Average
- Si se encuentra una coincidencia dentro de esta diferencia, los jugadores se emparejan.
- Si no se encuentra una coincidencia inicial, el valor del nivel del jugador se expande en 2 en cada iteración (de forma predeterminada, hay tres iteraciones).
Ejemplo 2 (regla de colección)
El juego publica tres tipos de DLC disponibles para los jugadores. Esta regla de emparejamiento se aplica al emparejamiento de juego “solo DLC”, y un jugador debe poseer al menos un DLC para ser emparejado con otros jugadores.- Player DLC Rule
- Rule Type: MUST
- Data Type: Collection
- Set Operation: Intersection
- Target Intersection: 1
En la tabla siguiente, el valor de la colección indica la propiedad del DLC. Si el DLC está disponible para el jugador, el valor se establece en 1. Si no lo está, se establece en 0. |
Si la intersección de destino de este ejemplo se establece en 2, los jugadores 1 y 3 no se emparejarán porque la intersección entre ellos es solo 1.
Ejemplo 3 (evitar jugadores anteriores)
El título prefiere evitar una partida con el jugador con el que se jugó más recientemente.- Rule Type: MUST
- Data Type: Collection
- Set Operation: Difference
- Target Intersection: 0
Definición de reglas de equipo durante la configuración de SmartMatch
Configuración de reglas de equipo
Para configurar la regla de equipo, comience por crear una en Partner Center. Rellene los tamaños de equipo que su juego espera crear a partir de los vales emparejados en esta tolva. Por ejemplo, si su juego espera cuatro contra cuatro, debe crear dos entradas, cada una con un tamaño máximo de cuatro y un nombre distinto. También hay un tamaño mínimo de equipo. Úselo si se puede jugar una partida con menos jugadores en un equipo. De lo contrario, el mínimo y el máximo deben tener el mismo valor.Uso de reglas de equipo
Después de configurar la regla de equipo, se impide que los vales dentro de la tolva coincidan si no hay forma de encajar sus grupos en equipos sin provocar una división. La regla escribe la asignación de equipos resultante en la sesión de destino, en members/constants/custom/matchmakingresult/initialTeam.Esta es simplemente una asignación sugerida. El título podría descubrir que, al reorganizar a los jugadores, puede crear una partida mejor y, al mismo tiempo, evitar que los vales se dividan en equipos distintos.
PreserveSession establecido en always.
En tales casos, dado que los equipos ya se han asignado a los jugadores, el título debe especificar la asignación de equipos actual para que Match sepa cuántos espacios quedan libres en cada equipo.
Para proporcionar los nombres de los equipos en los que está cada jugador, cada jugador escribe el nombre de su equipo en la sesión de juego, en members/me/properties/system/groups.
Este campo es un JArray.
Después de que las propiedades mencionadas anteriormente se escriban en la sesión de juego, un jugador crea un vale para la sesión en un intento de encontrar más jugadores.
Cuando se completa el vale, Match volverá a escribir el equipo sugerido de los jugadores que se unan en members/constants/custom/matchmakingresult/initialTeam.
Preferencia por equipos equilibrados
Además, las partidas se crean primero con los equipos más grandes. Esto significa que, en una hipotética tolva de cuatro contra cuatro, los vales de cuatro jugadores se emparejarán primero entre sí, hasta que no queden vales de cuatro. Los vales de tres continúan después, incorporando jugadores individuales según sea necesario, y así sucesivamente. De esta manera, los vales de tamaño similar generalmente jugarán unos contra otros, si están presentes y otras reglas no lo impiden.Esto otorga a la regla de equipo una precedencia bastante fuerte sobre otras reglas.