¿Puedes seguir desarrollando un juego generado con IA?

Que un juego se abra en el navegador no significa necesariamente que sea un proyecto que puedas seguir desarrollando. La siguiente pregunta útil es si alguien puede reproducirlo, explicar sus reglas y añadir una función sin romper la partida original. Compruébalo con una versión de referencia conservada y una extensión definida de forma precisa, no con una captura ni con la afirmación de que el código es editable. Este artículo define una prueba reproducible de continuación para un pequeño juego de recoger estrellas. No es un informe práctico completado: para este borrador no había proyecto fuente, ejecución de referencia ni parche de extensión disponibles. La necesidad de resultados reales sigue pendiente. Usa el protocolo para reunir la evidencia que falta; no interpretes sus criterios de aceptación como hallazgos sobre SEELE ni sobre ningún proyecto generado.

1. Identifica el proyecto y sus reglas originales

Usa un caso de prueba acotado: un juego para navegador de escritorio con movimiento mediante flechas, cinco estrellas para recoger, una partida de 30 segundos, victoria al recoger las cinco, derrota por tiempo y un reinicio limpio. Es el caso previsto, no una versión existente. Consigue el proyecto realmente editable, sus recursos, declaraciones de dependencias e instrucciones de inicio. Registra, si se muestra, la versión del generador o herramienta, la revisión del proyecto, el entorno de ejecución, el navegador y el sistema operativo.

Distingue los archivos fuente de una vista alojada o de un paquete compilado. Los recursos ausentes, las dependencias sin documentar o la imposibilidad de obtener las fuentes son hallazgos que deben registrarse, no lagunas que deban rellenarse silenciosamente. Si el proyecto proporcionado difiere del caso previsto, documenta sus reglas antes de elegir una extensión acotada equivalente. Conserva una copia intacta y otra de trabajo para que los cambios posteriores no borren la evidencia original.

2. Reproduce la referencia antes de reparar nada

Sigue las instrucciones proporcionadas en un directorio limpio. Guarda los comandos exactos, la salida de instalación, el registro de arranque y la consola del navegador. No inventes un comando porque el proyecto se parezca a un framework conocido. Si falla la configuración, conserva el error y registra por separado cualquier intervención. Una referencia reparada por la persona evaluadora es una referencia reparada, no un éxito sin matices del proyecto entregado.

Ejecuta cuatro escenarios: recoge una estrella y permanece en su posición; recoge las cinco; deja que se agote el tiempo; y reinicia después de cada final. Comprueba que cada estrella cuente una vez, que el movimiento se bloquee al terminar y que se restablezcan todos los estados de la partida. Anota acción, resultado esperado, resultado observado y revisión para cada escenario. Conserva los fallos con el mismo cuidado que las ejecuciones satisfactorias.

3. Sigue la regla que vas a cambiar

Localiza el código real o la lógica editable que conecta movimiento, detección de contacto, estado de recogida, contador mostrado y comprobación de victoria. Usa nombres de archivo o identificadores de evento reales en tus notas. Explica qué componente controla el temporizador y qué acción de reinicio lo restaura. Una explicación plausible de la IA no basta: compruébala frente al proyecto.

Busca contadores duplicados o lógica de reinicio repartida entre sistemas sin relación. Son cuestiones que revisar, no pruebas automáticas de una mala arquitectura. El objetivo práctico es identificar dónde corresponde el objeto de bonificación y qué comportamiento existente debe permanecer igual. Registra las dudas antes de solicitar el parche.

4. Añade una estrella azul de bonificación al mismo proyecto

Guarda la revisión de referencia y solicita este único cambio. El ejemplo separa deliberadamente el nuevo efecto sobre el tiempo del contador de recogida existente:

Amplía este juego existente con una estrella azul de bonificación. Al primer contacto durante una partida activa, elimínala y añade tres segundos al tiempo restante. No debe aumentar el contador de estrellas normales ni cambiar el umbral de victoria de cinco estrellas. Reiniciar restaura la estrella de bonificación. Una partida terminada no puede reactivarse. Conserva el movimiento, las estrellas normales, el tiempo agotado y todas las reglas de final originales. Identifica los archivos o eventos reales afectados antes de proponer el parche más pequeño. No sustituyas el juego ni recursos sin relación.

Revisa el cambio propuesto antes de ejecutarlo. Registra archivos o eventos modificados, dependencias añadidas y cualquier reestructuración. Pregunta por qué cambió un subsistema sin relación. Un juego independiente nuevo con un objeto azul no demuestra la continuación de la referencia, aunque su vista previa sea parecida. Conserva el parche junto con su explicación para que otra persona pueda revisar la misma versión.

5. Comprueba de nuevo el comportamiento anterior, los límites nuevos y la reversión

