← Zero To Apex

Ingeniería · el desarrollador de Zero To Apex

Jose Manuel Vicente

Desarrollo Zero To Apex yo solo: un motor de carrera en C++17, una app de escritorio en Tauri y React, y un pequeño backend en la nube. Esta página enseña cómo encaja todo y cómo se toman las decisiones: midiendo lo que hace el sistema, no fiándose de lo que se le dijo que hiciera.

Cómo encaja

El motor no sabe nada de la interfaz. Cada operación es un nombre de método y un JSON de entrada, y un JSON de salida. Esa única forma permite poner varias interfaces delante del mismo motor: la app de escritorio junto al juego, una compilación WebAssembly en el navegador y datos fijos para pruebas y demos.

Diagrama: la app de escritorio, el motor de carrera, la integración con el juego y el backend en la nube, y cómo se comunican

Decisiones comprobadas, no supuestas

Un ajuste que no hacía nada

Problema
Un ajuste de dificultad debía controlar lo constantes que son los pilotos de la IA vuelta a vuelta. Siguió ahí durante meses, porque al usarlo nada parecía roto.
Qué hice
Registré trece carreras con ajustes distintos y comparé la variación vuelta a vuelta con el ajuste y con el tráfico.
Resultado
La variación seguía al tráfico, no al ajuste. El supuesto se descartó y el modelo se rehízo sobre lo medido.
La variación vuelta a vuelta sigue al tráfico, no al ajuste

El instrumento era la anomalía

Problema
Un vigilante marcaba una parte de las carreras como anómalas, y esa parte se citaba como indicador de salud.
Qué hice
Revisé a mano cada carrera marcada en lugar de fiarme del porcentaje.
Resultado
El 71 % de las marcas eran un artefacto de cómo el vigilante muestreaba sus propios datos. La tasa real de anomalías era del 5 %.
El 71 % de las carreras marcadas eran artefactos del vigilante; la tasa real de anomalías era del 5 %

Contar la parrilla que de verdad corrió

Problema
Una parrilla estaba configurada para repartir 3, 17 y 5 coches en tres niveles de habilidad.
Qué hice
Conté la parrilla que llegó a la pista en lugar de releer el valor configurado.
Resultado
Corrió como 9, 8 y 8: algo por el camino renormalizaba el reparto. Escribir un valor y releerlo son dos pruebas distintas.
Reparto configurado de 3, 17 y 5 coches frente al reparto corrido de 9, 8 y 8

Cómo se construye

La mayor parte de la implementación pasa por un agente de programación con IA, con reglas sencillas. El desarrollo va guiado por pruebas, contra un banco del motor cuyo código de salida es el número de pruebas que fallan. Un comportamiento se mide antes de cambiarlo. Y cualquier comprobación que obligue a auditar una superficie grande, como cada fichero que podría contradecir una afirmación, la hace un agente que ejecuta la versión exhaustiva que una persona tiende a recortar.

Lee el código

Una exportación saneada del motor de carrera (contratos, mercado de fichajes, calendarios, parrillas y ratings) funciona sobre un mundo inventado de series y pilotos ficticios, con su propia CI. Publicado para revisión, no para reutilizar.