Cuándo dejar de escribir prompts y empezar a construir

Describir sale barato, y ese es el problema

Pedir un cambio cuesta una frase. Hacer el cambio le cuesta a la máquina unos segundos. Esa proporción es todo el atractivo, y también es la trampa, porque un proceso tan barato no trae ningún punto de parada natural.

Cuando un cambio era caro, el gasto pensaba por ti. Nadie pasaba dos días implementando una variación de la que no estaba seguro. El coste obligaba a decidir antes de empezar el trabajo, lo que significaba que alguien tomaba la decisión, a propósito, en un momento que podía señalar.

Quita ese coste y la decisión deja de ser obligatoria. Puedes probar la cuarta variación del impulso sin haber decidido nunca para qué sirve el impulso, y puedes hacerlo indefinidamente. La sensación es productiva. Aparece algo nuevo cada pocos minutos. Pero no se resuelve nada.

Lo que sigue no es un argumento contra describir lo que quieres. Es un argumento para notar el momento en que deja de compensar, porque ese momento tiene una forma y es fácil de reconocer cuando sabes qué buscar.

Los dos modos y para qué sirve cada uno

Describir es una búsqueda. Estás explorando un espacio de juegos posibles sin comprometerte con ningún punto. Buscar es el modo correcto cuando de verdad no sabes lo que quieres, que al principio de un proyecto es casi siempre.

Construir es un compromiso. Pones una cosa en una coordenada, decides que es de ese color, dices que esta sala va antes que aquella. Los compromisos son lo que convierte un montón de posibilidades en algo que se puede juzgar, porque no puedes juzgar una media de opciones y sí puedes juzgar una disposición concreta.

Los dos modos son necesarios y ninguno es más virtuoso. Un proyecto que solo busca nunca tiene un juego dentro. Un proyecto que solo se compromete es una larga defensa de la primera idea que tuvo alguien.

La habilidad está en cambiar en el momento justo, y el cambio casi siempre llega tarde en una dirección. Buscar sienta bien y comprometerse da miedo, así que la gente se queda buscando. Reconocer las señales es sobre todo una forma de incomodarte a tiempo.

Primera señal: estás describiendo el arreglo, no el objetivo

Al principio, las peticiones suenan a objetivos. Haz que el personaje pueda escalar. Dale a la tienda una forma de revender cosas. Añade un segundo tipo de enemigo que ataque a distancia.

Más tarde, si las cosas se han torcido, empiezan a sonar a correcciones de una corrección anterior. Un poco menos que la última vez. Vuelve a dejarlo como estaba pero conserva el sonido nuevo. Pruébalo un poco más rápido, no, entre los dos.

Esa deriva es la señal de alarma más clara que hay. Has dejado de describir un juego y has empezado a dirigir un valor, y dirigir un valor a base de frases es una interfaz pésima para eso. Las frases no tienen la resolución de un deslizador, y cada ida y vuelta añade un error de traducción.

Lo que toca es ir a poner tú el número, esté donde esté, y sentir el cambio directamente en lugar de describir una cantidad que no puedes nombrar. Dos minutos de ajustes ganan a veinte minutos de "un poco más que eso".

Segunda señal: la respuesta llega y cada vez está mal de una forma nueva

Una iteración útil converge. El segundo intento está más cerca que el primero, el tercero más cerca que el segundo, y sientes que te acercas al objetivo aunque no lo hayas alcanzado.

Una iteración atascada no converge. Cada intento es una interpretación nueva, equivocada en una dirección que no tiene nada que ver con la anterior. Pides que la sala se sienta más opresiva y te dan menos luz, luego un techo más bajo, luego paredes rojas, luego un zumbido de ambiente. Cada una es una lectura razonable y ninguna es lo que querías decir.

Ese patrón casi siempre significa que estás pidiendo algo que vive en cien decisiones pequeñas, no en una. La atmósfera no es un ajuste. Es la suma de la luz, el sonido, las líneas de visión, el ritmo del movimiento y lo que hay a la vuelta de la esquina. Nadie puede entregarla como una sola petición, porque no tiene nada de única.

Tres intentos que no convergen son una buena regla para parar. Al tercero, ve a cambiar tú una de esas cien cosas, mira el resultado y cambia la siguiente.

Tercera señal: no puedes decir lo que quieres en una frase

Antes de enviar una petición, prueba a decirla en voz alta como una sola frase sin condiciones. Si puedes, probablemente es una buena petición. Si hacen falta tres frases con una excepción en medio, conviene fijarse.

Las peticiones largas y llenas de matices suelen significar una de dos cosas. O todavía no has decidido, y entonces le estás pidiendo a otro que decida por ti y no te gustará lo que vuelva. O has decidido algo espacial, y las decisiones espaciales no sobreviven a que las aplasten en prosa.

"El pasillo debería girar a la izquierda después de los pilares, pero no tanto como para perder de vista la torre, y la puerta debería verse desde el giro pero no antes" es un pensamiento de diseño real. También es la descripción de un plano, y la forma más rápida de comunicar un plano es dibujarlo.

