Minientrada

Diseñando un juego #2: controles y mecánicas básicas

Después de un tiempo sin escribir, ya tocaba volver a realizar otra entrada para el blog. Desde la entrada anterior me he estado dedicando a terminar de elaborar el primer puzzle del juego (con su correspondiente documentación) además de parte del segundo, por lo que lo más lógico sería hablar de eso en esta entrada. Sin embargo, aún no me considero con los conocimientos suficientes para hablar sobre cómo hay que hacer los puzzles de una manera básica, teniendo en cuenta que, para mí, también es la primera vez que los elaboro. Por ello, prefiero relegar esa entrada para más adelante, contando mi experiencia al término de realizarlos y sobre los pasos que seguí para conseguirlo, sean los mejores o no.

Así pues, voy a dedicar esta entrada a los elementos que he ido enseñando en los vídeos, que son los controles y mecánicas en un juego. Esto lo comentamos brevemente en la entrada que escribí sobre lo básico para empezar a diseñar un videojuego y que, ciertamente, el argumento y la ambientación (en el caso de que la haya) pueden ser relevantes para que un jugador disfrute con nuestro juego. No obstante, el núcleo y la principal fuente de diversión de nuestro juego siempre serán las mecánicas de juego acompañados de un diseño de niveles que le proporcionen un reto superable al jugador. En otras palabras, el cómo lo jugamos.

Aunque hay que hacer el inciso de que es igualmente importante el diseño de niveles, en el que usando las mecánicas diseñadas hay que crear un reto, el cual siempre ofrece un desafío más difícil o complejo que el anterior, para así lograr mantener el interés del jugador. Además de muchas más cosas a tener en cuenta, que procederé a escribir más adelante en otra entrada.

De la misma forma, un juego que goce de unos gráficos exquisitos y de un argumento espléndido puede inspirar aversión hacia el usuario si sus controles y mecánicas son complejas, tediosas o han sido mal diseñadas. Sin embargo, si esas mecánicas son fácilmente asimilables e incluso adictivas, unidas a un diseño capaz de mantener la atención del jugador por el reto que ofrece, dará igual todo lo anterior. Y si no, que se lo digan a los juegos clásicos que han acabado en la cultura popular (Tetris, Pacman, Space Invaders…) o incluso juegos más actuales que técnicamente carecen de gráficos (VVVVV) o historia (Counter Strike, Worms).

Centrándonos en el tema, una vez que tengamos una ligera idea de sobre qué queremos hacer el juego, debemos preguntarnos:

  • ¿De cuáles acciones dispondrá el jugador para interactuar con el entorno que le ofrece el juego? Estas pueden ser tan básicas como caminar o saltar, o ser cada vez más complejas como disparar diferente según las armas de que disponga, lanzar conjuros que realicen diferentes cosas, etc. Todo esto sin olvidarnos de posibles acciones necesarias para poder interactuar con los menús disponibles en el juego.
  • ¿Qué realizan dichas acciones? Puede parecer un poco obvio el comentar que hace cada acción, pero realmente es necesario para tener claro qué hace la acción paso a paso, y de cómo afectan a otros elementos o al mismo jugador. Así evitamos interpretaciones erróneas de las acciones por otros miembros del equipo que desarrollen el juego.
  • ¿Cuándo se podrán realizar dichas acciones? No siempre tendremos las mismas acciones para todos los elementos disponibles en el juego ni todas las acciones se pueden hacer bajo las mismas condiciones. Por ejemplo, si un personaje está agachado para evitar que lo detecten, no podrá correr, o si está en mitad de un salto, no podrá saltar otra vez. O lo mismo un objeto del juego, no se puede coger pero si examinar.
  • ¿Cómo se pueden ejecutar las acciones? Para ello, es necesario saber de qué tipo de controles vamos a poder usar, dependiendo de la plataforma a la que estará destinada el juego sea un smartphone o tablet, consola u ordenador. Según nuestra plataforma elegida dispondremos de trazos y toques en una pantalla táctil, joysticks, botones, o teclas y ratón. Una vez elegida la plataforma y sabiendo de los controles disponibles, tendremos que ir asignandole a estos una acción a realizar, o incluso que si ejecutamos una serie de controles de una forma en concreto, también se haga. Pero cuidado, no es cuestión de asignar de forma aleatoria los controles y ya está, hay que tener en cuenta que estos se tienen que poder realizar de manera cómoda con los controles disponibles. Por ejemplo, en el caso de usar un mando, dispondremos las acciones que más se vayan a utilizar, en los botones más accesibles en el mando, y si se requiere de una combinación de botones para realizar otra acción, que estos dos botones sean fáciles de pulsar a la vez.

