API de Torneos¶

A continuación se da una descripción del comportamiento soportado por Onsite ante el flujo de creación y juego de un torneo. Se describen las entidades que componen a un torneo y su relación con la arquitectura del servidor.

Lógica de torneos¶

En esta sección se define y ejemplifica el flujo que es llevado a cabo por los asistentes de un local Arena para configurar un torneo, así como el proceso de llevar registro de los resultados de las partidas. Se detallan las modalidades de torneo a contemplar por el sistema y el comportamiento a seguir cuando la cantidad de equipos a inscribirse requiera un ajuste en la organización de las partidas.

Creación de un torneo¶

Los parámetros de inicialización de un torneo son los siguientes:

Nombre
Juego
Modo de juego
Máxima cantidad de jugadores participantes
Jugadores por equipo
Información de reglamento general
Información de configuración de partida
Criterios. Información sobre cada equipo en una partida. Ej: Porcentaje de tiros a la cabeza, número de goles.

Flujo de juego¶

Los participantes del torneo anunciarán su asistencia haciendo check in en la aplicación Kiosk. Después de cierto tiempo de tolerancia, se cierra el check in desde Kiosk.
El Asistente pasa lista a los equipos que se registraron en Kiosk, estos equipos pueden ser de 1 o más jugadores. Marca en su aplicación a los equipos presentes.
Con la alineación de equipos confirmada se integra el conjunto de participantes del torneo. A partir de este momento no es posible unir equipos.
El asistente configura en su aplicación el número de grupos en que se dividirá a los equipos, así como la modalidad de juego en cada grupo. Seleccionar 1 grupo si no desea dividirse a los equipos.
El asistente asocia equipos a los grupos recién creados.
Confirmar el proceso llevado a cabo en 4 - 5. Como consecuencia, el sistema propondrá una distribución de partidas aleatoria para cada grupo, misma que puede ser editada. Posterior a la confirmación de esta distribución no es posible realizar cambios en la cantidad de grupos, los equipos que los integran, o la modalidad de los mismos. En un grupo con modalidad de juego Round Robin no es posible efectuar cambios en el orden de las partidas, dado que en esta modalidad de juego cada equipo se enfrentará a todos los restantes.
Se registra manualmente el resultado de cada partida para cada grupo en las plantillas generadas en la aplicación Asistente. También es labor manual marcar el equipo que pasa a la siguiente partida del grupo, en caso de jugarse eliminación simple / doble.
Manualmente se indica qué equipos pasan a la siguiente fase.

Caso de ejemplo¶

A continuación se describe un torneo de ejemplo con el fin de ilustrar el comportamiento contemplado por el sistema Arena.

Registro¶

Se registran 27 equipos de un jugador a través del portal a un torneo con las siguientes características

Nombre: Torneo FIFA 17 febrero
Juego: FIFA 17
Modo de juego: 1 vs 1
Cantidad de participantes: Hasta 40
Jugadores por equipo: 1
Información de reglamento general: El creador del torneo carga un PDF
Información de configuración de partida: El creador del torneo carga un PDF
Fecha: 15 de febrero del 2017
Hora: 17:00 horas
Estaciones reservadas para el torneo: TV001, TV002, TV004, TV005, TV006, TV025

Asistencia¶

A través de Kiosk se presentan 20 equipos. El Asistente hace una segunda verificación de los presentes y se marca asistencia a 19 equipos. A partir de este momento no es posible admitir a los equipos que no se han presentado.

Creación de grupos¶

Se configura que los equipos de la fase actual se dividirán en 4 grupos, siendo el formato para todos best-of-one. La alineación de grupos es la siguiente

Creación de plantillas¶

Una vez confirmada la división en grupos, se crean las plantillas como sigue

Grupo 1

Grupo 2

Grupo 3

Grupo 4

Se confirman las plantillas desde uno de los clientes Assistant. Una vez confirmadas, las plantillas no podrán ser editadas.

Resultados del torneo¶

A lo largo del torneo se registran los resultados de las partidas. Esto se llevará a cabo seleccionando la partida e indicando al equipo ganador y al perdedor.

Grupo 1

Grupo 2

Grupo 3

Grupo 4

Transición a la siguiente fase¶

Mediante inspección de los resultados ingresados a las plantillas, una asistente determina que los ganadores de la fase son los siguientes:

Grupo 1: Equipo 4
Grupo 2: Equipo 6
Grupo 3: Los equipos 7 y 13 empataron. Se consultan los criterios de evaluación y se concluye que el equipo 7 es el ganador.
Grupo 4: Equipo 18

Por lo tanto, se registra a través de la aplicación que los ganadores de la fase son E4, E6, E7, E18. Estos ganadores pueden pasar a una siguiente fase si así se desea o pasar a un nuevo torneo, por ejemplo un torneo de final.

Al momento de crear una nueva fase o un nuevo torneo desde Assistant, es posible consultar e importar a los ganadores de otra fase u otro torneo, respectivamente.

Formatos best-of¶

Los formatos best-of se refieren a una configuración en la modalidad de juego de un grupo que indica el número máximo de veces que debe suceder un enfrentamiento entre dos equipos antes de declarar un ganador definitivo entre ambos. En este esquema, cada pareja de equipos enfrentados dentro del grupo compite para ganar la mayoría de los juegos definidos. Los formatos best-of soportados por el sistema son:

Best-of-one. Formato disponible para modalidades Round Robin, Eliminación Simple y Eliminación Doble donde cada pareja de equipos se enfrenta en una única ocasión para determinar al ganador de la ronda; o bien, una única vez dentro del bracket de winners y otra dentro del bracket de losers en caso de tratarse de un grupo con modalidad de Eliminación Doble. Este formato es el default al momento de definición de un grupo.
Best-of-two. Formato únicamente disponible para modalidades Round Robin donde cada pareja de equipos se enfrenta en dos ocasiones. En consecuencia, se asigna puntuación a un equipo en la ronda tomando en cuenta el número de veces que ganó, perdió o empató frente al oponente en los dos enfrentamientos.
Best-of-three / best-of-five / best-of-seven. Formato disponible para modalidades Round Robin, Eliminación Simple y Eliminación Doble donde cada pareja de equipos en el grupo se enfrenta en un máximo de tres / cinco / siete ocasiones antes de declarar al ganador de la ronda. En el caso de un grupo con modalidad de juego Round Robin, los puntos al ganador se otorgarán al equipo que gane dos / tres / cuatro juegos de tres / cinco / siete, por lo que no hay posibilidad de empate.

Modalidades de torneo¶

Round Robin¶

Descripción: Cada contendiente se enfrenta una o dos veces a cada uno de los contendientes en su grupo. En caso de que se registre un empate entre varios equipos, se utilizan los criterios de evaluación (tiros a la cabeza, goles a favor, precisión) para determinar al equipo ganador. De manera alternativa, puede crearse un grupo de desempate donde jugarán los participantes empatados.

Parámetros de configuración requeridos: Número de equipos, puntos por victoria, puntos por derrota, puntos por empate, número de contendientes que clasifican (en caso de permitir más de un ganador).

Eliminación Simple¶

Descripción: El contendiente perdedor de cada bracket es eliminado inmediatamente del torneo, por lo que el ganador será el contendiente que no haya sido derrotado a lo largo de los enfrentamientos. Únicamente clasifica el primer lugar.

Parámetros de configuración requeridos: Número de equipos.

Eliminación Doble¶

Descripción: Un contendiente puede perder en una ocasión a lo largo del torneo sin ser expulsado del mismo. La segunda derrota del participante resulta en eliminación. El torneo se maneja en dos brackets: Winners, donde permanecen los equipos que no han sufrido derrotas; y Losers, donde participan los equipos que han perdido en una ocasión a lo largo del torneo. Si el perdedor de la ronda final proviene del bracket de Winners, será necesario jugar un segunda final. Esto debido a que el perdedor sufrió su primera derrota del torneo, y por definición de Eliminación doble, son necesarias dos derrotas para salir del torneo. Únicamente clasifica el primer lugar.

Parámetros de configuración requeridos: Número de equipos.

Sistema de byes¶

Un bye es un privilegio concedido a un equipo en la ronda inicial al estar exento de jugar; por lo tanto, el equipo entra directamente a la segunda ronda. Se hace uso del sistema de byes cuando el número de contendientes en un grupo con modo de eliminación (simple o doble) no es una potencia de dos.

Para determinar a los byes en un torneo se sigue el siguiente algoritmo

Byes = Potencia de dos más próxima - Número de participantes
No byes = Número de participantes - Número de byes
De manera aleatoria se selecciona a los equipos que contarán con el privilegio de ser byes.
Aquellos contendientes que no sean seleccionados como byes son elegidos para ser los primeros en jugar. Los ganadores de esta ronda jugarán con los byes.

Ejemplo:

Para un torneo con 6 equipos E1, E2, E3, E4, E5, E6 es necesario usar el sistema de byes, dado que la cantidad de equipos no es una potencia de dos.

Byes = Potencia de dos más próxima - Número de participantes = 8 - 6 = 2
No byes = Número de participantes - Número de byes = 6 - 2 = 4
Se otorga el privilegio de bye a los equipos E3 y E5
Los equipos que jugarán una ronda inicial son E1, E2, E4, E6

Sobre las potencias de dos: Una potencia de dos es un número que se obtiene de multiplicar el 2 por sí mismo repetidas veces.

Únicamente un número de participantes que corresponda a una potencia de dos permite generar un bracket de torneo donde el número de contendientes sea par en toda etapa del mismo. Un número de participantes múltiplo de 4 no basta debido a que es posible que estos contengan factores impares. Ejemplo: 20 es múltiplo de 4; sin embargo, 20 = 4 x 5, por lo que en algún momento del torneo se tendrá a un número impar de contendientes (5).

Gráfica de torneos¶

A continuación se muestra una estructura de torneos que será soportada por el sistema Arena. Se contemplará una relación de dependencia entre torneos clasificatorios, es decir, los ganadores de un torneo pueden ser exportados a otro.

En la imagen anterior, los nodos corresponden a torneos; y las flechas señalan la transición de equipos ganadores de cada uno. Adicionalmente, se subdivide a cada torneo en fases, que corresponden a etapas de juego dentro de un mismo torneo. En cada una de las fases se lleva a cabo una división en grupos, donde se configura la modalidad de juego. Un esquema de fases dentro de un torneo se muestra a continuación.

Como observación, los equipos ganadores de un torneo no pueden transicionar a más de un torneo clasificatorio por ocasión. Esto es, el siguiente esquema de clasificación no es contemplado

Donde las flechas resaltadas en rojo corresponden a transiciones no permitidas, al no soportar que los equipos ganadores de un torneo clasifiquen simultáneamente a más de otro.

Creación de una plantilla torneo¶

