Diseño de videojuegos #01. Entrando

Esta entrada se ve mejor en el NUEVO BLOG. Revísalo aquí: https://danimally.wordpress.com/2017/06/24/diseno-de-videojuegos-01-entrando/

Durante estos meses he estado compaginando mis esfuerzos con un sector que es casi totalmente desconocido para mi: la industria del videojuego. Y no estoy hablando de jugar a videojuegos y hacer gameplays o los famosos e-sports, hablo de cómo crear un videojuego. Aquí os explicaré, a modo histórico-reflexivo, qué pasos sigo para comprender la industria, y con suerte, quizás hasta ser parte de ella. Puede que os ayude, o lo que es mejor: os ahorre tiempo.
Ante todo, vivo en Málaga. Quizás tenga mucho o poco que ver con querer de primera mano trabajar en la industria del videojuego. En Málaga capital tenemos la suerte de contar con varias iniciativas que permiten a los locos que quieren trabajar en videojuegos unirse y hacer piña. Una de ellas es Málaga Jams, y ya en un contexto más grande tenemos Polo Digital.
Pero todo eso no lo sabía, así que comencé en el diseño de videojuegos de la forma más tosca: sólo y diseñando directamente el videojuego. Y cómo no, hacer un Trabajo de Fin de Grado sobre ello. En primer lugar como práctica me lancé a RPG Maker VX Ace, un programa casi de juguete para crear tus propios videojuegos RPG.

• No os confundáis: RM es una herramienta y motor como cualquier otro y permite de forma intuitiva hacer un juego. Muchos lo odian porque muchos de los juegos resultantes son sólo redundar, son muy parecidos entre si en estilo de juego y gráfico. Pero eso pasa con todos los motores, simplemente RM es más popular y accesible que otros. No creo que nadie prejuzgue un corto porque se ha grabado con una cámara casera: lo juzgarán por la ejecución. Lo mismo deberíamos hacer con esto, no juzguemos al juego porque se hizo con RM, si no porque se ha hecho correcto o no. Creo sinceramente que RM es una de las mejores formas de iniciarse directamente. No requiere conocimientos de programación (a niveles básicos), y sólo necesitas sintáxis y algo de lógica. Un niño de 10 años sabría usarlo.

Así, siguiendo pequeñas guías y tutoriales creé un juego muy pequeño pero pulido: el Anillo de Udrai (podéis descargarlo aquí). La historia más simple que se me pudo ocurrir, pero incluso añadí misiones secundarias. Tardé sólo 4 días en hacerlo. ¿Qué descubrí con esto?

• Que quien aplique tiempo y esfuerzo puede crear un videojuego.
• Que puede ser más fácil de lo que parece.
• Que hay mucha información en internet.

Pero lo más importante:

• Que tu juego no lo probará ni tu madre a menos que se lo pongas en la cara.

Con esa práctica decidí presentar como TFG un diseño de videojuego. Pero, ¿por dónde empezar? En mi carrera existía una asignatura llamada "Diseño y desarrollo de videojuegos" que me enseñó de nada y menos a diseñar un videojuego. Así que tiré de libros.

Libros sobre Diseño de Juegos (para empezar)
Sí, ya había creado un juego. Ya parecía que sabía hacer, pero no sabía cómo lo sabía. Quizás por suerte o por inspiración conseguí un resultado apañado, quizás tenga algo que ver que llevo toda la vida entre videojuegos, pero de un sólo golpe de suerte no se vive. Tengo claro por mi carrera y mis trabajos que cualquier creación de la industria cultural es más artesanía que arte.

• Spielberg no hace películas para "hacer arte", las hace para vender. Si puede aplicarle arte, lo hará, pero en realidad es un proceso mecánico y comprensible para maximizar el beneficio y reducir los costes de producción. Luego, con suerte, alguien llamará "arte" a lo que has hecho. Lo siento por la frialdad pero hay que comer, gente.
• Considero que hay que aprender desde lo básico y luego a lo complejo. Sé que existen métodos, libros o técnica "avanzadas" con las que nos gustaría trabajar desde un principio, pero estoy seguro de que no las aplicaré bien si no coloco una base estable. Creo que esta forma de aprendizaje es la mejor, al menos para mi.

