Bitácora de experimentos: controlador neuroevolutivo contra el árbol de comportamiento de Lyra

Documento para la Dra. Ponce de León y el Dr. Cuéllar. Reúne en orden cronológico todo lo que se construyó, probó, corrigió y decidió desde el lunes 5 de octubre, con el motivo de cada cambio de diseño y las cifras que lo respaldan. Se indica de forma explícita lo que no se puede afirmar.

Resumen

• Qué existe. Un controlador NEAT nativo dentro de Lyra (C++), con observación de 13 entradas y 5 salidas, evaluación por lotes sin ventana (8 instancias de Unreal en paralelo, tiempo acelerado ×3 en entrenamiento y ×1 en evaluación final) y un ciclo evolutivo con neat-python que intercambia genomas y resultados por archivos JSON.
• Qué se encontró. Con una semilla mínima de puntería, la evolución produjo en dos corridas independientes un controlador que sobrevive 30 a 38 s más que el BT de Lyra y que, según la línea y el escenario, empata o supera al BT en daño. En ningún caso la tasa de victoria es significativamente distinta de 50 %. Sin semilla, a 100 generaciones, una corrida alcanzó paridad en 3v3; a 60 generaciones no.
• Qué es ese controlador. Una red de 1 a 4 conexiones: gira hacia el enemigo, dispara siempre y casi no se mueve (velocidad media de 12 a 68 cm/s contra ≈400 del BT). Un controlador de tres reglas escrito a mano rinde igual o mejor. La evolución redescubrió esa táctica; no hay evidencia de que la supere. Su precisión de disparo es 4 a 7 % frente a 32 a 38 % del BT.
• Qué se validó del método. El fitness ordena correctamente controladores de referencia (aleatorio, inerte, reflejo a mano, BT); la medición es estable entre repeticiones; el entrenamiento a ×3 degrada algo la puntería; se identificaron y corrigieron dos causas técnicas por las que las primeras corridas no aprendían (deriva del giro vertical y mutaciones demasiado fuertes).
• Hallazgo de diseño de la madrugada del 9 de oct. El NEAT recibía la dirección y distancia al enemigo más cercano sin línea de visión, mientras que el BT apunta y dispara solo con lo que percibe. Se implementó una condición de percepción por vista, igual al BT en alcance (2500 uu) y ángulo (cono de 120°), y se relanzó la serie de experimentos. También se encontró que el BT navega hacia el enemigo más cercano del mapa cuando no percibe a nadie. Ambas asimetrías se declaran.
• Resultado bajo percepción por vista. Ningún controlador alcanza al BT en daño y bajas: seis campeones evaluados sin reentrenar y dos corridas entrenadas desde cero con esa restricción (una con semilla, 60 generaciones; una sin semilla, 100). La supervivencia mayor se conserva solo en los reflejos que casi no se mueven. Quitar la información privilegiada reduce el daño relativo en 70 a 140 puntos. No hay evidencia de un error de programación ni de corridas; hay evidencia de que la condición anterior inflaba los resultados y de que el entrenamiento por vista no basta con este diseño y presupuesto. No se puede concluir que NEAT no sirve.
• Etapa 2 bajo percepción por vista (E1). Entrenar 40 generaciones más contra 5 NEAT + 5 BT no mejoró al campeón: Δ de daño en 3v3 de −89.7 a −84.8 (intervalos solapados), tasa de victorias de 0.06 a 0.27 (Wilson 0.11–0.52), y peor en 5v5 y 10v2. No se cumple el criterio de «mejora clara» fijado antes (límite inferior del intervalo sobre −63.9). Con visión completa la misma etapa sí había dado una mejora de unos 25 puntos.
• Qué no se puede afirmar. Que NEAT supere al BT en general, que aprenda tácticas complejas, que sea reproducible más allá de n=2 por línea con semilla, ni que resista a jugadores humanos (no se ha medido).