Repite todos los escenarios de referencia. Después recoge una vez la estrella de bonificación y permanece en su antigua posición: el tiempo debe aumentar una sola vez y el contador normal no debe cambiar. Reinicia, vuelve a recogerla y verifica el restablecimiento. Comprueba el contacto cerca del fin del tiempo y después de un final; el objeto nuevo no debe reanudar una partida terminada. Registra las suposiciones sobre el orden de los fotogramas si los eventos simultáneos pueden afectar al resultado.

Cuando falle una comprobación, guarda la revisión fallida y una secuencia breve de reproducción antes de pedir otra reparación. Vuelve a la referencia conservada y ejecuta de nuevo un escenario de referencia. Solo después de esa comprobación puedes informar de que la reversión se ha reproducido. Aquí no se ha establecido ningún parche exitoso, resultado sin regresiones, duración de reparación ni resultado de reversión.

Qué puede aportar SEELE y qué debe verificarse

SEELE describe un flujo de creación de juegos mediante lenguaje natural que incluye escenas, recursos y código de juego. Por ello, un pequeño juego generado es un punto de partida pertinente para esta prueba. Proporciona primero el brief breve y comprueba después qué entrega realmente el flujo actual: un resultado jugable, un proyecto editable, archivos fuente u otro artefacto. Estas entregas no son intercambiables.

En la etapa de continuación, proporciona el contexto del proyecto existente y el único requisito de la estrella de bonificación. Inspecciona el cambio resultante en lugar de asumir que una revisión en lenguaje natural conserva correctamente el estado. El acceso al proyecto, la compatibilidad con motores y los detalles de exportación deben confirmarse en la cuenta y el resultado reales. La descripción del producto permite intentar el flujo; no demuestra la reproducibilidad, arquitectura ni mantenibilidad de este proyecto.

La evidencia necesaria para una conclusión real

• Archivo del código original o proyecto editable, recursos necesarios y una revisión de referencia estable.
• Instrucciones de configuración reales, datos del entorno, salida de comandos y errores o reparaciones de inicio.
• Registro de escenarios de referencia y evidencia continua de ejecución para victoria, derrota y reinicio.
• Explicación vinculada al código o eventos reales, solicitud exacta de extensión y parche inspeccionable.
• Revisiones anteriores y posteriores, observaciones de regresión y límites, y una reversión reproducida.
• Una conclusión limitada a este proyecto y esta extensión, incluidos los fallos sin resolver.

Todos estos artefactos que contienen resultados faltan por ahora. Un cambio satisfactorio de la estrella de bonificación respaldaría una conclusión limitada sobre continuación, no una promesa sobre red, migraciones de guardado o desarrollo a escala de producción. Una entrega incompleta debe permanecer visible en el informe, en lugar de sustituirse por la conclusión genérica «el código de IA es editable».

Conclusión: reúne primero la evidencia para el siguiente cambio

Evalúa la continuación mediante un cambio que supere la revisión y las pruebas de regresión. Empieza con materiales reproducibles del proyecto, conserva las reglas originales y mantén la extensión lo bastante pequeña para detectar una modificación inesperada. El borrador actual proporciona ese método, no el resultado que falta: un veredicto práctico de mantenibilidad sigue bloqueado hasta disponer del proyecto, el parche y la evidencia de ejecución. Como siguiente paso, usa el brief del pequeño juego de recoger estrellas en SEELE y conserva la entrega real antes de solicitar la estrella de bonificación. Detente si faltan fuentes o falla la configuración, documenta el obstáculo y no trates una vista previa pulida como prueba de que el desarrollo puede continuar.

Preguntas frecuentes

¿Puede una vista alojada demostrar que un juego es mantenible?

No. Una vista alojada puede mostrar la jugabilidad observable, pero no demuestra que las fuentes estén completas, que la configuración sea reproducible ni las consecuencias de cambiar el código. Úsala como una parte del registro. Una afirmación sobre continuación también necesita materiales editables, una referencia conservada, un cambio inspeccionable y pruebas de regresión en el entorno previsto.

¿Necesito una persona programadora para realizar esta prueba?

Puedes registrar escenarios visibles para el jugador sin saber programar, pero una revisión fiable del código y las dependencias necesita a alguien familiarizado con el lenguaje o editor del proyecto. Separa esas responsabilidades. Pide a una persona cualificada que verifique el cambio real en vez de tratar una explicación segura de la IA o una pantalla inicial funcional como una revisión de arquitectura.

¿Qué ocurre si la extensión funciona pero la configuración sigue sin documentarse?

Informa de un éxito parcial, no de una entrega completa. La extensión puede funcionar en un entorno ya configurado mientras una persona desarrolladora nueva no logra reproducirla. Conserva la revisión satisfactoria, anota los pasos de configuración realmente utilizados y repítelos a partir de los materiales entregados antes de describir el proyecto como reproducible de forma independiente.