Un User de Offsite es capaz de dar de alta plantillas de torneo, con el objetivo de que estas puedan ser leídas posteriormente por un local. El proceso es descrito a continuación.

Descripción general¶

_images/tournament_template_creation_overview.svg

Un usuario solicita la creación de una plantilla de torneo en Offsite.
Offsite da de alta la plantilla de torneo y confirma su creación al usuario.

Flujo¶

La creación de plantilla se lleva a cabo como se indica en Crear una plantilla.

Creación de torneo¶

A continuación se describe el proceso para la creación de un torneo en un local a partir de una plantilla existente en Offsite.

Descripción general¶

Consulta de plantillas en Offsite¶

El usuario solicita a Offsite conocer la lista de plantillas existentes.
Offsite responde con la información de los esquemas de torneo disponibles.

Creación de torneo¶

El usuario solicita a Offsite la creación de un torneo siguiendo algún esquema existente.
Offsite responde con la información del torneo creado.

Flujo¶

La consulta de plantillas de torneo se lleva a cabo como se indica en Ver lista de plantillas.

Para la creción y actualización de un torneo, se hace uso de las siguientes rutas:

Offsite: `POST /tournaments`¶

Autorización: User (super, tournament)

Mediante esta ruta, se solicita la creación de un torneo a partir de la plantilla proporcionada. El cuerpo de la petición, con tipo de contenido multipart/form-data, es el siguiente:

Campo	Contenido
templateId	Identificador de la plantilla a partir de la cual se instancia el torneo.
locationId	Sucursal donde se llevará a cabo el torneo.
name	Nombre del torneo.
tournamentProductId	Identificador del producto de entrada al torneo que aplicará para el mismo.
scheduledAt	Fecha programada para el inicio del torneo. Se recibe en hora local a la sucursal.
minTeams	Número mínimo de equipos requeridos para ser registrados.
maxTeams	Número máximo de equipos permitidos para ser registrados.
systemId	Identificador de la consola asociada al torneo.
systemName	Nombre de la consola asociada al torneo.
isAvailable	De indicarse como verdadero, establece la fecha de la recepción de la petición como aquella en que el torneo es ofertado.
cover	Portada del torneo. Si esta imagen es proporcionada, se elimina la versión anterior de la imagen alojada en el proveedor de almacenamiento.
banner	Anuncio del torneo. Si esta imagen es proporcionada, se elimina la versión anterior de la imagen alojada en el proveedor de almacenamiento.
rules	Archivo PDF con las reglas del torneo. Si este archivo es proporcionado, se elimina la versión anterior del mismo alojada en el proveedor de almacenamiento.
setup	Archivo PDF con la guía de configuración. Si este archivo es proporcionado, se elimina la versión anterior del mismo alojada en el proveedor de almacenamiento.

En consecuencia, se crea un registro de torneo y se responde a la sucursal con el estado 201 Created, acompañado del esquema del torneo recién creado.

Si la fecha de comienzo del torneo no está en el futuro, si el nombre del torneo excede los 120 caracteres en longitud, o si el número mínimo de equipos es menor a dos, se responde con el estado 422 Unprocessable Entity.

Si alguna de las imágenes excede los 500 kb en tamaño, o si alguno de los archivos en PDF excede los 3 mb en tamaño, si el producto de torneo no existe en la sucursal, o si la plantilla o la sucursal no se encuentranse responde con el estado 409 Conflict.

Posterior a la creación de un torneo, es necesario completar la información del mismo en el local haciendo uso de la ruta:

Offsite: `PUT /tournaments/{id}`¶

Autorización: User (super, tournament)

Mediante esta ruta se actualiza la información de un torneo existente en el local que lleva a cabo la petición. El torneo es referenciado por el parámetro id. La petición, con tipo de contenido multipart/form-data recibe uno o más de entre los siguientes campos:

Campo	Contenido
name	Nombre del torneo.
tournamentProductId	Identificador del producto de entrada al torneo que aplicará para el mismo.
scheduledAt	Fecha programada para el inicio del torneo. Se recibe en hora local a la sucursal.
minTeams	Número mínimo de equipos requeridos para ser registrados.
maxTeams	Número máximo de equipos permitidos para ser registrados.
systemId	Identificador de la consola asociada al torneo.
systemName	Nombre de la consola asociada al torneo.
isAvailable	De indicarse como verdadero, establece la fecha de la recepción de la petición como aquella en que el torneo es ofertado.
cover	Portada del torneo. Si esta imagen es proporcionada, se elimina la versión anterior de la imagen alojada en el proveedor de almacenamiento.
banner	Anuncio del torneo. Si esta imagen es proporcionada, se elimina la versión anterior de la imagen alojada en el proveedor de almacenamiento.
rules	Archivo PDF con las reglas del torneo. Si este archivo es proporcionado, se elimina la versión anterior del mismo alojada en el proveedor de almacenamiento.
setup	Archivo PDF con la guía de configuración. Si este archivo es proporcionado, se elimina la versión anterior del mismo alojada en el proveedor de almacenamiento.

La ruta responde con el estado 200 OK acompañado de la información actualizada del torneo. Si el torneo ha sido ofertado, se responde con el estado 403 Forbidden. Si la fecha de comienzo del torneo no está en el futuro, o si el nombre del torneo excede los 120 caracteres en longitud, o si el número mínimo de equipos es menor a dos, se responde con el estado 422 Unprocessable Entity. Si alguna de las imágenes excede los 500 kb en tamaño, o si alguno de los archivos en PDF excede los 3 mb en tamaño, o si el producto de torneo no existe en la sucursal, se responde con el estado 409 Conflict. Si el torneo referenciado en la ruta no existe, se responde con el estado 404 Not Found. Si se desea ofertar un torneo que no cuenta con la información completa, se responde con el estado 412 Precondition Failed.

Consejo

Los archivos de confirguración de partida y reglamento son cargados por la sucursal en el bucket que le es asignado al momento de su inicialización. Sin embargo, Onsite definirá el nombre del archivo siguiendo la convención [rules | setup]_UUUUUUUUUU_AAAAA.pdf, donde el prefijo corresponde al uso dado al archivo, UUUUUUUUUU es la fecha UNIX en segundos y AAAAA es una cadena alfanumérica aleatoria.

Registro a un torneo¶

A continuación se describe el flujo de registro a un torneo por parte de un jugador. Comprende la consulta de torneos disponibles en un local y la inscripción a alguno seleccionado.

Cabe señalar que a pesar de que un jugador es capaz de registrar a un grupo de Players a un torneo, este registro de jugadores adicionales no es definitivo. Cada jugador que conforma el equipo (a excepción de aquel que inscribe a los demás) debe efectuar el pago correspondiente de su entrada previo al Check In de torneo.

Descripción general¶

El cliente consulta la información sobre los torneos registrados.
Offsite responde con la información de cada uno de los torneos a los cuales es posible registrarse.
El cliente solicita la inscripción de un equipo al torneo seleccionado.
Offsite registra al equipo y se comunica con el servidor de correos para enviar la confirmación de registro de los jugadores.
Offsite obtiene la respuesta del encolamiento del correo en el servidor.
Offsite confirma el registro del equipo al torneo.

Flujo¶

Se requieren las siguientes rutas en Offsite para consulta y alta a un torneo

Offsite: `GET /tournaments`¶

Autorización: Kiosk, Player, Assistant, Timer, User (super, tournament)

Mediante esta ruta es posible consultar la información existente en Offsite sobre los torneos a llevarse a cabo en alguna de las sucursales. Únicamente son devueltos los torneos ofertados a menos que el solicitante sea un usuario, en cuyo caso son devueltos todos los torneos.

Dependiendo del origen de la petición se tienen distintos filtros:

Player y Kiosk

Devuelve los torneos abiertos por los siguientes doce meses. En caso de ser Kiosk son devueltos únicamente los torneos de su sucursal. Existen los filtros location_id, month, system, include_teams y nick. En caso de proporcionar include_teams y nick, por cada torneo se incluye el equipo (en caso de existir) en el cual se encuentra registrado el jugador con el nick proporcionado.

Timer

Sólo devuelve torneos a llevarse a cabo en su sucursal de origen, además es requisito indicar el id del torneo a consultar.

User y Assistant

Toma como filtros from y to para especificar un rango de fechas, en caso de no proporcionarse devuelve torneos que se lleven a cabo en el futuro.

La ruta responde con el estado 200 OK acompañado de la información devuelta como en el siguiente esquema:

tournaments:
  - id: 1
    locationId: 2
    name: Fifa 2017 Otoño
    cost: 150
    type: PRO
    maxPlayersPerTeam: 3
    minPlayersPerTeam: 1
    systemId: 2
    gameName: Fifa 2017
    modeName: 1 vs 1
    scheduledAt: 1469491719
    availableAt: 1469485678
    criteria:
      - id: 3
        name: Precisión
        isPercentage: true
        maxValue: null
      - id: 5
        name: Cantidad de goles
        isPercentage: false
        maxValue: 10
    maxTeams: 15
    minTeams: 2
    cover: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    banner: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    rules: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    setup: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
  - id: 2
    locationId: 13
    name: Apertura de Mario Kart
    cost: 140
    type: PLUS
    maxPlayersPerTeam: 4
    minPlayersPerTeam: 4
    systemId: 4
    gameName: Mario Kart 8
    modeName: Grand Prix
    scheduledAt: 1469492534
    availableAt: 1469485678
    criteria:
      - id: 5
        name: Carreras ganadas
        isPercentage: false
        maxValue: 25
    maxTeams: 10
    minTeams: 2
    cover: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    banner: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    rules: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    setup: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543

Si la cota superior del intervalo es menor a la inferior, se responde con el estado 400 Bad Request.

Advertencia

Únicamente serán incluidos los archivos de rules y setup para clientes user y Assistant.

Offsite: `POST /tournaments/{id}/teams`¶

Autorización: Kiosk, Player

Mediante esta ruta se inscribe a un equipo de jugadores al torneo indicado en el parámetro id. La estructura de la petición es la siguiente:

name: Los meros meros
leadPlayer: donnie
players:
  - nick: donnie
    performPayment: true
  - email: aleexkj@turbomail.com
    performPayment: false
  - nick: amira
    performPayment: true

Como resultado de la recepción de la petición, se valida que el jugador que lleva a cabo la reservación cuente con la moneda suficiente para pagar por su entrada y la de cada jugador por quien desee pagar. Posteriormente, se crea una transacción de tipo retención al jugador titular por cada una de las entradas a pagar.

A continuación, se registra a todos los Players incluidos en el cuerpo del mensaje al torneo, los cuales deben integrar un equipo con el nombre name. El nombre del equipo es requerido únicamente cuando este es conformado por más de un jugador.

