Hace unos pocos años, cuando estudiaba en la universidad, decidí desarrollar un juego junto a un par de amigos. Por aquel entonces, no tenía ni idea de lo que conllevaba el desarrollo de un videojuego y no conocía el diseño como disciplina, pero años más tarde descubriría que algunas de las cosas que hicimos tenían mucho más sentido y eran más habituales de lo que se podía pensar. Esta es la breve historia de un juego que jamás llegó a ser.

Corría el año 2008, la crisis sólo era psicológica, y yo era otro estudiante de ingeniería frustrado más, que no entendía la mitad de las cosas que estudiaba ni mucho menos para qué servían (eso no ha cambiado mucho). Pero por suerte tenía mucho tiempo libre, así que podía trastear con DirectX y 3D Studio Max. Aún pensaba que todo estaba a mi alcance, así que después de montar un minijuego de coches que no funcionaba nada bien (y que nunca acabé), ya me creía que con un poco más de práctica y planificación podría hacer un Grand Theft Auto.

La idea

Aparte de programar sin mucho atino en mis ratos libres, leía un libro sobre la carrera espacial que me había dejado mi tío. Era un tema muy interesante, por lo que no tardó en inspirarme y enseguida empecé a imaginarme un videojuego.

La brillante idea que se me ocurrió era un juego de estrategia y gestión sobre la carrera espacial. El jugador tendría que llevar una agencia espacial desde los años cincuenta hasta un futuro de ciencia ficción (otro de mis temas favoritos), investigando tecnologías, lanzando satélites y cohetes, dirigiendo astronautas en misiones espaciales, etc. Había nacido el «concepto de juego».

De la cabeza al papel

Tras comentárselo a un par de amigos, que aceptaron como buena esta descabellada ocurrencia, nos pusimos a empaparnos de la cultura espacial: la historia, la física básica de los cohetes, los accidentes y sus causas, el viaje a la Luna, las estaciones espaciales, etc.

Muy pronto fue necesario organizar el caos informativo, así que comencé a escribir un documento de texto resumiendo las ideas generales del juego, descripción de las posibles pantallas, y especificaciones de algunas fórmulas que utilizaría. Este documento, además nos serviría para que todos estuviéramos al día en el desarrollo y pudiéramos discutir adecuadamente sobre el juego con él delante. Conforme íbamos concretando más ideas, fueron necesarios otros documentos nuevos, con información más detallada y específica sobre ciertos aspectos del juego, como un árbol tecnológico, o una especificación más concreta de alguna pantalla.

No lo sabía entonces, pero estaba escribiendo lo que se conoce como «documentos de diseño».

Del papel al prototipo

Sin embargo, aún con las ideas más claras, había muchas dudas a resolver. Una de las fórmulas en las que se basaba el juego, la que calculaba el alcance de los cohetes, no parecía muy ajustada para ser divertida, y era complicado imaginarse sus posibles resultados (ya que no es fácil visualizar un logaritmo neperiano).

Así que, para entender mejor cómo funcionaba, decidimos usar una hoja de cálculo. En esta hoja podía poner celdas con las distintas variables de la ecuación y observar directamente cómo los cambios en estas variables afectarían al resultado final. Paulatinamente fuimos añadiendo otros elementos, incluyendo algunos valores que tendría el juego final y en poco tiempo teníamos una hoja bastante completa con el funcionamiento detallado de una de las mecánicas principales del juego: un «prototipo jugable».

En resumen

Nunca llegamos a avanzar mucho más en el juego, sin embargo, es un buen ejemplo de porqué son necesarias y qué lleva a algunas de las prácticas de diseño de videojuegos que se usan hoy día.

Tanto si se trabaja en solitario, como en compañía es muy buena idea llevar algún tipo de documentación donde se exponga la descripción del juego. Puede servir para tener las ideas claras, más orientado el desarrollo, y que todos los miembros del equipo tengan el mismo concepto y estén al día. Será útil también para saber por qué se tomaron algunas decisiones, y para recordar conceptos claves. Y el simple hecho de escribirlo además puede ayudar a encontrar posibles flaquezas en el diseño. Sin embargo, tampoco se debe abusar de la documentación, ya que complica la tarea de llevarla al día y es más difícil de leer. Como bien dijo un profesor que tuve:

Demasiada documentación es contraproducente, poca es peligroso, ninguna es suicida.

Sobre cómo debe escribirse esta documentación, no hay ninguna regla o directriz que sirva para todos los casos. Según el proyecto será mejor un tipo de documento u otro, con más dibujos, con menos dibujos, en un documento de texto, en una presentación, en una Wiki, lo que haga falta. Eso sí, por norma general hay que tener en cuenta que a nadie le gusta leer mucha documentación y normalmente nadie lo hará (incluido uno mismo), así que cuanto más concisa sea, mejor (por ahí incluso se habla de documentos de diseño de una sola página). En cualquier caso, el estilo debe buscar la mejor forma de comunicar las ideas, teniendo en cuenta, sobretodo, a quién va dirigido.

Con el procesador de textos, el cuaderno, o el papel higiénico delante y ya en la faena de diseñar, surgirán dudas sobre si una determinada mecánica funciona, cómo se puede hacer, o qué valores serían adecuados en algún sistema. Para dispar esas dudas nada mejor que un prototipo con el que poder jugar y observar exactamente el comportamiento. Un buen prototipo permitirá hacer pruebas rápidas en un escenario lo más parecido posible al que habrá finalmente. Es importante tener en cuenta que según lo que se vaya a probar, no hacen falta buenos gráficos, ni una programación limpia. Incluso puede no ser necesario programar lo más mínimo. Es posible que baste con una hoja de cálculo, o incluso un papel cuadriculado o un tablero de ajedrez. El mejor prototipo es el que menos se tarda en hacer y cumple específicamente un cometido, respondiendo a una pregunta o aclarando una duda. Es bueno pensar en un prototipo como algo que hay que tirar a la basura después: poco se suele poder aprovechar, y partir de él puede resultar perjudicial si se ha realizado rápido y sin pensar en el conjunto del juego.