El arnés

Arquitectura

Cada partida tiene su propia instancia del emulador en su propia pantalla X virtual, su propia copia del directorio del juego, su propio demonio del emulador y sus propias filas en una base de datos SQLite compartida. Las partidas de una tanda no comparten ningún estado.

Lectura del estado: la memoria del juego

El arnés lee directamente la memoria del juego en marcha; no va pasando pantallas. Un pequeño demonio por instancia arranca el emulador como proceso hijo, lo que le permite leer la RAM del sistema emulado a través de /proc/<pid>/mem y servirla por una API HTTP local.

• Registros del juego. El juego guarda jugadores y clubes en tablas contiguas de registros de tamaño fijo, con la misma estructura que sus partidas guardadas. La estructura se descifró usando editores de partidas de la comunidad como referencia: se cambia un campo en el editor y se comparan los bytes. El arnés decodifica estas tablas en milisegundos: atributos, posiciones, contratos, valores, plantillas, alineaciones, tácticas, lesiones y sanciones.
• Calendario y fechas. Los partidos de liga, copa, competiciones europeas y selecciones, con sus fechas, salen de las tablas de calendario del juego en memoria.
• Texto en pantalla. El juego guarda en memoria, como una lista, el texto que ha dibujado en la pantalla actual. El arnés lee esa lista (1–5 ms, exacta, con tildes) para noticias, ofertas y el minuto e incidencias del partido en juego. El OCR de una captura queda solo como reserva, y para lo único que no está en la lista, el cuerpo de una noticia; ese OCR se cruza después con las cadenas exactas de la memoria.
• Instantáneas. Cada vez que el juego se detiene para el entrenador, el estado decodificado se guarda en SQLite como una instantánea con fecha: plantillas, clasificaciones, resultados, fichajes y finanzas. El panel y la puntuación leen estas instantáneas.
• Filtro de vista. Todas las herramientas de lectura pasan por una única lista de los campos que el juego enseña a un jugador humano. Los valores ocultos (por ejemplo, la calidad actual y potencial) se decodifican y se guardan para los observadores, pero ninguna herramienta puede devolverlos. El modelo ve lo que vería una persona delante del teclado.

Acciones

• Alineación antes del partido. set_lineup escribe el once, los suplentes, las posiciones, la táctica y los lanzadores de balón parado en los bytes de alineación del club en memoria: los mismos bytes que fija la pantalla de alineación del propio juego.
• Todo lo demás pasa por las pantallas del juego. Ofertas, propuestas de contrato, listas de transferibles y cedibles, respuestas a las preguntas del juego y cambios durante el partido se hacen con macros de teclado y ratón en el emulador. La respuesta del juego se lee y se devuelve al modelo. Las acciones de mercado se ponen en cola durante el turno y se ejecutan después, en orden.
• Nada se escribe en memoria durante un partido. Los cambios en juego se hacen solo desde la pantalla de tácticas del juego.

Son las reglas del propio juego las que deciden si una acción sale bien: una oferta rechazada, un jugador que no acepta un contrato o un traspaso que no se puede pagar se comunican tal como los comunica el juego. El arnés nunca modifica el dinero, la calidad, los resultados ni ningún otro valor del juego.

Turnos

El arnés detiene el juego cada vez que toca decidir algo y abre un turno. Durante un partido vigila el minuto en la lista de texto de la pantalla, congela el proceso del emulador en el descanso o en el minuto 70, abre la pantalla de pausa y reanuda tras el turno. Cada turno empieza con una conversación nueva: unas reglas fijas y después un informe con el estado actual, las noticias desde el último turno, el plan de temporada y las notas del propio modelo, y su última revisión mensual. La memoria entre turnos existe solo a través de estas herramientas (set_plan, update_notes, read_memory, write_review).

El reloj del juego está parado durante el turno, así que no hay prisa: un modelo lento y uno rápido juegan exactamente la misma partida. El tiempo real y los tokens se registran, pero no puntúan.

Conexión de modelos

Todos los modelos reciben las mismas definiciones de herramientas, las mismas reglas y el mismo informe. Solo cambia el canal.

• Modelos locales y por API (endpoints compatibles con OpenAI, p. ej. vLLM): el arnés lleva él mismo el bucle de herramientas.
• Modelos punteros funcionan a través de las CLI de agente de sus propios fabricantes en modo sin interfaz, con todas sus herramientas integradas y la búsqueda web desactivadas, un directorio de trabajo vacío y las herramientas del arnés como único servidor MCP. No pueden leer archivos, ejecutar órdenes ni navegar.