El jugador leadPlayer es aquel, cuando la petición se origina en Kiosk, que solicita inicialmente la inscripción de un equipo a un torneo. Es por lo anterior que dicho jugador no necesita una notificación de inscripción por correo. Por lo tanto, el envío de invitaciones se realiza únicamente para los jugadores indicados en el arreglo players, campo que existe si el torneo a jugar es para más de una persona. Si el JWT de la petición corresponde a un jugador, este es tomado como el jugador líder, por lo que el campo leadPlayer no es requerido.

Para cada nick indicado en el cuerpo de la petición, se crea un registro Team Enrollment asociado al Player y al equipo con el que este participará en el torneo, registro que cuenta con una transacción de tipo retención correspondiente al pago de la entrada. Posteriormente, se realiza el envío de correo a los integrantes invitados.

Para cada email proporcionado en la petición, se comprobará si existe registro de un jugador cuya dirección de correo coincida con el email que se indica. En caso de existir el Player, se asocia a este una entidad Team Enrollment que simboliza su participación en el equipo. De no existir el Player con el correo que fue proporcionado, se crea una entidad Team Enrollment carente de jugador y con el correo proporcionado como atributo. De esta manera se representa que el invitado a integrar el torneo está pendiente de registrarse a Arena como Player. En este caso, también es enviado un correo a los integrantes invitados al equipo.

Esta ruta responde con el estado 201 Created acompañado del equipo recién inscrito. Si el torneo no ha sido ofertado, se responde con el estado 403 Forbidden. Si ya existe un equipo con el mismo nombre, o si se desea inscribir al torneo treinta minutos antes o menos del comienzo programado del mismo en hora local a la sucursal, o el jugador que lleva a cabo la inscripción no cuenta con el saldo suficiente para pagar por los jugadores deseados, se responde con el estado 409 Conflict.

Si alguno de los jugadores -ya sea el que solicita el registro del equipo o alguno de los invitados a unirse al mismo- es de perfil Guest, se responde con el estado 412 Precondition Failed. Si alguno de los jugadores o de las direcciones de correo ya pertenece a un equipo registrado en el torneo en cuestión, el número de jugadores excede el valor maxPlayers, o si alguno de los nicks proporcionados no existe o el nombre del equipo excede los 30 caracteres, se responde con el estado 422 Unprocessable Entity. En cualquier caso de error, se cancela la creación y registro del equipo al torneo.

Consejo

Como parte del flujo exitoso, se envía un correo al jugador titular, indicando que la inscripción del equipo fue satisfactoria. Adicionalmente, cada miembro del equipo debe recibir un correo que notifique de la invitación al correo, indicando el estado de pago por la entrada al torneo.

Offsite: `PUT /teams/{id}/confirmation`¶

Autorización: Player

Mediante esta ruta se confirma la participación de un jugador al equipo.

Si no ha sido efectuado el pago por la entrada del jugador, se realiza una retención al jugador solicitante por tantos ares como aquellos correspondientes al costo de entrada al torneo. En otro caso, debe confirmarse que la entrada del jugador ya haya sido cubierta por el titular del equipo.

La ruta responde con el estado 200 OK acompañado del estado actualizado de la participación del jugador.

Si el jugador no cuenta con el saldo en ares suficiente para cubrir su entrada, o si se desea confirmar la participación al torneo treinta minutos antes o menos de la fecha programada de inicio del mismo, se responde con el estado 409 Conflict.

Si el jugador ya ha confirmado su participación con anterioridad se responde con el estado 410 Gone.

Si el jugador no tiene una inscripción al torneo, se responde con el estado 412 Precondition Failed.

Consejo

Como parte del flujo exitoso, se notifica mediante correo electrónico al titular del equipo acerca de la confirmación de la participación del jugador. Asimismo, el jugador que acepta la invitación al torneo recibe una confirmación mediante correo electrónico.

Offsite: `DELETE /tournaments/{id}/team_enrollment/player`¶

Autorización: Player

Mediante esta ruta se rechaza la participación al torneo del jugador que lleva a cabo la petición.

En consecuencia, se libera la retención de ares efectuada a quien pagó por la inscripción, en caso de haberse llevado a cabo el movimiento.

La ruta responde con el estado 204 No Content indicando que el procesamiento de la petición fue exitoso.

Si el torneo no se encuentra, se responde con el estado 404 Not Found.

Si el jugador no tiene participación en el torneo, se responde con el estado 409 Conflict.

Consejo

Como parte del flujo exitoso, el jugador titular del equipo recibe un correo indicando que un integrante canceló su participación al torneo.

Consulta de torneos¶

El jugador tiene la facultad de consultar los torneos a los que se encuentra registrado, así como aquellos a los que se registró en el pasado. A continuación se indica el comportamiento del servidor que satisface dicha funcionalidad.

Flujo¶

Offsite: `GET /tournaments/enrollments`¶

Autorización: Player

Mediante esta ruta se consulta el estado de participación del jugador a los torneos a los que se ha inscrito.

Se tienen los siguientes parámetros de consulta:

Parámetro	Tipo	Función
confirmed	boolean	En caso de indicarse como verdadero, se devuelven únicamente invitaciones a torneo que han sido confirmadas.

La ruta responde con el estado 200 OK acompañado de la siguiente información:

tournaments:
  - id: 3
    name: Torneo Doom
    cost: 150
    type: PRO
    scheduledAt: 1469491719
    maxTeams: 30
    minTeams: 2
    availablePlaces: 3
    systemName: PS4
    template:
      maxPlayersPerTeam: 30
      minPlayersPerTeam: 12
      gameName: Doom
      modeName: Desempate por duelo directo
    locationId: 4
    cover: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    banner: https://www.googleapis.com/storage/v1/b/arena-offsite-bucket/o/1475281865163-0.9304038190748543
    createdAt: 1469491364
    updatedAt: 1469491364

Administración de invitaciones a torneo¶

Si un jugador es el titular del equipo (quien llevó a cabo la inscripción), le es permitido solicitar el reenvío de invitaciones a torneo, así como cancelar la participación de un integrante, siempre y cuando éste no haya confirmado su participación. A continuación se describen los flujos seguidos para satisfacer el comportamiento.

Flujo¶

Offsite: `GET /tournaments/{id}/team_enrollment`¶

Autorización: Player

Mediante esta ruta, un jugador solicita la información de la inscripción de su equipo al torneo indicado en la ruta.

El servidor responde con el estado 200 OK acompañado de la siguiente información:

id: 2
name: Los meros meros
isLeadPlayer: true
players:
  - nick: jijiji
    confirmedAt: 1469491719
    checkedAt: null
    validatedAt: null
  - nick: cealmees
    confirmedAt: 1469491222
    checkedAt: null
    validatedAt: null
invitees:
  - email: jose@dominio.com
  - email: cityofstars@movies.com

donde

id: Identificador del equipo.
name: Nombre del equipo.
isLeadPlayer: Indica si el jugador que lleva a cabo la petición es aquel que registró al equipo.
players: Arreglo de jugadores participantes en el equipo. En este arreglo no es incluido el jugador que lleva a cabo la petición.
player.nick: Nombre usuario del jugador dentro del sistema.
player.confirmedAt: Fecha en la que un jugador confirma su participación dentro de un equipo a un torneo.
player.checkedAt: Fecha en la que un jugador anuncia su presencia en el torneo a través de Kiosk.
player.validatedAt: Fecha en la que un asistente confirma la asistencia de un jugador al torneo.
invitees: Arreglo de correos correspondientes a invitados aún no registrados.

Si el torneo del cual se solicita la información no se encuentra, la respuesta es 404 Not Found. Si el jugador no está inscrito al torneo, se responde con el estado 412 Precondition Failed.

Offsite: `PUT /teams/{id}/player`¶

Autorización: Player

Mediante esta ruta se inscribe a un jugador al torneo indicado en el parámetro id. La estructura de la petición es la siguiente:

nick: jonaVark
performPayment: true

Como resultado de la recepción de la petición, se valida que el jugador que lleva a cabo la reservación cuente con la moneda suficiente para pagar por la entrada del jugador. Posteriormente, se crea una transacción de tipo retención al jugador titular para representar el pago.

Si un nick es indicado en el cuerpo de la petición, se crea un registro Team Enrollment asociado al Player y al equipo con el que este participará en el torneo. Posteriormente, se realiza el envío de correo al integrante recién invitado.

Por el contrario, si un email es proporcionado en la petición, se comprobará si existe registro de un jugador cuya dirección de correo coincida con el email que se indica. En caso de existir el Player, se asocia a este una entidad Team Enrollment que simboliza su participación en el equipo. De no existir el Player con el correo que fue proporcionado, se crea una entidad Team Enrollment carente de jugador y con el correo proporcionado como atributo. De esta manera se representa que el invitado a integrar el torneo está pendiente de registrarse a Arena como Player. En este caso, también es enviado un correo al integrante invitado al equipo.

Esta ruta responde con el estado 200 OK acompañado del estado de inscripción del equipo. Si el jugador que lleva a cabo la inscripción no es el titular del equipo, se responde con el estado 403 Forbidden. Si se desea inscribir un jugador al torneo treinta minutos antes o menos del comienzo programado del mismo en hora local a la sucursal, o el jugador que lleva a cabo la inscripción no cuenta con el saldo suficiente para pagar, se responde con el estado 409 Conflict.

Si alguno de los jugadores -ya sea el que solicita el registro del equipo o el invitado a unirse al mismo- es de perfil Guest, se responde con el estado 412 Precondition Failed. Si el jugador o la dirección de correo ya pertenece a un equipo registrado en el torneo en cuestión, el número de jugadores excede el valor maxPlayers, o si el nick proporcionado no existe, se responde con el estado 422 Unprocessable Entity.

En cualquier caso de error, se cancela la invitación del jugador al torneo.

Consejo

El jugador invitado al torneo debe recibir una notificación por correo electrónico, indicando el estado del pago de su entrada. De igual manera, el jugador que invita a un nuevo participante debe recibir una notificación, indicando el nuevo balance de ares.

Offsite: `POST /teams/{id}/template`¶

Autorización: Player

Solicita el reenvío de un correo de confirmación de participación en el torneo a los jugadores indicados en la petición, la cual lleva por cuerpo:

players:
  - nick: donnie
  - email: aleexkj@turbomail.com
  - nick: amira

Como consecuencia, se envían de nuevo correos de confirmación a aquellos participantes indicados.

El servidor responde con el estado 204 No Content, indicando así que el envío se agendó exitosamente.

Si el torneo indicado no se encuentra, la respuesta es 404 Not Found. Si el jugador que lleva a cabo la petición no está inscrito al torneo, o si alguno de los jugadores indicados no tiene participación en el equipo del jugador que realiza la petición, se responde con el estado 412 Precondition Failed. Si el torneo ya finalizó, se responde con el estado 410 Gone.

