De la idea de juego al prototipo: escribe un brief de una página y una lista de tareas

Un brief de una página vale más que un documento de diseño de cuarenta

Para un prototipo, un documento de diseño largo caduca antes de haberse usado. Un brief de una página cabe en la cabeza, se relee en dos minutos y se puede entregar a un compañero o a un agente de código. No describe todo el juego: explica qué estás probando, por qué y qué dejas fuera a propósito.

1. Las seis líneas del brief

Escribe: la intención (lo que debe sentir el jugador), la mecánica que probar, las referencias útiles, las restricciones (tiempo, herramientas, alcance), lo que queda fuera del alcance y la pregunta que comprobar. Para Dicebound: «Probar si bloquear un dado crea una decisión interesante. Referencias: Dicey Dungeons, Slice & Dice. Restricciones: un personaje, un enemigo, dos tardes. Fuera del alcance: progresión, sonido, menús. Pregunta: ¿los probadores relanzan voluntariamente?»

2. Divídelo en tareas de menos de media jornada

Cada tarea debe caber en una sesión de trabajo. Para Dicebound: mostrar tres dados y un enemigo; permitir bloquear un dado; relanzar los dados no bloqueados; repartir los resultados entre ataque y defensa; mostrar la intención del enemigo; pantalla de fin de combate. Una tarea vaga como «hacer el combate» esconde varias decisiones. Divídela hasta poder terminarla sin otra reunión contigo mismo.

3. Dale a cada tarea un resultado observable

Describe lo que se puede ver o hacer cuando la tarea esté terminada: «Hago clic en un dado, se bloquea y no se mueve en la siguiente tirada». Esa frase sirve de criterio de revisión, ya sea que la haya programado tú, un compañero o un agente. Añade una línea sobre lo que no forma parte de la tarea para evitar añadidos silenciosos.

4. En Impstash: de la idea conservada a la tarea

Marca la idea como conservada y crea la tarea desde la idea: su título y su texto sirven de punto de partida y la tarea queda vinculada a la idea. Completa la descripción con el brief y coloca las tareas en las columnas del Kanban. Para cada tarea se puede enviar una versión a revisión con una nota y enlaces, y un miembro la acepta o pide rehacerla.

5. Termina con una tarea de prueba, no con una función

La última tarea del lote es siempre: «Hacer que tres o cinco personas lo prueben y anotar lo que hicieron». Sin ella, el prototipo sirve para construir un juego y no para responder a tu pregunta. Tras la prueba, actualiza el brief: conserva, ajusta o abandona, y escribe la siguiente apuesta.

Un prompt para adaptar a tu juego

Esta es una idea conservada para Dicebound: bloquear un dado, relanzar los demás y repartir los resultados entre ataque y defensa. Referencias: Dicey Dungeons, Slice & Dice. Restricciones: un personaje, un enemigo, dos tardes. Escribe un brief de una página con intención, mecánica que probar, referencias, restricciones, fuera del alcance y pregunta que comprobar. Después propón seis tareas de menos de media jornada, cada una con un resultado observable. Termina con una tarea de prueba con cinco personas. Señala los puntos en los que haces una suposición.

Reemplace las referencias y las restricciones por las suyas. Las respuestas de la IA son propuestas para examinar; la elección sigue siendo suya.

Referencias y comunidades para seguir

• Dicey Dungeons — Valores de dados convertidos en decisiones: observar las restricciones del equipamiento.
• Slice & Dice — Intenciones enemigas visibles: comparar riesgo, relanzamiento y cooperación de los dados.
• Dicey Dungeons — Notas del creador y vídeos
• r/gamedesign — Para hablar de mecánicas, reglas y compromisos de diseño.
• r/gameideas — Para compartir una idea estructurada y desarrollar sus posibilidades. Revisa las reglas antes de publicar.