Skip to content

Category: 🇪🇸 ES route

MailPoet routing — do not delete

La diferencia entre documento y documentación

Published by Paolo Gambardella on 21/05/2026

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Una de las responsabilidades principales de un game designer es escribir documentación de diseño. Cualquiera es capaz de escribir documentos, pero un designer se dedica a la documentación, que es algo diferente.

Un documento contiene pensamientos, ideas, lo que sea. La documentación, en cambio, es un tipo de documento específico sobre algo concreto. Una investigación sobre un juego de la competencia. El resultado de un playtest. Una feature que hemos construido y observado en acción. Un prototipo que ha respondido a una pregunta concreta.

Para entender por qué esta regla se viola tan a menudo, conviene pensar en cómo se acumula el conocimiento durante el desarrollo de un juego.

Concept DOCUMENTS

Al principio de un proyecto, casi todo es incierto.

  • Constraints | Hay cosas que ya sabemos: la plataforma objetivo, el género, quizás el presupuesto.
  • Frontiers | Hay preguntas que sabemos que tenemos que responder: cómo funciona el core loop, cuánto dura una sesión típica.
  • Risks | Hay cosas que aún no sabemos que no sabemos. Los problemas de diseño que solo emergen cuando el jugador tiene el mando en la mano. Las interacciones entre sistemas que parecían obvias sobre el papel y resultan un desastre en la práctica. Las suposiciones que nadie ha cuestionado nunca porque parecían tan evidentes que no merecían atención.

Un concept document vive casi por completo en esa tercera capa. No es documentación, es una instantánea de la imaginación del equipo en un momento concreto.

Game Design DOCUMENTATION

La documentación de verdad llega después. Después de haber prototipado y descubierto que la mecánica que parecía brillante no funciona como pensábamos. Después de haber analizado cómo otro juego ha resuelto el mismo problema. Después de haber testeado y observado. En ese momento sí tenemos algo que documentar de verdad.

Documentos y Documentación

Un documento sirve a un objetivo temporal. Las notas de una reunión son un documento. Un concept doc es un documento. Una lista de ideas apuntadas antes de una sesión de brainstorming es un documento. Son herramientas de trabajo válidas, necesarias, y tienen una vida útil natural: sirven ahora, luego pasan a la historia.

La documentación, en cambio, está pensada para durar.

  • Debe ser clara para alguien que no estuvo en esa reunión.
  • Debe ser práctica, una referencia que se pueda usar de verdad, no solo leer.
  • Debe inspirar a quien la lea seis meses después, cuando el entusiasmo inicial se ha enfriado y hacen falta puntos de apoyo concretos.
  • Y debe ser atractiva: no como ejercicio estético, sino porque si nadie abre un documento, ese documento no existe. Yo aplico esta fórmula: el 60% del espacio debe estar ocupado por elementos visuales (diagramas, imágenes, vídeos…). El 30% por datos y tablas. El 10% por texto. ¡La documentación no es un tratado ni una novela para leer!

No todos los documentos son documentación; el proyecto requerirá distintos tipos de documento. Tu equipo, en cambio, necesita documentación.

Cómo es una documentación de verdad

Una buena documentación de diseño responde a pocas preguntas de forma inequívoca: ¿qué es este juego? ¿Por qué es interesante? ¿Cuál es la fantasy, la promesa emocional que le hace al jugador? ¿Cuáles son las features core —no todas las features, solo las que definen la identidad del producto—? ¿Cómo funciona exactamente este sistema? Y suficiente contexto de producción como para que el documento sea accionable.

Hay un principio que me resulta especialmente útil en este sentido: si un equipo no es capaz de explicar su juego de forma clara y concisa, probablemente el diseño todavía no está suficientemente claro. La claridad de la documentación refleja la claridad del pensamiento. Un documento denso, lleno de secciones y subsecciones que intentan cubrir cada eventualidad, es a menudo la señal de que aún no sabemos lo suficiente para documentar.

Y esto nos devuelve a la regla número 1. Si todavía no tienes algo concreto que documentar, quizás no es el momento de escribir documentación. Es el momento de investigar. De construir un prototipo. De testear. De responder a las preguntas que aún no sabes que tienes. De aprender y descubrir.

¿Esto documenta algo que existe, o algo que queremos construir?

Prototipos para aprender

Published by Paolo Gambardella on 20/05/2026

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Los prototipos son uno de los campos en los que el game design ha evolucionado muchísimo en los últimos meses. Los nuevos algoritmos de machine learning y automatización permiten a todo el mundo ser mucho más rápido a la hora de desarrollar artefactos que necesitamos para aprender y para que nuestro equipo aprenda. Esto es un gran avance, pero puede agudizar una tendencia que he visto en algunos equipos: crear un prototipo demasiado sofisticado que acaba convirtiéndose en una demo.

El prototipo sirve para aprender, para responder preguntas. Una demo sirve para convencer, para conseguir el greenlight, para vender. El problema surge cuando creas un prototipo tan pulido que parece convincente, pero tan ambiguo que no puedes decir que estabas aprendiendo nada. Al final no aprendes nada y no convences a nadie.

