Escribe el documento que necesita la próxima versión
Un documento de diseño de juego debe explicar qué hay que crear, qué queda fuera y cómo saber si el prototipo funciona. Para el desarrollo asistido por IA, las secciones más útiles son las reglas concretas, los controles, los límites del alcance y las comprobaciones de aceptación. Un largo esquema de la historia no resuelve si un objeto recogido puede contarse dos veces ni qué debe restablecer Reiniciar.
Esta guía utiliza un único ejemplo didáctico: Rain Route, un pequeño juego de entregas protagonizado por un robot. Su GDD, prompts, revisión y pruebas se refieren al mismo juego propuesto. No es un proyecto realmente generado ni una experiencia de usuario documentada. El flujo muestra cómo conectar decisiones con la implementación sin afirmar que la versión propuesta ya existe.
Copia este mini-GDD completado
Rain Route, versión de diseño 0.1.
Idea: un robot visto desde arriba transporta paquetes de recuerdos por una manzana lluviosa.
Jugador y plataforma: una persona en un navegador de escritorio con teclado. Una primera sesión de aproximadamente cinco minutos es un objetivo de diseño, no un resultado medido.
Promesa y pilares: navegación tranquila, destinos legibles y pequeñas decisiones de ruta. Priorizar una respuesta clara frente a añadir sistemas.
Ciclo principal: recoger un paquete en el depósito, caminar hasta la puerta numerada correspondiente, entregarlo y volver por el siguiente. Completar tres entregas da la victoria.
Controles y cámara: cámara cenital fija. WASD o flechas para moverse. E recoge o entrega dentro del área de interacción marcada. R reinicia después de ganar. Mostrar las instrucciones en pantalla.
Reglas: solo se puede llevar un paquete. Las entregas siguen el orden de las puertas 1, 2 y 3. Pulsar E en la puerta equivocada muestra un mensaje pero no retira el paquete. Cada entrega correcta incrementa el contador una vez. Pulsar E repetidamente no puede volver a contar una entrega ya completada.
Mapa y desafío: una manzana, un depósito, tres puertas, un tramo con charco y un desvío seco. Dentro del charco, la velocidad es la mitad de la normal. No hay pérdida de vida, enemigos ni derrota por tiempo.
Información al jugador: mostrar destino actual, paquete transportado y entregas completadas. Usar números de puerta diferenciados y una confirmación visible de entrega. La lluvia ambiental debe ser suave y tener opción de silenciarse.
Alcance técnico: un prototipo para navegador, sin cuentas, guardados en la nube, red, compras, mapas adicionales ni sistema de desbloqueo. Recargar comienza una partida nueva. Usar formas originales sencillas hasta que el ciclo pase las pruebas.
Victoria y reinicio: después de la tercera entrega, mostrar un panel de victoria. R restaura el robot, el paquete, el destino, el contador de entregas y el panel al estado inicial.
Pregunta de revisión: ¿puede una persona nueva completar la primera entrega usando solo las instrucciones visibles?
Paso 1: convierte el GDD en una solicitud de creación
Usa el documento como entrada, no como prueba de implementación. Antes de enviarlo, revisa contradicciones entre alcance, controles y condición de victoria. «Recargar comienza una partida nueva» descarta prometer entregas persistentes; «un paquete» descarta una cola de inventario oculta. Resuelve estas decisiones en el GDD en lugar de dejar que la implementación las adivine. Un primer prompt adecuado sería:
Crea Rain Route a partir de la versión de diseño 0.1. Implementa primero solo el mapa, el movimiento, la recogida en el depósito y la entrega en la puerta 1. Mantén visibles pero inactivas las puertas posteriores. Muestra el destino actual y si se lleva un paquete. Usa formas originales sencillas. No añadas efectos meteorológicos, desbloqueos, temporizadores de derrota ni mecánicas adicionales. Explica qué componentes han cambiado y cómo probar la recogida, la interacción en una puerta equivocada, la entrega correcta y la pulsación repetida de E.
Limita esta primera solicitud al fragmento de entrega. Su resultado debe permitir inspeccionar una interacción completa antes de multiplicar los destinos. Si no se puede completar la ruta con los controles documentados, corrige ese fragmento en lugar de ampliar el mapa.
Paso 2: relaciona los requisitos con pruebas del mismo juego
Asigna identificadores breves a las reglas importantes y consérvalos en el prompt, las notas y el registro de pruebas:
| Requisito | Acción en Rain Route | Resultado esperado |
|---|---|---|
| R1: máximo un paquete | Pulsar E dos veces en el depósito | Se sigue llevando un solo paquete |
| R2: solo el destino correcto | Visitar la puerta 2 con el paquete 1 | Aparece un mensaje y se conserva el paquete |
| R3: cada entrega cuenta una vez | Entregar en la puerta 1 y pulsar E repetidamente | El contador permanece en uno |
| R4: progreso ordenado | Completar las tres entregas | El destino avanza 1 → 2 → 3 y la victoria aparece una vez |
| R5: reducción de velocidad en el charco | Cronometrar la misma ruta marcada dentro y fuera del agua | La velocidad en el charco corresponde a la mitad especificada |
| R6: reinicio completo | Pulsar R después de ganar | Posición inicial, manos vacías, cero entregas y sin panel de victoria |
Registra las observaciones reales en un registro independiente con la versión de la compilación y el entorno. Añade estados como aprobado, fallido o bloqueado solo después de realizar la acción. Si el primer fragmento falla en R2, corrige esa interacción antes de solicitar tres entregas. Mantén la secuencia de entradas lo bastante precisa para que otra persona pueda reproducir el fallo.
Paso 3: amplía el ciclo y después añade atmósfera
Cuando la primera entrega pase la prueba, solicita las puertas 2 y 3 junto con los estados de victoria y reinicio. Ejecuta de nuevo R1 a R4 y R6. Después solicita la reducción de velocidad en el charco y comprueba R5 sin cambiar la lógica de recogida.
Añade efectos visuales de lluvia y sonido ambiental suave solo cuando esas reglas pasen. Verifica que la lluvia no oculte números ni marcadores de interacción y que funcione el silencio. Si el efecto meteorológico vuelve ilegible el mapa, redúcelo en vez de aceptar la atmósfera a costa de la experiencia prometida en el documento.
Paso 4: actualiza el GDD cuando la evidencia cambie una decisión
Supón que una prueba futura muestra que los jugadores no ven el destino actual. Aquí es una observación hipotética, no un resultado. Una revisión concreta pediría una etiqueta de destino más destacada manteniendo el orden de las puertas y las reglas de entrega. Vuelve a plantear la misma pregunta sobre la primera entrega a una persona nueva.
Registra la decisión como versión 0.2, explica el motivo del cambio y relaciónala con el requisito y la compilación afectados. Conserva las decisiones anteriores para no confundir un resultado de prueba antiguo con evidencia de una regla nueva. Un requisito revisado debe indicar qué comprobaciones anteriores hay que repetir.
Si un cambio generado rompe un requisito anterior, revierte o aísla ese cambio. Comunica el requisito fallido, la entrada exacta, el resultado esperado y el real. «R3 cuenta dos veces después de pulsar E repetidamente» permite actuar mejor que «el prototipo parece tener errores».
Usa SEELE entre la especificación y el registro de pruebas
SEELE permite crear juegos con lenguaje natural y realizar cambios iterativos en jugabilidad, escenas y recursos. Proporciona el mini-GDD como entrada de diseño y solicita después un fragmento de implementación acotado. El resultado útil es una versión candidata que pueda compararse con el mismo documento, no un sustituto del criterio de diseño ni un registro de pruebas completado.
En cada petición posterior, indica el requisito que cambia y los que deben mantenerse estables. Pedir una etiqueta de destino más clara no debería introducir silenciosamente un temporizador ni cambiar el orden de las puertas. Relaciona documento, prompt y resultado observado mediante versiones para que una descripción pulida nunca sustituya al comportamiento real.
Usa el GDD para empezar a crear, no para posponerlo
Un GDD útil acorta la distancia entre una decisión y una comprobación. Rain Route necesita reglas claras de recogida, orden de destinos y definición de reinicio antes que un esquema más extenso de la historia. Mantén el documento breve, pero haz que las reglas sean lo bastante precisas para que otra persona pueda evaluar la misma versión.
Copia la especificación en SEELE y solicita el primer fragmento de entrega. Mantén alineados por versión el documento, la compilación funcional y el registro de pruebas. Amplía el alcance solo cuando las reglas existentes del mismo juego sobrevivan a la implementación y a las revisiones, y actualiza el GDD cuando la evidencia cambie una decisión.
Del diseño a una comprobación jugable
Esta matriz organiza las comprobaciones propuestas en el artículo. No es un informe de una prueba completada.
| Elemento del GDD | Pregunta que responde | Ejemplo de aceptación |
|---|---|---|
| Jugador y entrada | ¿Quién juega y cómo actúa? | Una persona en escritorio puede mover el robot con los controles de teclado indicados. |
| Objetivo y alcance | ¿Qué debe ocurrir en esta versión? | El jugador puede entregar el paquete indicado en la escena definida. |
| Reglas y límites | ¿Qué ocurre cuando se activa una regla? | Una entrega o recogida se cuenta solo como indica el diseño. |
| Fallo y recuperación | ¿Qué sucede si el jugador no puede completar la tarea? | El comportamiento de fallo o reinicio indicado devuelve el juego al estado documentado. |
| Registro de revisiones | ¿Qué decisión cambió y por qué? | Registra la observación, la regla modificada y el resultado de repetir la comprobación. |
Preguntas frecuentes
¿Qué extensión debe tener el GDD de un prototipo?
La menor posible que resuelva las próximas decisiones de implementación. El ejemplo completado especifica alcance, controles, reglas y pruebas sin necesitar una biblia de producción. Añade secciones cuando cambien lo que alguien debe crear o comprobar. Una regla de interacción ausente cuesta más que una página de historia de fondo que falta.
¿Puede la IA escribir el documento por mí?
La IA puede redactar secciones y mostrar ambigüedades, pero tú debes decidir las reglas y verificar su viabilidad. Pídele que identifique requisitos contradictorios y criterios de aceptación ausentes. No consideres un documento pulido como validación de la diversión, la calidad de implementación, los derechos de los recursos o capacidades del producto que no se hayan comprobado.
¿Qué diferencia hay entre el GDD y el registro de pruebas?
El GDD establece el comportamiento previsto y las decisiones. El registro de pruebas recoge lo que ocurrió en una compilación y un entorno concretos. Mantenlos relacionados pero separados: una expectativa de aprobación no es una prueba aprobada. Cuando las observaciones justifiquen cambiar una regla, actualiza el diseño de forma explícita y repite las comprobaciones afectadas.
Una lista de verificación de capítulos para un GDD más grande
Agregue secciones solo cuando guíen una decisión para la próxima compilación. Comience con la audiencia, la plataforma y el discurso de una oración. Siga con el bucle principal, los controles, la progresión, el mundo o la narrativa, las limitaciones de arte y sonido y los requisitos técnicos. Para cada característica dentro del alcance, indique su propietario, la prueba reproducible más pequeña y una prueba que el equipo pueda volver a ejecutar. Mueva las ideas opcionales a un trabajo pendiente separado.
