SaxonDragon, sobre Prophesy of Pendor: "El modding me enseñó a liderar sin tener autoridad"

Tras dos artículos, ya sabes qué es Prophesy of Pendor 2 y qué pretende conseguir. Pero para entender por qué SaxonDragon es la persona capaz de construirlo, hay que volver al principio: al mod que lo originó todo, a la disciplina creativa que lo moldeó y a las lecciones, aprendidas a golpes, sobre cómo liderar a personas a las que nadie paga.

Esta tercera entrega recoge la parte más universalmente aplicable de la entrevista: cómo se hace realmente un gran mod, qué comparten el modding y el desarrollo comercial (más de lo que cabría esperar) y las dimensiones humanas del desarrollo de videojuegos que ningún documento de diseño menciona jamás. Tanto si llevas mil horas en Pendor como si nunca has tocado Mount & Blade, esta conversación tiene algo que decirle a cualquiera que haya intentado construir algo junto a otras personas.

La respuesta honesta es que Prophesy of Pendor conectó porque apliqué los mismos principios de diseño que habían ido forjando mi manera de pensar desde aquellas campañas de sandbox en los años setenta, pero esta vez contaba con una herramienta adicional que la mayoría de los diseñadores de juegos no utilizaban de forma explícita: un marco psicológico formal para entender por qué la gente juega en primer lugar.

Había dedicado mucho tiempo a ampliar el modelo motivacional de McClelland, un marco desarrollado originalmente para explicar las necesidades humanas de logro, afiliación y poder, extendiéndolo a lo largo de ejes adicionales para dar cuenta del espectro más amplio de necesidades que los juegos activan. Una vez que mapeas esas necesidades de forma sistemática y luego confrontas un juego con ese mapa, ocurre algo clarificador. Las grietas se vuelven visibles. Los lugares donde el diseño deja necesidades del jugador sin cubrir dejan de ser una vaga sensación de insatisfacción y se convierten en deficiencias concretas y abordables.

Cuando apliqué ese modelo a Mount & Blade y Warband, el panorama era claro. El juego base tenía unos cimientos extraordinarios: el sistema de combate, la estructura de mundo abierto, la guerra a caballo. Pero la capa de presentación tenía agujeros importantes. El lore era escaso. El mundo no se explicaba del todo a sí mismo. La sensación de consecuencia, de una realidad política y cultural viva que operaba alrededor del jugador, estaba poco desarrollada.

Los jugadores se relacionaban con el esqueleto de un mundo cuando merecían un mundo con carne. Prophesy of Pendor fue, en esencia, un intento de proporcionar esa carne, de rellenar los huecos que el mapeo motivacional había hecho visibles.

Lo que hizo la ejecución especialmente difícil, y quiero ser transparente al respecto, fue el entorno en el que se construyó. No tenía presupuesto. Ningún recurso profesional más allá de mi propio tiempo. Aprendía un nuevo lenguaje de programación sobre la marcha. Y lideraba un equipo de desarrollo de casi dos docenas de colaboradores a los que solo conocía como nombres de usuario en un foro, personas a las que nunca había visto, repartidas por distintas zonas horarias, unidas únicamente por el entusiasmo compartido por lo que estábamos construyendo juntos. Gestionar ese tipo de esfuerzo creativo distribuido y basado en el voluntariado es una disciplina en sí misma, y no una que venga con manual de instrucciones.

El resultado no fue lo que yo llamaría perfecto. Conocía sus limitaciones mejor que nadie, porque sabía hacia dónde apuntaba el diseño y exactamente dónde se quedaba corto. Pero la perfección nunca fue el objetivo principal. El objetivo era demostrar, tanto a mí mismo como a cualquier otro, que las habilidades seguían ahí. Que tras años alejado de la industria, aún era capaz de construir algo con lo que los jugadores se comprometieran profundamente y al que volvieran una y otra vez. Prophesy of Pendor respondió a esa pregunta de forma más contundente de lo que me había atrevido a esperar.

Lo que también hizo fue mostrarme, con considerable claridad, lo que necesitaba ser la siguiente iteración. Prophesy of Pendor fue la prueba de concepto. Lo que viene después es la expresión plena de la idea.

Es una pregunta fascinante, y habiendo trabajado extensamente en ambos lados de esa línea puedo darte una respuesta que quizá sorprenda a mucha gente: la diferencia es menos fundamental de lo que la mayoría asume. Es principalmente una cuestión de alcance y escala, no una distinción categórica en la filosofía creativa.

Piensa en cómo se construye la mayoría de los juegos comerciales hoy en día. La gran mayoría utiliza middleware, motores como Unity o Unreal, y cuando construyes dentro de esos motores estás, por definición, trabajando dentro de la casa de otro. Operas dentro de un marco que no has arquitectado, sujeto a restricciones que no has diseñado, dependiente de sistemas que no controlas del todo. La casa tiene muebles distintos a los de un mod, y bastante más metros cuadrados, pero la realidad estructural es notablemente similar. Siempre hay paredes que no puedes mover.

En el modding, la restricción específica es lo que los desarrolladores llaman la caja negra: los sistemas con código cerrado en el núcleo del juego original que sencillamente no son accesibles para su modificación. Trabajas a su alrededor, trabajas con ellos, encuentras soluciones creativas que alcanzan tus objetivos de diseño dentro de sus límites, pero no puedes reescribirlos. Eso exige un tipo particular de creatividad disciplinada: aprender a trabajar a favor de la corriente de un sistema en lugar de contra ella, encontrar los espacios donde tu visión y la arquitectura del motor pueden coexistir de forma productiva.