Offsite: `POST /teams/{id}/payment`¶

Autorización: Player

Solicita el pago de las entrada de los jugadores indicados en la petición, la cual lleva el siguiente cuerpo:

players:
  - nick: donnie
  - email: aleexkj@turbomail.com
  - nick: amira

Como consecuencia, se crean tantas retenciones de ares como jugadores se encuentran involucrados en la petición.

El servidor responde con el estado 204 No Content, indicando así que el procesamiento fue exitoso.

Si el equipo indicado no se encuentra, la respuesta es 404 Not Found.

Si se solicitó el pago de alguna entrada que ya ha sido cubierta, si el titular no cuenta con el saldo en ares suficiente para cubrir la totalidad de las entradas, o si se desea pagar la participación al torneo treinta minutos antes o menos de la fecha programada de inicio del mismo, se responde con el estado 409 Conflict. En cualquier caso, el pago de entradas para todos los jugadores es anulado.

Si el jugador que lleva a cabo la petición no está inscrito al torneo, o si alguno de los jugadores indicados no tiene participación en el equipo del jugador que realiza la petición, se responde con el estado 412 Precondition Failed. Si el torneo ya finalizó, se responde con el estado 410 Gone.

Consejo

El jugador que llevó a cabo el pago de las entradas de los jugadores debe recibir un correo de confirmación indicando su nuevo balance en ares. De igual manera, cada uno de los jugadores cuya participación fue pagada recibe un correo indicando el movimiento.

Offsite: `DELETE /teams/{id}/enrollment`¶

Autorización: Player

Mediante esta ruta se cancela la participación en el torneo de los jugadores indicados en la petición, la cual lleva por cuerpo:

players:
  - nick: donnie
  - email: aleexkj@turbomail.com
  - nick: amira

Al recibir la petición, se comprueba que los jugadores indicados no hayan confirmado su participación en el torneo, para posteriormente eliminar su inscripción al mismo.

Para cada jugador cuya participación se cancela, se libera la retención de ares del jugador que pagó por la respectiva incripción.

La ruta responde con el estado 200 OK acompañado de la información actualizada del equipo. Si el torneo indicado no se encuentra, la respuesta es 404 Not Found. Si uno o más de los jugadores indicados han confirmado su participación en el torneo, o si la petición se recibe posterior a 30 minutos antes del inicio del torneo, se anula la operación y se responde con el estado 409 Conflict. Si el jugador no está inscrito al torneo, o alguno de los jugadores no se encuentran en el equipo, se responde con el estado 412 Precondition Failed.

Consejo

El jugador que cancela la participación de los integrantes del equipo debe recibir un correo con la confirmación del movimiento, así como el nuevo balance en ares. Adicionalmente, cada jugador cuya participación es cancelada, recibe un correo electrónico con la notificación de la operación.

Check In¶

A continuación se describe el flujo llevado a cabo por un jugador para registrar su llegada al local donde se llevará a cabo el torneo donde se registró.

Descripción general¶

El primer paso consiste en obtener un check in token del servidor Offsite.

Identificación¶

_images/kiosk_identification_overview1.svg

La aplicación cliente Kiosk envía las credenciales del jugador al servidor offsite.
El servidor offsite genera un checkin_token que envía en la respuesta a la aplicación cliente Kiosk.

Offsite: `POST /tournaments/{id}/check_ins`¶

Autorización: Kiosk

Recibe un código de autorización para marcarlo como usado dentro de un torneo en una sucursal. Dicho check in únicamente será aceptado si proviene el local donde se creó, y este no ha sido marcado como usado.

La ruta responde con el estado 200 OK acompañado de la información del torneo al cual se efectuó el Check In, así como la información de los jugadores del equipo, indicando cuáles han efectuado ya el check in.

Si la autorización de check in no es válida, o si el usuario ya ha hecho Check In para el torneo en cuestión, el sistema debe responder con el estado 403 Forbidden.

Si no se encuentra el torneo con el identificador proporcionado, se responde con el estado 404 Not Found. Si el jugador cuenta con un Check In abierto y usado en alguna sucursal, o si no se tiene registro de ningún token de check in otorgado al Onsite en cuestión con el código de autorización proporcionado, se responde con el estado 409 Conflict.

Si el jugador no se encuentra registrado al torneo, o si su participación no se encuentra confirmada, se responde con el estado 412 Precondition Failed.

Si el usuario desea hacer check in a un torneo para el cual posee un registro confirmado, pero la petición se lleva a cabo antes de treinta minutos del comienzo programado (scheduledAt) en la hora local de la sucursal, o si ha sido cerrado el Check In, se responde con el estado 409 Conflict.

Cualquier caso de error anula el proceso de Check In al torneo para el jugador.

Validación de participantes¶

Flujo¶

Offsite: `GET /tournaments/{id}/teams`¶

Autorización: Assistant

Mediante esta ruta se obtiene el estado de asistencia de los jugadores en cada uno de los equipos registrados al torneo.

La ruta responde con el estado 200 OK acompañado de un esquema como el que sigue:

teams:
  - id: 2
    name: Los meros meros
    players:
      - nick: jijiji
        confirmedAt: 1469491719
        checkedAt: 1469491976
        validatedAt: 1469491712
      - nick: cealmees
        confirmedAt: 1469491222
        checkedAt: 1469491945
        validatedAt: 1469496521
    invitees:
      - email: jose@dominio.com
      - email: cityofstars@movies.com
  - id: 5
    name: Los winners
    players:
      - nick: eseca
        confirmedAt: 1469493452
        checkedAt: 1469494567
        validatedAt: 1469491712
      - nick: susuhahn
        confirmedAt: 1469496543
        checkedAt: 1469491945
        validatedAt: 1469496521
      - nick: maestrovencedor
        confirmedAt: 1469491674
        checkedAt: 1469491127
        validatedAt: 1469496871
      - nick: comesytevas
        confirmedAt: 1469491122
        checkedAt: 1469491959
        validatedAt: 1469496001

donde

id: Identificador del equipo.
name: Nombre del equipo.
players: Arreglo de jugadores participantes en el equipo.
player.nick: Nombre usuario del jugador dentro del sistema.
player.confirmedAt: Fecha en la que un jugador confirma su participación dentor de un equipo a un torneo.
player.checkedAt: Fecha en la que un jugador anuncia su presencia en el torneo a través de Kiosk.
player.validatedAt: Fecha en la que un asistente confirma la asistencia de un jugador al torneo.
invitees: Arreglo de correos correspondientes a invitados aún no registrados.

Onsite: `PUT /tournaments/{xid}/check_ins`¶

Autorización: Assistant

Mediante esta ruta, un asistente solicita la confirmación de participación al torneo de los jugadores indicados en la petición. El esquema de petición aceptada por esta ruta es el siguiente:

nicks:
  - eseca
  - cealmees
  - kyky
  - ochoaleonor
  - cerillito
  - kreiz
  - malfie

Como acción a la recepción de la petición, se valida la participación al torneo del grupo de jugadores seleccionados. No es posible validar la participación de jugadores sin que estos hayan efectuado el Check In correspondiente.

La ruta responde con el estado 200 OK acompañado del estado actualizado de aquellos equipos que son aptos para participar en el torneo. Si alguno de los jugadores no se encuentra en el torneo, o si el torneo no pudo ser localizado, se responde con el estado 404 Not Found. Si al menos uno de los jugadores no cuenta con un Check In efectuado, se responde con el estado 409 Conflict. Si ya se efectuó con anterioridad el proceso de validación de jugadores (la fecha checkInClosedAt es no nula), se responde con el estado 403 Forbidden.

Offsite: `PUT /tournaments/{id}/check_ins/validation`¶

Autorización: Location

Mediante esta ruta, una sucursal solicita la confirmación de participación al torneo de los jugadores indicados en la petición. El esquema de petición aceptada por esta ruta es el siguiente:

nicks:
  - eseca
  - cealmees
  - kyky
  - ochoaleonor
  - cerillito
  - kreiz
  - malfie

Como acción a la recepción de la petición, se valida la participación al torneo del grupo de jugadores seleccionados. No es posible validar la participación de jugadores sin que estos hayan efectuado el Check In correspondiente.

Solo aquellos equipos donde todos los participantes hayan sido validados por un asistente podrán jugar el correspondiente torneo. En este punto, se cancela la participación al torneo de los equipos incompletos. Adicionalmente, se liberan las respectivas retenciones de pago de todos los integrantes.

Posteriormente, se efectúa el cobro de las retenciones de ares a aquellos jugadores que pagaron una o más entradas al torneo. Esto se lleva a cabo únicamente para los equipos que se presentaron en su totalidad.

La ruta responde con el estado 200 OK acompañado del estado actualizado de aquellos equipos que son aptos para participar en el torneo. Si alguno de los jugadores no se encuentra en el torneo, o si el torneo no pudo ser localizado, se responde con el estado 404 Not Found. Si al menos uno de los jugadores no cuenta con un Check In efectuado, se responde con el estado 409 Conflict. Si ya se efectuó con anterioridad el proceso de validación de jugadores (la fecha checkInClosedAt es no nula), se responde con el estado 403 Forbidden. En caso de error en esta ruta, se cancela la validación de todos los jugadores incluidos en la petición.

Como acción posterior a la invocación de esta ruta, se cierra el Check In y se termina la participación al torneo de aquellos equipos con jugadores cuya participacion no fue confirmada. La participación también se termina de existir equipos con jugadores que no llevaron a cabo Check In. Dichas participaciones canceladas también involucran una liberación de ares para todos los integrantes del equipo.

Tournament Handler: `POST /tournaments`¶

Autorización: Offsite

A través de esta ruta se da de alta la información de un torneo a ser jugado. El cuerpo de la petición es el siguiente:

id: 23
name: Fifa 2017 Otoño
gameName: Fifa 2017
modeName: 1 vs 1
criteria:
  - name: Precisión
    isPercentage: true
  - name: Cantidad de goles
    isPercentage: false
teams:
  - name: Los mejores
    players:
      - patron
      - yoliDeLimon
  - name: Do be do
    players:
      - Lucie
      - loreh

Como resultado a la recepción de la petición, se crea en Tournament Handler un torneo con la información que se proporciona. Cada uno de los criterios recibidos es creado y ligado al torneo, o únicamente ligado en caso de existir. En el sistema también son dados de alta los equipos con sus respectivos jugadores, los cuales son buscados en la base de datos antes de su creación para evitar repeticiones. De manera adicional y para cada torneo nuevo creado en el manejador de torneos, debe crearse una fase por defecto, la cual contiene a todos los jugadores.

La ruta responde con el estado 201 Created acompañado de la información del torneo recién creado de la siguiente manera.

