A Longitudinal Look Into Student Video Game Designs
Enseñar diseño de videojuegos tiene una trampa que cualquier profesor del área conoce: la parte "bonita" (inventar mecánicas, pensar historias, imaginar mundos) se entiende rápido y engancha. Los estudiantes llegan con ideas, con referencias, con ganas de crear. Pero el trabajo real de un diseñador es iterar, documentar, tomar decisiones con método y comunicarlas a un equipo. Eso cuesta más de enseñar, y cuesta más de aprender.
Durante varios años hemos recogido y analizado los documentos de diseño (GDD) que entregan equipos de estudiantes en la Facultad de Informática de la UCM. No es un análisis de calidad ("este GDD es mejor que aquel"), sino de uso: qué apartados rellenan, cuándo los rellenan, qué nivel de detalle alcanzan, y cómo evoluciona el documento a lo largo del proyecto. Queríamos entender cómo usan realmente los estudiantes esta herramienta, no cómo deberían usarla según los manuales.
Lo que encontramos es bastante consistente de año en año, independientemente del tipo de juego o del tamaño del equipo. Los estudiantes tienden a usar el GDD para documentar lo que ya han hecho, no para guiar el diseño antes de programar. Es decir, el documento se convierte en un registro retrospectivo más que en una herramienta de planificación. Primero programan una mecánica, y luego la describen en el GDD. Primero deciden la estética, y luego la justifican por escrito.
Esto no es necesariamente malo —a veces el diseño emerge del hacer—, pero tiene un coste. Cuando el GDD va por detrás del desarrollo, pierde su función de comunicación. Si un miembro del equipo quiere saber qué se supone que hace el sistema de combate, el GDD no le ayuda porque todavía no está actualizado. Y cuando llegan los conflictos de diseño ("yo pensaba que el juego iba de X, pero tú lo estás haciendo de Y"), el documento no sirve para arbitrar porque nadie lo consultó antes de decidir.
También vimos diferencias claras entre apartados. Los más creativos —narrativa, mecánicas core, estética visual, referencias— se rellenan con más gusto y detalle. Los estudiantes disfrutan escribiendo sobre el mundo del juego, sobre los personajes, sobre el "feeling" que quieren conseguir. Los apartados técnicos —interfaz, flujo de pantallas, sistemas secundarios, economía del juego— tienden a quedarse más vacíos o a rellenarse con frases genéricas ("la interfaz será intuitiva").
Esto no es un defecto de los estudiantes; es una señal de que hace falta enseñar estructura y hábitos de diseño de forma explícita. Las plantillas rígidas no funcionan bien porque cada juego es distinto: lo que necesita documentar un puzzle game no es lo mismo que lo que necesita un roguelike. Pero las guías demasiado abiertas tampoco ayudan a quienes están aprendiendo, porque no saben qué preguntas hacerse.
El punto medio parece estar en guías flexibles con checkpoints frecuentes. En lugar de pedir un GDD "completo" al final del cuatrimestre, pedirlo en versiones incrementales que se revisan cada pocas semanas. Así el documento crece con el proyecto, y los estudiantes reciben feedback antes de que sea demasiado tarde para corregir. La clave es que el GDD se revise y actualice como parte del proceso, no como un trámite burocrático al final.
El estudio también muestra diferencias interesantes entre equipos. Los que tienen un "diseñador dedicado" —aunque sea informal, alguien que asume el rol de mantener la visión coherente— tienden a producir documentos más completos y a usarlos más durante el desarrollo. Esto sugiere que el rol de diseñador, incluso en proyectos pequeños de estudiantes, tiene un valor organizativo que va más allá de las ideas creativas. Es el que pregunta "¿esto que estamos haciendo encaja con lo que dijimos que queríamos hacer?".
De cara a la enseñanza, el estudio refuerza algo que muchos profesores intuyen: no basta con explicar qué es un GDD y dar una plantilla. Hay que enseñar el hábito de documentar mientras se diseña, no después. Y hay que crear contextos donde el documento sea útil de verdad —por ejemplo, rotando miembros entre equipos para que tengan que leer y entender el GDD de otro grupo—.
¿Para qué sirve? Para mejorar la enseñanza de diseño de videojuegos y, en general, para entender cómo los estudiantes aprenden a documentar y planificar proyectos creativos. Útil para profesores, diseñadores de currículos y estudios que contratan juniors.
Si te interesó este…
-
Effectiveness of information modality in virtual reality tutorialsTexto vs vídeo en tutoriales VR: qué funciona mejor y cuándo.
-
Prompting an LLM Chatbot to Role Play Conversational Situations for Language PracticePrompts para practicar idiomas con role-play y feedback usando un LLM.