Know what you're doing (And do as you must)

Hay una pequeña anécdota reflejada en The Art of Game Design, concretamente al comienzo del capítulo 27, que en su momento me hizo reflexionar sobre algo que he hablado con compañeros de trabajo en multiples ocasiones. La historia es la siguiente:

Habla el autor sobre un estudio que estaba haciendo un juego de carreras, en un estado de desarrollo bastante avanzado. En una revisión del cliente (llamémosle publisher, inversor, o simplemente el que financia y manda) este hizo una pequeña sugerencia acerca del aspecto del juego: "Los coches tienen que estar más cromados". En ese momento el equipo se llevó las manos a la cabeza, ya que este cambio supondría rehacer los modelos de los coches y afinar el engine para nuevos efectos gráficos que no se habían tenido en cuenta al principio. En lugar de decir que si o que no, le preguntaron por qué al cliente, y este contestó que los coches daban la impresión de ir un poco lentos, y que un efecto de cromado podría dar una sensación de coches con más velocidad. Finalmente, y tras negociar un poco, se consiguió el mismo efecto acercando la cámara al suelo y aumentando ligeramente la velocidad de los vehículos. Final feliz.

Lo que se me vino a la cabeza al leer esto fueron las ocasiones en las que he oido peticiones de features para juegos por motivos como "porque es molón", "porque queremos hacer un juego de X género y esta característica es imprescindible" o "porque esta feature está de moda y vamos a poder vender mejor el juego". Algo muy interesante que se comenta en The Art of Game Design es que toda decisión de diseño debe de tomarse con un fín específico, sea cual sea este (aumentar la simplicidad o complejidad del juego, paliar algún problema, potenciar algún aspecto de la jugabilidad, etc...).

En resumen, que a la hora de establecer un diseño de juego, es importante no sólo saber qué se quiere, si no por qué se quiere. Un error común que he visto en alguna ocasión es incluir mecánicas de juego copiadas de otros juegos parecidos sin hacer un estudio detallado del motivo por el que esas mecánicas son como son; lo más obvio es pensar que cada feature en cada juego tiene un motivo detrás, que ha ido siendo desarrollada iterativamente hasta que ha encajado con el fín con el que se había diseñado. Por desgracia se tiende a pensar que si vale para un caso, vale para todos.

El hecho de tomar algo de otro juego sin pasar por un proceso de análisis suele traer más desgracias que otra cosa, más cuando llegado el momento el diseñador no entiende por qué en su juego esa mecánica funciona tan mal cuando en el juego original iba de maravilla. Esto también ocurre con las corazonadas y las revelaciones: si un diseñador no puede dar el razonamiento subyacente a la necesidad de una feature que quiere en el juego, es más que probable que la feature al final no encaje con la filosofía de juego, y que no haga más que consumir tiempo hasta que quede decente (poco probable), se decida abandonar en un estado intermedio (probable) o directamente se descarte (bastante probable).

Moraleja: No vale con saber qué se quiere o cómo se quiere, hay que saber por qué se quieren las cosas. El no llevar a cabo un estudio mínimamente decente a la hora de definir features y mecánicas indica una falta de metodología y rigor que puede facilmente llevar por el camino de la amargura a todo aquel que se cruce con la feature en cuestión.