Cómo veis, a pesar de ser un tema relativamente sencillo, hay que pensarlo concienzudamente porque es con lo único que el jugador va a poder usar para comunicarse con el juego. Y si esta comunicación falla, todo lo demás se va desmoronando conforme el jugador se va frustrando por su impotencia. ¿Os imagináis jugar con las manos atadas y que os pidan pulsar tres botones a la vez para poder saltar en un juego? Pues esa es la idea a evitar.

Una vez más, espero que os haya gustado mi breve (pero larga) visión sobre cómo diseñar acciones para nuestro juego. Y si tenéis algún comentario, objeción o mejora, no dudéis en comentármelo por aquí o por las redes sociales.

Hasta la próxima entrada.

 

Finalizado el Documento de Diseño

Han sido unas semanas duras, no solo por el hecho de escribir semejante cantidad de páginas casi de una vez, si no por otros hechos. La mayoría no son relevantes para este blog de seguimiento del proyecto, pero al menos comentaré uno de los principales motivos de mi retraso: iré a la Gamelab y a la Indie Burguer Developer Awards en Barcelona del 26 al 28 de este mes. Ha sido un enorme jaleo el organizar el viaje, sobretodo por la parte económica para que no se disparara demasiado, pero finalmente ha salido todo bien. Todo gracias a los compañeros de Videoshock que me han invitado a estos eventos, y a los que finalmente podré desvirtualizarlos a ellos y a otros muchos más que se animen a saludarme.

También decir que espero que no ocurran atrasos tan grandes como este para las próximas partes de desarrollo del proyecto. Pues escribir un documento de diseño, o GDD (Game Design Document) para abreviar, tal y como el que he hecho desde 0, a pesar de contar con la guía de los otros documentos comentados en la anterior entrada, ha supuesto un enorme esfuerzo.

Sin más dilación, aquí tenéis el GDD de 1812: La aventura, del cual os comentaré algunas cosas que tendréis que tener en cuenta a la hora de leerlo:

Enlace al documento de diseño

Una vez le hayáis dado un vistazo, os habréis dado cuenta de la gran cantidad de páginas que componen este GDD. Son 53 páginas a día de la publicación de esta entrada, y seguramente en un futuro aumentará en bastantes más.

¿A qué es debido esto si estamos hablando de un juego que va a durar entre 30 y 45 minutos? Pues a que gran parte de este documento no es sólo para mí, quiero dejarlo como guía (o biblia por el tamaño) para las futuras personas que quieras realizar un GDD. Por ello me he tomado la molestia de organizarlo  en tantas secciones, y en cada la mayoría de estas, explicar en qué consiste cada capítulo y sección. Logrando destripar la mayoría de las partes que debería contener la mayoría de los videojuegos. Así, cualquier persona que quiera aprender sobre cómo realizar un GDD, sepa en todo lo que tiene que pensar a la hora de realizar el suyo propio. De hecho, futuras entradas en este blog serán para desglosar distintas partes (al menos las más importantes o a las que hay que hacer una mención especial) que componen este GDD.

Pues, seamos sinceros, un diseñador de videojuegos profesional no hubiera malgastado tanto tiempo en describir todas las secciones, algunas incluso que ni son pertinentes para 1812: La aventura. Lo que uno de verdad hubiera hecho en mi opinión (y espero que alguno de verdad me lo corrobore o me desmienta) es escribir directamente lo que necesita el videojuego, descartando las demás secciones o presuponiendo otras. E incluso ni hubiera escrito tanto texto en las partes que si hubieran necesitado escribir, si no, simplemente, realizar dibujos y esquemas con los que sus compañeros hubieran entendido rápidamente las mecánicas y el diseño a seguir en el juego.

