Cómo entrené robots pixel art con una red neuronal en JavaScript

Durante estos últimos días me he encontrado trabajando en el frontend de Artisanal Brew como parte del desarrollo de mi portafolio personal. Pensé en implementar algunas de las últimas propuestas que se han venido desarrollando en Ethereum, como lo son los ERC-4337, ERC-8004, ERC-7683 y ERC-8183.

Por qué pagos agénticos, y por qué robots

Estos protocolos tienen algo en común: habilitan pagos agénticos, es decir, transacciones que la propia wallet firma sin que un humano intervenga en cada una, y que además patrocinan (sponsorship) los fees de gas. Eso me hizo preguntarme de qué otra forma podía representar ese tipo de interacción en el home actual.

Al inicio el proyecto era simplemente un storefront: comprabas artículos con Sepolia Tokens, recibías tu voucher por correo, y también podías hacer staking de tokens que viven en esa misma testnet. Pero conforme fui avanzando e implementando más funcionalidad, empecé a querer algo que se adaptara mejor a lo que el proyecto se estaba convirtiendo.

De cabeza de monitor a un crew con más carácter

La versión 1 del crew ya existía, pero no se parecía en nada a la de ahora: la cabeza era prácticamente un monitor CRT (pantalla verde fosforescente y cuerpo color crema), más cercano a una vieja computadora de escritorio con patas que a un personaje con personalidad. Funcionaba para probar las animaciones básicas en loop, pero se sentía plano y le faltaba esa vibra retro-futurista que buscaba para la experiencia del hero.

Para transformar esa versión inicial, le pedí un concepto 3D pixelado al modelo GPT 5.6 Sol. El resultado superó mis expectativas: una cabeza esférica pulida, proporciones metálicas mejor definidas y una expresión simpática. Usé este diseño como plano maestro de referencia para rediseñar desde cero todo el crew en 2D, logrando que los robots tuvieran identidad propia y lucieran vivos en la interfaz.

¿Y si los hiciera recogerlas?

Originalmente los cuatro robots se ubicaban en las cuatro esquinas de la pantalla y flotaban ahí, estáticos, para siempre. Había monedas repartidas por el fondo, y me pregunté: ¿y si hiciera que las recogieran? Lo primero que se me ocurrió fue programar cinco escenarios distintos, cada uno con las monedas repartidas de forma diferente, y rotar el escenario en cada refresh. No me convenció: seguía siendo una coreografía fija, no una decisión. Fue ahí cuando le pregunté a mi mejor amigo Claudio (mi alias para la familia de modelos de lenguaje de Anthropic) qué método de entrenamiento le convenía más a este proyecto:

El entrenamiento

Cómo implementé Evolution Strategies

Evolution Strategies cabe en una frase: en cada generación pruebo variaciones aleatorias de los pesos, puntúo cada una y muevo los pesos originales hacia las que salieron mejor. Lo que me gustó fue lo poco que hace falta para implementarlo.

El trainer es un script de Node sin dependencias de machine learning. Los 258 parámetros viven en un Float64Array llamado theta, el simulador es una función que recibe ese arreglo y devuelve un número, y el entrenamiento completo es un for de 300 generaciones alrededor de este ciclo:

Traducido a código, ese ciclo son ocho líneas:

for (let k = 0; k < population / 2; k++) {
  const eps = gaussianNoise(parameterCount);

  returns[k] = evaluate(theta + sigma * eps);
  returns[k + population / 2] =
    evaluate(theta - sigma * eps);
}

const shaped = rankNormalise(returns);
theta += learningRate * estimateGradient(shaped);

Con una población de 64, el bucle sólo da 32 vueltas: cada una genera un vector de ruido gaussiano eps del mismo tamaño que theta y lo usa dos veces, en ambas direcciones. Eso es el muestreo espejeado, y en código me salió gratis, un solo gaussianNoise() por par, escalado por un sigma de 0.1, que es cuánto se le permite moverse a cada peso en la prueba.

Comparar cada versión contra su opuesta es lo que me deja distinguir si el cambio ayudó de verdad o si sólo tuvo suerte. Del otro lado, evaluate() es toda la interfaz con el simulador: le paso los pesos, corre tres episodios completos y me devuelve el promedio. El trainer no sabe nada de monedas, tazas ni colisiones.

Las dos últimas líneas son la actualización. rankNormalise tira las magnitudes y se queda sólo con el orden: reemplaza los 64 retornos por su posición dentro del grupo, repartida de forma pareja entre -0.5 y 0.5.

La actualización final

Después estimateGradient multiplica cada ruido por la puntuación ya normalizada, suma los 64 vectores y divide entre población por sigma. El resultado tiene la misma forma que theta, se escala por el learning rate de 0.03 y se suma. No hay gradientes reales ni tensores en ningún punto: son sumas y multiplicaciones sobre arreglos planos.