id: 2
xid: 23
name: Fifa 2017 Otoño
gameName: Fifa 2017
modeName: 1 vs 1
criteria:
  - id: 1
    name: Precisión
    isPercentage: true
  - id: 7
    name: Cantidad de goles
    isPercentage: false
phases:
  - id: 1
    teams:
      - id: 5
        name: Los mejores
        players:
          - id: 2
            nick: patron
          - id: 8
            nick: yoliDeLimon
      - id: 2
        name: Do be do
        players:
          - id: 9
            nick: Lucie
          - id: 5
            nick: loreh

Generación de brackets¶

Posterior a la confirmación de asistencia de los jugadores al torneo, un asistente divide a los equipos en grupos y, para cada uno, define la modalidad de juego. A continuación se describe el proceso llevado a cabo para llevar a cabo dichas operaciones.

Descripción general¶

Assistant consulta la información del torneo actual.
El manejador de torneos responde con la información solicitada.
Assistant propone una división en grupos de los jugadores de la fase actual. Para cada grupo, indica la modalidad de juego.
El manejador de torneos valida la información proporcionada por el asistente y procede a la generación de los brackets.

Flujo¶

Se hace uso de las siguientes rutas para consulta de torneos y generación de brackets:

Tournament Handler: `GET /tournaments`¶

Autorización: Assistant

Mediante esta ruta, es posible consultar los torneos de los cuales el manejador tiene registro. Esta ruta responde con el estado 200 OK acompañado de la siguiente información

- id: 2
  xid: 23
  name: Fifa 2017 Otoño
  gameName: Fifa 2017
  modeName: 1 vs 1
  criteria:
    - id: 1
      name: Precisión
      isPercentage: true
    - id: 7
      name: Cantidad de goles
      isPercentage: false
  phases:
    - id: 1
      teams:
        - id: 5
          name: Los mejores
          players:
            - id: 2
              nick: patron
            - id: 8
              nick: yoliDeLimon
        - id: 2
          name: Do be do
          players:
            - id: 9
              nick: Lucie
            - id: 5
              nick: loreh

Adicionalmente, puede realizarse una búsqueda con el parámetro id o xid para consultar un torneo en particular.

A partir de este paso, los clientes Assistant que participen en el jueceo del torneo, deben solicitar una conexión por socket hacia Tournament Handler, indicando el identificador del torneo del cual desean recibir notificaciones.

Tournament Handler: `POST /tournaments/{id}/phases/{id}/groups`¶

Autorización: Assistant

Mediante esta ruta se solicita la división de los equipos que integran la fase en grupos, indicando para cada grupo la modalidad de eliminación. La estructura de la petición es la siguiente

groups:
  - elimination: single
    bestOf: 3
    teamIds:
      - 9
      - 3
      - 2
  - elimination: double
    bestOf: 5
    teamIds:
      - 10
      - 1
      - 4
  - elimination: round robin
    bestOf: 2
    scoring:
      victoryPoints: 2
      defeatPoints: 0
      tiePoints: 1
    teamIds:
      - 7
      - 6
      - 5

Como resultado, el manejador de torneos valida que en cada grupo haya al menos dos equipos contendientes, que el modo de eliminación sea uno de entre los siguientes: single, double, round robin, que la modalidad bestOf sea una de entre [1, 2, 3, 5, 7], y que, en caso de jugar best of 2, el tipo de eliminación sea round robin. Además, debe validarse que ningún equipo está contendiendo en más de un grupo. Posteriormente, se dan de alta en el sistema los grupos siguiendo el algoritmo en función de la modalidad de eliminación.

La ruta responde con el estado 201 Created acompañado de los grupos recién creados y su respectivo bracket como en el siguiente ejemplo. Para cada modalidad de juego, el servidor propone una alineación de jugadores elegida arbitrariamente.

groups:
  - id: 1
    elimination: single
    bestOf: 3
    scoring: null
    teams:
      - id: 2
        name: Los mejores
        players:
          - id: 3
            nick: patron
          - id: 4
            nick: yoliDeLimon
      - id: 4
        name: Do be do
        players:
          - id: 5
            nick: loreh
          - id: 6
            nick: Lucie
      - id: 9
        name: JUJUJU
        players:
          - id: 7
            nick: Carlita
          - id: 8
            nick: Moreno
    matchNodes:
      - id: 5
        parentId: 6
        height: 1
        teams:
          - id: 2
            name: Los mejores
            players:
              - id: 3
                nick: patron
              - id: 4
                nick: yoliDeLimon
          - id: 4
            name: Do be do
            players:
              - id: 5
                nick: loreh
              - id: 6
                nick: Lucie
        tournamentMatches:
          - id: 9
          - id: 10
          - id: 8
      - id: 6
        parentId: null
        height: 0
        teams:
          - id: 9
            name: JUJUJU
            players:
              - id: 7
                nick: Carlita
              - id: 8
                nick: Moreno
        tournamentMatches:
          - id: 16
          - id: 17
          - id: 18
  - id: 2
    elimination: round robin
    bestOf: 2
    scoring:
      victoryPoints: 2
      defeatPoints: 0
      tiePoints: 1
    teams:
      - id: 3
        name: Watermelon
        players:
          - id: 11
            nick: Blue Jazmine
          - id: 12
            nick: Temembe
      - id: 5
        name: La la la
        players:
          - id: 13
            nick: Tu padre
          - id: 14
            nick: La jefa
    matchNodes:
      - id: 10
        teams:
          - id: 3
            name: Watermelon
            players:
              - id: 11
                nick: Blue Jazmine
              - id: 12
                nick: Temembe
          - id: 5
            name: La la la
            players:
              - id: 13
                nick: Tu padre
              - id: 6
                nick: La jefa
        tournamentMatches:
          - id: 20
          - id: 21

Como parte del flujo exitoso, se notifica a los asistentes sobre la actualización de los grupos de la fase como se indica en Tournament Handler broadcast: update_phase.

Se responde con el estado 409 Conflict bajo cualquiera de los siguientes escenarios:

Si alguno de los grupos proporcionados tiene un único equipo.
Si existen equipos incluidos en más de un grupo.
Si bestOf no corresponde a un número válido.
Si al menos un equipo registrado en la fase no es asociado a ningún grupo.
Si alguno de los equipos no existe o no pertenece a la fase.
Si no son proporcionados los puntos por victoria, derrota y empate de un grupo con modalidad round robin.
La fase ya cuenta con una división en grupos.

Si el tipo de eliminación no es reconocido, si entra en conflicto con la modalidad best of, o si el número de puntos para evaluar una partida de tipo round robin es mayor a 100, se responde con el estado 422 Unprocessable Entity. Si el torneo o la fase indicadas en la petición no se encuentran, o si la fase no pertenece al torneo, se responde con el estado 404 Not Found.

Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone.

Al momento de generar un bracket de eliminación simple con esta ruta, debe garantizarse que cada equipo aparece una sola vez en una de las hojas del árbol de torneo. En caso de generar un bracket de eliminación doble, debe asegurarse la misma postcondición, limitada a las hojas del árbol de winners.

En función de la modalidad de eliminación propuesta para un grupo, se tienen los siguientes algoritmos de generación de plantillas:

Eliminación simple (simple)¶

ALG. BuildSingleElimTree (teams) : MatchNode
Input: teams - Cantidad de participantes en el torneo
       playoffs - Cantidad de partidas a jugarse por ronda
Output: Referencia a la cabeza del árbol de torneo

1. matches <- teams - 1
2. queue <- Queue.new()
3. head <- BuildTournamentTree (matches, playoffs)
4. RETURN head

Eliminación doble (double)¶

ALG. BuildDoubleElimTree (teams) : MatchNode
Input: teams - Cantidad de participantes en el torneo
       playoffs - Cantidad de partidas a jugarse por ronda
Output: Referencia a la cabeza del árbol de torneo

matches <- teams - 1
winnersQueue <- Queue.new()
losersQueue <- Queue.new()
winners <- BuildTournamentTree(matches, playoffs, winnersQueue)
losers <- BuildTournamentTree(matches - 1, playoffs, losersQueue)
tieBreaker <- MatchNode.new(playoffs)
head <- MatchNode.new(tieBreaker, playoffs)
winners.parent <- head
losers.parent <- head
RETURN tieBreaker

Round Robin (round robin)¶

ALG. BuildRoundRobinTriangularMatrix (teams) : List
Input: teams - equipos participantes en el torneo
Output: Colección con las rondas a jugarse

i <- 0, list <- Collection.new()
WHILE i < teams.size
1 j <- 0
2 WHILE j < i
2.1 node <- MatchNode.new(teams[i], teams[j], playoffs)
2.2 list.add(node)
2.3 j <- j + 1
3 i <- i + 1
RETURN list

Auxiliares¶

ALG. BuildTournamentTree (order, playoffs, queue) : MatchNode
Input: order - Cantidad de rondas a jugarse durante el torneo
       playoffs - Cantidad de partidas a jugarse por ronda
       queue - Estructura auxiliar FIFO vacía
Output: Referencia a la cabeza del árbol de torneo
        Al término, *queue* contendrá referencias a
        las partidas que corresponden al primer enfrentamiento

1. if (order == 0)
  1.1 return EMPTY_SET
2. head <- MatchNode.new(playoffs)
3. queue.add(head)
4. nodes <- 1
5. WHILE nodes < order
  5.1 parent <- queue.peek()
  5.2 child <- MatchNode.new(parent, playoffs)
  5.3 queue.add(child)
  5.4 nodes <- nodes + 1
  5.5 IF nodes.isOdd()
    5.5.1 queue.removeFirst()
6. RETURN head

DEF. MatchNode
// Estructura que alberga una serie de partidas a enfrentarse
// sobre la misma pareja de equipos.
  id integer
  integer height
  parent MatchNode
  Team homeTeam
  Team visitorTeam
  matches Collection(TournamentMatch)

DEF. MatchNode.new (playoffs)
// Construcción de un nodo dada la cantidad de partidas a
// jugar sobre los mismos equipos

1. this(null, playoffs)

DEF. MatchNode.new (node, playoffs)
// Construcción de un nodo dada la referencia al padre y la
// cantidad de partidas a jugar sobre los mismos equipos

1. this.id <- model.generateId()
2. this.parent <- node
3. this.matches <- new Collection(playoffs)
4. this.height <- node == null ? 0 : node.height + 1

DEF. MatchNode.new (teamA, teamB, playoffs)
// Constructor de un nodo con la información de una partida

1. this.id <- model.generateId()
2. this.parent <- null
3. this.height <- null
4. this.homeTeam <- teamA
5. this.visitorTeam <- teamB
6. this.matches <- new Collection(playoffs)
7. this.matches.add(new TournamentMatch())

DEF. Tournament Match
// Estructura que almacena la información de una partida
// entre dos contendientes dentro de un torneo
  id integer

DEF. TournamentMatch.new ()
// Constructor de una partida con la información de los equipos