Diseño de las estancias del castillo de Unepic, hecho en un cuaderno.

Diseño de las estancias del castillo de Unepic, hecho en un cuaderno.

Como veis, en la vida profesional, el GDD se adapta al diseñador y a sus limitaciones, pero en mi caso he optado a una versión más académica con todo lo que he considerado oportuno de incluir para un videojuego genérico, además de explicar cada sección.

Cómo último punto a comentar sobre el GDD, decir que no está completo y faltan varios elementos. Esto es porque, un GDD avanza a la vez que el proyecto, es lo que se llama un documento vivo en el que los desarrolladores del proyecto tendrán que revisar casi todos los días si existe una versión nueva, y si esta versión influye en su área de trabajo.

Y esto es todo por ahora, espero que os haya agradado mi trabajo y espero, de verdad, que sirva de inspiración para otros futuros diseñadores de videojuegos.

Imagen

Adelanto del Documento de Diseño

Empezando a escribir el GDD

Empezando a escribir el GDD

Como podéis ver en la foto, ya estoy empezando con el Documento de Diseño. O más conocido por su nombre en inglés: Game Document Design (GDD). Este documento, es la base sobre la que construir todo nuestro videojuego cuando nos propongamos hacer uno. Sirve tanto para esclarecer las cosas, como para que cada persona involucrada en el proyecto sepa con exactitud su labor en el videojuego. Sin embargo, no existe ninguna manera concreta de cómo organizar este documento y cuáles son las secciones necesarias. Todo esto depende del proyecto en cuestión, del género, y de las necesidades especificas del videojuego en sí, aunque hay algunas guías con directrices para orientarnos, la mayoría en inglés.

Yo, siguiendo el trabajo de otros compañeros como David Saltares (antiguo miembro de mi Escuela Superior de Ingeniería, el cual trabaja a día de hoy para Sony Entertainment Europe en Reino Unido) , he decidido realizar mi GDD en español y liberarlo con la intención de que le sirva a alguien y , de paso, enriquecer la documentación de habla hispana sobre el desarrollo de videojuegos. Al igual que me serví del GDD del proyecto final de carrera de David, conjuntamente con el artículo de Gamasutra sobre consejos de cómo realizar uno, y de varios GDD de aventuras gráficas tales como las de AI Lowe o del videojuego Resonance. Con todo ello, he conformado mi propia versión de un GDD. Uno más centrado en el desengranar cada paso necesario tanto para una aventura gráfica, pero manteniendo la mayoría de los puntos comunes que hay en los videojuegos en general.

Tal y cómo voy a hacer con la memoria de mi proyecto, el GDD tal y cómo se dijo en la presentación de este blog, será liberado bajo licencia GFDL 1.3. Además de eso, he optado por escribir el documento con el lenguaje LaTeX por su versatilidad a la hora de componer textos, introducir bibliografía, etc. Para ello, estoy empleando la web ShareLaTeX, con la que podemos crear nuestros proyectos (documentos), compartirlos con la gente para que lo vea o modifique y que además incluye un compilador online. Realmente, ShareLaTeX, es una herramienta útil a la hora de escribir documentos más avanzados que con Google Docs. El esfuerzo de aprender lo básico del lenguaje LaTeX, en el que por cierto existe un Wikilibro excelente para ello, es gratamente recompensado con la libertad con la que podemos modificar nuestro documento.

Sin más tardanza, os dejo el enlace de mi GDD en ShareLaTex, aunque los no registrados solo podréis ver el texto en LaTeX y no el PDF que resultaría. Cuando esté terminado, lo subiré tanto como en el repositorio del proyecto, como en el blog para el deleite de todos. Y que, cómo siempre, estoy abierta a sugerencias para la modificación del GDD y para nuevas entradas en el blog.

Enlace al GDD en ShareLaTeX.