Dos detalles de implementación

• El tablero cambia en cada generación. Vuelvo a sortear la posición de los objetos, así que ningún individuo se evalúa sobre el mismo tablero que el anterior. La red no puede memorizar un acomodo específico de monedas y tiene que aprender una estrategia que funcione en escenarios distintos.
• Trainer y navegador importan el mismo pixelCrewSim.js. La física, las observaciones, las recompensas y el cálculo de la red están definidos en un solo lugar. Así evito que ambos entornos se comporten de manera ligeramente distinta, un error difícil de notar porque los pesos cargan y los robots se mueven, pero no tan bien como durante las pruebas.

La economía de las tazas

Las monedas siempre están en el campo; las tazas no. Esa asimetría es lo que convierte al café en una decisión y no en otro objeto que recoger: una taza sólo vale la pena si el desvío cuesta menos de lo que devuelve el boost, y puede expirar antes de que el robot llegue. La primera versión pagaba 0.4 por taza y las dejaba visibles 7–12 segundos, y el crew las ignoraba olímpicamente: 46% de captura.

Mi primera reacción fue que la recompensa era muy baja. Estaba a medias: el problema de fondo era geométrico. El crew cruza la pantalla completa en unos 10.6 segundos, así que una taza que aparecía del otro lado no se podía alcanzar dentro de una ventana de 7 segundos. La política tenía razón en ignorarla (la recompensa era inalcanzable, no estaba subvaluada). Corrí un barrido de 120 generaciones por configuración:

export const SHAPE = [13, 16, 2];
export const GENERATIONS = 300;

export const WEIGHTS = {
  untrained: [-0.0314, 0.0821, -0.0105, 0.0442, ...], // Baseline azaroso
  early:     [0.1284, -0.4501, 0.3892, -0.1042, ...], // Gen 20
  trained:   [0.4812, -0.8910, 0.7321, -0.3129, ...]  # Gen 300 final
};

La composición del Hero

La página separa la experiencia en tres planos. Esa decisión evita el problema habitual de los fondos animados: que una partícula o un personaje pase por encima del título y lo vuelva ilegible.

Z 1FondoZ 2CrewZ 3Contenido

01 Fondo ambiental

GlobalScene conserva ambos planos con data-permanent durante la navegación mejorada. El cielo no se reinicia, la paleta aleatoria no cambia al entrar a staking y las animaciones no vuelven al fotograma cero. Lo único que cambia es la capa visible, seleccionada mediante data-scene-route en el elemento <html>.

El background y sus cinco cielos

La base visual no es una imagen gigante. Parte de un negro café #100D0B y combina dos gradientes radiales muy tenues. Al iniciar una visita se elige una de cinco variantes; cada una cambia los brillos, la formación inicial del crew y la distribución de las monedas ambientales.

.gs-scene {
  --hero-glow-a: rgba(200, 155, 106, 0.11);
  --hero-glow-b: rgba(143, 185, 155, 0.08);
  background:
    radial-gradient(ellipse 62% 52% at 18% 14%,
      var(--hero-glow-a), transparent 70%),
    radial-gradient(ellipse 55% 48% at 82% 72%,
      var(--hero-glow-b), transparent 70%);
}

.ph-star {
  width: 11px;
  height: 3px;
  background: var(--star-color);
}

.ph-star::after {
  width: 3px;
  height: 11px;
  content: "";
}

Las dieciséis estrellas son cruces hechas con CSS y un pseudo-elemento; parpadean con duraciones y retrasos diferentes. Andrómeda queda al fondo con baja opacidad y un desplazamiento de 74 segundos. Los planetas y los badges de Ethereum, Solana y BNB usan movimiento escalonado y image-rendering: pixelated para conservar bordes duros.

De coreografía a simulación

La primera versión movía cada robot con un keyframe de 90 segundos. Su moneda estaba colocada exactamente en el destino de esa animación y desaparecía cuando el reloj decía que el robot había llegado. Parecía una recolección, pero ningún objeto percibía al otro.

Ese truco se rompía al arrastrar un robot: había que mover también su moneda para que la coreografía siguiera coincidiendo. La simulación eliminó ese acoplamiento. Ahora soltar un robot es simplemente cambiar su posición; la política vuelve a observar y continúa desde ahí.

Un mundo normalizado para desktop y móvil

La física vive en un cuadrado normalizado de 0 a 1. El runtime transforma esas coordenadas a píxeles al renderizar. Por eso la misma política funciona en un teléfono y en un monitor ancho sin entrenar dos modelos.

export const OBS_SIZE = 13;
export const ACT_SIZE = 2;
export const EPISODE_STEPS = 1800;

