Convierte la idea en una prueba, no en una lista de deseos
Puedes crear un juego con IA definiendo un ciclo jugable, solicitando una implementación pequeña y comprobando el resultado antes de añadir más. Un prompt es una entrada, no una prueba de que las funciones solicitadas funcionen. Después de generar, la pregunta útil no es «¿parece un juego?», sino «¿puede el jugador realizar la acción, alcanzar el objetivo, perder de forma comprensible y reiniciar?».
Esta guía combina un ejemplo documentado de SEELE que se ha conservado con un brief didáctico independiente. El ejemplo dispone de un enlace jugable y grabaciones existentes; el brief didáctico no se ha generado ni probado para este borrador. Separarlos evita confundir un flujo plausible con un caso de éxito documentado.
Qué demuestra el ejemplo documentado de supervivencia zombi
El artículo original describe un registro de generación de SEELE de octubre de 2026 que solicitaba un juego de supervivencia zombi en primera persona con Three.js. Las funciones solicitadas incluían movimiento con bloqueo del puntero, armas de fuego, recarga, apuntar con la mira, agacharse, correr, recoger objetos y un minimapa.
La descripción de la grabación del resultado identifica una vista del arma en primera persona, indicadores de salud y munición, minimapa, contador de oleadas, enemigos y un aviso de recogida. La grabación de 21,5 segundos solo cubre parte de la primera oleada. Esos elementos visibles no demuestran por sí solos que funcionen la recarga, la acción de agacharse, todas las interacciones de recogida, una partida completa de cinco oleadas o la compatibilidad con otros navegadores. Estos son los límites del ejemplo publicado, no un nuevo informe de una prueba completada.
La imagen documenta el proceso mediante prompts de este proyecto concreto.
Abrir el proyecto jugable existente.
Copia un brief más pequeño para la primera versión
Usa el siguiente ejemplo didáctico si un juego de disparos tiene demasiados sistemas interdependientes para un primer intento:
Ejemplo didáctico, no una versión probada: crea Signal Run, un juego de navegador cenital de una sola pantalla. El jugador se mueve con WASD o las flechas, recoge tres baterías y llega a una salida visible. Muestra el contador de baterías y los controles. Un obstáculo se mueve horizontalmente entre dos puntos fijos. El contacto muestra una pantalla de derrota; llegar a la salida sin todas las baterías muestra un mensaje con el requisito. Recoger las tres y alcanzar la salida muestra una pantalla de victoria. R reinicia desde cualquiera de los resultados y restaura al jugador, las baterías, el contador y el obstáculo. Usa formas provisionales legibles. No añadas enemigos, armas, guardados, red, niveles adicionales ni pagos. Explica qué componentes del proyecto han cambiado y proporciona comprobaciones de movimiento, recogida, victoria, derrota y reinicio.
La creación de juegos mediante prompts de SEELE puede utilizarse en el paso del brief al prototipo. Los controles y el reinicio solicitados aún deben validarse en el resultado real; la redacción del prompt no los garantiza.
Paso 1: inspecciona el primer ciclo jugable
Antes de pulir el resultado, ejecuta la versión prevista y sigue los controles que aparecen dentro del juego. Comprueba el movimiento en todas las direcciones y confirma que no se puede salir del área de juego. Recoge una batería y vuelve a pasar por su antigua posición: el contador no debe aumentar dos veces.
Prueba la salida antes de tiempo y registra el mensaje. Completa la ruta de recogida y comprueba la victoria. Toca el obstáculo deliberadamente y comprueba la derrota. Reinicia después de ambos resultados. Si el obstáculo se reinicia pero las baterías no, comunica esa diferencia exacta en lugar de pedir a la IA que «arregle el juego».
Paso 2: usa el caso para crear un registro de verificación
Para cada función, mantén cuatro campos: comportamiento solicitado, evidencia disponible, comportamiento observado y estado. En el ejemplo zombi, un minimapa visible pertenece al campo de evidencia; el seguimiento preciso de la posición sigue sin verificarse hasta probarlo. Una solicitud de recarga permanece en el campo de especificación hasta poder registrar la acción y los cambios de munición.
Aplica la misma disciplina a Signal Run. «Se solicitaron tres baterías» no equivale a «tres objetos únicos se contaron correctamente». Marca los elementos dudosos como no verificados en lugar de llenar el vacío con una descripción categórica. Este registro permite hacer la siguiente petición más concreta y ofrece a los colaboradores una descripción fiable de la versión.
Paso 3: modifica una regla y repite el ciclo
Después de guardar una versión funcional, solicita un solo cambio: reducir un 20 % la velocidad del obstáculo conservando su recorrido y todas las reglas de recogida. Repite el mismo cruce desde el mismo punto de partida, compara los tiempos y vuelve a probar ambos estados finales.
Si el movimiento falla tras un cambio visual no relacionado, vuelve a la última versión conocida que funcionaba y acota la solicitud. Proporciona el error exacto, el entorno objetivo, el comportamiento esperado y la secuencia de reproducción más corta. Evita acumular reescrituras amplias sobre un fallo todavía inexplicado.
Paso 4: comprueba por separado la entrega técnica
Un enlace jugable no equivale a entregar el proyecto fuente. Antes de depender de una herramienta para continuar el desarrollo, comprueba el acceso al proyecto y las opciones de exportación del plan actual. Si el formato solicitado está disponible, guarda una copia versionada y enumera su punto de entrada, archivos fuente, recursos, manifiesto de dependencias, archivo de bloqueo e instrucciones de ejecución. Pregunta qué se generó, qué es una dependencia y qué requiere un servicio aparte. No publiques credenciales, direcciones privadas ni tokens de cuenta con el proyecto.
En una carpeta limpia independiente, sigue los comandos de instalación y ejecución documentados para ese motor o framework concreto. Registra la versión del entorno de ejecución y cualquier dependencia ausente. Repite movimiento, recogida, victoria, derrota y reinicio sin depender del espacio de trabajo alojado. Si falla la versión local o no hay exportación disponible, registra esa limitación; una vista alojada no cubre la falta de evidencia. En el ejemplo zombi conservado no se ha demostrado ninguna exportación de código fuente ni ejecución local.
Paso 5: prepara una publicación acotada y honesta
Antes de compartir, comprueba la carga desde cero, que los controles se lean, el audio si existe, el foco de teclado y el reinicio. Revisa las condiciones actuales de la herramienta y los recursos para el uso previsto. Prueba otro navegador o dispositivo antes de afirmar que es compatible. Vincula cualquier afirmación de rendimiento a hardware identificado y un método registrado, no a la aparente fluidez de un clip incrustado.
Empieza tu propio prototipo pequeño en SEELE con el brief anterior. Conserva la versión funcional, el prompt exacto y las notas de prueba antes de pedir más. El objetivo es un ciclo verificado, no una lista larga de funciones: una persona nueva puede moverse, entender el objetivo, alcanzar ambos resultados y reiniciar. Añade niveles y recursos más elaborados solo cuando puedas demostrar ese ciclo sin explicaciones de su creador. Si continuar fuera del espacio de trabajo es importante para el proyecto, trata la entrega del código fuente y la ejecución local limpia como criterios de aceptación independientes, no como suposiciones sobre la vista previa.
Matriz de evidencia y aceptación
Esta matriz organiza las comprobaciones propuestas en el artículo. No es un informe de una prueba completada.
| Afirmación o tarea | Qué establece la fuente o el brief | Qué falta por comprobar |
|---|---|---|
| Ejemplo de supervivencia grabado | El artículo describe una grabación breve e identifica los indicadores y enemigos visibles. | No deduzcas el comportamiento de una partida completa ni la compatibilidad del navegador a partir de un clip corto. |
| Ciclo jugable | El brief didáctico propone una acción, un objetivo, una derrota y un reinicio. | Ejecuta cada comportamiento en la versión real y registra el resultado. |
| Revisión | El flujo solicita un cambio acotado. | Repite las comprobaciones de referencia después de aplicar el cambio. |
| Entrega técnica | La entrega es una etapa independiente del flujo. | Inspecciona los archivos reales, las instrucciones de configuración y el uso permitido. |
Preguntas frecuentes
¿Puede un vídeo breve demostrar que todo el juego funciona?
No. Solo respalda lo visible durante el intervalo grabado. Pueden aparecer indicadores sin que todas las reglas subyacentes sean correctas. Usa una lista de funciones, entradas reproducibles y grabaciones dirigidas más largas para establecer el comportamiento. Mantén la distinción entre un vídeo del proceso, una vista de apariencia y una prueba de juego completada.
¿Necesito entender todos los archivos generados?
Necesitas entender lo suficiente para probar el juego, proteger las versiones funcionales y localizar los cambios relevantes. Pide al asistente que explique componentes y supuestos en lenguaje sencillo. Para comportamientos específicos de un motor que no conozcas, consulta su documentación actual. No aceptes una reescritura amplia solo porque la explicación suene técnicamente convincente.
¿Cuándo debería sustituir el arte provisional?
Después de que el ciclo sea legible y repetible. Sustituye los recursos en grupos pequeños y vuelve a comprobar colisión, escala, contraste, carga y derechos. Los medios atractivos pueden mejorar la comunicación, pero no verifican una mecánica no probada. Identifica con honestidad las imágenes conceptuales en lugar de presentarlas como capturas de un resultado generado y funcional.
Elija un flujo de trabajo para el próximo hito jugable
Utilice un creador de juegos cuando la siguiente decisión pueda probarse en un bucle reproducible en el navegador. Si un proyecto ya tiene un motor, recursos o una base de código, pruebe un asistente en un cambio limitado dentro de ese entorno. Mantenga una lista de verificación de recursos y exportación junto con las notas de la prueba de juego para que un resultado reproducible y un proyecto portátil puedan evaluarse por separado.