Desarrollo técnico: cómo funciona NEAT y cómo se conecta con Unreal

Esta sección responde a las dudas sobre cómo se implementó NEAT en Python, cómo se configura la red, qué contiene un genoma y cómo se conecta con el controlador de Unreal.

Respuestas directas

• ¿Python y Unreal se comunican «en vivo» por un socket, con Learning Agents? No. La conexión final es por archivos JSON, generación por generación. Python escribe genomas.json, lanza procesos de Unreal que juegan las partidas y leen ese archivo, y cada proceso escribe un archivo de resultados y termina. Python no está conectado durante la partida. La solicitud y conversaciones anteriores hablaban de un puente en tiempo real con Learning Agents; ese plugin se analizó a nivel de código fuente y no se usó, porque espera una política con capas fijas y NEAT cambia la estructura de cada individuo.
• ¿La red aprende «en vivo», durante la partida? No. Durante un episodio los pesos no cambian. Lo que cambia entre generaciones es la población: NEAT selecciona, cruza y muta los genomas con base en el fitness medido.
• ¿La red corre en tiempo real dentro del juego? Sí. En Unreal, un cerebro escrito en C++ ejecuta la red 10 veces por segundo (cada 0.1 s de juego) sin Python. Se comprobó que calcula lo mismo que Python (ver «Verificación»).
• ¿Se entrena mientras una persona juega? No. Todo el entrenamiento ocurre en partidas de bots contra bots, en servidores sin ventana. Una persona podría jugar contra un campeón ya entrenado, pero eso todavía no se ha probado.

Arquitectura