export const PARAMS = {
  accel: 0.6,
  drag: 0.7,
  maxSpeed: 0.12,
  respawnSeconds: 5.5,
  bagBoost: 1.4,
  bagBoostSeconds: 6,
  bagReward: 0.9,
};

Cada robot reclama su propia moneda. La asignación se mantiene hasta que esa moneda desaparece, evitando que cuatro agentes se amontonen sobre el mismo objetivo. Las tazas aparecen durante ventanas aleatorias de 12 a 20 segundos y dan un aumento de 40% a la velocidad máxima durante seis segundos. La política debe decidir si el desvío compensa.

Cómo aparecen las monedas

El mundo inicia con siete monedas activas en puntos aleatorios. spawnPoint rechaza cualquier coordenada dentro del rectángulo ocupado por el copy, así que una moneda puede cruzar detrás del título cuando la lleva un robot, pero nunca aparece estacionada sobre el texto.

Al tocarla, la moneda deja de estar viva, suma una unidad a la recompensa y recibe .is-collected. Su imagen sube 14 píxeles, se reduce y desaparece durante 360 ms. Permanece oculta 5.5 segundos; después reaparece en una nueva posición válida y el runtime retira la clase.

if (distance(robot, coin) < PARAMS.pickupRadius) {
  coin.alive = false;
  coin.respawnAt = world.time + 5.5;
  world.collected++;
  reward += 1;
}

if (!coin.alive && world.time >= coin.respawnAt) {
  const point = spawnPoint(world);
  coin.x = point.x;
  coin.y = point.y;
  coin.alive = true;
}

.ph-coinbit.is-collected img {
  animation: coin-pop 360ms ease-out 1 forwards;
}

@keyframes coin-pop {
  from {
    opacity: 1;
    transform: translate3d(0, 0, 0) scale(1);
  }
  to {
    opacity: 0;
    transform: translate3d(0, -14px, 0) scale(0.3);
  }
}

Cómo funcionan las tazas de café

Las monedas son el trabajo; las tazas son la capa de dificultad. La diferencia es que las seis tazas no existen permanentemente. Cada slot arranca dormido con un tiempo de aparición distinto (escalonado a propósito, para que no aparezcan todas juntas en el primer segundo de la página). Cuando ese reloj vence, el simulador elige una posición nueva fuera del copy, activa la taza y le da una vida aleatoria de 12 a 20 segundos. Si nadie llega, expira y vuelve a dormir entre 6 y 18 segundos.

Nada de ese calendario está atado al crew, y ahí está justo la dificultad: un robot no puede planear alrededor de la taza, sólo puede reaccionar. Cuando alcanza una, gana un 40% de velocidad máxima durante seis segundos. El detalle que más me gustó al implementarlo es que el boost sube el techo, no el empuje: un robot cafeinado conserva la misma aceleración ingrávida y simplemente alcanza a planear más rápido. Así el café se lee como inercia y no como un tirón.

if (mug.alive && world.time >= mug.expiresAt) {
  mug.alive = false;
  mug.appearAt = world.time + randomBetween(6, 18);
}

if (!mug.alive && world.time >= mug.appearAt) {
  const point = spawnPoint(world);
  mug.x = point.x;
  mug.y = point.y;
  mug.alive = true;
  mug.expiresAt = world.time + randomBetween(12, 20);
}

El runtime traduce alive a la clase .is-live y CSS hace un fade de 220 ms. Si un robot la alcanza, añade .is-caught durante 900 ms, cambia al sprite de beber y activa .is-boosted durante seis segundos. Los zapatos sónicos muestran visualmente el aumento de 40% en la velocidad máxima.

.ph-scene--sim .ph-bag {
  opacity: 0;
  transition: opacity 220ms ease;
}

.ph-scene--sim .ph-bag.is-live {
  opacity: 0.92;
}

.ph-scene--sim .ph-bag.is-caught {
  opacity: 0;
}

Los tenis de Sonic

Un boost invisible es un boost que nadie cree. Necesitaba que se notara que ese robot va más rápido porque se tomó un café, así que le puse tenis: unos sneakers pixelados que el robot usa exactamente mientras dura la cafeína. Y lo bonito es que no tienen temporizador propio. El runtime ya mantiene .is-boosted durante toda la ventana de seis segundos, así que los tenis se cuelgan directo de esa clase: no hay dos relojes que se puedan desincronizar, hay uno solo y CSS lo obedece.

Los dos detalles que no eran obvios hasta que lo vi roto en pantalla: el clip-path y el sprite espejeado. Sin el recorte, los pies originales del robot se asoman por debajo de los tenis y quedan dos siluetas encimadas; con él, el sprite reemplaza limpiamente las últimas dos filas de pierna. Y como las puntas de los tenis son largas y apuntan hacia adelante, un robot que viaja a la izquierda necesita la variante -flip o parece que camina de reversa. Mientras nadie tiene café, los tenis están en display: none y no cuestan nada.