1. this.id <- model.generateId()

Edición de brackets¶

Un asistente está facultado para modificar la alineación de jugadores en la ronda inicial de un grupo, siempre y cuando no se haya registrado el resultado de ninguna ronda en algún enfrentamiento del grupo.

Flujo¶

Tournament Handler: `PUT /groups/{id}/alignment`¶

Autorización: Assistant

Mediante esta ruta se edita la ronda inicial de un bracket con eliminación simple o doble, para el cual no debe haberse registrado ningún resultado. El cuerpo de la petición es el siguiente:

matchNodes:
  - matchNodeId: 5
    teamIds:
      - 2
      - 4
  - matchNodeId: 6
    teamIds:
      - 9

Al recibir la petición, el servidor de torneos valida que no se haya asignado ninguna partida a una estación (lo cual indicaría que se dio comienzo al torneo) para posteriormente verificar que todos los jugadores del grupo sean incluidos en la petición.

El servidor responde con el estado 200 OK acompañado de la información actualizada del grupo como sigue:

id: 1
elimination: single
bestOf: 3
teams:
  - id: 2
    name: Los mejores
    players:
      - id: 3
        nick: patron
      - id: 4
        nick: yoliDeLimon
  - id: 4
    name: Do be do
    players:
      - id: 5
        nick: loreh
      - id: 6
        nick: Lucie
  - id: 9
    name: JUJUJU
    players:
      - id: 7
        nick: Carlita
      - id: 8
        nick: Moreno
matchNodes:
  - id: 5
    parentId: 6
    height: 1
    teams:
      - id: 2
        name: Los mejores
        players:
          - id: 3
            nick: patron
          - id: 4
            nick: yoliDeLimon
      - id: 4
        name: Do be do
        players:
          - id: 5
            nick: loreh
          - id: 6
            nick: Lucie
    tournamentMatches:
      - id: 9
      - id: 10
      - id: 8
  - id: 6
    parentId: null
    height: 0
    teams:
      - id: 9
        name: JUJUJU
        players:
          - id: 7
            nick: Carlita
          - id: 8
            nick: Moreno
    tournamentMatches:
      - id: 16
      - id: 17
      - id: 18

Como parte del flujo exitoso, se notifica a los asistentes sobre la actualización de los grupos de la fase como se indica en Tournament Handler broadcast: update_phase.

Si ya dio comienzo el registro de resultados de la fase, es decir, si se ha asignado estación a al menos una de las partidas del bracket, se responde con el estado 403 Forbidden. Si el grupo indicado no existe, se responde con el estado 404 Not Found.

Se responde con el estado 409 Conflict bajo cualquiera de los siguientes casos:

Si el modo de eliminación del grupo es Round Robin.
Si en la petición no son incluidos todos los equipos que participan en el grupo.
Si alguno de los equipos indicados no pertenece al grupo.
Si alguno de los Match Node indicados no pertenece al grupo.
Si alguno de los Match Node indicados tiene dos hijos en el árbol del torneo.

Asignación de ronda a estación¶

Una vez que se confirmó la alineación de equipos en los brackets, un asistente solicita restringir el uso de una estación con el objetivo de que ésta sea el punto de enfrentamiento de uno o dos equipos mientras dure la ronda. En el caso de jugarse en PCs, el asistente debe indicar qué conjunto de estaciones son reservadas. Dichas estaciones restringidas no pueden ser usadas dentro del torneo ni por la operación normal de la sucursal sino hasta que son liberadas.

Descripción general¶

Un asistente solicita al servidor Onsite asignar una ronda a una estación de la sucursal.
El servidor Onsite valida que la estación solicitada esté disponible para su uso; de ser así, ésta es bloqueada, lo cual debe notificarse al cliente Timer correspondiente a la estación reservada. Si la estación está ocupada, la transacción no es procesada.
El servidor Onsite notifica al manejador de torneos de la asignación de una partida a una estación.
El manejador de torneos verifica el estado de la partida y registra la asignación de la estación.
El servidor Onsite responde al asistente con el resultado de la operación.

Flujo¶

Onsite: `PUT /stations/teams`¶

Autorización: Assistant

Mediante esta ruta, un asistente solicita a Onsite el bloqueo de las estaciones indicadas en la ruta para reservar su uso durante una ronda. El cuerpo de la petición es el siguiente:

tournamentId: 43
matchNodeId: 14
stationTeams:
  - stationId: 2
    teamIds:
      - 2
      - 31
  - stationId: 17
    teamIds:
      - 23

Al recibir la petición, el servidor Onsite valida que las estaciones en cuestión no estén siendo usadas para la operación normal del local. Posteriormente, se notifica a Tournament Handler de la asignación a estación como se indica en Tournament Handler: PUT /match_nodes/{id}/stations.

Esta operación es atómica sobre las estaciones bloqueadas, es decir, si alguna de las estaciones falla en bloquearse, ninguna estación debe reservarse. Si la estación ya se encontraba en uso dentro del torneo, se permite la actualización de la información.

La ruta responde con el estado 204 No Content indicando que el bloqueo de las estaciones fue exitoso.

Si se decide asignar a más de dos o a cero equipos en una estación, se responde con el estado 400 Bad Request.

Si los equipos proporcionados no están en el Match Node en su totalidad, si el nodo donde se asignará estación no existe, o alguna de las estaciones a bloquear o el torneo no se encuentran, se responde con el estado 409 Conflict.

Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone.

Si alguna de las estaciones está siendo ocupada por la operación normal, si alguno de los equipos proporcionados no existe en el torneo, o si la estación no tiene Timer asociado, se responde con el estado 412 Preconditon Failed.

Como parte del comportamiento exitoso del bloqueo de las estaciones, se notifica a los clientes Timer asociados, así como a los clientes Assistant, del uso de las mismas como se indica en el broadcast Onsite broadcast: lock_station.

Tournament Handler: `PUT /match_nodes/{id}/stations`¶

Autorización: Location

Mediante esta ruta se establece el conjunto de estaciones reservadas para el enfrentamiento de una ronda, así como los equipos participantes en la misma. El cuerpo de la petición es el siguiente:

stationTeams:
  - stationId: 2
    timerSubject: 'PP3rGtx'
    teamIds:
      - 2
      - 31
  - stationId: 17
    timerSubject: 'PPlP346'
    teamIds:
      - 23

El manejador registra en el Match Node a las estaciones que fueron bloqueadas (creándolas en caso de no existir), para posteriormente responder con el estado 200 OK.

Si se decide asignar a más de dos o a cero equipos en una estación, se responde con el estado 400 Bad Request.

Si el nodo donde se asignará estación no existe, se responde con el estado 404 Not Found.

Si los equipos proporcionados no están en el Match Node en su totalidad, se responde con el estado 409 Conflict.

Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone.

Si alguno de los equipos no pertenece al torneo, se responde con el estado 412 Precondition Failed.

En caso de invocar esta petición en múltiples ocasiones, la consulta más reciente sobreescribe las operaciones efectuadas anteriormente. Esto es, es posible llevar a cabo múltiples asignaciones de estación sobre el mismo nodo.

Tournament Handler: `GET /match_node`¶

Autorización: Timer

Mediante esta ruta un Timer consulta el estado de su partida dentro de un torneo en curso, en caso de existir. La ruta responde con el estado 200 OK con la siguiente información:

{
  "id": 5,
  "parentId": 6,
  "height": 1,
  "scoredAt": null,
  "winnerTeamId": null,
  "teams": [
    {
      "id": 2,
      "name": "Los mejores",
      "players": [
        {
          "id": 3,
          "nick": "patron"
        },
        {
          "id": 4,
          "nick": "yoliDeLimon"
        }
      ]
    },
    {
      "id": 4,
      "name": "Do be do",
      "players": [
        {
          "id": 5,
          "nick": "loreh"
        },
        {
          "id": 6,
          "nick": "Lucie"
        }
      ]
    }
  ],
  "tournamentMatches": [
    {
      "id": 9,
      "scoredAt": 1479862013,  // Victoria del equipo con id 2
      "winnerTeamId": 2,
      "teamCriteria": [
        {
          "id": 2,
          "value": 23,
          "teamId": 2,
          "criterion": {
            "id": 2,
            "name": "precisión",
            "isPercentage": true
          }
        },
        {
          "id": 76,
          "value": 2,
          "teamId": 4,
          "criterion": {
            "id": 5,
            "name": "goles",
            "isPercentage": false
          }
           },
        {
          "id": 45,
          "value": 40,
          "teamId": 4,
          "criterion": {
            "id": 2,
            "name": "precisión",
            "isPercentage": true
          }
        }
      ]
    },
    {
      "id": 10,
      "scoredAt": 1479862113, // Empate
      "winnerTeamId": 0,
      "teamCriteria": [
        {
          "id": 2,
          "value": 50,
          "teamId": 2,
          "criterion": {
            "id": 2,
            "name": "precisión",
            "isPercentage": true
          }
        },
        {
          "id": 76,
          "value": 1,
          "teamId": 4,
          "criterion": {
            "id": 5,
            "name": "goles",
            "isPercentage": false
          }
        },
        {
          "id": 45,
          "value": 25,
          "teamId": 4,
          "criterion": {
            "id": 2,
            "name": "precisión",
            "isPercentage": true
          }
        }
      ]
    },
    {
      "id": 8,                // Aún no registrada
      "scoredAt": null,
      "winnerTeamId": null,
      "teamCriteria": []
    }
  ]
}

Si el Timer que lleva a cabo la petición no está participando en un torneo al momento de realizar la petición se responde con el estado 409 Conflict.

Registro y anulación de resultados¶

Una vez que concluye un enfrentamiento entre un par de equipos, es necesario llevar registro de aquel que obtuvo la victoria. En otro caso, se puede presentar la situación en que sea requerido eliminar el registro del resultado de una partida. A continuación de definen ambos comportamientos.

Flujo¶

Tournament Handler: `PUT /tournament_matches/{id}/winner_team`¶

Autorización: Assistant

Mediante esta ruta se registra al ganador de una partida dentro de una ronda. El cuerpo de la petición es el siguiente:

winnerTeamId: 567  // 0 en caso de empate

como acción posterior, el manejador de torneos establece al ganador de la partida y persiste la fecha en que el resultado fue registrado (scoredAt).

Consejo

Para efectos de interpretación del modelo, una partida evaluada (con valor en scoredAt distinto de nulo) sin un equipo ganador asociado, se considera empatada.

La ruta responde con el estado 200 OK acompañado de la partida recién actualizada.

Si ya fue liberada la estación, se responde con el estado 403 Forbidden.

Si el match de torneo no se encuentra, se responde con el estado 404 Not Found. Si el equipo a registrar no se encuentra contendiendo en la partida indicada en la ruta, se responde con el estado``409 Conflict``.