Pongo un ejemplo práctico. Si es la primera vez que lees esto, debes saber que soy consultor de game design especializado en ideación y preproducción de nuevos videojuegos, sobre todo free-to-play. Tengo un pequeño estudio y la semana pasada, junto con mis colaboradores, creamos este prototipo usando Godot:

  • El proyecto arrancó el lunes con una visión que llevo tiempo madurando y que plasmé en un documento de visión
  • Mi ayudante Eduard investigó otros juegos y el miércoles me entregó un concept document
  • El jueves le pasé ese documento a Claude Code y le pedí que me generara un prototipo base
  • Del viernes al domingo fui haciendo pequeños ajustes según las ideas que me iban surgiendo mientras me dedicaba a otras cosas.

Después de entregarle el resultado a mi ayudante, lo estuvo probando durante un día entero y me dio su punto de vista. La conversación derivó mucho hacia problemas del tipo “el track generado es monótono” o “no consigues chocar con los coches”. Todo eso tiene sentido a partir de la demo, pero no en esta fase. Entre los dos, discutiendo, conseguimos identificar el aprendizaje real, qué es lo que nos gusta de este prototipo. Lo dejamos apartado, lo documentamos y pasamos a la siguiente fase de aprendizaje.

Si no hubiéramos sido dos, si hubiéramos estado en una empresa más grande, probablemente también habríamos tenido que preparar una presentación con los learnings para alinear al equipo. Así es como a mí me gusta trabajar, pero os digo una cosa: la tentación de querer resolver los problemas técnicos o mejorar las “inteligencias” artificiales de los rivales virtuales fue muy grande. ¿Por qué? Porque ahora es fácil, es rápido.

Tú puedes hacerlo, pero tu competidor también. Para mí gana quien se centra en las cosas correctas en el momento adecuado. Hoy más que nunca hace falta criterio. Un contacto mío me comentó que en la App Store los tiempos de aprobación se están alargando muchísimo debido a la cantidad de apps “vibe-coded” que les están llegando a los moderadores. Si vamos a esperar más para nuestras aprobaciones, al menos que sea por algo que realmente merezca la pena.

Una buena época para el diseño de juegos

Published by Paolo Gambardella on 19/05/2026

Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.

Durante los años del boom del free-to-play en móviles, esta parte de la industria del videojuego fue rápidamente dominada por el product management. En cierto modo se entiende, dado que el negocio del free-to-play gira en torno a la adquisición de jugadores, es decir, el performance marketing. Si el coste de adquirir un jugador es inferior a lo que ese jugador invierte de media en el propio juego, tienes un negocio que funciona.

Así, trabajar como game designer en esas empresas se convertía muy a menudo en una conversación basada puramente en datos. Yo mismo me encontré en más de una ocasión discutiendo con mis jefes sobre cuestiones que podríamos resumir como: mi criterio VS la realidad actual del mercado. Pongo un ejemplo concreto: si yo, como diseñador, consideraba que cierta fantasía tenía que expresarse mediante mecánicas específicas porque tenía el presentimiento de que funcionaría, la respuesta habitual era: “de acuerdo, ¿y dónde has visto eso? ¿En qué otros juegos?” Muy a menudo era algo que venía más bien de una experiencia personal, o de otra cosa. Quizás una aplicación, una película o una exposición que había visitado me daba una idea. Nada, tenía que encontrar sí o sí la manera de explicarlo con datos.

Y en efecto, los diseñadores que luego han hecho más carrera en ese sector muy a menudo se autodefinen como data-driven. Son capaces de investigar lo que ya existe en los juegos de éxito y reaplicarlo como una fórmula matemática al juego en el que trabajan. Todo el respeto — es una buena habilidad. Pero para mí un diseñador debe tener tanto un sentido del contexto de negocio como buen gusto. Porque, ya que estamos poniendo tanta energía, bien vale la pena crear algo nuevo, poner algo de uno mismo. A la gente le gusta cuando tienes algo que decir.

Creo que este es nuestro momento, ahora. El momento de los diseñadores que quieren expresar su propio criterio. En mi opinión, el diseño puramente basado en datos ha muerto. En realidad siempre fue un trabajo repetitivo y poco creativo, pero creo que en la era de la IA — donde un agente hace todo eso en mucho menos tiempo y a una fracción del coste — es mejor cultivar nuestro propio gusto. Mejor ver películas, estudiar otro tipo de aplicaciones, ir a exposiciones. Mejor, en definitiva, buscar de verdad nuestra propia voz.

Lo que creo, y en lo que siempre he creído, es en el diseño informado por datos. Todo diseñador que se precie debe intentar siempre empatizar con los jugadores, y no hay mejor manera de hacerlo que recopilando datos. Pero esto no debe condicionar nuestro gusto, o siempre estaremos ofreciendo caballos a quien necesita algo nuevo — como vender carruajes en tiempos de Henry Ford. Un diseñador no puede ir a ciegas.

Pero un game designer debe tener la posibilidad de crear, de aportar algo nuevo al mundo. Es absurdo contratar a personas para que repitan fórmulas, y creo que eso está condenado a desaparecer, porque ahora tenemos el algoritmo adecuado. Un algoritmo que nos permite concentrarnos en lo que realmente importa.

Powered by