La arquitectura de compilación y ejecución toma forma
El segundo día conecta formalmente el "mundo del juego" con la "pantalla": el puente ECS↔render se ejecuta, un punto de referencia establece un criterio para el rendimiento, el shell frontal de Studio aparece por primera vez y el agente de chat desarrolla un sistema de comando y una compactación de contexto más inteligente. La base pasa de "poder dibujar un marco" a "un tiempo de ejecución que realmente gira".
Del "puedo dibujar un marco" al "la arquitectura toma forma"
Si el primer día respondió "¿se puede dibujar correctamente un píxel en el navegador?", este día responde a la siguiente pregunta: de dónde viene la imagen. Lo que realmente se mueve en un juego es un modelo mundial llamado ECS (Entidad-Componente-Sistema): cada personaje, accesorio y cámara es una "entidad", y su posición, apariencia y comportamiento los deciden "componentes" y "sistemas". Con renderizado pero sin modelo mundial, el motor es solo una herramienta de dibujo; con un modelo del mundo pero sin representación, el mundo permanece invisible. El hilo conductor de este día conecta esas dos mitades y, junto con ello, defiende la arquitectura general de construcción y tiempo de ejecución, el shell frontal y varias capacidades fundamentales del agente, para que cada eslabón de la cadena de "generar un juego mediante conversación" comience a tomar forma.
El puente ECS↔render: conectando el mundo a la pantalla
El paso más importante de este día fue producir una primera versión funcional del puente entre el mundo ECS y el renderizador. Lo que resuelve suena sencillo pero es absolutamente fundamental: hay una "entidad" en el mundo que lleva componentes como posición, orientación, malla y material. ¿Cómo sabe el renderizador en qué parte de la pantalla y de qué forma dibujarlo? El puente es ese canal de traducción: cada cuadro convierte el estado del modelo mundial en comandos de dibujo que el renderizador entiende. Con él, colocar un objeto en movimiento en el mundo hace que realmente aparezca y se mueva en la pantalla, sin necesidad de escribir a mano ningún código de dibujo. Este es el punto de inflexión en el que el motor pasa de "dos subsistemas no relacionados" a "un todo que gira"; Cada experiencia posterior de "colocar un objeto y aparecerá en la pantalla" se remonta al puente conectado este día.
Un punto de referencia de doble implementación: un criterio para medir el desempeño
En las rutas críticas de un motor suele haber más de una forma de implementar algo, cada una con su propia velocidad y compensaciones. Este día se construyó una sonda de "punto de referencia de implementación dual": hacer lo mismo de dos maneras diferentes y medir su costo real uno al lado del otro. El valor no es quién ganó una sola carrera, sino que el desempeño ya no se basa en conjeturas: cualquier presentimiento de que "escribirlo de esta manera podría ser más rápido" se puede medir en el acto con el mismo criterio, evitando una decisión aparentemente inteligente que en realidad es más lenta. Para un motor destinado a evolucionar a largo plazo y funcionar en todo tipo de dispositivos, establecer primero "cómo comparar el rendimiento objetivamente" es como asignar un árbitro a cada optimización futura, por lo que lo rápido y lo lento tienen evidencia detrás.
Nace el front-end de Studio
Ese día también se produjo un hito: el front-end de Studio obtuvo su primera versión preliminar. Hasta entonces, toda la capacidad vivía del lado del motor y de la línea de comando; pero lo que realmente enfrenta el usuario final es una interfaz web que puede abrir, chatear y ver la imagen de la derecha. El caparazón inicial que se levantó hoy es el "punto de partida esquelético" para el panel de chat, la ventana de vista previa y varios bancos de trabajo por venir. Está vacío por ahora, pero lo importante es que el producto comienza a converger de "un montón de capacidades" hacia "una forma utilizable". Por un lado, una base de motor cada vez más sólida, por el otro, una interfaz que comienza a tomar forma; durante las próximas semanas, los dos se acoplarán al Studio.
El agente desarrolla un sistema de comando: un borrador + /contexto
El agente de chat dio un paso "de una simple conversación a comandos" este día: llegó un borrador de diseño para un sistema de comandos, y primero se fijaron las especificaciones para el comando /context. Un sistema de comando brinda a la "colaboración con la IA" un conjunto de atajos predecibles y reutilizables; en lugar de describir una acción frecuente en una oración indirecta cada vez, un comando la activa con precisión. /context, el primer comando que se especificará, aborda exactamente lo que más importa en sesiones largas: "qué contexto tiene el modelo actualmente". Establecer primero la forma del sistema de comando y su primer comando significa que los comandos posteriores pueden crecer a partir del mismo estándar, en lugar de que cada uno se escriba a su manera y entre en conflicto.
Autocompactación más inteligente: por herramienta, por espacio inactivo
Tras largos intercambios con la IA, el contexto acumulado se hace cada vez más largo, lo que ralentiza las respuestas y aumenta los costos; pero una compactación tosca desperdicia información útil. Este día agregó dos puntos de inteligencia a la compactación de contexto: uno, trátelo "por herramienta": los resultados de diferentes herramientas importan de manera diferente, por lo que puede decidir por herramienta qué recortar y qué conservar en lugar de una talla única para todos; dos, activarlo "por espacio inactivo": haga la compactación en las ventanas cuando no esté esperando un resultado, ocultando el costo en momentos que no notará en lugar de cuando más desea una respuesta rápida. Juntos permiten que largas sesiones sigan adelgazando mientras te molestan lo menos posible. Esta cuidadosa explicación de "cómo gestionar el contexto del modelo" es exactamente donde esta plataforma trata las cosas como ingeniería real desde el principio.
Robustez en utillaje y terminal: fetch, llaves, bus de eventos
Este día también se pusieron en orden una serie de detalles que hacen que el uso diario sea menos propenso a desviarse. Ambos modos de la herramienta de búsqueda web se volvieron más estables: los mensajes de error del modo profundo son más específicos y más fáciles de diagnosticar, mientras que el modo directo tiene prohibido instalar componentes adicionales por sí solo, lo que hace que su comportamiento sea más controlable. El movimiento del cursor en la terminal (inicio/fin de línea) se trasladó a un enrutamiento de teclas más claro, por lo que el enfoque y las pulsaciones de teclas se alinean con mayor precisión. El bus de eventos solucionó un bucle de autoamplificación donde el error de un observador desencadenaba nuevos errores que se acumulaban sobre sí mismos; una vez que eso sucede, los registros explotan instantáneamente, por lo que es importante cortarlos en la fuente. Ninguna de estas son características nuevas y llamativas; son el trabajo de crear poco a poco "no se siente difícil de usar".
Instalación y puesta en marcha más sencillas
Dado que el objetivo es "ejecutarse localmente en minutos", el camino de instalación e inicio no puede estar lleno de obstáculos. Este día reorganizó el flujo de inicio en módulos, lo hizo compatible con una versión más nueva del administrador de paquetes, agregó "instalación automática como alternativa cuando falta el tiempo de ejecución" y alineó el script de limpieza con las mismas convenciones. Para una plataforma que quiere que más personas (incluidos desarrolladores no profesionales) comiencen, cuanto más sencillo sea el camino "desde la clonación hasta la visualización de la imagen", más baja será la barra. Pavimentar ese camino temprano salva a todos los que luego quieran probar una serie de problemas potencialmente desagradables.