Como parte del comportamiento exitoso, se notifica a los clientes Assistant y Timer sobre el ganador de la partida como se indica en la ruta Tournament Handler broadcast: update_match_node.

Tournament Handler: `DELETE /tournament_matches/{id}/winner_team`¶

Autorización: Assistant

Mediante esta ruta se anula el resultado de una partida entre dos equipos, indicando en la ruta el identificador del match de torneo a anular.

Al recibir la petición, se establece como nula la fecha de registro de resultado para la partida, para después deshacer la relación entre el match y el equipo que se encontraba registrado como ganador. Adicionalmente, debe eliminarse cualquier criterio de desempate registrado durante la partida, para cualquiera de los equipos contendientes.

La ruta responde con el estado 200 OK acompañado de la partida cuyos valores fueron eliminados.

Si ya fue liberada la estación, se responde con el estado 403 Forbidden.

Si el match de torneo no se encuentra, se responde con el estado 404 Not Found.

Como parte del comportamiento exitoso, se notifica a los clientes Assistant y Timer sobre la actualización en la ronda que contiene a la partida como se indica en la ruta Tournament Handler broadcast: update_match_node.

Confirmación de resultados y liberación de estación¶

Un asistente confirma los resultados de una ronda para que los mismos no puedan permanecer editables. En consecuencia, se libera la estación en la que los jugadores contendían, con el objetivo de que ésta pueda volver a ser usada dentro de la operación normal de la sucursal. A continuación se define el flujo correspondiente.

Flujo¶

Onsite: `DELETE /stations/teams`¶

Autorización: Assistant

Mediante esta ruta, un asistente solicita al servidor Onsite la liberación de una estación con el objetivo de que ésta pueda ser usada nuevamente por la operación normal de la sucursal. El cuerpo de la petición es el siguiente:

tournamentId: 43
matchNodeId: 14
winnerTeamId: 59
stationIds:
  - 56
  - 12

En consecuencia, Onsite solicita el registro de resultados de la ronda como se indica en Tournament Handler: PUT /match_nodes/{id}/winner_team, y establece la fecha de liberación de las asignaciones a estación por torneo.

Onsite responde con el estado 204 No Content si la petición se procesó de manera exitosa y fue liberada la estación.

Si no se ha registrado el ganador de cada ronda dentro del enfrentamiento, o si el equipo no pertenece al nodo, se responde con el estado 403 Forbidden.

Si alguna de las estaciones a bloquear no se encuentran, si alguna de las estaciones está siendo ocupada como parte del comportamiento normal de Arena, si la estación no tiene Timer asociado, o si no existe el node donde se liberarán las estaciones, se responde con el estado 409 Conflict.

Si se registra un empate para una partida con tipo de eliminación distinto a Round Robin, o si ya fueron registrados resultados para la ronda, se responde con el estado 412 Precondition Failed.

Como parte del comportamiento exitoso de la petición, se notifica a los clientes Assistant y a los Timer relevantes de la liberación de la estación como se indica en Onsite broadcast: unlock_station.

Al indicar a un ganador de la ronda en un modo de eliminación simple o doble, éste debe ser agregado como contendiente de la partida inmediata siguiente. En consecuencia, debe propagarse la notificación de actualización del nodo padre como se indica en Tournament Handler broadcast: update_match_node.

Tournament Handler: `PUT /match_nodes/{id}/winner_team`¶

Autorización: Location

Mediante esta ruta se confirman los resultados de la ronda cuyo nodo se indica como parte de la ruta. El cuerpo de la petición es el siguiente:

winnerTeamId: 567  // 0 en caso de empate

como acción posterior, el manejador de torneos establece al ganador de la ronda y persiste la fecha en que el resultado fue registrado (scoredAt).

Consejo

Para efectos de interpretación del modelo, una ronda evaluada (con valor en scoredAt distinto de nulo) sin un equipo ganador asociado, se considera empatada.

El manejador registra en el Match Node la fecha en que se registró la liberación de las estaciones, para posteriormente responder con el estado 200 OK.

Si no se ha registrado el ganador de cada ronda dentro del enfrentamiento, o si el equipo no pertenece al nodo, se responde con el estado 403 Forbidden.

Si se registra un empate para una partida con tipo de eliminación distinto a Round Robin, o si ya fueron registrados resultados para la ronda, se responde con el estado 412 Precondition Failed.

Como parte del comportamiento exitoso, se notifica a los clientes Assistant y Timer sobre el ganador de la ronda como se indica en la ruta Tournament Handler broadcast: update_match_node.

Criterios de desempate¶

Es posible que un asistente desee registrar valores estadísticos para una partida, los cuales son devueltos por la respectiva pantalla de resultados del juego, la cual es mostrada al final de un enfrentamiento. Tales valores estadísticos fungen como criterios de desempate en caso de no existir un ganador claro.

A continuación, se definen las rutas que permiten registrar y consultar estadísticas de un equipo durante una partida, así como la actualización pertinente en caso de ocurrir un ajuste.

Flujo¶

Tournament Handler: `PATCH /tournament_matches/{id}/team_criteria`¶

Autorización: Assistant

Mediante esta ruta se registran o actualizan estadísticas para la partida indicada en la ruta. Dichas estadísticas deben ser compatibles con aquellas permitidas para el torneo. El cuerpo de la petición es el siguiente:

- criterionId: 368 // nueva estadística
  teamId: 52
  value: 98
- teamCriterionId: 266 // actualización
  value: 56

Por cada elemento, el manejador de torneos registra un nuevo criterio para el equipo indicado o actualiza el registro con el valor proporcionado y responde con el estado 200 Ok acompañado de los registros recién actualizados.

Si la partida no se encuentra, se responde con el estado 404 Not Found. Si alguno de los criterios no existe o no es compatible con el torneo, si algún equipo no se encuenta o si no está participando en la partida, si el registro indicado no se encuentra o no pertenece a la partida, o si algún criterio es porcentaje y el valor proporcionado no pertenece al intervalo [0, 100], o si el valor numérico del cirterio excede el valor máximo estipulado, se responde con el estado 409 Conflict. Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone.

En cualquier caso de error, debe anularse la creación y actualización de cualquier criterio.

Como parte del comportamiento exitoso, se notifica a los clientes Timer y Assistant asociados al torneo sobre el establecimiento de valores en los criterios. Esto se logra mediante el broadcast Tournament Handler broadcast: update_match_criteria.

Tournament Handler: `GET /tournament_matches/{id}/team_criteria`¶

Autorización: Assistant

Mediante esta ruta se obtiene el listado de criterios de desempate registrados para una partida particular de la ronda llevada a cabo entre una pareja de equipos. La ruta responde con el estado 200 OK acompañado de la siguiente información:

teamCriteria:
  - id: 2
    value: 23
    teamId: 97
    criterion:
      id: 2
      name: precisión
      isPercentage: true
  - id: 76
    value: 2
    teamId: 97
    criterion:
      id: 5
      name: goles
      isPercentage: false
  - id: 45
    value: 40
    teamId: 75
    criterion:
      id: 2
      name: precisión
      isPercentage: true

Creación de bracket con los jugadores empatados¶

En caso de que dos o más equipos empaten en un grupo donde la modalidad de juego es Round Robin, es necesario crear un grupo que contendrá a los jugadores empatados.

A continuación, se definen las rutas necesarias para llevar a cabo el desempate de jugadores.

Flujo¶

Tournament Handler: `POST /groups/{id}/replay_group`¶

Autorización: Assistant

Mediante esta ruta se crea un nuevo grupo de desempate asociado a uno ya existente dentro de la fase, mismo que es proporcionado en la ruta.

elimination: round robin
bestOf: 2
teamIds:
  - 7
  - 6
  - 5

Al recibir la petición, se crea un nuevo grupo en la fase con los equipos recibidos. La ruta responde con el estado 201 Created acompañado del grupo recién creado como sigue:

id: 1
elimination: round robin
bestOf: 2
replaysGroupId: 5
teams:
  - id: 7
    name: Los mejores
    players:
      - id: 3
        nick: patron
      - id: 4
        nick: yoliDeLimon
  - id: 6
    name: Do be do
    players:
      - id: 5
        nick: loreh
      - id: 6
        nick: Lucie
  - id: 5
    name: JUJUJU
    players:
      - id: 7
        nick: Carlita
      - id: 8
        nick: Moreno
matchNodes:
  - id: 10
    teams:
      - id: 7
        name: Los mejores
        players:
           - id: 3
             nick: patron
           - id: 4
             nick: yoliDeLimon
      - id: 5
        name: La la la
        players:
          - id: 7
            nick: Carlita
          - id: 8
            nick: Moreno
    tournamentMatches:
      - id: 20
      - id: 21
  - id: 11
    teams:
      - id: 7
        name: Los mejores
        players:
           - id: 3
             nick: patron
           - id: 4
             nick: yoliDeLimon
      - id: 6
        name: Do be do
        players:
          - id: 5
            nick: loreh
          - id: 6
            nick: Lucie
    tournamentMatches:
      - id: 22
      - id: 23
  - id: 12
    teams:
      - id: 5
        name: JUJUJU
        players:
          - id: 7
            nick: Carlita
          - id: 8
            nick: Moreno
      - id: 6
        name: Do be do
        players:
          - id: 5
            nick: loreh
          - id: 6
            nick: Lucie
    tournamentMatches:
      - id: 24
      - id: 25

Como parte del comportamiento exitoso, se notifica a los clientes Assistant de la actualización de los grupos de la fase como se indica en Tournament Handler broadcast: update_phase.

Si no se encuentra el grupo, se responde con el estado 404 Not Found.

Se responde con el estado 409 Conflict bajo cualquiera de los siguientes casos:

Los equipos en la petición provienen de grupos diferentes
El grupo de origen de los equipos es de modalidad distinta a Round Robin.
Aún existen partidas en el grupo de origen de los equipos cuyos resultados no han sido asentados.
Los equipos no pertenecen a la fase.
Los equipos no pertenecen al torneo.

Creación de fase siguiente¶

Cuando se han registrado los resultados de una fase, el asistente puede solicitar la creación de una nueva, para posteriormente indicar los jugadores que harán la transición a la misma. A continuación, se indica el comportamiento llevado a cabo para realizar la función.

Flujo¶

Tournament Handler: `POST /tournaments/{id}/phases`¶

Autorización: Assistant

Mediante esta ruta se crea una nueva fase para el torneo indicado en la petición. La ruta responde con el estado 201 Created acompañado de la siguiente información.

id: 67
teams: []
groups: []
createdAt: 1480642412
updatedAt: 1480642412

Como consecuencia de la creación de fase, debe cerrarse la fase de creación inmediata anterior, estableciendo el valor en el campo closedAt.

