2313. Identidad de la lección
Esta lección define el contrato de un sistema procedural antes de comenzar su implementación.
2314. Objetivo de aprendizaje
Al finalizar esta lección, podrás especificar un generador procedural con invariantes explícitas, entradas acotadas, comportamiento determinista basado en una semilla y casos de fallo comprobables.
2315. Por qué importa
La generación procedural produce variación, pero variar no equivale a mantener la calidad. Un generador solo resulta útil cuando sus salidas siguen siendo jugables, válidas e inspeccionables en muchas ejecuciones. Las invariantes claras proporcionan a una persona desarrolladora o a un colaborador de programación basado en IA un objetivo preciso, en lugar de una petición imprecisa de “más variedad”. También hacen que los fallos puedan diagnosticarse: permiten identificar qué garantía se rompió y bajo qué condiciones.
2316. Conocimientos previos
Debes poder describir un sistema de juego mediante reglas, estado, retroalimentación y evidencias de aceptación. El proceso de revisión de 5.11 — Audio y feedback es pertinente porque el contenido generado también necesita validarse dentro de su contexto, no aprobarse solo por el aspecto de un resultado aislado. En esta lección no tienes que implementar un generador procedural.
2317. Concepto central
Una invariante es una propiedad que debe mantenerse verdadera en todo resultado procedural aceptado. No es lo mismo que una preferencia. “Las salas deben sentirse variadas” es un objetivo de diseño; “toda sala tiene una entrada y una salida válidas” es una invariante que puede comprobarse.
Una especificación útil separa cinco elementos:
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Invariante | ¿Qué debe ser siempre cierto? | El diseño generado tiene una ruta transitable entre el inicio y el objetivo. |
| Límite | ¿Qué restringe la entrada o la salida? | El diseño contiene entre 8 y 12 salas. |
| Semilla | ¿Cómo se reproduce el resultado? | La semilla 1842 produce el mismo diseño con la misma versión del generador. |
| Caso de fallo | ¿Qué ocurre si no se pueden cumplir los requisitos? | Se rechaza el resultado y se informa de la invariante incumplida. |
| Evidencia de aceptación | ¿Cómo se comprobará la afirmación? | Una prueba de conectividad encuentra una ruta y registra la semilla evaluada. |
Una especificación completa también diferencia las restricciones duras de los objetivos blandos. Las restricciones duras deciden si se acepta un resultado. Los objetivos blandos ayudan a escoger entre resultados aceptables, por ejemplo, favoreciendo una mayor variedad de tamaños de sala.
2318. Modelo mental
Usa el modelo Generar → Comprobar → Aceptar o rechazar:
- Generar: Produce un candidato a partir de entradas acotadas y una semilla registrada.
- Comprobar: Evalúa todas las invariantes duras y registra el resultado.
- Aceptar o rechazar: Conserva el candidato solo si supera todas las comprobaciones; si no, recházalo, reintenta dentro de un límite establecido o devuelve un fallo controlado.
Este modelo tiene tres consecuencias importantes:
- Un resultado que parece aleatorio no es automáticamente válido.
- La reproducibilidad forma parte del contrato del sistema, no es solo una comodidad para depurar.
- El comportamiento ante fallos debe diseñarse. Un bucle de reintentos sin límite puede ocultar una especificación imposible o contradictoria.
2319. Ejemplo concreto
Considera un generador para un pequeño diseño de encuentro. El generador recibe una semilla y una cantidad solicitada de salas.
En este contrato, la cantidad solicitada no es una simple preferencia: el resultado aceptado debe contener exactamente la cantidad de salas solicitada. La solicitud debe ser un entero del 8 al 12. Por tanto, una solicitud de 10 salas debe producir un diseño aceptado con exactamente 10 salas; no es válido devolver cualquier cantidad dentro del intervalo de 8 a 12. Una solicitud menor que 8, mayor que 12 o que no sea entera se rechaza antes de comenzar la generación.
Invariantes duras:
- El resultado aceptado contiene exactamente la cantidad solicitada de salas, siempre que la solicitud sea un entero del 8 al 12.
- Cada sala tiene una posición válida dentro del área de juego.
- La entrada y el objetivo se encuentran en salas distintas.
- Existe al menos una ruta transitable entre la entrada y el objetivo.
- Las salas no se superponen más allá del margen permitido.
Límites y comportamiento de la semilla:
- Cantidad solicitada de salas: entero del 8 al 12; la cantidad de salida debe coincidir exactamente con la solicitud.
- Área de juego: cuadrícula de 40 por 40 celdas.
- Límite de reintentos: como máximo 20 candidatos por semilla base y por solicitud válida de cantidad de salas.
- Política de intentos: se inicializa una sola secuencia pseudoaleatoria para la solicitud y se consume de forma continua entre intentos, sin reinicializarla con la misma semilla para cada candidato.
- Se registran la semilla base, la cantidad solicitada, la versión del generador, la configuración y la política de intentos. Reutilizar ese contrato completo reproduce el resultado aceptado o el mismo fallo controlado.
Comportamiento ante fallos:
Si la cantidad solicitada está fuera del intervalo de 8 a 12 o no es un entero, el sistema rechaza la solicitud antes de intentar generar y comunica el valor inválido y el límite permitido. Si una solicitud válida no produce un candidato que cumpla todas las invariantes en 20 intentos, el sistema devuelve un fallo controlado que contiene la semilla, la cantidad solicitada, la versión del generador, los nombres de las invariantes incumplidas y la cantidad de reintentos. No sustituye silenciosamente la cantidad de salas, no devuelve un diseño inválido ni reintenta para siempre.
Después, un objetivo blando puede elegir entre los diseños válidos: por ejemplo, favorecer diseños cuyos tamaños de sala no sean todos idénticos. Ese objetivo puede mejorar la variedad sin debilitar el contrato de cantidad exacta ni ninguna otra invariante dura.
2320. Error común
El error común es tratar una llamada de función exitosa como prueba de que la generación tuvo éxito. Un generador puede devolver un objeto, dibujar un mapa o producir datos plausibles y, aun así, incumplir los requisitos de conectividad, límites, unicidad o reproducibilidad. “Generó algo” describe la ejecución, no la aceptación.
Otro error consiste en añadir aleatoriedad antes de definir el contrato de la semilla. Si la fuente de aleatoriedad no está controlada y registrada, un fallo puede desaparecer antes de que pueda investigarse.
2321. Práctica guiada
Escribe una especificación de una página para un sistema procedural de tu elección: un diseño de encuentro, un conjunto de objetos, una variación de misión, una disposición visual u otro sistema de contenido acotado. Todavía no lo implementes.
Completa estos pasos:
- Expresa el propósito del sistema en una sola frase.
- Enumera al menos cuatro invariantes duras. Cada una debe poder comprobarse como verdadera o falsa.
- Define los límites relevantes de entrada y salida para el sistema elegido.
- Especifica qué controla la semilla, cómo avanzan los reintentos de forma determinista y qué datos sobre la semilla, la solicitud, la versión, la configuración y la política de intentos deben registrarse para reproducir el resultado.
- Define un objetivo blando que pueda mejorar la variación sin convertirse en un requisito duro.
- Define un límite finito de reintentos y la información que se devuelve cuando la generación falla.
- Para cada invariante, indica la evidencia que demostraría que se cumplió.
Toma una decisión explícita sobre una solicitud imposible o inválida: rechazarla antes de generar, gestionarla mediante reintentos acotados o utilizar una alternativa controlada. Explica por qué esa decisión conserva el contrato del sistema elegido.
2322. Validación / evidencia
Tu especificación está lista para revisión cuando otra persona desarrolladora pueda responder estas preguntas sin hacer suposiciones:
- ¿Qué debe ser cierto en todo resultado aceptado?
- ¿Qué valores están acotados y qué ocurre fuera de esos límites?
- Si se solicita una cantidad de salida, ¿el resultado debe coincidir con esa cantidad o basta con que esté dentro de un intervalo?
- ¿Puede reproducirse el resultado aceptado o el fallo controlado con la misma semilla base, solicitud, versión del generador, configuración y política de intentos?
- ¿Cómo se comprueba cada invariante?
- ¿Qué ocurre cuando se agota el límite de reintentos?
- ¿Qué objetivos son preferencias y no condiciones de aceptación?
La evidencia de esta lección es la especificación terminada, incluida una tabla de invariantes y una ruta de fallo documentada. Debe indicar el contrato de aceptación del sistema, sus límites de entrada y salida, cómo se gestionan las solicitudes inválidas y qué ocurre cuando se agota el límite de reintentos. La persona revisora debe poder identificar al menos cuatro invariantes, sus comprobaciones y la condición exacta en la que se rechaza el resultado o se utiliza una alternativa controlada especificada.
Entrega práctica y rúbrica
Entrega la especificación de una página como evidencia de la evaluación práctica. Puntúa cada criterio con 0 = ausente o no comprobable, 1 = presente pero incompleto o 2 = completo y comprobable, hasta un total de 10 puntos:
- Invariantes: Incluye al menos cuatro invariantes duras formuladas como condiciones comprobables.
- Límites: Explicita los límites relevantes de entrada y salida y el tratamiento de las solicitudes inválidas.
- Reproducción determinista: La semilla, la solicitud, la versión del generador, la configuración y la política de intentos registradas permiten reproducir el resultado aceptado o el fallo controlado.
- Gestión finita de fallos: Especifica el límite de reintentos y el comportamiento de rechazo, fallo controlado o alternativa previamente definida.
- Evidencia de aceptación: Cada invariante indica la comprobación o el artefacto que demuestra si se cumplió.
2323. Puntos clave
- Una invariante es una propiedad que todo resultado procedural aceptado debe conservar.
- Los límites evitan entradas descontroladas y hacen predecible el comportamiento del generador.
- Las semillas y las versiones del generador permiten reproducir los resultados procedurales.
- Un sistema válido define el rechazo, los límites de reintento y el comportamiento ante un fallo controlado.
- Los objetivos blandos pueden mejorar la variedad, pero no deben sustituir silenciosamente a las restricciones duras.
2324. Siguiente lección
Continúa con 5.12 L2 — Evaluar la variación sin venerar la cantidad, centrada en el muestreo, el rechazo y los criterios de calidad.
2325. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Cuál de estas afirmaciones es una invariante procedural?
Mostrar respuesta y explicación
Respuesta: Todo diseño aceptado contiene una ruta transitable entre la entrada y el objetivo.
Por qué: Una invariante es una propiedad comprobable que debe cumplirse en todo resultado aceptado. La variedad y las preferencias estéticas pueden ser objetivos útiles, pero aquí no están expresadas como garantías obligatorias y comprobables.
¿Por qué debe un generador registrar su semilla y su versión?
Mostrar respuesta y explicación
Respuesta: Para reproducir un resultado observado bajo el mismo contrato de generación.
Por qué: La semilla identifica la secuencia aleatoria y la versión identifica la lógica de generación. Juntas permiten reproducir e investigar el resultado, pero no demuestran que sea válido.
¿Cuál es la respuesta más segura cuando un generador no puede cumplir sus invariantes dentro del límite de reintentos?
Mostrar respuesta y explicación
Respuesta: Devolver un fallo controlado con información diagnóstica o utilizar un fallback previamente especificado.
Por qué: Un fallo acotado y observable evita que contenido inválido entre en el juego y deja al descubierto requisitos contradictorios o imposibles. Un fallback solo es válido si se definió como parte del contrato.
¿Cuál de estos elementos es un objetivo blando y no una condición dura de aceptación?
Mostrar respuesta y explicación
Respuesta: Preferir diseños con tamaños de sala variados cuando todas las comprobaciones duras se superen.
Por qué: Un objetivo blando ordena o mejora resultados que ya son válidos. No puede imponerse sobre un requisito duro como los límites, la distinción de roles o la conectividad.