Define una inmersión submarina que pueda volver a la superficie

La supervivencia submarina es más fácil de prototipar cuando el jugador tiene una ruta, un objetivo de recuperación y dos límites claros. Empieza con un muelle de superficie, una repisa y una fosa. Define cada coste de oxígeno y sellado antes de pedir una versión. Esta ruta ficticia de seis acciones permite revisar tanto una vuelta segura como los casos de derrota.

Blueglass Reach es un diseño ficticio original que se usa como ejemplo didáctico calculado a mano. No se ha ejecutado ningún prompt ni existe una versión jugable o prueba. Sus valores de oxígeno y sellado son reglas de juego, no recomendaciones de buceo. NOAA aporta únicamente el hecho físico general citado más abajo.

Haz que la primera inmersión sea el alcance

Un primer prototipo submarino no necesita mapa mundial, economía de oxígeno, construcción de bases ni varias especies marinas. Necesita un viaje breve en el que el jugador entienda qué puede hacer, qué cuesta cada acción y qué debe traer de vuelta. Blueglass Reach reduce el alcance a tres ubicaciones conectadas, una cápsula y un regreso al muelle.

Mantén la ruta lo bastante pequeña para inspeccionarla como una secuencia de lugares, sin coordenadas. D0 es el muelle superficial Moon Pool. D1 es una repisa rocosa entre el muelle y la fosa. D2 es la fosa Blue Trench, donde se encuentra la cápsula de reconocimiento. El único final victorioso exige regresar a D0 llevándola.

Este es un segmento de un jugador y una sola inmersión. Excluye deliberadamente roles cooperativos, progreso persistente, asentamientos conectados, fabricación y un ciclo de recursos renovables. Esos sistemas ampliarían la simulación antes de que la ruta básica se pudiera revisar. Primero comprueba si una sola inmersión se entiende y permite regresar.

Especifica los costes de oxígeno y presión antes del prompt

Define el estado inicial y el orden de las acciones antes de pedirle a una herramienta que construya una escena. En este ejemplo, el buzo empieza en D0 con oxígeno 8/8, sellado del traje 5/5, sin escaneo y sin cápsula. Cada acción válida cuesta una unidad de oxígeno. Si la acción empieza o termina en D2, también cuesta una unidad de sellado. Una unidad llega a cero y provoca derrota; después de cada acción, comprueba primero la derrota y luego la victoria por regreso.

La regla de exposición a profundidad es una ficha sencilla de juego, no una simulación de un buzo ni de su traje. La premisa física real es más limitada: NOAA indica que la presión del agua aumenta con la profundidad aproximadamente una atmósfera por cada 33 pies de descenso. Eso no valida los contadores ficticios de esta tabla ni ofrece pautas de seguridad para bucear. Explicación de presión de NOAA solo respalda la premisa física.

Resuelve cada turno válido en el mismo orden: resta un oxígeno, aplica el movimiento o cambio del objetivo, resta un punto de sellado si la acción empezó o terminó en D2 y, después, comprueba derrota antes que victoria.

La imagen marca la decisión exacta después de Recoger: la cápsula ya no está en su hueco, el buzo la lleva y la ruta hacia arriba sigue abierta. Los dos puntos de sellado restantes bastan para completar el regreso previsto.

Convierte las reglas en tres prompts de IA

No mezcles construcción del mundo, implementación y pruebas en una sola petición demasiado larga. Cada prompt de abajo tiene una función y un resultado que se puede inspeccionar. Son plantillas listas para adaptar, no informes de una generación ejecutada.

Prompt 1: solicita un contrato de implementación

Diseña un pequeño prototipo original de supervivencia submarina para un jugador llamado Blueglass Reach. Antes de escribir código, devuelve un contrato de implementación conciso limitado a esta ruta: muelle Moon Pool, repisa D1, fosa D2 y regreso con una cápsula. Estado inicial: D0, oxígeno 8/8, sellado 5/5, sin escaneo ni cápsula. Cada acción válida cuesta 1 oxígeno; una acción que empieza o termina en D2 también cuesta 1 sellado. Define precondiciones y coste para Move, Scan, Collect y Wait; el movimiento solo va a un vecino. Scan y Collect se permiten una sola vez en D2, y Collect requiere escaneo. Las acciones no válidas no cambian estado ni contadores. Tras una acción válida, resta oxígeno, aplica la acción, aplica el coste de sellado y comprueba derrota por cualquier recurso a cero antes de victoria por volver a D0 con la cápsula. Devuelve esquema de estado, orden de transición y casos de éxito y fallo calculados a mano. No añadas recargas, fabricación, oxígeno realista, criaturas, cooperativo ni sistemas persistentes.