Muchos han pensado eso y comprendido que existe una "plantilla" general para crear videojuegos. En general son gente que escribe en inglés. Un consejo: aprende inglés o abandona el mundo audiovisual. Así de claro. Y otra segunda aclaración: los libros son sólo guías. No hay que seguirlos a rajatabla pero se han enfrentado a problemas que seguramente tú tendrás en el futuro, y aunque coinciden en muchas cosas cada uno ataja el diseño de una manera. Lo mejor es leerlos, entenderlos, y aprehender (con h) lo que creas necesario.

1. "Level Up!" de Scott Rogers. Empieza aquí, léelo de una pasada. Scott es un señor que trabajó para Namco, Capcom, Sony, y ha creado cosas como God of War (2005), Darksiders (2010) o Drawn to Life (2009) entre otros títulos. Escribe de forma fácil y se aproxima al diseño de forma clásica, y su libro es ameno, divertido, y sentará unas bases fenomenales. Aquí es donde descubrí las diferenciaciones entre mecánicas y jugabilidad, la importancia de dividir en secciones el trabajo y estar acorde a un calendario.
2. "Fundamentals of Game Design" de Ernest Adams. Este es el libro del que mi profesor se copió completamente y entendió totalmente mal. Entra en mayor profundidad sobre conceptos de desarrollo y las mecánicas del juego. También explica la importancia de las interfaces, o las diferencias de trabajar en plataformas al uso y dirigirnos al teléfono móvil. Lo importante: hacer el juego comercial y que atraiga a los publicadores.

-->"Don't Make Me Think, Revisited" de Steve Krug. No va de videojuegos. Pero va de una cosa que todos los juegos necesitan, que es la usabilidad. El campo que cubre va dirigido al dispositivo de juegos que cubre actualmente el 80% del mercado, osea, el teléfono móvil. Así que saber cómo diseñar contenido para móviles es crucial. Se lee en un par de horas y te servirá para todo tu trabajo. Hay libros más complejos sobre usabilidad y quizás algunas cosas te parezcan obvias, pero son cruciales. No lo busques en castellano: está mal traducido por intépretes baratos de sudamerica y Google Translate. ¿Sólo tres libros? Sólo para empezar, no son la "santa trinidad" pero creedme que son la base para comprender.

Lo que siguió a esto fueron dos meses de trabajo diario. Todos los días aplicaba aproximadamente unas 3 horas para intentar hacer comprensible la idea de juego que tenía y crear un documento de diseño de juego (Game Design Document o GDD) adecuado. Quizás alguien más listo hubiese tardado menos, pero no soy tan listo como otros. Sólo soy metódico.
Finalmente creé un "Proyecto de Documento de Diseño de Videojuego", titulado Conflict & Jewels. La premisa era simple: haz combos de gemas en un puzzle, y con los puntos reclutas a tropas que luchan "solas" para destruir la base enemiga. ¿Qué aprendí mientras lo hacía?