Si no se encuentra el torneo proporcionado, se responde con el estado 404 Not Found. Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone. Si los resultados de la fase de creación inmediata anterior no han sido completamente establecidos, se responde con el estado 412 Precondition Failed.

El cierre de la fase anterior se notifica mediante el envío del broadcast Tournament Handler broadcast: update_phase. Asimismo, debe notificarse de la creación de la nueva fase usando el mismo broadcast.

Añadir equipos a la nueva fase¶

Una vez que se ha creado una fase, es necesario indicar los equipos que se enfrentarán en la misma, para porteriormente continuar con el flujo normal de jueceo. A continuación de indica el comportamiento seguido en el servidor para cumplir con la funcionalidad.

Flujo¶

Tournament Handler: `PUT /tournaments/{id}/phases/{id}/teams`¶

Añade equipos a la fase indicada en la petición. El cuerpo es el siguiente:

teamIds:
  - 2
  - 10
  - 21
  - 4

Como consecuencia, los equipos serán vinculados a al fase indicada. En caso de recibir la petición en más de una ocasión para la fase, se permite agregar nuevos equipos (ignorando duplicidad), siempre y cuando no haya dado lugar la división en grupos dentro de la fase.

La ruta responde con el estado 200 OK acompañado de la información de la fase actualizada. Si únicamente es proporcionado un equipo para agregar a la fase, se responde con 400 Bad Request. Si el torneo o la fase no se encuentran, se responde con el estado 404 Not Found. Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone.

Si alguno de los equipos no pertenece al torneo, o si ya se llevó a cabo la división en grupos de la fase, se responde con el estado 412 Precondition Failed.

La adición de equipos a la fase se notifica mediante el broadcast Tournament Handler broadcast: update_phase.

Indicar el cierre del torneo¶

Cuando se han registrado resultados para alguna fase del torneo, un asistente puede tomar la decisión de cerrar el torneo. A continuación, es indicado el proceso para dar por finalizado un torneo.

Flujo¶

Tournament Handler: `PUT /tournaments/{id}/winner_teams`¶

Autorización: Assistant

Mediante esta ruta se indican los equipos ganadores de un torneo, llevando a cabo el cierre del mismo. El cuerpo de la petición es el siguiente:

teamIds:
  - 3
  - 5
  - 19

Como acción posterior, se establece el listado de equipos ganadores del torneo en el servidor de torneos, estableciendo también la fecha de finalización del torneo.

El servidor responde con el estado 200 OK acompañado de la información del torneo actualizada. Si existe una fase en el torneo que no ha sido terminada, se responde con el estado 409 Conflict. Si el torneo ya ha finalizado al momento de la petición, se responde con el estado 410 Gone. Si alguno de los equipos no pertenece al torneo, se responde con el estado 412 Precondition Failed.

El cierre del torneo se notifica a los clientes Assistant suscritos a las notificaciones del mismo como se indica en Tournament Handler broadcast: delete_tournament.

Consulta de estadísticas¶

A continuación se describe el flujo seguido por un administrador para consultar el estado de un torneo que ya ha finalizado.

Flujo¶

Tournament Handler: `GET /tournaments/{xid}/team_statistics`¶

Autorización: User (super, onsite)

Consulta las estadísiticas de los equipos participantes en el torneo. La ruta responde con el estado 200 OK acompañado de la siguiente información:

- id: 22                       // anfitrión
  name: Los Rockstars QEPD
  players:
      - patron
      - yoliDeLimon
  isTournamentWinner: true
  contendedPhases:
    - id: 2
      isPhaseWinner: true
      createdAt: 1456738456
      contendedGroups:
        - id: 3
          isGroupWinner: true
          elimination: simple
          opponentTeams:
            - id: 11           // visitante
              name: Los guapos
              tournamentMatchesNumber: 5
              winnerTeamId: 0
- id: 9
  name: Los apestados
  players:
      - wololo
      - folome
  isTournamentWinner: false
  contendedPhases:
    - id: 3
      isPhaseWinner: false
      createdAt: 1456738456
      contendedGroups:
        - id: 5
          isGroupWinner: false
          elimination: simple
          opponentTeams:
            - id: 14
              name: Los apestosos
              tournamentMatchesNumber: 3
              winnerTeamId: 9

id: Identificador del equipo del cual se devuelve información.
name: Nombre del equipo.
isTournamentWinner: Indica si el equipo fue registrado como ganador del torneo.
contendedPhases[].id: Identificador de la fase en la cual participó el equipo.
contendedPhases[].isPhaseWinner: Indica si el equipo fue el ganador de la fase. El equipo es considerado ganador de la fase i si avanzó a la fase i + 1. Si la fase i es la última del torneo, se considera ganador de la fase al equipo sólo si éste ganó el torneo.
contendedPhases[].createdAt: Fecha de creación de la fase.
contendedPhases[].contendedGroups[].id: Identificador del grupo en el cual participó el equipo dentro de la fase.
contendedPhases[].contendedGroups[].isGroupWinner: Indica si el equipo fue el ganador del grupo.
contendedPhases[].contendedGroups[].elimination: Tipo de eliminación del grupo en el cual se enfrentó el equipo.
contendedPhases[].contendedGroups[].opponentTeams[].id: Identificador del equipo contra el cual se dio un enfrentamiento dentro del grupo.
contendedPhases[].contendedGroups[].opponentTeams[].name: Nombre del equipo con el cual se dio un enfrentamiento dentro del grupo.
contendedPhases[].contendedGroups[].opponentTeams[].tournamentMatchesNumber: Número de partidas que se dieron en el enfrentamiento entre ambos equipos.
contendedPhases[].contendedGroups[].opponentTeams[].winnerCode: Identificador del equipo que gana la ronda. El valor es 0 en caso de empate.

Si el torneo no se encuentra, se responde con el estado 404 Not Found. Si el torneo no ha finalizado al momento de efectuar la consulta, se responde con el estado 412 Precondition Failed.

API de Torneos¶

Lógica de torneos¶

Creación de un torneo¶

Flujo de juego¶

Caso de ejemplo¶

Registro¶

Asistencia¶

Creación de grupos¶

Creación de plantillas¶

Resultados del torneo¶

Transición a la siguiente fase¶

Formatos best-of¶

Modalidades de torneo¶

Round Robin¶

Eliminación Simple¶

Eliminación Doble¶

Sistema de byes¶

Gráfica de torneos¶

Creación de una plantilla torneo¶

Descripción general¶

Flujo¶

Creación de torneo¶

Descripción general¶

Consulta de plantillas en Offsite¶

Creación de torneo¶

Flujo¶

Offsite: POST /tournaments¶

Offsite: PUT /tournaments/{id}¶

Registro a un torneo¶

Descripción general¶

Flujo¶

Offsite: GET /tournaments¶

Offsite: POST /tournaments/{id}/teams¶

Offsite: PUT /teams/{id}/confirmation¶

Offsite: DELETE /tournaments/{id}/team_enrollment/player¶

Consulta de torneos¶

Flujo¶

Offsite: GET /tournaments/enrollments¶

Administración de invitaciones a torneo¶

Flujo¶

Offsite: GET /tournaments/{id}/team_enrollment¶

Offsite: PUT /teams/{id}/player¶

Offsite: POST /teams/{id}/template¶

Offsite: POST /teams/{id}/payment¶

Offsite: DELETE /teams/{id}/enrollment¶

Check In¶

Descripción general¶

Identificación¶

Offsite: POST /tournaments/{id}/check_ins¶

Validación de participantes¶

Flujo¶

Offsite: GET /tournaments/{id}/teams¶

Onsite: PUT /tournaments/{xid}/check_ins¶

Offsite: PUT /tournaments/{id}/check_ins/validation¶

Tournament Handler: POST /tournaments¶

Generación de brackets¶

Descripción general¶

Flujo¶

Tournament Handler: GET /tournaments¶

Tournament Handler: POST /tournaments/{id}/phases/{id}/groups¶

Eliminación simple (simple)¶

Eliminación doble (double)¶

Round Robin (round robin)¶

Auxiliares¶

Edición de brackets¶

Flujo¶

Tournament Handler: PUT /groups/{id}/alignment¶

Asignación de ronda a estación¶

Descripción general¶

Flujo¶

Onsite: PUT /stations/teams¶

Tournament Handler: PUT /match_nodes/{id}/stations¶

Tournament Handler: GET /match_node¶

Registro y anulación de resultados¶

Flujo¶

Tournament Handler: PUT /tournament_matches/{id}/winner_team¶

Tournament Handler: DELETE /tournament_matches/{id}/winner_team¶

Confirmación de resultados y liberación de estación¶

Flujo¶

Onsite: DELETE /stations/teams¶

Offsite: `POST /tournaments`¶

Offsite: `PUT /tournaments/{id}`¶

Offsite: `GET /tournaments`¶

Offsite: `POST /tournaments/{id}/teams`¶

Offsite: `PUT /teams/{id}/confirmation`¶

Offsite: `DELETE /tournaments/{id}/team_enrollment/player`¶

Offsite: `GET /tournaments/enrollments`¶

Offsite: `GET /tournaments/{id}/team_enrollment`¶

Offsite: `PUT /teams/{id}/player`¶

Offsite: `POST /teams/{id}/template`¶

Offsite: `POST /teams/{id}/payment`¶

Offsite: `DELETE /teams/{id}/enrollment`¶

Offsite: `POST /tournaments/{id}/check_ins`¶

Offsite: `GET /tournaments/{id}/teams`¶

Onsite: `PUT /tournaments/{xid}/check_ins`¶

Offsite: `PUT /tournaments/{id}/check_ins/validation`¶

Tournament Handler: `POST /tournaments`¶

Tournament Handler: `GET /tournaments`¶

Tournament Handler: `POST /tournaments/{id}/phases/{id}/groups`¶

Tournament Handler: `PUT /groups/{id}/alignment`¶

Onsite: `PUT /stations/teams`¶

Tournament Handler: `PUT /match_nodes/{id}/stations`¶

Tournament Handler: `GET /match_node`¶

Tournament Handler: `PUT /tournament_matches/{id}/winner_team`¶

Tournament Handler: `DELETE /tournament_matches/{id}/winner_team`¶

Onsite: `DELETE /stations/teams`¶

Tournament Handler: `PUT /match_nodes/{id}/winner_team`¶

Tournament Handler: `PATCH /tournament_matches/{id}/team_criteria`¶

Tournament Handler: `GET /tournament_matches/{id}/team_criteria`¶

Tournament Handler: `POST /groups/{id}/replay_group`¶

Tournament Handler: `POST /tournaments/{id}/phases`¶

Tournament Handler: `PUT /tournaments/{id}/phases/{id}/teams`¶

Tournament Handler: `PUT /tournaments/{id}/winner_teams`¶

Tournament Handler: `GET /tournaments/{xid}/team_statistics`¶