Crear Clean Break: un juego de puzles 3D con OpenGame

Juega a Clean Break, un juego de puzles para navegador con seis niveles creado en OpenGame Studio. Apunta al mecanismo, cambia el movimiento de sus piezas y lleva la caja marcada hasta la zona de recuperación sin dañar la máquina azul. Dispones de tres disparos por intento. La interfaz del juego está en inglés.

El patio de entrenamiento de la V16 publicada. La captura corresponde al juego real.

Llegar hasta aquí requirió 16 tareas de generación, varias rondas de pruebas en el navegador y correcciones tanto del juego como de la plataforma. Este artículo explica cómo definimos el primer puzle, encontramos problemas al jugar y convertimos esas observaciones en solicitudes de cambio útiles.

Empieza con una decisión que se entienda

Antes de Clean Break probamos un juego de reparto. Las rutas y los objetivos funcionaban, pero al creador le parecían estrechas las calles y poco convincente la conducción. Añadir decorado no solucionaba eso. Dejamos esa dirección y elegimos otra interacción.

En Clean Break, el jugador observa un mecanismo desde una perspectiva fija, decide dónde disparar y contempla las consecuencias. Al eliminar el movimiento del personaje y la cámara libre, podíamos concentrarnos en menos controles.

El primer diseño seguía siendo demasiado simple: acertar en un único pasador para ganar de inmediato dejaba poco que descubrir. Durante la conversación en Studio lo transformamos en un problema de equilibrio con dos pasos: cambiar el equilibrio de la viga y después soltar la caja. El orden incorrecto debía producir una consecuencia distinta y comprensible.

También acotamos la simulación a bisagras, soportes, gravedad y movimiento guiado. No habíamos verificado la disponibilidad de un motor general de destrucción con cuerpos rígidos. Ese límite condicionó los puzles que podíamos pedir razonablemente.

Define la SPEC antes de generar

Discutimos el diseño en la conversación real de Studio y confirmamos la SPEC antes de solicitar la primera versión. Las condiciones eran concretas:

• Cámara oblicua fija que mostrara el mecanismo y el destino.
• Puntería libre con el ratón y un máximo de tres disparos.
• Caja marcada, zona de recuperación y máquina azul protegida.
• Resultados distintos según las decisiones de disparo y su orden.
• Reinicio inmediato, incluso mientras se mueven los objetos.
• Un paquete del juego descargable.

Este prompt inicial en inglés resume el diseño. Es una plantilla reutilizable, no la transcripción del primer prompt ni una garantía de obtener V16 en una sola generación.

Discuss a small English-language 3D puzzle game before generating code.

The player inspects a mechanism from a fixed oblique camera, aims,
and fires up to three shots. The goal is to move a marked crate into
salvage without hitting a protected blue machine.

Start with one puzzle requiring two consequential actions.
A wrong order must have a visible, understandable consequence.
Success must follow the crate's position and contact with objects.

Explain which support, hinge, gravity, and collision behavior the
available runtime can reliably support. Keep the simulation bounded.

Define the controls, win and loss conditions, last-shot resolution,
reset behavior, and downloadable output. Return a SPEC for review
before generating the game.

Lo más útil son los criterios de aceptación: permiten comprobar algo más que la aparición de una escena.

Prueba el primer puzle de varias formas

Tras la primera generación jugamos en el sitio con ratón y teclado reales. Probamos la secuencia correcta, la incorrecta y un fallo deliberado seguido de los dos disparos útiles.

Este último caso importa: gastar el último disparo no debe provocar una derrota inmediata si la caja todavía se está desplazando hacia su destino.

También reiniciamos durante el movimiento e hicimos clic rápidamente para comprobar si el juego gastaba munición adicional mientras resolvía una acción. Así verificábamos las reglas que rodeaban al puzle, además de su solución.

La primera versión tenía una cadena causal funcional, pero la escena era oscura y el cañón quedaba parcialmente fuera de pantalla. Pedimos una revisión centrada en la legibilidad. Después, una ventana alta reveló que el límite de distancia de la cámara dejaba fuera la zona de recuperación. Eso se convirtió en una corrección independiente.

El proceso era: jugar, describir el fallo observado, pedir un conjunto coherente de cambios y volver a jugar la nueva versión.

Amplía después de validar el núcleo

Pasamos de un puzle a tres y luego a seis. Una generación completada no significaba que cada nivel nuevo fuera jugable.

En el segundo patio, la caja no se deslizaba por la ruta prevista. Leer el código descargado ayudó a explicar lo observado: la pendiente era insuficiente para la fricción configurada. Un pasador podía caer sobre la máquina protegida, y el puente necesitaba más espacio libre.

Enviamos esas observaciones a Studio. El sitio generó la siguiente revisión; no subimos un juego reparado localmente para presentarlo como resultado de Studio.

El quinto patio necesitó dos intentos de reparación. El ángulo de un mecanismo articulado y la posición inicial de la segunda caja eran incorrectos. La solución correcta seguía fallando y una ruta supuestamente incorrecta no se comportaba como estaba previsto. V11 fue la primera versión en la que completamos los seis patios.

“Arregla la física” era demasiado amplio. Un informe útil identifica el nivel, las acciones, el resultado visible y la comprobación que debería superar la corrección.

Redacta los cambios a partir de lo observado

Una revisión visual posterior introdujo un problema de transición: al pulsar Continue, algunas piezas sueltas del patio anterior permanecían en el siguiente. Probar los niveles por separado podía ocultarlo.

Este fragmento procede de la solicitud real para V14:

After clearing L1 and pressing Continue, its fallen counterweight and latch remain visible in L2. More detached pins/latches accumulate in L3-L6. This is not intentional salvage dressing.

La petición concretaba el comportamiento esperado: retirar los objetos sueltos al abandonar su nivel, restaurar el mecanismo al regresar y conservar las piezas móviles mientras su patio siguiera activo.

Esta plantilla en inglés ayuda a estructurar una revisión:

Baseline: identify the saved version you just played.

Observed problem: name the scene and visible symptom.
Reproduction: give the actions that produce it.
Expected result: explain what should happen instead.
Scope: identify the related changes for this revision.
Acceptance: list the routes, retries, and transitions to replay.

Return the revised SPEC for confirmation before generating.

Una petición acotada hace que la iteración sea comprensible. No garantiza que una revisión generativa deje intactas todas las demás líneas de código. Hay que volver a comprobar lo que ya funcionaba.

Mantén visible la mecánica al añadir decorado

V13 ya incluía los seis patios. La última revisión cambió el aspecto conservando la estructura prevista de los puzles.

El detalle también puede estorbar. En el sexto patio, una viga decorativa tapaba partes importantes y algunas etiquetas se superponían. Pedimos un primer plano más abierto y etiquetas colocadas según su tamaño real, con líneas que señalaran claramente cada objeto.

Solo después de completar la campaña probamos el estilo de taller de juguete de V16: colores más claros, cajas expresivas y pequeños accesorios. Los modelos siguen basándose en geometría sencilla. Aceptamos la mejora y dejamos de hacer grandes revisiones gráficas. Ambas imágenes proceden de partidas reales, no de ilustraciones conceptuales.

Distingue los errores del juego de los fallos de la plataforma

Algunos problemas exigían otra versión del juego; otros pertenecían a OpenGame. Corregimos un tiempo de espera de las cabeceras de respuesta del proveedor y un error al comprimir conversaciones largas en el sistema de generación. En el sitio, corregimos la clasificación de descargas interrumpidas y añadimos una comprobación de resultados ya guardados después de un fallo.

V14 dejó clara la diferencia: la tarea había fallado y se habían devuelto los créditos, pero existían archivos utilizables. Los recuperamos a través del sitio y verificamos la vista previa y el ZIP. El fallo original y el reembolso siguieron registrados.

También cometimos un error evitable: pedir otra revisión antes de recuperar V14. V15 devolvió contenido sin cambios y falló. Aunque se reembolsaron los créditos, perdimos otros 13 minutos esperando.

Conviene investigar antes de repetir. Un resultado guardado pero inaccesible, un error de generación y un nivel imposible de completar requieren respuestas distintas.

Cuánto costaron las iteraciones

Estas cifras cubren solo Clean Break, sin el experimento anterior de reparto.

| Medida | Resultado | | --- | --- | | Tareas de generación | 16 | | Completadas inicialmente | 11 | | Fallidas inicialmente | 5 | | Duración acumulada de las tareas | 2 horas, 43 minutos y 54 segundos | | Tiempo de tareas fallidas | 50 minutos y 53 segundos | | Créditos cobrados / devueltos / netos | 160 / 50 / 110 | | Versión publicada | V16 |

La duración va desde la creación de la tarea hasta su finalización o fallo. Incluye llamadas al modelo, herramientas, validación y guardado. No incluye discusión, pruebas, diagnóstico ni reparaciones de la plataforma, por lo que no es el total de horas de producción.

V14 sigue contando como fallo inicial aunque después recuperáramos el resultado. Los créditos son unidades de uso de OpenGame, no un cálculo del coste del proveedor del modelo.

Una modificación pequeña también podía tardar mucho porque el flujo escribía un archivo completo del juego. Por eso eran importantes las solicitudes precisas y las pruebas intencionadas: una iteración innecesaria suponía otra espera considerable.

Termina comprobando la campaña y la entrega

Pantalla final tras completar las seis rutas correctas de V16.

Antes de cerrar el trabajo completamos los seis niveles de V16, descargamos el ZIP original, publicamos mediante Studio y comprobamos que el juego arrancara en su página pública.

V14 había pasado pruebas adicionales de órdenes incorrectos, victoria con el último disparo, reinicio en movimiento, transiciones y distintos tamaños de ventana. No repetimos todos esos casos límite en V16. Tampoco validamos formalmente la duración para un jugador nuevo ni la persistencia del progreso al recargar.

Clean Break es un ejemplo publicado y jugable, con un paquete descargable para continuar el desarrollo. El arte y la cobertura de pruebas todavía pueden mejorar.

Aplica el proceso a tu propio juego

1. Define una decisión y su consecuencia visible.
2. Confirma la SPEC antes de generar.
3. Prueba una ruta ganadora, una perdedora y un reinicio.
4. Describe los fallos con acciones reproducibles.
5. Pide una revisión coherente y vuelve a comprobar los comportamientos afectados.
6. Amplía el contenido cuando la interacción principal funcione.
7. Verifica el juego final y su exportación antes de darlo por terminado.

Juega a Clean Break y abre OpenGame Studio para plantear un puzle original. También puedes explorar otros juegos de navegador con ciclos de juego completos. El prompt ayuda a iniciar la conversación; el resultado final llegó mediante las iteraciones posteriores.

Nota de producción: este caso se basa en sesiones de Studio del 26–27 de septiembre de 2026, prompts guardados, registros de tareas, versiones descargadas y pruebas en el navegador. Las capturas indican la versión. La creación y las revisiones del juego se hicieron en Studio; las reparaciones de la plataforma fueron trabajo de ingeniería independiente.