Comprueba el contrato recibido contra el grafo de nodos y el orden de costes. Debe rechazar un salto directo de D0 a D2, un segundo escaneo y una recogida antes del escaneo sin cambiar contadores. Verifica que una acción en D2 paga solo un punto de sellado, incluso si empieza y termina allí.

Prompt 2: solicita el segmento jugable más pequeño

Con el siguiente contrato de Blueglass Reach, construye el prototipo jugable más pequeño de una inmersión en el entorno de juego disponible. Muestra un buzo en tercera persona y tres ubicaciones conectadas: muelle Moon Pool D0, repisa D1 y fosa Blue Trench D2. El jugador empieza en D0 con oxígeno 8/8, sellado 5/5, sin escaneo ni cápsula. Un movimiento avanza una conexión y cuesta 1 oxígeno; si empieza o termina en D2, cuesta además 1 de sellado. En D2 se puede escanear una vez y luego recoger una cápsula, con el mismo coste por acción. Esperar cuesta 1 oxígeno y, en D2, 1 de sellado. Una acción no válida no modifica el estado. Después de una acción válida, revisa primero si un recurso llegó a cero: eso es derrota. Solo con recursos positivos, volver a D0 llevando la cápsula es victoria. Muestra ubicación, oxígeno, sellado, escaneo y cápsula; permite reiniciar. Mantén cada acción visible y no añadas otros recursos ni objetivos.

Esta solicitud define las interacciones y señales necesarias para inspeccionar las reglas; no garantiza que una herramienta las implemente. Si más adelante recibes una versión real, prueba la ruta paso a paso, una acción no válida y el orden de derrota en cero. Registra los resultados observados por separado de las expectativas calculadas a mano.

Prompt 3: compara observaciones y solicita una reparación

Revisa la versión real de Blueglass Reach y las notas de ejecución que se proporcionan a continuación. No deduzcas un aprobado a partir del documento de diseño. Para cada caso, enumera estado esperado, estado observado, diferencia y si pasó. Comprueba: (1) intentar D0→D2 no cambia nada; (2) Scan en D2 cuesta 1 oxígeno y 1 sellado; (3) repetir Scan no cambia nada; (4) Collect antes de Scan no cambia nada; (5) tras Scan y Collect, el estado es D2, O4/8, S2/5; (6) la ruta D0→D1→D2→Scan→Collect→D1→D0 acaba en victoria con O2/8, S1/5; (7) una acción que lleva un recurso a cero causa derrota antes de cualquier victoria. Si una observación real contradice una regla, propone solo una corrección concreta y di qué casos se deben volver a ejecutar. Si faltan notas o no se puede acceder a la versión, marca los casos como no verificados y no inventes resultados.

El tercer prompt depende de la evidencia. Sin notas de una ejecución real, la respuesta correcta es una lista de comprobaciones no verificadas y ninguna afirmación de aprobado. Así la traza manual sigue siendo útil como objetivo de aceptación sin presentarse como resultado de un juego.

Comprueba en papel el regreso y los fallos

Antes de pedir código, recorre la ruta acción por acción. Empieza en D0 con oxígeno 8 y sellado 5. La ruta segura tiene seis acciones: ir a la repisa, descender, escanear, recoger, ascender a la repisa y volver al muelle.

La ruta tiene éxito porque ambos contadores siguen por encima de cero cuando el buzo regresa con la cápsula. Escanear y recoger consumen acciones separadas. El descenso y el ascenso también son acciones distintas, así que no comprimas la excursión en un solo movimiento.

Dos alternativas cercanas ponen a prueba el orden terminal. Si el buzo espera en D2 después de recoger, oxígeno pasa de 4 a 3 y sellado de 2 a 1. El ascenso siguiente los reduce a 2 y 0: es derrota inmediata antes del regreso. Si recoge antes de escanear, la acción se rechaza y el estado permanece D2, O5/8, S3/5.

Esta imagen de resultado es una representación conceptual de ese estado terminal. La luz verde del muelle indica el regreso ficticio; no demuestra que una versión generada haya llegado a ese estado.

