En 1989, el diseñador Ron Gilbert publicó un ensayo interno en LucasArts que acusaba a los juegos de aventura de estar rotos por diseño, y propuso arreglarlo con un diagrama de dependencia de puzzles: un mapa donde cada acertijo es un nodo y cada prerrequisito una flecha. Casi una década después, ese mismo método sirvió para diseñar Grim Fandango, y en 2008 una copia escaneada del documento original terminó publicada en un blog de videojuegos.
El hallazgo no es solo una curiosidad de archivo. El diagrama de puzzles que dibujaba LucasArts a mano es, en su estructura, el mismo grafo acíclico dirigido que hoy resuelve el orden de tareas en un sistema de build o en un pipeline de datos, y se puede reconstruir en minutos con Graphviz, Mermaid o unas pocas líneas de Python.
TL;DR
- Ron Gilbert introdujo el concepto de diagrama de dependencia de puzzles en su ensayo de 1989 'Why Adventure Games Suck'.- LucasArts aplicó la técnica al diseño de Grim Fandango, lanzado en 1998 bajo la dirección de Tim Schafer.- El bloguero Jason McIntosh publicó un escaneo del documento interno de LucasArts en gameshelf.jmac.org el 13 de noviembre de 2008.- El diagrama modela cada puzzle como un nodo y cada prerrequisito como una arista dirigida de un grafo acíclico dirigido (DAG).- Esa estructura es la que hoy usan herramientas como Make, npm o Airflow para resolver el orden de ejecución de tareas con dependencias.- Un algoritmo de ordenamiento topológico detecta automáticamente si el grafo de puzzles tiene un ciclo imposible de resolver.- Graphviz y Mermaid permiten construir hoy el mismo tipo de diagrama que LucasArts dibujaba a mano en los años 90.
Qué pasó
El 13 de noviembre de 2008, el bloguero Jason McIntosh publicó en The Gameshelf el escaneo de un documento interno de LucasArts: el diagrama de dependencia de puzzles usado durante el desarrollo de Grim Fandango, la aventura gráfica dirigida por Tim Schafer y lanzada en 1998 (Grim Fandango en Wikipedia). El archivo original es una imagen de gran tamaño, resultado de escanear una hoja de papel cubierta de cajas y flechas dibujadas a mano por el equipo de diseño.
Cada caja del diagrama de puzzles representa un objetivo o un hito de la historia, como conseguir el boleto de barco de Manny Calavera, comprar lija en el mercado negro o sobornar al inspector del Departamento de la Muerte. Cada flecha indica qué otro objetivo tiene que estar resuelto antes de que ese puzzle se vuelva accesible para el jugador. El resultado visual se parece más a un plano de circuitos que a un guion narrativo, y esa era justamente la idea, convertir el diseño de una historia no lineal en algo auditable con la vista antes de escribir una sola línea de diálogo. El documento circuló rápido entre comunidades de fans de LucasArts y hoy sigue citándose en foros y cursos de diseño de videojuegos como uno de los pocos artefactos de producción real disponibles públicamente para un juego de esa escala.
Grim Fandango se ambienta en una versión art-decó del mundo de los muertos, inspirada en el cine mexicano de los años cuarenta.
Contexto e historia
La técnica no nació con Grim Fandango. Ron Gilbert la describió en 1989, cuando trabajaba en LucasArts diseñando la primera entrega de Monkey Island, en un ensayo interno sobre por qué tantos juegos de aventura terminaban frustrando a quien los jugaba. Su diagnóstico era simple. Si un puzzle dependía de un objeto que el jugador podía perder, vender o dejar atrás en otra zona del mapa, el juego se volvía irresoluble sin ninguna señal previa de que eso había pasado. Antes de esa filosofía era común que las aventuras gráficas incluyeran objetos consumibles que dejaban al jugador sin forma de terminar el juego horas después, algo que Gilbert señalaba como uno de los peores pecados de diseño posibles (perfil de Ron Gilbert en Wikipedia).
La solución que propuso Gilbert fue dibujar, antes de escribir una sola línea de diálogo, el mapa completo de dependencias entre puzzles. Si ese mapa tenía un ciclo, un puzzle A que necesitaba a B y B que a su vez necesitaba a A, o un nodo que ningún camino podía alcanzar, el diseño estaba roto por definición, sin necesidad de jugarlo primero para descubrirlo. Grim Fandango, publicado casi diez años después de ese ensayo, heredó el método casi sin cambios. El documento que subió McIntosh es la evidencia directa de que el equipo lo siguió aplicando puzzle por puzzle, acto por acto, durante toda la producción del juego.
Detalles técnicos del diagrama de puzzles
En términos de estructuras de datos, un diagrama de puzzles es un grafo acíclico dirigido, conocido en inglés como DAG. Los nodos son los puzzles y las aristas apuntan del prerrequisito hacia el puzzle que habilitan. Esa restricción, que el grafo no tenga ciclos, es la misma que exige cualquier sistema capaz de resolver un orden de ejecución a partir de dependencias declaradas, desde un Makefile hasta un DAG de Apache Airflow.
El siguiente diagrama recrea, de forma simplificada, cuatro nodos típicos de ese tipo de documento:
flowchart TD
A["Conseguir el boleto de Manny"] --> B["Comprar lija en el mercado negro"]
B --> C["Sobornar al inspector del DOD"]
D["Hablar con Glottis sobre el auto"] --> C
C --> E["Salir de Rubacava"]
Conseguir el boleto de Manny habilita comprar la lija, y tanto la lija como haber hablado con Glottis sobre el auto son prerrequisito para sobornar al inspector, que a su vez habilita salir de Rubacava. Esa misma lógica sostiene un pipeline de integración continua, donde el paso de pruebas no puede arrancar antes que el paso de build si depende de su resultado.
HerramientaCuándo usarlaVentajaLimitaciónGraphvizDiagramas grandes generados por scriptLayout automático desde texto plano (DOT)Curva de aprendizaje de la sintaxis DOTMermaidDocumentación embebida en Markdown o wikisSe renderiza directo en GitHub y NotionSe desordena con grafos muy grandesMiro / draw.ioSesiones colaborativas de diseño en equipoEdición visual en tiempo real, sin códigoNo se versiona bien en GitNetworkX (Python)Validar el grafo con código, no solo dibujarloDetecta ciclos y calcula el orden topológicoNo genera un diagrama bonito por sí solo
La técnica tiene un límite práctico. A partir de varias decenas de puzzles, el diagrama se vuelve difícil de leer a simple vista incluso con herramientas de layout automático como Graphviz, y equipos grandes suelen terminar dividiéndolo por actos o capítulos, tal como parece reflejar la estructura del documento de Grim Fandango. Un diagrama de puzzles tampoco captura mecánicas que dependen del tiempo o del azar, solo relaciones de prerrequisito puro.
💭 Clave: un diagrama de dependencia de puzzles es, en esencia, el mismo grafo acíclico dirigido que usa un sistema de build como Make o un orquestador como Airflow para decidir en qué orden ejecutar tareas con dependencias.
💡 Tip: si documentás tu proyecto en GitHub o Notion, Mermaid se renderiza directo en el Markdown sin instalar nada extra, a diferencia de Graphviz, que necesita generar la imagen aparte con el comando dot.
Un grafo acíclico dirigido nunca permite que un nodo dependa, directa o indirectamente, de sí mismo.Cómo construir tu propio diagrama de puzzles
Para reproducir hoy el mismo ejercicio que hacía LucasArts a mano, alcanza con Graphviz, disponible en la mayoría de los gestores de paquetes con apt install graphviz en Debian y Ubuntu, o brew install graphviz en macOS. Un archivo .dot mínimo describe los nodos y las flechas del diagrama de puzzles en texto plano, sin necesidad de ningún editor gráfico.
digraph puzzles {
manny_boleto -> lija_mercado;
lija_mercado -> sobornar_inspector;
hablar_glottis -> sobornar_inspector;
sobornar_inspector -> salir_rubacava;
}
Con el comando dot -Tpng puzzles.dot -o puzzles.png ese texto se convierte en una imagen con el mismo tipo de layout automático que usan Graphviz y, por debajo, herramientas como Mermaid. El paso que en 1989 no existía es validar el grafo con código en lugar de revisarlo a ojo. La librería NetworkX de Python detecta ciclos y calcula un orden de resolución válido en apenas dos líneas.
import networkx as nx
grafo = nx.DiGraph()
grafo.add_edges_from([
("manny_boleto", "lija_mercado"),
("lija_mercado", "sobornar_inspector"),
("hablar_glottis", "sobornar_inspector"),
("sobornar_inspector", "salir_rubacava"),
])
print(nx.is_directed_acyclic_graph(grafo))
print(list(nx.topological_sort(grafo)))
La primera línea imprime True si el diseño es resoluble y False si hay un ciclo, es decir, un puzzle imposible de completar tal como está planteado. La segunda imprime un orden válido en el que, en teoría, un jugador podría resolver todos los puzzles sin quedar trabado. Para confirmar que tu propio diagrama pasa la prueba, corré nx.is_directed_acyclic_graph(grafo) después de cada cambio. Si devuelve False, hay una dependencia circular que conviene romper antes de seguir escribiendo diálogos.
Impacto y análisis
El diagrama de puzzles no resolvió el problema de que las aventuras gráficas fueran divertidas, solo el de que fueran completables. Esa distinción explica por qué la técnica sobrevivió cuarenta años. Es una herramienta de control de calidad, no de creatividad, y por eso encaja bien con procesos de ingeniería de software que ya usan la misma lógica de grafos para otras cosas. La persistencia de la idea se explica también porque no depende de ningún software concreto, sirve igual dibujada en papel en 1989 que generada por script en 2026.
Fuera de los videojuegos, la idea de modelar tareas como nodos con prerrequisitos es la base de gestores de paquetes como npm o de orquestadores como Apache Airflow, que calculan automáticamente en qué orden ejecutar cada paso a partir de sus dependencias declaradas. La diferencia con el documento de LucasArts es que ahí el grafo lo resolvía un algoritmo, no un diseñador con una regla y un lápiz.
Qué sigue
Estudios de diseño de videojuegos siguen citando el ensayo de Gilbert como referencia obligatoria en cursos de narrativa no lineal, y el documento de Grim Fandango circula como ejemplo real de que la técnica se aplicó en un juego comercial y no solo quedó en la teoría. En paralelo, la generación actual de herramientas de diseño narrativo, desde Twine hasta motores con soporte nativo para grafos, incorpora la validación de ciclos como una función integrada, el mismo chequeo que antes exigía dibujar todo a mano y revisarlo con la vista.
📖 Resumen en Telegram: Ver resumen
Probalo vos: instalá Graphviz con apt install graphviz y convertí en un archivo .dot las dependencias de tu propio proyecto para ver si el grafo esconde algún ciclo.
Preguntas frecuentes
¿Qué es un diagrama de dependencia de puzzles?
Es un mapa donde cada puzzle de un juego aparece como un nodo y cada flecha indica qué otro puzzle hay que resolver antes. Sirve para comprobar, antes de programar nada, que el juego se puede completar de principio a fin.
¿Quién inventó la técnica?
El diseñador Ron Gilbert, que la describió en un ensayo de 1989 mientras trabajaba en LucasArts, la empresa que después usó el mismo método para Grim Fandango.
¿Grim Fandango usó este diagrama durante todo su desarrollo?
El documento publicado en The Gameshelf muestra que el equipo lo aplicó acto por acto, siguiendo los distintos capítulos en los que se divide la historia del juego.
¿En qué se parece a un grafo de dependencias de software?
En que ambos son grafos acíclicos dirigidos. Un nodo no puede depender, ni directa ni indirectamente, de sí mismo, sea un puzzle de videojuego o un paso de un pipeline de build.
¿Qué herramienta conviene usar hoy para hacer uno?
Graphviz o Mermaid para dibujarlo, y una librería como NetworkX si además querés validar con código que el grafo no tiene ciclos.
¿Sirve para otros géneros además de las aventuras gráficas?
Sí. Cualquier diseño con progresión basada en prerrequisitos, como RPGs con árboles de misiones, juegos de crafteo o metroidvanias, puede modelarse con el mismo tipo de grafo.
Referencias
- The Gameshelf: el documento escaneado del diagrama de dependencia de puzzles de Grim Fandango, publicado por Jason McIntosh el 13 de noviembre de 2008.- Wikipedia: Grim Fandango: ficha del juego, año de lanzamiento y equipo de desarrollo.- Wikipedia: Ron Gilbert: biografía del diseñador que propuso la técnica en 1989.- Graphviz: documentación oficial de la herramienta usada para generar diagramas de dependencia a partir de texto plano.- Mermaid: documentación oficial de la sintaxis usada en el diagrama de este artículo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)