La prueba es rápida y ahorra tardes enteras. Todo lo que necesite un diagrama para explicarse es algo que deberías estar colocando directamente, no describiendo.

Cuarta señal: no se ha jugado nada en una hora

Mira cuándo fue la última vez que ejecutaste el juego. Ejecutarlo de verdad, moverte por él, verlo moverse.

Si la respuesta es más de una hora, más o menos, y has hecho una docena de peticiones en ese tiempo, no estás desarrollando un juego. Estás acumulando cambios sobre algo cuyo estado actual nadie ha observado. Eso sale mal no porque los cambios sean malos uno a uno. Sale mal porque interactúan, y las interacciones son invisibles hasta que juegas.

También hay un coste más sutil. Sin una partida reciente, tu idea del juego funciona con la memoria, y la memoria suaviza las cosas. Recuerdas la versión que pretendías. La build que tienes delante es la versión que existe, y la distancia entre las dos crece cada vez que te saltas la comprobación.

Juégalo. Incluso una pasada de dos minutos reinicia tu punto de referencia, y a menudo hace innecesarias las cuatro peticiones siguientes porque lo que ibas a arreglar resultó no ser el problema.

Qué significa construir de verdad cuando no escribes código

Construir no tiene por qué significar escribir código. Casi todas las decisiones que definen un juego no son decisiones de código, y casi todas se toman moviendo cosas.

La colocación es la más grande. Dónde están los enemigos, a qué distancia están las plataformas, hacia dónde se abre la sala, qué ves desde la entrada, dónde está el botiquín respecto al combate. El diseño de niveles es casi por completo la disposición de objetos en el espacio, y disponer es una tarea de manipulación directa. Nadie ha escrito nunca a mano una buena arena describiendo coordenadas.

Los números son la segunda. Velocidades, gravedad, altura de salto, daño, tiempos de recarga, cuánto tiempo sigue abierta una puerta. Piden sentirse, no especificarse, y el ciclo de ajustar y jugar a intervalos de diez segundos es la única forma que se ha encontrado de dar con un buen valor para cualquiera de ellos.

El orden es la tercera. Qué sala va primero, cuándo se presenta la mecánica, cuánto tarda en subir la dificultad. Es la estructura de la experiencia y te toca a ti decidirla, porque eres tú quien la ha jugado en secuencia.

Dónde describir sigue ganándose su sitio

Nada de esto es un argumento para parar. Hay una gran clase de trabajo donde describir lo que quieres es con diferencia el camino más rápido, y es la clase que antes se comía casi toda la semana.

Todo lo que es un mecanismo y no un juicio. Hacer que la puerta responda a un interruptor. Guardar y cargar. Contar las monedas. Conectar un evento para que la música cambie cuando empieza un combate. Conseguir que la cámara deje de atravesar una pared. Este trabajo es estructural, tiene una respuesta correcta y no mejora por darle vueltas.

Todo lo que habrías tenido que aprender antes de poder intentarlo también entra. La mitad de los proyectos mueren porque un pequeño obstáculo mecánico se interpone entre la persona y la siguiente decisión interesante, y el obstáculo es lo bastante aburrido como para que deje de volver.

Lee la división así: describe los mecanismos, decide la experiencia. Lo primero es trabajo que quieres hecho. Lo segundo es lo que estás haciendo de verdad, y no se delega.

Un ritmo que mantiene honestos los dos modos

Una forma que aguanta: describe una vez, juega una vez, ajusta a mano y luego decide si lo siguiente es otra descripción u otro ajuste.

Describir una vez significa pedir una capacidad entera y no un cambio fino. Jugar una vez significa ejecutar el juego antes de evaluar nada, sin excepciones. Ajustar a mano significa que los números, la colocación y el orden son tuyos y los cambias donde viven.

Luego la decisión al final del ciclo: ¿el siguiente problema es maquinaria que falta o una mala elección sobre algo que ya existe? La maquinaria que falta es una descripción. Una mala elección es un ajuste. Acertar esa única pregunta casi siempre es casi toda la disciplina.

El fallo no es la pereza. Es que describir parece avance justo en los momentos en que ha dejado de serlo, y la única defensa fiable es la costumbre de comprobar. Mira cuándo jugaste por última vez, y mira si tus tres últimas peticiones convergían. Esas dos comprobaciones atrapan casi todo.

Descarga Flockbay

Describe los mecanismos, decide la experiencia. La segunda mitad es el juego, y se hace colocando cosas y jugándolas.

Lee más notas de diseño de juegos

Sigue leyendo

• Cómo juzgar un juego que no programaste
• Por qué tu primer juego generado es malo, y qué hacer al respecto
• ¿Para qué sirve hacer prototipos?
• Secretos de la sensación de juego y el juice
• Qué es un creador de juegos con IA, y dónde toman el relevo tus manos
• Qué es el vibe coding y dónde deja de funcionar para los juegos