La diferencia más profunda, en mi experiencia, tiene menos que ver con la libertad creativa y más con la naturaleza del compromiso. Cuando tienes un equipo de desarrollo profesional a tiempo completo, dispones de algo enormemente valioso que es fácil dar por sentado: la fiabilidad. El trabajo está documentado. Los procesos están establecidos. Cada miembro del equipo aparece, completa sus tareas asignadas y se puede contar con él para entregar. La maquinaria funciona de forma constante.

Un equipo de modding opera sobre una base completamente distinta. Tus colaboradores son condicionales: están ahí porque aman el proyecto, y en el momento en que la vida les exige atención en otro lado, el proyecto espera. Los niveles de habilidad varían enormemente. La disponibilidad fluctúa sin previo aviso. La documentación es inconsistente en el mejor de los casos. En la práctica, estás liderando una organización de voluntarios que se mantiene unida por el entusiasmo compartido, y el entusiasmo compartido, por muy real que sea, es un aglutinante más frágil que un sueldo y un contrato.

Pero aquí el panorama se vuelve más matizado, porque los equipos de modding llevan consigo algo que los equipos profesionales no siempre tienen, y que importa más de lo que la gente reconoce: la pasión. La gente se une a un equipo de modding porque ama el juego base y cree en la visión de lo que están creando juntos. Esa pasión es autoseleccionada y autosostenida.

Nadie rellena una solicitud para modear un juego que no le importa.

Lo que el modding me enseñó, en definitiva, fue a liderar sin autoridad: a inspirar una contribución constante de personas a las que nunca había conocido, usando únicamente la calidad de la visión y la cultura de la comunidad como herramientas. Esa es una habilidad que se transfiere directamente a cualquier entorno de desarrollo, comercial o de otro tipo, y no la cambiaría por nada.

Es una pregunta con muchas respuestas honestas, y quiero resistir la tentación de darte solo una, porque los mayores retos en el desarrollo de videojuegos, ya sea modding o comercial, tienden a agruparse en torno a un núcleo común del que casi nunca se habla en los círculos de diseño. Hablamos mucho de tecnología, de sistemas y de pipelines. No hablamos ni de lejos lo suficiente sobre las dimensiones humanas de hacer juegos, y esas, en mi experiencia, son donde se libran las batallas de verdad.

El liderazgo es la base sobre la que descansa todo lo demás. No el tipo de liderazgo que impone autoridad o dicta la visión desde arriba, sino el que crea las condiciones para que el buen trabajo ocurra.

Eso requiere, ante todo, la capacidad de escuchar, y me refiero a escuchar en el sentido más pleno de la palabra. Escucharte a ti mismo, para que tus instintos y tus principios de diseño permanezcan alineados a lo largo de un ciclo de desarrollo que hará todo lo posible por separarlos. Escuchar a tu equipo, porque las personas más cercanas al trabajo ven cosas que el responsable de diseño no puede ver desde la distancia. Escuchar a tus jugadores, porque te dirán, con claridad, con insistencia y a veces con bastante poca delicadeza, exactamente dónde tu visión y su experiencia han divergido. Y escuchar a todos los demás: los críticos, los escépticos, las voces que no pediste, porque esas suelen ser las que llevan la información que más necesitas oír.

Quizá el reto más subestimado de todos es mantener una visión coherente a lo largo de un ciclo de desarrollo que puede abarcar años. La expansión descontrolada del alcance es real. La rotación del equipo es real. La tentación de perseguir tendencias, de responder a cada comentario de los jugadores con un cambio de diseño, de dejar que la visión se difumine en los bordes a medida que se acumulan el tiempo y la presión: todo eso es real.

Mantener la línea sobre lo que el juego es fundamentalmente, mientras se permanece genuinamente abierto a cómo puede mejorarse, es un equilibrio que exige una atención constante y consciente.

Y luego está el ego. Dejarlo en la puerta no es una decisión que se toma una sola vez; es una práctica diaria. En el momento en que te importa más tener razón que hacer algo grande, has perdido el hilo.

Asumir la realidad de que no lo sabes todo, de que los miembros de tu equipo verán soluciones que tú no has contemplado e identificarán problemas que tú no has detectado, no es una concesión de debilidad. Es la posición estratégicamente más inteligente que puede ocupar un responsable de diseño.

Reducir la distancia de poder entre tú y tu equipo, crear un entorno donde el feedback fluya libremente en todas las direcciones y nadie tenga miedo de decir que algo no funciona, produce sistemáticamente mejores resultados que cualquier cantidad de brillantez individual aplicada en solitario.

En el desarrollo comercial específicamente, los retos cambian de énfasis aunque no de naturaleza. La tecnología en constante evolución es una presión permanente. Comunicarse eficazmente con el cliente, las personas que financian el desarrollo y en cuya confianza depositas tu trabajo, es una disciplina en sí misma. Necesitan entender qué van a recibir, cuándo lo van a recibir y qué riesgos existen entre el punto de partida y el de llegada. Eso requiere un nivel de transparencia que puede resultar incómodo, porque la respuesta honesta a muchas preguntas de desarrollo es: todavía no lo sabemos.

Y por último, los hitos. Hitos alcanzables y realistas que incorporen margen para lo imprevisto, porque en el desarrollo de videojuegos lo imprevisto no es la excepción, es la norma. Todos los calendarios de desarrollo que he visto han sido humillados por lo inesperado. La diferencia entre los equipos que sobreviven a esos momentos y los que no se reduce a una sola cosa: si construyeron espacio para la realidad en sus planes. El margen no es pesimismo. Es el tejido cicatricial de la experiencia.