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.

 

Diseñando un juego : Tengo una idea

Ya puestos a comenzar a destripar las partes más importantes de un GDD (Game Design Document o Documento de Diseño en español, recordemos), ¿qué mejor sitio que empezar por dónde comienza todo? Tal cómo indica el título de la entrada, hablo de las ideas de las que todos los juegos nacen. Tener una idea es muy sencillo, solo falta darte un paseo, ver una película, dormir, tomarse una ducha, mientras estamos haciendo nuestras necesidades… Cualquier cosa o momento que te inspire, divierta o transmita algo. A gusto de cada uno es el cómo obtener dicha idea.   Pero, ¿cuántas veces hemos escuchado (o leído en los foros) a alguien decir que tiene una idea buenísima (normalmente un The Legend of Final Fantasy) y que necesita a un equipo que le haga el juego? Todos hemos caído alguna vez en esto, yo inclusive. Y es que, ay amigos, esto es porque a muchos de nosotros aún nos cuesta entender que una idea por buena que sea, necesita ser trabajada.

Al igual que se tratase de una planta, la idea de un juego es la semilla de la que nace todo juego,  pero para que esta tenga frutos hay que cuidarla y desarrollarla.

Entonces, ¿que hay que hacer cuando tienes una idea?

Pues dependiendo de lo avanzada o difusa que tengamos la idea, se puede optar por hacer un pequeña lluvia de ideas, de forma que fluyan mejoras que avancen la idea o cambios (¡o incluso encontrar una idea mejor aún!). Y ojo, tener una idea con relación a una historia o mundo esta bien, pero recordad que un juego no es (ni siquiera en un JRPG) sólo su historia, sino también sus mecánicas, así que vendría bien (o mejor que una historia) pensar en cómo queremos que se juegue nuestro juego.

Una vez tengamos una idea más o menos consolidada, tristemente tenemos que bajar a tierra. Todo siempre es bonito en la cabeza tal y cómo imaginamos, pero otra cosa es lo que nuestras manos o mentes puedan hacer con ello.

Porque, en primer lugar, hay que plantearse la difícil pregunta de: “¿Puedo yo con mis habilidades hacer dicho juego con mi idea?” Y NO vale en dicha pregunta el que me lo haga otro. Si es así, felicidades. Eres un hacha diseñando videojuegos, porque lo normal es que prácticamente nunca, y menos si no tenemos un estudio profesional con varias (o cientos) de personas profesionales, puedas hacer tu grandísimo videojuego de tu grandísima idea decentemente. Básicamente, es mejor tener una idea pequeña y sencilla que veamos factible de ser capaces de realizar en videojuego que una idea grande para un videojuego grande que no podamos realizar y acabemos abandonando nuestro proyecto por la frustración que supone el no poder desarrollarlo tal y cómo queriamos. Y, con suerte, con la experiencia que ganemos podremos irnos permitiendo realizar ideas cada vez más grandes y mejores. Palabra de una persona que ha pasado por esto y de la frustración acabó estudiando Informática para desarrollar videojuegos.

Cuando ya tengamos una idea que se amolde a nuestras capacidades, podremos ir desarrollando aspectos del juego a partir de nuestra idea. Los principal que deberíamos preguntarnos cuando empezamos con la base de nuestro juego son las siguientes cuestiones:

  • ¿Qué queremos,  un juego en 2D o en 3D?
  • Y una vez elegida las dimensiones del juego, ¿qué estilo artístico queremos?
  • ¿ De qué género o mezcla de género queremos que sea el juego? Pues influirán en las mecánicas.
  • ¿Qué tipo de ambientación tendrá? Pues varía dependiendo de si quieres uno de fantasía o de ciencia ficción.
  • ¿Qué tipo de público queremos que juegue nuestro juego? ¿Uno de temática juvenil, adulta o para todos los públicos?

Si hemos podido responder a estas preguntas, ¡enhorabuena! Ya has dado el primer paso en cuanto al diseño de videojuegos.

Espero que os haya gustado esta entrada, básica pero necesaria. En un futuro hablaré de otros elementos más específicos a tratar en cuanto al diseño, pero con lo de hoy ya tenemos lo básico para que nuestro proyecto pueda empezar a marchar.

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.

 

Planificación del proyecto

Teniendo en mi haber dos jueguecitos terminados y otro en camino (pero este sin un tiempo límite establecido), el concepto de la planificación no es desconocido para nada por mi. Pero fueron trabajos pequeños con fechas concisas al ser hechas para asignaturas, había unas directrices de planificación de antemano. Básicamente, aunque tuviera una maniobrabilidad con la planificación, los milestones o hitos (los puntos de acabado de una fase del proyecto) eran impuestos por la asignatura. Así se evitaba que se pudieran alargar infinitamente un proyecto, o para evaluar a todos con un mismo calibre por haber hecho similares cosas entre los alumnos.

Esta vez, es mi primer proyecto sola ante el peligro. No hay directrices, no hay nada. Mando yo. Y eso es lo que hace que esta parte pueda ser la que con más seguridad varíe del proyecto. Esto nace de mi inexperiencia en este campo. Usualmente en la industria de los videojuegos, esto lo lleva un Productor, una persona ya experimentada y que suele tener una idea precisa de cuanto suele tardar cada apartado de un videojuego y guía su desarrollo a buen puerto, además de negociar los contratos de su empresa. Esto en estudios pequeños, suele hacerlo una persona con otros cargos más, normalmente el Diseñador (o al menos eso tengo entendido) por ser el que más idea tiene sobre la dirección que debe seguir el proyecto.

En otros estudios más grandes, el Productor trabaja solo de eso y acaba a veces casi siendo una eminencia. Casos de estos son Shigeru Miyamoto, Hideo Kojima, Michel Ancel, etc.

Pero bueno, como toda experiencia, esta se tiene que forjar y ya es hora de afrontarla sin miedo. Haré uso del ojo de buen cubero para calcular cuanto me llevaría en cada cosa aproximadamente. Pero tened por seguro que esta versión preliminar será difícil de llevarla, al menos en el sentido más estricto. Los plazos los he elegido dentro de un marco realista pero sin querer abusar de días. En un principio, mi intención es presentar el proyecto en Julio, y Septiembre a más tardar, si por motivos ajenos al proyecto no puedo terminarlo para la primera fecha.  Pero por si acaso haré la planificación hasta Septiembre.

Aún así, iré haciendo un registro del progreso real, de manera que así pueda compararlo con la planificación estipulada. Cuando acabe el desarrollo del proyecto, compararemos los dos y así se verán dónde se produjeron las inexactitudes que las comentaré en el Post-Mortem al finalizar el proyecto.

La planificación está hecha con Gantter, un planificador de proyectos online que permite establecer tareas y asignárselas a personas generando un Diagrama de Gantt. Es muy sencillo de utilizar, siendo más ligero que otros software de gestión de proyectos más complejos, pero para las necesidades del proyecto es adecuado. Además, permite que los otros colaboradores del proyecto puedan editarlo tal y como ellos consideren apropiado para sus tareas.

En líneas generales el proyecto se divide en:

  • Formación: Todo lo relacionado con aprender historia y las herramientas necesarias para la realización del proyecto.
  • Juego: Análisis, diseño, implementación y pruebas para crear el videojuego.
  • Arte: Todo lo relacionado con gráficos, músicas y texto necesarios para el videojuego.
  • Memoria: Toda la información sobre cómo se ha realizado el proyecto.

 

Podéis acceder al Diagrama de Gantt de forma online aquí.