Los ajustes de cada modelo (esfuerzo de razonamiento, muestreo) forman parte de su entrada en la alineación de la tanda y no cambian durante ella.

Salvaguardas

Los modelos más débiles pueden entrar en bucle. El arnés cierra el turno, conservando lo que ya se aceptó, cuando:

• el modelo responde tres veces seguidas sin llamar a ninguna herramienta;
• el modelo repite exactamente la misma llamada después de que ya se aceptara;
• el turno llega a su máximo de llamadas.

Si el juego fuera a empezar un partido con una alineación no válida y el turno de corrección del modelo no lo ha arreglado, el arnés sustituye al jugador no disponible por otro de su misma posición. Cada una de estas intervenciones queda registrada como harness fallback y aparece en el registro de la partida.

Recuperación

El software antiguo se cuelga. El arnés guarda un punto de control (una partida guardada del juego más la posición en la base de datos) en el menú principal después de cada día en que juega el club. Un proceso supervisor vigila cada partida; si el emulador o el ejecutor caen, restaura el último punto de control y aparta las filas de la base de datos escritas después, para que la partida siga desde un estado coherente. Las restauraciones quedan registradas.

Registros y qué es público

Se guarda cada turno: el informe, el razonamiento del modelo cuando el modelo lo muestra, cada llamada a herramienta con sus argumentos, la respuesta del juego, los tokens y los segundos. El panel público lo muestra todo para cada turno. El texto del modelo se publica tal cual lo escribió, en inglés. El prompt de sistema y las definiciones de herramientas no se publican.

El panel también muestra valores ocultos del juego (por ejemplo, la calidad real de un jugador), marcados como solo para observadores. Los modelos nunca los ven.

Benchmarks, tandas y competiciones

• Un benchmark es una tarea fija sobre un juego: una partida inicial, un periodo, un conjunto de herramientas y una puntuación, con número de versión.
• Una tanda es una ejecución de un benchmark con una alineación de modelos. Cada modelo juega su propia copia del juego desde la misma partida guardada. Antes de empezar una tanda se calcula el hash de cada archivo del arnés, de la puntuación, de sus tests y del script de lanzamiento, y se guardan con la tanda. Los tests de la puntuación tienen que pasar o la tanda no se congela. En una tanda en marcha no se cambia nada.
• Las referencias se juegan en paralelo: la IA del propio juego dirigiendo el mismo club desde la misma partida. Se muestran como contexto y no puntúan.
• Los rankings salen solo de los benchmarks. Las competiciones (todos los modelos en una misma partida) se publican aparte y nunca entran en los rankings, porque los modelos influyen en los resultados de los demás.

Championship Manager 97/98

Un juego de gestión de fútbol (1997, MS-DOS). El jugador dirige un club: plantilla, táctica, fichajes, contratos y las expectativas de la directiva. Los partidos los simula el motor del juego. Se usa la versión original en inglés.

Herramientas

Unas 35 herramientas, agrupadas así:

• Plantilla y partidos: get_squad, get_player, set_lineup, my_lineups, list_tactics, change_tactic, substitute, match_report, player_games, recent_results
• Mercado: search_players, find_players, scout_club, compare_with_squad, make_offer, transfer_list, list_for_loan, loan_player, contract_terms, offer_new_contract, herramientas de seguimiento
• Club: club_info, board_confidence, league_table, fixtures, search_history
• Preguntas del juego: answer, decide
• Memoria: set_plan, update_notes, read_memory, season_review, write_review; y end_turn

Puntuación (Reto de club, A-v1)

• Puntos = puntos de liga ganados al mando, más 5 por cada temporada completa sin ser destituido.
• Cada liga se puntúa en su propia fecha de juego. Si el entrenador es destituido, los puntos se detienen en la destitución y su porcentaje de días al mando se mide contra la fecha de la liga más avanzada de la tanda.
• Se muestra un índice de gestión secundario (liga 35, copas 15, calidad de la plantilla 25, finanzas 15, proceso 10, frente a las referencias), pero no decide el ranking.

Particularidades del juego

• La calidad de los jugadores está oculta en el juego; el modelo ve los atributos numéricos y las descripciones que muestran las pantallas del juego.
• La directiva puede destituir al entrenador. Una destitución termina la partida de ese modelo.