• Escribir tus ideas de diseño es complicado, y a veces aburrido.Traducir lo que tienes en tu cabeza a un papel donde expliques paso por paso cómo funciona es pesado, y cuanto mayor envergadura tenga el proyecto es peor. En Conflict & Jewels diseñé un juego a mi forma de ver sencillo y rápido, que podría hacer creado con RPG Maker, pero sin embargo descubrí que su diseño puede ser tan complejo o incluso más que el desarrollo mismo del videojuego.
• Boceta un Ten-Pager Document antes de crear. No hay que partirse la espalda escribiendo documentos de diseño sin ton ni son. Debes primero comprobar si la idea es viable. Explora durante un par de días tu idea, invierte 10 páginas en crear un texto que apile las ideas principales y luego decide si quieres enséñarlas a la gente.
• A nadie le importan tus ideas, así que cuéntalas. Una cosa que siempre dice mi madre es "el no ya lo tienes". Así que si pruebas y pierdes te quedas igual, pero si ganas mejoras. Antes de iniciar el GDD prepara bien las ideas y muéstralas. Cuéntalas, descubre opiniones, prepara dibujos cutres. No, nadie te va a robar las ideas, la mayoría son tan vagos que no pueden aplicar el esfuerzo en hacerlas realidad. Así que aprovecha. Recuerda: no queremos perder tiempo en un proyecto que no va a funcionar, así que cuanto antes descartes una idea, mejor. Si no la descartas y ves que tiene un buen feedback, adelante. Yo descarte 3 ideas distintas antes de dar con Conflict & Jewels, y el proceso sólo tardó una semana y media.
• Si el proyecto es muy pequeño, no merece la pena crear un GDD. Quizás un boceto de unas 10 páginas, pero en ocasiones ni siquiera eso. No te engañes: siempre aplicas diseño de juego al crear un videojuego, pero no siempre es rentable en tiempo crear el documento. Esto es algo que se aprende en las Game Jams, donde sólo tienes dos días para crear un juego. Haz un boceto, pero no intentes hacer un Ten-Pager.
• Si el proyecto es grande, es COMPLETAMENTE necesario un GDD. Puedes tardar entre dos y cuatro meses en escribir un documento de diseño "apañado". Una vez confirmado que tu Ten-Pager es correcto, ya puedes empezar a crear el GDD puro e incluso teclear algo en desarrollo. Repito: es muy importante confirmar que la idea funcionará antes de embarcarte en esta mierda.
• Otra vez, A NADIE le importan tus ideas, y menos leerlas. Tras escribir el GDD descubres aterrado que poca gente tiene el tiempo o las ganas de leerlo. Tu equipo sabe en líneas generales o en partes qué debe hacer, pero no ven el "conjunto". No te asustes y no intentes explicarles todo por completo, y menos obligarles a leer ese GDD de 324 páginas. En su lugar, busca forma de esquematizar o resumir, y responde a dudas puntuales o haz indicaciones.
• El diseño de videojuegos es algo vivo. No es estático. No se equivoquen pensando que cuando han escrito algo eso está tallado en piedra. Aunque en papel todo parezca funcionar, en la realidad no, o quizás descubráis soluciones mejores. Así que esos cambios deben reflejarse en el GDD. Recuerda que al hacer diseño de juegos debes saber explicar el conjunto sin hacerles leer la Biblia.
• Ninguna idea anterior es descartable. Anota las variaciones, y haz un seguimiento de las iteraciones del desarrollo y el diseño. No descartes nada, incluso si sabes que es completamente inutil. Tenlo organizado todo porque de las ideas más extrañas y más descatables pueden surgir utilidades. Un ejemplo: la parte superior de la caja de la pizza parece que solo es una tapadera, pero hay quien la recorta y usa para coger trozos de pizza sin mancharte. Es un ejemplo tonto, aunque espero que se entienda.
• La monetización es el ideal. Incluye siempre una sección de monetización. Aquí es donde indicas si existe una tienda en el juego y qué permite comprar. Cubre aquí también si habrá futuros episodios, DLCs, Season Passes, e incluso el merchandising físico y digital. No te equivoques: tu juego, sobre todo si es grande, busca ganar dinero. Claro, no siempre el juego nacerá con monetización. Pero plantea siempre esta parte en los diseños grandes.
• Se debe ser conciso, claro y no repetitivo. Hay que usar las palabras exactas para cada cuestión, crear glosarios de palabras para las mecánicas y acciones del juego. Quizás "Avanzar" con mayúsculas significa la acción de mover al persona hacia delante, o quizás te refieras al hecho de pulsar en la intefaz un botón para ir al siguiente menú.

Esa es sólo una pequeña lista de consejos. Decid que más tarde descubriría otras cosas, pero dejo estos por ahora. Si se os ocurren otros sólo comentadlos. Una vez más aunque redunde, es importantísimo saber si tu idea es viable antes de empezar a crear el documento de diseño. No hagas nada hasta saber eso.
En la siguiente entrada os contaré cómo poco a poco el proyecto fue tomando forma, cómo se hizo  cada vez más claro, más viable, y más apañado, y cómo una idea que academicamente no funciona si lo hace para el público. Y por supuesto, recorreremos más aspectos concretos del diseño de videojuegos.
Espero que os haya gustado leer esto, y si habéis llegado hasta aquí, muchísimas gracias.