flowchart LR
  A["evolve.py
neat-python: población de genomas"] -->|"genomas.json"| B["ue_evaluator.py
lanza N procesos de Unreal"]
  B --> C["UnrealEditor-Cmd
servidor sin ventana, L_GymAVE"]
  C --> D["LyraNeatBotController
cerebro C++ de cada genoma"]
  D --> E["LyraNeatEpisodeSubsystem
mide el episodio"]
  E -->|"launch_*.json"| B
  B -->|"resultados.json"| A
  A --> F["fitness.py
fitness por genoma"]
  F --> A

Ciclo de una generación, paso a paso

1. Población. evolve.py crea la población con neat.Population (60 genomas) o la reanuda desde un checkpoint (--resume).
2. Escenarios. Para la generación g define K=4 escenarios con semillas seed·100003 + g·1009 + k. Todos los genomas juegan los mismos escenarios, aunque las posiciones de aparición no se fijan.
3. Exportación. ave_io.make_genomes_payload escribe genomas.json: la interfaz (entradas, salidas, normalización), los identificadores de nodos de entrada y de salida, los escenarios y, por genoma, sus nodos y conexiones habilitadas.
4. Lanzamientos. UnrealEvaluator.run divide los genomas en bloques de 10 (o 5 en la etapa 2) y, para cada escenario y bloque, lanza UnrealEditor-Cmd.exe con -server -game -nullrhi, el mapa L_GymAVE?NumBots=…?Experience=B_AVE_Experience, un puerto propio y los argumentos -NeatGenomes, -NeatGenomeOffset, -NeatBotCount, -NeatGeneration, -NeatScenario, -NeatEpisodeSeconds, -NeatTimeDilation y -NeatResults. Con población 60, K=4 y bloques de 10 NEAT + 2 BT son 24 lanzamientos por generación, 8 en paralelo.
5. Dentro de Unreal. El componente de creación de bots (LyraBotCreationComponent) asigna controlador NEAT a los primeros N bots y el Behavior Tree al resto. Cada ALyraNeatBotController carga su genoma (índice = offset + ranura) y construye su red. El gestor de episodios espera la fase Playing, acelera el tiempo ×3, mide la primera vida de cada bot NEAT durante 60 s (o hasta que mueran todos) y escribe launch_*.json. Luego el proceso termina.
6. Unión. Python junta los resultados parciales en resultados.json y los valida (validate_results: versión, generación, genomas y campos).
7. Fitness. fitness.genome_fitness calcula el fitness del episodio y promedia los K episodios de cada genoma. Se guardan components.csv (una fila por episodio) y curve.csv (mejor, medio y número de especies por generación).
8. Reproducción. neat-python agrupa en especies, selecciona, cruza y muta, y deja un checkpoint por generación. Una generación toma unos 2.4 minutos en el entrenamiento normal.

Archivos de Python (carpeta NEAT_Training/)

Configuración de la red (neat-python)

El genoma

En neat-python un genoma es un conjunto de genes de nodo (sesgo, respuesta, activación, agregación) y de conexión (origen, destino, peso, habilitada). Las entradas llevan identificadores −1 a −13 y las salidas 0 a 4. genome_to_dict exporta solo las conexiones habilitadas. Ejemplo real, el reflejo con retroceso hecho a mano (id 9002), con la estructura del campeón 7837: cinco nodos de salida con sesgos (avance −0.21, disparo +2.65) y una sola conexión, de la entrada −9 (ángulo hacia el enemigo) a la salida 2 (giro), con peso 4.94.

Archivos de C++ (Source/LyraGame/Neat/ y relacionados)

Las banderas de percepción por vista (-NeatRequireLos, -NeatFovHalfDeg, -NeatSightRadius) y las de experimento (-NeatMaxPitchDegPerSecond, -NeatGenomeId, -NeatMeasureBt) se pasan por línea de comandos, y la variable de entorno NEAT_EXTRA_ARGS las agrega a todos los lanzamientos de Python.

Función de fitness, tal como está implementada

Por episodio: F = 1.0·Dd + 0.2·Ts − 0.2·Dr + λ(g)·(0.05·Fcerca + 4.0·Fapunta), con Dd = min(daño hecho / 100, 3), Ts = min(tiempo vivo / 60 s, 1), Dr = min(daño recibido / 100, 1), λ(g) = max(0, 1 − g/30), Fcerca la fracción de ticks con el enemigo a distancia media y Fapunta la alineación media de la mira (1 − error/90°, mínimo 0). El fitness del genoma es el promedio de sus 4 episodios. El peso de Fvis es 0.

Verificación de que Unreal calcula lo mismo que Python

El 9 de octubre, el comando ave.Neat.Golden comparó la red de C++ con la referencia de Python sobre golden/golden_test.json: 140 vectores de entrada, error máximo 1.4·10⁻¹⁵, con tolerancia de 10⁻⁵. Resultado: aprobado. Además, mock_evaluator.py permitió probar el ciclo completo sin Unreal el 5 de octubre.

Limitaciones técnicas del diseño

• Red hacia adelante, sin memoria: no recuerda dónde vio al enemigo.
• El entrenamiento reinicia un proceso de Unreal por partida; es estable, pero cuesta tiempo de arranque.
• Las posiciones de aparición no se fijan entre genomas; es una fuente de ruido.
• El giro vertical se anuló por la deriva observada; la mira del NEAT solo gira en horizontal.
• La aceleración ×3 del tiempo reduce un poco la puntería (0.96 a 0.88 en una prueba), por eso la evaluación final se hace a ×1.

Línea de tiempo

Primero, el ritmo de trabajo medido. Cada celda es una hora; está activa si ese día se escribió al menos un archivo de resultados en NEAT_Training/runs/. Es una medida mínima de que la computadora estuvo ejecutando experimentos: no cuenta las pruebas que no dejan archivos ni el trabajo de redacción.

53 horas con actividad de 98 transcurridas desde el 5 de oct 16:00 (corte: 9 de oct, 17:37). El 8 de oct hubo actividad en 21 de 24 horas y el 9 de oct en 16 de las 18 horas transcurridas. Pausas largas: 7 de oct de 05:00 a 18:00; 8 de oct de 08:00 a 11:00; y 9 de oct de unos 09:20 a 12:05, entre el fin de la cola de la noche y el siguiente experimento, mientras se analizaban los resultados y se escribía el protocolo (sin corridas en ese lapso). El 9 de oct a las 00:45 se detuvo todo por decisión del responsable para corregir el diseño, y se reanudó a las 01:55. Desde las 12:50 corre la cola de reentrenamiento y sigue en marcha. Las horas en recuadro punteado todavía no ocurren.

Cómo leer la serie: desarrollo y condiciones

Los experimentos se pueden leer en dos etapas. La serie no se planeó como un diseño factorial desde el primer día; surgió de ir descubriendo qué variables importaban. Cada condición nueva se anotó con su motivo en el momento en que apareció, y eso es lo que permite compararlas ahora.

• Desarrollo (28 sep a 7 oct, 22:00). Construir el sistema y depurarlo: corridas piloto a 11. Aquí se encontraron y corrigieron errores del propio montaje. No se comparan entre sí.
• Condiciones experimentales (desde el 8 oct, 01:00). Con el fitness congelado desde el 7 de oct (1.0·Dd + 0.2·Ts − 0.2·Dr + ayuda de puntería que se apaga en la generación 30), K=4, población 60, configuración NEAT v2 y los mismos escenarios de evaluación. Lo que cambia entre condiciones es la información del enemigo, la inicialización y el oponente de entrenamiento.

En C4 y C5 cambia el significado de dos términos del fitness: Fapunta y Fcerca solo cuentan con enemigo percibido. El resto de la fórmula es idéntico.

Ventajas y desventajas del NEAT frente al BT, por condición

Con información completa, el NEAT tenía ventajas de información y desventajas de ejecución. Con percepción por vista pierde la ventaja de información y conserva las desventajas de ejecución, más la de búsqueda. Comparar C1 con C4 mide cuánto valía esa información. Es un resultado, no solo una corrección.

Qué significa para los jugadores humanos

• Lo medido con humanos. Solo hay 33 sesiones de humanos contra el BT (el BT ganó 28). No hay sesiones de humanos contra el NEAT. Los resultados del NEAT contra el BT no se pueden trasladar a humanos sin medirlo.
• La condición de información completa no sería aceptable como oponente. Un jugador percibiría como trampa que el NPC apunte a través de paredes. La condición por vista se parece más a lo que tiene un jugador. El BT también tiene ventaja de información al buscar (conoce posiciones), algo habitual en juegos; «justo» depende del marco que se elija.
• Riesgo de ajuste al BT. El campeón que más sobrevive aprendió a disparar casi sin moverse contra un BT que ataca de frente. No sabemos si esa táctica funciona contra una persona. Es una hipótesis que se puede comprobar con unas pocas partidas jugadas.
• Un NPC que no sabe buscar. Con percepción por vista, el NEAT solo reacciona a lo que ve. Como oponente de un humano necesitaría una forma de desplazarse; eso queda como trabajo futuro y no se afirma aquí.

Inventario de corridas

Se conservan todas, también las descartadas, porque cada una explica una decisión.

Experimentos de validación del método

Estas pruebas no buscan un mejor controlador, sino saber si las medidas del proyecto se pueden creer.

Resultados contra el BT

Partidas nuevas, a velocidad ×1, solo la primera vida de cada bot, media por bot. «Gana» es el equipo con más bajas por bot en la partida. Intervalo de Wilson al 95 %; diferencias por partida con remuestreo (bootstrap).

3 contra 3, 90 s, 20 partidas

Estadística de los campeones principales

Un intervalo que no contiene 0 es evidencia de diferencia entre el NEAT y el BT en esa métrica. Con 12 a 20 partidas por comparación y sin corrección por comparaciones múltiples, ninguna tasa de victoria es significativamente distinta de 50 %. Los intervalos del reflejo con retroceso (9002) están pendientes de calcular.

Lo que muestran las métricas extra

• Precisión de disparo (impactos entre disparos): NEAT 4 a 7 %, BT 32 a 38 %. El NEAT dispara siempre; su ventaja viene de sobrevivir, no de apuntar mejor.
• Cobertura (enemigo a menos de 1500 uu, cubierto = sin línea de visión). Definición operacional pendiente de validar por el Dr. Cuéllar. Los campeones de etapa 2 pasan menos tiempo a cubierto que el BT (0.24–0.29 contra 0.34–0.37 de la fracción), pero reciben menos daño por segundo expuesto (14 a 19 contra 46 a 55). La lectura es que no usan cobertura: se quedan casi quietos mientras disparan (ver «Velocidad medida»). El tiempo con enemigo cerca es de 2 a 3 s por bot, así que es una tendencia.
• Estructura de los campeones. 7837: una conexión (rumbo → giro, +4.94) y sesgos de disparo (+2.65) y avance (−0.21: la entrada de movimiento sería −0.48, pero la velocidad medida es ≈20 cm/s). 5768: 4 conexiones, la mayoría de efecto pequeño. El promedio de la población en la etapa 2 no mejoró; el campeón es un valor atípico, validado en partidas nuevas.

El BT de Lyra, tal como se verificó en los activos

Tres ramas bajo un selector: sin munición, busca arma (EQS_FindWeapon); con munición y objetivo percibido, «Shoot And Move» (fija el foco en el objetivo, dispara cada ≈0.1 s y se mueve a una posición de EQS_MoveAgainstEnnemy con strafe); con munición y sin objetivo, recarga, busca arma y busca al jugador. El objetivo lo escribe un servicio que corre EQS_AIPerceptionEnemy. Las decisiones son ramas discretas, pero las acciones son continuas. Referencia humana: 33 sesiones (106.5 min, 247 vidas), el BT ganó 28; bajas y muertes por sesión 2.9 y 6.8.

Resultados bajo percepción por vista

Mismos escenarios y mismo protocolo de evaluación que antes (a ×1, partidas nuevas, 3v3 de 90 s con 20 partidas). Solo cambia lo que recibe el NEAT: el enemigo existe únicamente si hay línea de visión, está dentro de ±60° y a ≤2500 uu. Δ = NEAT menos BT, en promedio por bot.

Los mismos campeones, con visión completa y por vista

Con visión completa, el reflejo con retroceso hecho a mano ganó 13 de 20 partidas al BT (tasa 0.87, Wilson 0.62–0.96), el único resultado de toda la serie con significancia sobre 50 %. Por vista pierde 16 de 20. Para los seis controladores, quitar la información privilegiada reduce el daño relativo en 70 a 140 puntos. El tiempo vivo se mantiene en los que casi no se mueven (+25 a +28 s).

Controladores entrenados bajo percepción por vista

Qué muestran los registros de entrenamiento

Fracción de ticks en que el NEAT tenía un enemigo percibido con línea de visión, alineación media de la mira y daño por episodio en el entorno de entrenamiento (10 NEAT + 2 BT). Se compara el inicio (generaciones 0 a 2) con las últimas 10.

• Bajo percepción por vista el NEAT ve al enemigo un tercio del tiempo con semilla (contra poco más de la mitad con visión completa) y no aprende a verlo más.
• La línea con semilla hace en el entorno de entrenamiento un daño (83) igual al de la línea con visión completa (80), pero contra el BT queda lejos (71.5 contra 161.2 en 3v3). En ese entorno la mayoría de los oponentes son otros NEAT con la misma limitación.
• La línea sin semilla no aprende: su alineación de mira queda en 0.16, frente a 0.67 del control con visión completa.

Control de diagnóstico: reflejo con búsqueda (9003)

Para comprobar si la falta de búsqueda explica el resultado, se escribió a mano una variante del reflejo con retroceso que gira de forma constante cuando no ve al enemigo (sesgo de giro +0.3 que se anula al percibirlo). La predicción, anotada antes de correrla: si la búsqueda fuera el cuello de botella, mejoraría de forma clara sobre 9002. Resultado por vista en 3v3 (20 partidas): daño 22.1 contra 162.2 del BT, bajas 0.13 contra 0.90, vivo 40.9 contra 23.4 s; Δ daño −140.1 (−164.4, −116.0), victorias 2/1/17. Es peor que 9002 (−98.2). La predicción no se cumple con una búsqueda tan simple. No descarta otras formas de búsqueda ni de memoria.

Velocidad medida

Velocidad horizontal media de los bots mientras viven (cm/s, tope de caminar 600), en las partidas 3v3 de 90 s con percepción por vista, 10 partidas por controlador (30 bots NEAT y 30 BT).

• Los controladores que hacen más daño y sobreviven más (los reflejos y los campeones de etapa 2) casi no se mueven: de 12 a 99 cm/s, entre el 2 y el 16 % del tope de 600.
• Los que corren a casi toda velocidad (526 y 576 cm/s) hacen poco daño (13 y 8).
• El BT se mueve a ≈390–490 cm/s en todas las partidas, entre el 65 y el 80 % del tope.
• La interpretación anterior, «retrocede a media velocidad», salía del sesgo de avance de la red (−0.21 daría una entrada de −0.48). La medición indica que casi no se mueve. La causa no está confirmada: una hipótesis es que retrocede hasta una pared y se queda disparando. No se registran posiciones.
• Esta medición es solo bajo percepción por vista. Con visión completa no se midió porque la instrumentación se compiló después.

Lo que implica: la táctica que la evolución y el reflejo a mano comparten se parece a una torreta: apuntar y disparar sin desplazarse. Contra ella, el BT se acerca con mira instantánea. Si un jugador humano percibiría ese comportamiento como campear o como parte natural del combate no está medido.

Qué pudo haber pasado

Lo que sí se puede decir: con esta observación, estas salidas, este presupuesto y percepción comparable a la humana, la evolución no produjo un controlador que alcance al BT de Lyra. Eso es un resultado negativo documentado con una condición de partida (visión completa) que explica por qué antes parecía lo contrario.

Qué cambia en las conclusiones

• «NEAT iguala al BT» deja de ser una conclusión general. Es cierto bajo visión completa, en 3v3, y no bajo percepción por vista.
• Se mantiene: el método y sus validaciones, el valor de la información medido (70 a 140 puntos de daño relativo), la supervivencia mayor de los reflejos que casi no se mueven y el hallazgo de que la táctica evolucionada la reproduce una regla escrita a mano.
• El diseño de la solicitud (sensores de vector al enemigo y línea de visión) no pedía igualdad de información con el BT. La comparación justa la define este trabajo.

Correcciones registradas

Estas son afirmaciones hechas durante el trabajo y retiradas o ajustadas cuando los datos las contradijeron. Se dejan por escrito porque forman parte del método.

Validez y asimetrías

La condición nueva, «percepción por vista», entrega al NEAT el enemigo más cercano que cumpla tres cosas: línea de visión, ángulo horizontal de ±60° y distancia ≤2500 uu, los valores del BT. No tiene memoria, igual que el BT. La prueba de humo mostró 0 de 495 muestras con enemigo sin visión. La condición cambia el significado de dos términos del fitness: Fapunta y Fcerca solo cuentan con enemigo percibido.

Asimetrías que permanecen, por orden de importancia:

• Búsqueda. Sin objetivo percibido, el BT navega hacia el enemigo vivo más cercano del mapa (EQS_GetAllEnemy recorre todos los personajes del equipo contrario sin filtro de visión). El NEAT no tiene ni navegación ni conocimiento de posiciones.
• Mira. La rotación de control del BT se ajusta al instante al objetivo percibido; el NEAT gira como máximo 180°/s en horizontal y no tiene giro vertical.
• Navegación y recarga. El BT usa navmesh, EQS, recarga y búsqueda de armas. El NEAT tiene tres rayos de obstáculos.
• Frecuencia. El NEAT decide a 10 Hz; el BT actualiza su objetivo cada ≈0.5 s (ventaja del NEAT en tiempo de reacción).
• Velocidad de movimiento. En las sesiones humanas se preguntó por qué el bot podía correr y los jugadores no. Lo verificado: Lyra no define un sprint en su código C++; el personaje (B_Hero_ShooterMannequin) tiene MaxWalkSpeed 600 uu/s (300 agachado) y velocidad analógica mínima de 200; el Gym usa los mismos datos de personaje (HeroData_AVE) y el mismo personaje para jugadores y bots. El conjunto de habilidades del Gym (AbilitySet_AVE) no incluye salto, dash, cuerpo a cuerpo, granada, soltar arma ni emote, que sí están en el de Lyra, aunque el mapa de entradas del jugador todavía los enlaza; eso pudo percibirse como que no podían correr. El apuntado con mira reduce la velocidad de los jugadores. Por configuración no hay diferencia de velocidad máxima entre humanos y bots. La velocidad real se midió después en los bots (sección «Velocidad medida»); en los humanos falta, porque la columna speed de la telemetría se compiló después de las sesiones.
• Sentido de daño. El BT lo tiene configurado. No se halló quién lo reporta en el C++; falta revisar los Blueprints.

Otras limitaciones: una sola corrida por condición sin semilla y dos con semilla, de modo que no hay variabilidad estimable; el campeón se elige entre 10 candidatos (maldición del ganador, parcialmente corregida con escenarios nuevos); la cobertura no está validada; el fitness no se recalibró bajo la nueva condición.

Solicitud contra realidad

Qué sigue

La cola night4.py terminó el 9 de oct a las 09:20 sin fallos. Quedan abiertas pruebas que separan las explicaciones de la sección anterior. La cola night5.py las ejecuta en orden desde las 12:50; han terminado el control 9003, la medición de velocidad y E1; corre ahora E2 (réplica de la línea por vista con semilla).

Criterio de reporte fijado antes de ver datos: se reportan todos los resultados, sean buenos o malos, sin umbral de éxito.

Decisiones que requieren la opinión de los doctores

• Dr. Cuéllar: validar la definición operacional de cobertura y el esquema de comparaciones (tasa de victoria por partida, intervalos por remuestreo, tamaño de efecto solo exploratorio).
• Dra. Ponce de León: el papel de la semilla de reflejo frente a la población inicial mínima aleatoria.
• Ambos: el marco de igualdad. Propuesta: para el miniproyecto, igualdad con el bot de Lyra en percepción; para el congreso, percepción comparable a la de un jugador humano, con partidas jugadas contra el campeón si hay tiempo.

Archivos de respaldo

• FITNESS_CHANGELOG.md: cada cambio de diseño con su evidencia y lo que no se afirma.
• night_log.md, runs/overnight_log.txt: bitácora de las guardias.
• informe_manana.md, runs/estadistica_comparaciones.md: resultados y estadística.
• CALIBRATION_PROTOCOL.md, AUDIT_PROTOCOL.md, AB_PITCH_PROTOCOL.md, STAGE2_PROTOCOL.md, NIGHT2_PROTOCOL.md, FAIR_PROTOCOL.md: protocolos escritos antes de ver datos.
• AUDITORIA_PLAN_VS_REALIDAD.md: comparación punto por punto con el plan del 1 de oct.

Participación de los alumnos inscritos en la solicitud: Leslie Benitez y Noé de Luna, por documentar por el responsable.