Revisa solo a partir de comportamiento observado

Si una versión real difiere del contrato, anota el primer estado divergente. Registra la entrada, ubicación inicial, oxígeno, sellado, marca de escaneo, marca de cápsula, próximo estado esperado, estado observado y regla relacionada. Cambia una sola regla; deja controles y recorrido sin cambios.

1. Localiza la primera diferencia. Compara el resultado real con la fila correspondiente de la traza en papel, no con una impresión vaga de que la inmersión se sintió mal.
2. Nombra la regla más pequeña implicada. Puede ser la adyacencia, el requisito de escaneo, una acción de un solo uso, el coste único de sellado en D2 o el orden de derrota antes de victoria.
3. Solicita una reparación concreta. Mantén fijos los controles, el mapa y los costes que no estén relacionados para que la siguiente observación aísle el cambio previsto.
4. Repite solo las comprobaciones afectadas. Cambiar la precondición de Recoger requiere el caso de recogida prematura; cambiar el orden terminal requiere el caso de regreso con oxígeno cero.
5. Mantén honesto el estado de la evidencia. Una tabla de diseño describe el comportamiento esperado. Un prompt es una instrucción no ejecutada. Para afirmar que algo pasó, hace falta una observación de una versión real.

Sin una versión real y notas de ejecución, detente en el contrato en papel. No inventes una captura esperada ni describas como probada una reparación propuesta. Cuando luego dispongas de una herramienta real con los tres prompts, inspecciona su salida, comprueba el modelo actual y el coste mostrado, y comunica únicamente lo que puedas observar.

Empieza un prototipo de supervivencia submarina

Empieza con una inmersión de ida y vuelta. Una ruta corta, un objetivo y un orden explícito de fallos dan un alcance pequeño para construir e inspeccionar. La traza manual es una base para tu propia prueba, no prueba de que una versión ya siga las reglas. Cuando tengas un resumen conciso, usa la herramienta Free AI game maker para explorar una primera dirección jugable y revisar qué funciona y qué requiere otra iteración. Antes de enviar una solicitud de generación, revisa el modelo seleccionado, el saldo Koin disponible y el coste de generación mostrado en Workspace.

Preguntas frecuentes

¿Cuál es el ciclo mínimo de supervivencia submarina que se puede prototipar?

Usa un buzo, una ruta con un punto de superficie y un objetivo más profundo, y una condición de regreso. Dale al jugador pocas acciones y valores de estado fáciles de leer; después, traza cómo cambia cada acción esos valores. Un segmento compacto ayuda a comprobar si el objetivo, la ruta y el fallo se entienden antes de añadir criaturas, fabricación o un mundo mayor.

¿El contador de sellado representa la presión real del buceo?

No. La pérdida de un punto de sellado cerca de D2 es una regla de juego ficticia para facilitar el cálculo del regreso. NOAA solo respalda el hecho físico general de que la presión aumenta con la profundidad, aproximadamente una atmósfera por cada 33 pies de descenso. El contador no modela fisiología, equipos, límites seguros ni prácticas submarinas.

¿Por qué las acciones no válidas deberían dejar todos los valores intactos?

Rechazar un movimiento no permitido o una recogida prematura antes de cobrar recursos le muestra al jugador qué regla incumplió. También crea una comprobación determinista: si el comando rechazado cambia posición, oxígeno, sellado o marcas, la implementación se aparta del contrato. Se puede elegir otro comportamiento de rechazo, pero hay que declarar su coste y probarlo de forma explícita.

¿Cuándo debería pedir que se repare un prompt?

Pide una reparación después de que una observación real identifique la primera diferencia entre el estado esperado y el real. Incluye la acción, valores iniciales, resultado esperado, resultado observado y una sola regla que se cambiará. Mantén como no verificados los casos no observados y vuelve a ejecutar las comprobaciones que dependen de la regla antes de dar por exitosa la corrección.

¿Se ejecutaron o probaron estos prompts de Blueglass Reach?

No. Son plantillas reutilizables para un escenario ficticio original, y los cálculos de la ruta se hicieron a mano siguiendo las reglas del artículo. No se representa aquí ninguna ejecución de modelo, versión jugable ni prueba de juego. Usa la traza como objetivo de aceptación para una versión futura e informa solo de estados que hayas observado realmente.