¿Quién dijo que copiar es sencillo?

Siguiendo con el tema de la entrada anterior, quiero hablar un poco sobre lo que implica copiar en el ámbito de diseño de videojuegos. Por regla general, siempre que se va a emprender la realización de un juego se intenta ser original en un punto u otro, ya sea por motivos económicos impulsados por los que ponen la pasta (nadie quiere pagar por un juego que ya ha jugado, así que hay que hacer algo distinto) como por motivos puramente artísticos que vienen de los diseñadores (ninguna persona que se precie como creador quiere copiar, ya que siempre es un reto y un orgullo concebir lo nunca visto).

Si uno no va a fusilar un juego ya existente (en ocasiones algo relativamente sensato, no hay más que ver el éxito de Shadow Complex y compararlo con los Metroid clásicos en 2D) se suelen tomar dos enfoques de cara a dar un giro de tuerca (ya sea pequeño o grande):
  1. "No nos vamos a restringir por etiquetas, géneros u otros juegos. Vamos a hacer lo nunca visto". Esto suele llevar a la reinvención de la rueda. Esto es, acabas haciendo algo parecido a otro juego (realmente hay mucho inventado) pero sin haberte fijado ántes en el género o juegos en cuestión, con lo que tropiezas con todos los fallos que se han dado en ese género a lo largo de los años. Este planteamiento de por sí suele ser una trampa mortal.
  2. "Queremos un juego como X, pero añadiendo y alterando elementos para añadir más variedad/proponer una experiencia de juego distinta/cambiar el público al que va dirigido/lo que sea". Esto en ocasiones acaba con un juego que recuerda vagamente al que se tomó de base, pero que no funciona por haber modificado mecánicas de juego vitales en la experiencia de juego del original. El símil podría ser si un médico le da por cambiar el corazón a una persona y poner el de un mono, si total, son piezas intercambiables y seguro que funciona. La clave aquí está en hacer un buen análisis previo para saber qué se puede quitar, qué se puede poner, y qué ocurre con la experiencia de juego cuando se llevan a cabo modificaciones.
En ambos casos, y por mucho que duela, hay que partir de la base de copiar. O si queremos verlo de una manera un poco más suave (menos cínica, que demonios), estudiar bien nuestras referencias. El estudio del género en cuestión (de uno o varios juegos) es una herramienta no valiosa, sino indispensable, para cualquier diseñador de videojuegos. Con esto hay un par de problemas que he llegado a ver y que son un tanto preocupantes.

El primero es que no es lo mismo jugar juegos que estudiar el diseño de los juegos. En el libro The Art of Game Design se habla justamente de que vivir una experiencia y analizar una experiencia son cosas distintas, con un símil que me gustó bastante: uno no es consciente de su respiración por regla general, pero en el mismo momento en que le prestamos atención no podemos dejar de controlarla (haced la prueba). Sin embargo, con el suficiente entrenamiento (en el caso de la respiración se habla de la meditación) se puede llegar a un estado en el que uno tiene un pié en cada sitio, se puede respirar de manera automática (disfrutar del juego) a la vez que se es consciente de este proceso (analizar el juego). En resumen, el verdadero conocedor de diseño de videojuegos no es necesariamente el que se ha terminado doscientos títulos, sino el que es capaz de sentarse delante de uno con una libreta y entender por que funcionan algunos de sus elementos.

El segundo problema (o yo lo percibo como un problema) es algo que no se si tiene que ver con la mentalidad laboral, o con alguna otra cosa: es raro ver a un diseñador documentándose con juegos en horas de trabajo. Cualquiera (especialmente el que paga el sueldo) podría pensar que cualquiera que juegue a juegos en su empresa en horario laboral (sin ser de QA) es que es un vago. La triste realidad es que un diseñador no tiene por qué analizar diseño de juegos en su tiempo libre, al igual que yo no programo en casa, más cuando parece que no es lo mismo jugar juegos que diseccionar juegos.

En el Shadow Complex hicieron que el equipo entero jugar a los Metroid clásicos ántes de empezar el desarrollo del juego (se habla de ello aquí). Esto es importante no sólo de cara a saber en qué se está trabajando y qué se está tratando de conseguir, si no que sirve a un propósito mucho más interesante y útil a mi parecer: establecer un lenguaje y un léxico de comunicación entre diseño y el resto de áreas de desarrollo. No es lo mismo decir "queremos un sistema de combate rápido y dinámico, donde primen los reflejos y la habilidad del jugador, para que el combate sea fluído, frenético y con una dificultad muy ajustada" que "queremos hacer un sistema de combate parecido al del Ninja Gaiden, pero con algunas modificaciones". Esto no sólo supone una ventaja de cara a comunicación, sino que a falta de detalles concretos sobre la mecánica uno puede ir al juego en cuestión sabiendo que como planteamiento base está aprobado por diseño, aunque luego haya que modificarlo.

En cuanto a llevar a cabo buenos análisis de los referentes (importante hacerlo al principio, no cuando la mitad de las mecánicas están diseñadas), es importante porque permite evitar escollos contra los que han chocado otros (son igual de instructivos los buenos ejemplos a seguir, que los malos ejemplos a evitar), y porque permite obtener conocimiento de cómo se integran diversas mecánicas de juego en productos ya acabaos. Mi sueño sería que algún día algún diseñador me presentara algún análisis como éste, o incluso que yo fuese capáz de hacer algo parecido al proponer una solución a algún problema de diseño.

Moraleja: Que nadie se engañe, copiar a la hora de crear no es simplemente plagiar, es estudiar y entender el por qué de ciertas decisiones de cara a utilizar experiencias previas para nuestro propio beneficio. Y una buena labor de estudio es algo necesario y muy dificil de llevar a cabo, aunque creo que siempre merece la pena el esfuerzo. Básicamente, es tomar el enfoque que describió Bernardo de Chartres: ver más allá siendo enanos subidos a hombros de gigantes.