SWAP // 2.5s

GlobalScene.razor.css — los tenis viven de .is-boostedDesliza ↔

.ph-scene__shoes {
  display: none;
  background: url("images/pl-sonic-shoes.png")
    center bottom / contain no-repeat;
  image-rendering: pixelated;
}

.ph-scene__roam.is-boosted .ph-scene__shoes {
  animation: ph-sonic-shoes-dash 0.5s steps(2, end) infinite;
  display: block;
}

/* Sin este recorte, los pies originales del robot
   asoman por debajo y las dos siluetas chocan. */
.ph-scene__roam.is-boosted .ph-scene__actor {
  clip-path: inset(0 0 12.5% 0);
}

Inventario completo de assets

Este es el inventario del primer viewport y de la simulación del crew. La segunda pantalla de descubrimiento de producto es un componente independiente y no forma parte de esta lista.

Del modelo al navegador

El trainer escribe tres juegos de pesos (sin entrenar, temprano y final) en pixelCrewPolicy.js. El runtime importa ese archivo y la simulación compartida. En cada frame observa el mundo, ejecuta la red, integra la física y escribe posiciones con translate3d.

Deploy

Me faltaba la última pieza, y es la que más me interesaba resolver bien: qué pasa cuando todo esto se sube. Un hero con una red neuronal adentro tiene una forma nueva de romperse, los pesos pueden truncarse, alguien (yo) puede tocar la física y olvidar reentrenar, y nada de eso falla ruidosamente. Los robots se siguen moviendo; simplemente son peores de lo que dicen los números del post.

El modelo viaja dentro de la imagen

El hero no descarga un modelo de ningún lado. Cuando el entrenamiento termina, train_pixel_crew.mjs escribe los 258 pesos de cada checkpoint como literales en pixelCrewPolicy.js, y ese archivo entra al repositorio con un commit: el modelo entrenado es código fuente, se revisa en el pull request y se compara con diff como cualquier otro cambio. No hay modelo.bin, ni bucket de artefactos, ni servidor de inferencia. Después docker build lo copia dentro de la imagen del Web igual que copia los .css y los .png, y ahí está la propiedad que me importa: los bytes que el gate de CI verificó son exactamente los que el navegador termina descargando.

Así que lo que se ve al abrir la portada no es una grabación del entrenamiento ni una coreografía que lo imita. El navegador importa esos mismos pesos, el runtime ejecuta la red en cada frame sobre el mismo pixelCrewSim.js que usó el gate, y los robots que recogen monedas son los 258 números multiplicándose en vivo, en la máquina de quien visita. Si CI aprobó la política, la política aprobada es (literalmente, byte a byte) la que está moviendo al crew en pantalla.

Entrenamiento y deploy forman un solo contrato

La política no se entrena durante el deploy. Se entrena offline y sus pesos se versionan como código. A partir de ahí CI trata ese archivo como cualquier otro artefacto de producción: comprueba su forma, sus valores y su desempeño antes de construir la imagen.

1. Un push a main ejecuta restore, build, tests .NET y node tools/verify_pixel_crew.mjs.
2. El gate evalúa 100 seeds no vistas, exige al menos 300 generaciones, valida los 258 pesos de cada checkpoint y prueba la política a 20, 60 y 120 FPS.
3. GitHub Actions autentica con Azure mediante OIDC, sin credenciales estáticas, y construye la imagen Docker del Web en el runner.
4. La imagen se publica en Azure Container Registry con el SHA del commit; después se aplican migraciones EF Core usando un secreto leído de Key Vault.
5. Azure Container Apps actualiza el Web con una a dos réplicas y espera hasta 150 segundos por salud y por el contrato visual del Hero.
6. Si falla, el workflow restaura la imagen anterior. La etiqueta latest sólo se mueve después de que Web y Worker están sanos.

- name: Verify trained homepage policy
  run: node tools/verify_pixel_crew.mjs

- name: Wait for Web app health
  run: |
    curl --fail "https://$WEB_FQDN/health/ready"
    HOME_HTML=$(curl --fail --silent "https://$WEB_FQDN/")
    grep -q 'class="ph-hero' <<< "$HOME_HTML"
    grep -q 'id="ph-scene-root"' <<< "$HOME_HTML"

Comprobar sólo /health/ready demostraría que ASP.NET arrancó, no que la portada correcta fue desplegada. El segundo check busca el Hero y el contenedor de la escena en el HTML real. Es una verificación pequeña, pero conecta el release con la experiencia que el usuario debe recibir.