Buenos días. Como mencioné la semana pasada, voy a comenzar el desarrollo de un juego para Game Boy y cada viernes me gustaría ir compartiendo con vosotros mis avances. Y bueno, supongo que si estás leyendo esto es porque te interesa el mundo de la programación de videojuegos y/o porque te estás planteando hacer uno.
La entrada de hoy irá enfocada a la documentación, un apartado que resulta imprescindible para todo proyecto que requiera más de un mes de desarrollo, incluso para proyectos “Juan Palomo” (“yo me lo guiso, yo me lo como”) donde una sola persona se ocupa del 100% del desarrollo). Todo proyecto que busque acabar bien debe de pasar por el empleo de las buenas prácticas y justamente una de las buenas prácticas es documentar todo.
También quiero aclarar que esto lo que vais a leer a continuación guarda más relación con el mundo de las consultorías informáticas que con el del desarrollo de juegos, pero eso no quita que varios de estos puntos puedan ser reutilizados para vuestro proyecto.
Y bueno, con todo ello, lo primero que quiero comentar es que definir tu juego en un solo documento suele ser imposible (a no ser que hagas algo extremadamente sencillo), por lo que los proyectos acaban abarcando diferentes tipos de documentos destinados cada uno a un apartado en concreto. El conjunto de toda esta documentación se conoce comúnmente como “corpus” (abreviación de “corpus documentario”).
Como ya he dicho, este “corpus” está formado por varios documentos, cada uno con un objetivo definido: “Hoja de concepción (también conocido como hoja de diseño)”, “dossier de arquitectura”, “matrices” (que funcionan a modo de anexo y pueden ser de interacción, de derechos de usuario, de flujos, de almacenamiento, etc.), “mapas de interfaz” (para definir los intercambios entre distintas API o webservices), “especificaciones funcionales”, “procesos técnicos de instalación”, “dossier de explotación”, etc.
Pero el documento básico e inicial debe de ser la “hoja de concepción/diseño”. Se trata de un documento de una o dos páginas en el que se define de forma rápida un resumen de la historia y del estilo de juego. Este documento no busca listar todos los detalles, si no especificar las estructuras básicas del juego. Su objetivo es simple: Definir de qué trata y cómo se juega para poder para poder partir de una base clara y, en proyectos de más de una persona, sirve para unificar criterios en fase de concepción (evitando así posibles malentendidos).
Este punto es muy importante, debido a que las tasas de abandono son extremadamente altas en los proyectos pequeños (de una o dos personas). A las personas nos gusta andarnos por las ramas e ir añadiendo funcionalidades a mitad del desarrollo, tomamos a veces decisiones sin avisar a compañeros y luego acabamos con un proyecto que un año más tarde no resulta jugable ni divertido y al que seguramente le falte aún más del 50% del desarrollo para acabarlo. También puede servirnos (aunque no es la idea) para compartir el documento entre amigos para que puedan valorar de una forma rápida si desean o no unirse a tu desarrollo.
Mi consejo es que cada vez que veamos algo que nos gustaría incluir, pero que es costoso de desarrollar y que no se ajuste a la hoja de concepción, lo anotes para desarrollarla en una eventual secuela (o para otro título similar). El objetivo principal de ello es de evitar eternizar los desarrollos pequeños. De hecho, ese tipo de funcionalidades que nos gustaría añadir pueden ir listados en el REX (documento de “retorno de experiencia”, donde al final del desarrollo, o de una iteración, anotamos las dificultades que hemos encontrado y las posibles mejoras para evitarlas).
Para la elaboración de “hoja de concepción” os hace falta tener 5 puntos claros:
Hay que destacar que durante la fase de diseño cada uno de esos apartados pueden derivar en documentos separados y gigantescos para especificar al detalle cada uno de estos apartados, pero conviene tener siempre presente esta “hoja de concepción” porque nos sirve para asentar los cimientos de nuestro juego a la vez que nos ayuda a verificar cada X semanas si nos estamos alejando de la idea inicial que teníamos en mente (por ejemplo: “quería hacer un juego de rol medieval de tipo bélico, pero me he enfocado demasiado en un sistema de citas y romances y ahora parece más una visual novel de ligar”).
Para profundizar o clarificar estos apartados, os animo a visualizar el siguiente vídeo del Dr. Clinton Woodward de la Swinburne University (Australia). El vídeo es escueto (apenas dura 8 minutos) y se trata de una lección grabada para el curso “Concepts in games development” de la antigua plataforma Open2Study (la cual ya no existe): https://www.youtube.com/watch?v=6kuYrBbDhJ8 (actualización: Parece ser que desde Open2Study se han dado cuenta y han deshabilitado los videos)
También quiero aclarar que esto lo que vais a leer a continuación guarda más relación con el mundo de las consultorías informáticas que con el del desarrollo de juegos, pero eso no quita que varios de estos puntos puedan ser reutilizados para vuestro proyecto.
Y bueno, con todo ello, lo primero que quiero comentar es que definir tu juego en un solo documento suele ser imposible (a no ser que hagas algo extremadamente sencillo), por lo que los proyectos acaban abarcando diferentes tipos de documentos destinados cada uno a un apartado en concreto. El conjunto de toda esta documentación se conoce comúnmente como “corpus” (abreviación de “corpus documentario”).
Como ya he dicho, este “corpus” está formado por varios documentos, cada uno con un objetivo definido: “Hoja de concepción (también conocido como hoja de diseño)”, “dossier de arquitectura”, “matrices” (que funcionan a modo de anexo y pueden ser de interacción, de derechos de usuario, de flujos, de almacenamiento, etc.), “mapas de interfaz” (para definir los intercambios entre distintas API o webservices), “especificaciones funcionales”, “procesos técnicos de instalación”, “dossier de explotación”, etc.
Pero el documento básico e inicial debe de ser la “hoja de concepción/diseño”. Se trata de un documento de una o dos páginas en el que se define de forma rápida un resumen de la historia y del estilo de juego. Este documento no busca listar todos los detalles, si no especificar las estructuras básicas del juego. Su objetivo es simple: Definir de qué trata y cómo se juega para poder para poder partir de una base clara y, en proyectos de más de una persona, sirve para unificar criterios en fase de concepción (evitando así posibles malentendidos).
Este punto es muy importante, debido a que las tasas de abandono son extremadamente altas en los proyectos pequeños (de una o dos personas). A las personas nos gusta andarnos por las ramas e ir añadiendo funcionalidades a mitad del desarrollo, tomamos a veces decisiones sin avisar a compañeros y luego acabamos con un proyecto que un año más tarde no resulta jugable ni divertido y al que seguramente le falte aún más del 50% del desarrollo para acabarlo. También puede servirnos (aunque no es la idea) para compartir el documento entre amigos para que puedan valorar de una forma rápida si desean o no unirse a tu desarrollo.
Mi consejo es que cada vez que veamos algo que nos gustaría incluir, pero que es costoso de desarrollar y que no se ajuste a la hoja de concepción, lo anotes para desarrollarla en una eventual secuela (o para otro título similar). El objetivo principal de ello es de evitar eternizar los desarrollos pequeños. De hecho, ese tipo de funcionalidades que nos gustaría añadir pueden ir listados en el REX (documento de “retorno de experiencia”, donde al final del desarrollo, o de una iteración, anotamos las dificultades que hemos encontrado y las posibles mejoras para evitarlas).
Para la elaboración de “hoja de concepción” os hace falta tener 5 puntos claros:
La lista de apartados no es canónica y podéis adaptarla a vuestro gusto (añadiendo nuevos o quitando los ya existentes) y además podemos hacer mención a otros juegos del mercado para poder plasmar mejor sobre el papel cuales son las ideas que tenemos (p. ex.: Es un “Asteroids” con toque de rol, donde al final de cada fase podemos realizar modificaciones en nuestra nave).
- La idea básica: Una descripción simple y escueta de qué consiste el juego.
- La historia: Un pequeño contexto o puesta en situación sobre el hilo argumental del juego. No hace falta dar todos los detalles, ni escribir una novela. Mi recomendación es limitarse a cumplir con las 5W del periodismo (who, what, when, where, why), sin destripar la trama o el final (salvo que consideres que sea pertinente indicarlo).
- El estilo visual: El nombre del apartado lo dice todo. Aquí habría que especificar si pensamos hacer un juego en 2D/3D, si pensamos hacer uso de alguna tecnología en concreto que afecte visualmente (como “cel-shading”), si pensamos hacer personajes enanitos y cabezones estilo RPG de SNES, si emplearemos colores vivos o si pensamos hacer un juego que visualmente luzca oscuro, etc.
- El estilo de audio: Se trata de uno de los apartados más ignorados y a la vez de los más importantes. ¿Pensamos utilizar música techno machacona? ¿Música de ascensor relajada? ¿Nos limitaremos al ruido ambiente (con pájaros y grillos)? ¿O planeamos poner un silencio total? Una buena elección ayuda a la inmersión, mientras que una mala puede romper por completo la experiencia de juego.
- El control: Se trata de definir con qué dispositivos se juega. ¿Teclado + ratón? ¿Un gamepad? ¿Un Wii-Mote? ¿Captura de movimiento mediante webcam?
- Y la interacción: Definir cómo el usuario interacciona con el mundo, si pensamos incluir JvsJ (jugador contra jugador), si nos limitamos a un modo campaña, si será un juego multiplayer, etc.
Hay que destacar que durante la fase de diseño cada uno de esos apartados pueden derivar en documentos separados y gigantescos para especificar al detalle cada uno de estos apartados, pero conviene tener siempre presente esta “hoja de concepción” porque nos sirve para asentar los cimientos de nuestro juego a la vez que nos ayuda a verificar cada X semanas si nos estamos alejando de la idea inicial que teníamos en mente (por ejemplo: “quería hacer un juego de rol medieval de tipo bélico, pero me he enfocado demasiado en un sistema de citas y romances y ahora parece más una visual novel de ligar”).
Para profundizar o clarificar estos apartados, os animo a visualizar el siguiente vídeo del Dr. Clinton Woodward de la Swinburne University (Australia). El vídeo es escueto (apenas dura 8 minutos) y se trata de una lección grabada para el curso “Concepts in games development” de la antigua plataforma Open2Study (la cual ya no existe): https://www.youtube.com/watch?v=6kuYrBbDhJ8 (actualización: Parece ser que desde Open2Study se han dado cuenta y han deshabilitado los videos)
Y si os ha gustado el vídeo, os comparto la siguiente lista de Youtube donde he recopilado todas las sesiones del curso que he podido encontrar por internet (los videos eran ocultos, pero el curso era gratuito, además de que la plataforma de Open2Study ya no existe y no lo he encontrado en ningún otro sitio, ni en la nueva Open Universities de Australia): https://www.youtube.com/playlist?list=PLroD_4x-Yzmd2hRASnd5aCwjGYsWXcmg_ (actualización: Parece ser que desde Open2Study se han dado cuenta y han deshabilitado los videos)
Y tras todo ello, a continuación os presento la hoja de concepción que he preparado para mi juego:
El segundo documento a tener en cuenta al iniciar un proyecto es el dossier de arquitectura, en el que definimos las tecnologías y herramientas empleadas para el proyecto. Definiremos, por ejemplo, el motor empleado (Unity, GameMaker, C# puro, RPG Maker, etc…), las herramientas de modelado (Blender, Maya, Gimp…), los distintos tipos de soluciones que crearemos (Windows, Linux, Mac, Android, Xbox One, etc…), etc. Muy importante, si nuestro juego tendrá un modelo del estilo cliente/servidor o si haremos uso de webservices externos, debe de salir reflejado en este documento. No hace falta indicar los detalles de los intercambios de información, puesto que los detalles técnicos irán definidos en los distintos mapas de interfaces (que se pueden entender como anexos) y sus funcionalidades asociadas irán descritas en las especificaciones funcionales.
En caso, por ejemplo, de tener un sistema de guardado de partida, deberéis de definirlo también en este DAT (“dossier de arquitectura”): ¿batería de cartucho de Gameboy? ¿base de datos de psqlite? ¿guardado en un servidor externo? No hace falta definir todos los detalles (el sistema de estructuras podéis definirlo en anexos/matrices/mapas), pero en el DAT debería de ir reflejada toda tecnología empleada.
Si vais a hacer vuestras propias herramientas internas (crear vuestro propio RPG Maker, por ejemplo), tened en cuenta que todo el “corpus” ligado de esas herramientas irán definidas como si de otro proyecto se tratara (con sus propias “hojas de concepción”, “dossieres de arquitectura” y “especificaciones funcionales”). Habrá que mencionar el empleo de dicha herramienta en nuestro DAT, pero la nueva herramienta propia que tengáis deberá de tener su propio “corpus” (no mezclemos peras con manzanas).
Por cierto, mi recomendación es que elijáis siempre un framework que os permita hacer tests unitarios automatizados, debido a que es muy común crear regresiones cuando modificáis código fuente que no habéis tocado en semanas o meses (os ayudará a evitar la creación de un bug cuando pretendáis corregir otro que impacte en regiones de código mutualizadas). En mi caso, este paso no voy a poderlo seguir porque he optado por hacer uso del GB Studio, una herramienta muy similar al RPG Maker pero enfocado a hacer juegos de Game Boy.
También recomiendo algo bastante obvio: Usad un sistema de repositorios como GIT, básicamente porque en caso de cagada (que la cagarás, todos comentemos errores), podrás hacer un “revert” de forma simple. Y el mero hecho de obligarte a poner comentarios te ayudará a entender en el futuro por qué en su día hiciste X y no Z. No hace falta montarse un gitlab o darse de alta en GitHub, os podéis montar un servidor básico de git en vuestro propio PC, la idea es poder trabajar de forma fácil con distintas ramas (actual, desarrollo, evolución XXX, evolución YYY) y tags y poder ir haciendo de forma simple vuestros merges y reverts.
Volviendo al hilo principal, está bien ir definiendo este documento con antelación (el “dossier de arquitectura”), puesto que las limitaciones de las distintas herramientas impactarán en mayor o menor medida en las especificaciones funcionales y, por ende, en el diseño de vuestro juego.
Por ejemplo, si hacemos uso de RPG Maker, debemos saber que en caso de hacer una pregunta al usuario, por defecto tenemos sólo 4 posibles opciones de respuesta como máximo; Tampoco podremos cargar animaciones de tipo “png”, pero sí archivos de vídeo; Si hacemos uso, por ejemplo, de GB Studio, pues podemos dar por hecho que el inventario de nuestro personaje será terriblemente limitado (hablamos de “saves” de 32 KB) o que debido a la resolución de la consola no podremos contar con un IHM (interfaz hombre-máquina, aka “Hud”) con numerosos paneles informativos a la vez (vida, energía, maná, dinero, etc.). Bueno, sí, puedes poner un “hud” gigante, pero en vez de un juego se parecerá más a una página web llena de publicidad.
Como he dicho antes, el juego en el que quiero trabajar utilizará el GB Studio 2.0 y las limitaciones de dicho framework impactará fuertemente en las especificaciones funcionales:
En caso, por ejemplo, de tener un sistema de guardado de partida, deberéis de definirlo también en este DAT (“dossier de arquitectura”): ¿batería de cartucho de Gameboy? ¿base de datos de psqlite? ¿guardado en un servidor externo? No hace falta definir todos los detalles (el sistema de estructuras podéis definirlo en anexos/matrices/mapas), pero en el DAT debería de ir reflejada toda tecnología empleada.
Si vais a hacer vuestras propias herramientas internas (crear vuestro propio RPG Maker, por ejemplo), tened en cuenta que todo el “corpus” ligado de esas herramientas irán definidas como si de otro proyecto se tratara (con sus propias “hojas de concepción”, “dossieres de arquitectura” y “especificaciones funcionales”). Habrá que mencionar el empleo de dicha herramienta en nuestro DAT, pero la nueva herramienta propia que tengáis deberá de tener su propio “corpus” (no mezclemos peras con manzanas).
Por cierto, mi recomendación es que elijáis siempre un framework que os permita hacer tests unitarios automatizados, debido a que es muy común crear regresiones cuando modificáis código fuente que no habéis tocado en semanas o meses (os ayudará a evitar la creación de un bug cuando pretendáis corregir otro que impacte en regiones de código mutualizadas). En mi caso, este paso no voy a poderlo seguir porque he optado por hacer uso del GB Studio, una herramienta muy similar al RPG Maker pero enfocado a hacer juegos de Game Boy.
También recomiendo algo bastante obvio: Usad un sistema de repositorios como GIT, básicamente porque en caso de cagada (que la cagarás, todos comentemos errores), podrás hacer un “revert” de forma simple. Y el mero hecho de obligarte a poner comentarios te ayudará a entender en el futuro por qué en su día hiciste X y no Z. No hace falta montarse un gitlab o darse de alta en GitHub, os podéis montar un servidor básico de git en vuestro propio PC, la idea es poder trabajar de forma fácil con distintas ramas (actual, desarrollo, evolución XXX, evolución YYY) y tags y poder ir haciendo de forma simple vuestros merges y reverts.
Volviendo al hilo principal, está bien ir definiendo este documento con antelación (el “dossier de arquitectura”), puesto que las limitaciones de las distintas herramientas impactarán en mayor o menor medida en las especificaciones funcionales y, por ende, en el diseño de vuestro juego.
Por ejemplo, si hacemos uso de RPG Maker, debemos saber que en caso de hacer una pregunta al usuario, por defecto tenemos sólo 4 posibles opciones de respuesta como máximo; Tampoco podremos cargar animaciones de tipo “png”, pero sí archivos de vídeo; Si hacemos uso, por ejemplo, de GB Studio, pues podemos dar por hecho que el inventario de nuestro personaje será terriblemente limitado (hablamos de “saves” de 32 KB) o que debido a la resolución de la consola no podremos contar con un IHM (interfaz hombre-máquina, aka “Hud”) con numerosos paneles informativos a la vez (vida, energía, maná, dinero, etc.). Bueno, sí, puedes poner un “hud” gigante, pero en vez de un juego se parecerá más a una página web llena de publicidad.
Como he dicho antes, el juego en el que quiero trabajar utilizará el GB Studio 2.0 y las limitaciones de dicho framework impactará fuertemente en las especificaciones funcionales:
- El framework permite almacenar un máximo de 512 variables globales de tipo byte (con valor de 0 a 255). En el momento que queramos hacer algo más complejo (hacer un string para ponerle nombre al personaje) debemos de jugar con ellos. 512 variables pueden parecer muchos, pero para un rpg son pocos.
- Un truco que podría seguirse en fase de desarrollo (tocaría modificar las fuentes de GB Studio) es dividir cada variable en 4 bits, donde los primeros 4 serían para una variable A y los 4 últimos para una variable B. Esto duplicaría el número de variables hasta las 1024, pero limitaría el margen de valor de 0 a 127. Y rizando el rizo se podría incluso personalizar distintos tipos de variable, por ejemplo:
- 100 variables de tipo byte (8 bits, 100 variables con valor de 0 a 255).
- 200 variables divididas en 4 bits (400 variables con valores de 0 a 127).
- 200 variables divididas en 2 bits (800 variables con valores de 0 a 7).
- 12 variables de 1 bit (12 booleanos).
- En resumen: 512 bytes repartidos en 1.212 variables (en vez de las 512 que tendríamos por defecto). Ahora bien, todo esto es teórico y requiere modificar las fuentes de GB Studio.
- Tener un número limitado de variables globales a nivel documentario implica tener que crear una matriz (un fichero Excel) con la lista de cada una y su funcionalidad, más aún si ya planifico dividir cada byte de variable en subvariables.
- El framework permite la friolera de 6 actores por escena, pudiendo considerar un actor los objetos como cofres, carteles o puertas, los enemigos, los NPC y el personaje que manejamos. Esta limitación viene dada a que la consola cuenta con 8 KB de SRAM (memoria volátil) y con 8 KB de VRAM (memoria gráfica).
- No podemos poner en pantalla a la vez, por ejemplo, un cofre del tesoro, un cartel para dar pistas, al jugador, a un NCP y a tres enemigos. El framework no lo permite.
- Existen trampas para engañar al jugador y dar a entender que se pueden definir más actores. Un truco que se está haciendo famoso es el de dibujar los actores directamente en el fondo (no tendrían sprite propio y por consiguiente permanecen inmóviles en pantalla) y desplazar el actor de posición (el cual tendría un srpite invisible) según el jugador accede a una región A, B o C. Luego, a nivel de código se modificaría el comportamiento del actor en tiempo real (según estemos en la región A, B o C).
- Sin contar el fondo (que se trataría de una imagen estática pegada, pero que puede ser desplazado por el scroll y puede contar con efectos de parallax), el framework permite cargar en memoria la friolera de 25 sprites de 16x16 píxeles. Esto quiere decir que, si hacemos un personaje con animaciones de andar hacia arriba, abajo y un lado (que pondremos en modo espejo), sólo para la animación de andar consumiremos 6 de esos 25 sprites (cada animación contaría con dos sprites). Si metes un cofre y le pones un cuadro de cofre abierto y cerrado, consumes otros dos cuadros. Lo mismo para las farolas y para cada NPC que pongas en pantalla.
- Esto hace que tengas que plantearte hacer que los NPC no puedan moverse o bien pegarlos directamente en el background (imagen estática) o hacer que se muevan, pero sin animación para poder consumir la mínima cantidad posible de sprites en memoria.
- Los sprites están limitados a 4 colores, pero hay que tener en cuenta que para el caso de los 25 sprites cargados en memoria, uno de esos colores se emplea para transparencias, por lo que realmente cuentas con 3 colores para definir a los personajes y objetos. Hacer pixel-art de 4 colores es complicado, pero con tres hay que hacer magia.
- El tamaño de los sprites es minúsculo (16x16 píxeles). Se podría editar el entorno para hacer que los personajes sean más grandes (por ejemplo, de 32x16), pero eso implica que cada animación del personaje consumiría el doble de sprites (a descontar del límite de 25 sprites). Si antes comentaba que para una animación de caminar en 4 direcciones consumíamos 6 sprites, con esto consumiríamos 12 de los 25 sprites. Si quieres hacer un action RPG, tienes que pensar además en añadir animaciones de ataque o de recibir daño.
- GB Studio permite que el personaje se mueva en cuatro direcciones: Arriba, Abajo, Izquierda y Derecha… Pero no permite el desplazamiento en diagonal (como en juegos como Zelda). Hay que modificar las fuentes de GB Studio para permitir esto.
- Los backgrounds tienen una talla máxima de 256x256 pixeles. Si planeas hacer escenarios más grandes te toca hacer trampas con los parallax o dividirlo en varias escenas.
- El único formato de audio soportado oficialmente es el .mod y con limitaciones. Olvidaros de incluir ningún tipo de voz.
¿Por qué os cuento todo esto? Muy sencillo, para que veáis cómo las limitaciones del framework pueden impactar de forma notable en las funcionalidades de vuestro juego y en el diseño de éste. Por ejemplo, si defino que un personaje NPC está pegado en un background, en las especificaciones no puedo poner que éste se pueda mover o desaparecer.
Ahora que ya somos conscientes de qué queremos que vaya el juego y de las limitaciones técnicas, tenemos que reflexionar sobre cómo diseñar el juego. Hay que pillar papel y lápiz e ir definiendo los diferentes tipos de escenarios y de actores que pueden intervenir y no me refiero a ponerle nombre y apellidos a los lugares o los personajes.
Como escenas me refiero a las distintas pantallas que tenga nuestro juego (las navegaciones entre menús, los tipos de pantalla de juego, pantallas de Game Over, etc). Por ejemplo, en un menú inicial solemos tener 1 actor de tipo botón y dependiendo de su funcionalidad cuando éste interaccione con el ratón o con el cursor acabaremos yendo a una pantalla u otra. Mientras que en pleno juego (que se considera una escena propia) nuestro personaje (1er actor) interacciona con otros elementos: Al interaccionar con un NPC, éste puede decirnos una frase (actor tipo NPC); Al leer un libro podemos abrir la pantalla de guardado (actor tipo guardado); Al ser tocados por un enemigo podemos perder vida (actor tipo enemigo); Al pulsar una baldosa X (como una puerta), podemos teletransportarnos a otro mapa (actor tipo teletransporte); Cuando tocamos una moneda, esta desaparece y se añade a nuestro inventario (actor tipo inventario); Etc.…
Y así vamos anotando todos los posibles tipos de actores y sus posibles interacciones. En juego simples, como los mata marcianos, esto no es nada complicado y podemos definir la funcionalidad en un fichero Excel llamado “matriz de interacciones”, donde listamos todos los posibles tipos de actor en horizontal y en vertical y al igual que en una quiniela, definimos en cada casilla el posible tipo de interacción entre todas las posibles combinaciones que deseemos.
Ahora bien, en juegos más complejos, como puede ser mi caso, para definir el motor/engine necesitamos forzosamente partir de un modelo de desarrollo más clásico y crear un documento de especificaciones funcionales. Este documento actúa como manual de instrucciones y define todas las pantallas y funcionalidades posibles (incluso las que no son evidentes a simple vista). Un ejemplo:
Pantalla de “Pulsa start”:
Ahora que ya somos conscientes de qué queremos que vaya el juego y de las limitaciones técnicas, tenemos que reflexionar sobre cómo diseñar el juego. Hay que pillar papel y lápiz e ir definiendo los diferentes tipos de escenarios y de actores que pueden intervenir y no me refiero a ponerle nombre y apellidos a los lugares o los personajes.
Como escenas me refiero a las distintas pantallas que tenga nuestro juego (las navegaciones entre menús, los tipos de pantalla de juego, pantallas de Game Over, etc). Por ejemplo, en un menú inicial solemos tener 1 actor de tipo botón y dependiendo de su funcionalidad cuando éste interaccione con el ratón o con el cursor acabaremos yendo a una pantalla u otra. Mientras que en pleno juego (que se considera una escena propia) nuestro personaje (1er actor) interacciona con otros elementos: Al interaccionar con un NPC, éste puede decirnos una frase (actor tipo NPC); Al leer un libro podemos abrir la pantalla de guardado (actor tipo guardado); Al ser tocados por un enemigo podemos perder vida (actor tipo enemigo); Al pulsar una baldosa X (como una puerta), podemos teletransportarnos a otro mapa (actor tipo teletransporte); Cuando tocamos una moneda, esta desaparece y se añade a nuestro inventario (actor tipo inventario); Etc.…
Y así vamos anotando todos los posibles tipos de actores y sus posibles interacciones. En juego simples, como los mata marcianos, esto no es nada complicado y podemos definir la funcionalidad en un fichero Excel llamado “matriz de interacciones”, donde listamos todos los posibles tipos de actor en horizontal y en vertical y al igual que en una quiniela, definimos en cada casilla el posible tipo de interacción entre todas las posibles combinaciones que deseemos.
Ahora bien, en juegos más complejos, como puede ser mi caso, para definir el motor/engine necesitamos forzosamente partir de un modelo de desarrollo más clásico y crear un documento de especificaciones funcionales. Este documento actúa como manual de instrucciones y define todas las pantallas y funcionalidades posibles (incluso las que no son evidentes a simple vista). Un ejemplo:
Pantalla de “Pulsa start”:
- Maqueta de la pantalla.
Reglas de gestión:
Pantalla de “Mundo libre”
Reglas de gestión:
Es muy importante señalar que las especificaciones funcionales no deben de definir el guion del juego (al programador a priori debe de darle igual si Zelda es la crush de Link o si el malo mató a sus padres, le han pedido que Link pueda mover rocas grandes y debe de conseguir que Link pueda mover rocas grandes). Con unas especificaciones bien definidas evitamos encontrarnos con sorpresas y reduciremos el número de bugs que puedan surgir durante nuestro desarrollo. Históricamente este documento suele ser el más “gordo” del corpus documentario.
Ahora que tenemos la “hoja de concepción”, el “DAT” y las “SF” (especificaciones funcionales), ¿qué hacemos? ¿Nos ponemos a programar? ¡NO! El siguiente paso es elaborar una campaña de tests para el motor que hemos definido.
Y para poder definir esta campaña hay que definir antes un guion básico que nos permita probar todas las funcionalidades que nos permite nuestro motor. Tened en cuenta que cuando defináis esta campaña de tests, el desarrollo aún no está hecho y aún no contáis con el guion final del juego (el cual puede ser cambiante, según inspiración divina) y que a cada vez que hagáis cambios en las especificaciones funcionales (una vez por iteración de tu prototipo), esta campaña de tests debe de ir evolucionando. Puede sonar a construir la casa por el tejado, pero con unas especificaciones funcionales claras y conociendo de antemano los posibles resultados de una campaña de testing, resulta mil veces más fácil programar las distintas tareas: Te han pedido hacer X y sabes que tienes que limitarte a cumplir con Y y Z, evitando reflexiones triviales como “Si pulso A, ¿Link tiene que mover una roca o también puede mover botijos?… oh, espera, no hace falta, en otro test dice que el botijo debe de estar encima de su cabeza si pulso A”. A este tipo de metodología se le conoce como “Test Driven Development”.
Una forma de crear una campaña básica de testing es creando una habitación vacía y gigante donde podamos testear todas las funcionalidades de forma individual. Un ejemplo de “habitación de testing” (o debug) la tenemos en la mansión del Tomb Raider 1 y 2. Estos dos juegos nos permiten recorrer la mansión de Lara y familiarizarnos con todos los posibles controles que veremos en el juego. Lógicamente, los desarrolladores hacían uso de la casa de lara para poder testear de forma rápida las distintas funcionalidades del juego (disparar a blancos, agacharse, correr, encender bengalas, nadar, activar interruptores, cambios de cámara, etc…) sin tener que guardar 50 save-states. Este tipo de habitación también está presente en los juegos de la saga The Elder Scrolls, pero su uso es menos conocido y sólo es accesible mediante comandos de consola. Esto no quita que cuando acabes tu desarrollo tengas que jugar el modo campaña entero para poder localizar posibles bugs.
En lo que se refiere a las campañas de tests, existen dos tipos:
Y ahora que hemos definido unas especificaciones funcionales, una campaña de testing y somos conscientes de las limitaciones técnicas… podemos por fin programar. Puede parecer pesado, pero como he dicho antes, una vez que has definido el comportamiento (vía especificaciones funcionales) y que además conoces de antemano los posibles resultados a obtener (vía campaña de test), resulta mucho más fácil programar (ayuda mucho a evitar marcianadas, chapuzas y ñapas).
Por cierto, cuando codificamos, una buena práctica es el “code peer review”, que básicamente consiste en pedirle a un compañero que revise el código que has hecho para aplicar las nuevas funcionalidades y lo ideal es hacerlo sistemáticamente cuando consideremos que nuestra rama de desarrollo de una funcionalidad X está lista para ser mergeada en la rama principal de desarrollo. Si en tu proyecto no vas a estar sólo, recomiendo encarnizadamente seguir dicha práctica. La gente suele malinterpretarlo, dando a entender que hay que revisar su código por considerarle un incompetente, pero realmente tiene una labor didáctica: Cuando un senior revisa código de un junior, éste le indica las mejoras a aplicar a su código; Cuando un junior revisa el código de un senior, sólo con la lectura sube en competencias de forma indirecta; Cuando un senior revisa a un senior, puede servir a detectar posibles mal entendidos de funcionalidad; Y cuando un junior revisa a un junior, por lo menos uno de los dos acaba aprendiendo algo. Con ello pretendo decir que el “code peer review” no debe de ir ligado siempre a “senior-revisa-a-junior”, puesto que esto puede crear problemas de saturación o de cuello de botella en el perfil senior.
Existen otros tipos de documentos, como las PTI (proceso técnico de instalación, donde definimos las intervenciones manuales y eventuales a hacer, como por ejemplo instalar nuestro entorno de desarrollo sobre un PC recién comprado o poner en marcha un servidor desde cero) o el DEX (dossier de explotación, donde definimos todos los procesos manuales comunes, como reiniciar un servidor o ponerlo en modo “mantenimiento”)… pero no los mencionaré en esta entrada debido a que no suelen ser pertinentes para proyectos pequeños.
Y muy importante: No incluyáis ningún password en claro (clave de admin a un servidor, token de acceso, etc…) en estos documentos. La buena práctica pasa por crearse un fichero keypass y hacer referencia a él en el corpus cada vez que sea necesario. El mundo está lleno de malas personas e incluso si pensáis que “no pasa nada, este PC sólo lo uso yo”, puede darse el peligroso caso de que realmente no seas la única persona que lo use.
Y hasta aquí la entrada de hoy, muchas gracias por vuestra lectura y os invito a volver el viernes 23 de julio para compartiros más acerca de este proyecto y de las metodologías que empleo para llevarlo a cabo.
- RG-Start-01: Al iniciarse la pantalla suena la melodía XXX.
- RG-Start-02: Al iniciarse la pantalla se chequea los saves del juego. Si el jugador se ha pasado ya el juego 1 vez (o más veces), la imagen del fondo cambia a YYYY.
- RG-Start-03: Al pulsar start suena un pitido, el mensaje de “Pulsa start” parpadea 3 veces seguidas y al cabo de 2 segundos se produce un fade-off de la pantalla y navegamos a la pantalla de “Menú inicial”.
- RV-Start-01: El texto de “Pulsa start” parpadea 1 vez cada 5 segundos.
- RV-Start-02: El texto de “Pulsa start” se ve en itálica.
- RV-Start-03: El fondo por defecto (a no ser que la regla RG-Start-02 esté activada) es la imagen ZZZZ.
Pantalla de “Mundo libre”
- Maqueta de la pantalla, incluyendo en ella los diferentes hud.
Reglas de gestión:
- RG-Libre-01: Al recibir un golpe con el jugador desprotegido, el indicador de vida se actualiza con el daño recibido.
- RG-Libre-02: Al recibir un golpe con el jugador protegido se aprecia una animación y el texto “Block!” encima del jugador.
- RG-Libre-03: Si tras actualizarse el indicador de vida este tiene 0 puntos de HP o menos, salta la animación de muerte del jugador. Al cabo de 2 segundos salta la animación de “Game Over”. Se produce un fade-off y el jugador es teletransportado al último “save-point”.
- RB-Libre-04: Al pulsar “Start”, suena el sonido “XXXX”, esperamos 1 segundo y navegamos a la pantalla de “Inventario”.
- RB-Libre-05: Al mover la rueda del ratón, la cámara se aleja o acerca, produciendo un efecto de Zoom-In/Zoom-Out.
- RB-Libre-06: Cuando el Zoom es mayor x2 y la configuración gráfica está en “ULTRA”, los objetos y personajes deben de usar sus modelos más detallados (más de 300.000 polígonos por instancia).
- RB-Libre-07: Cuando el Zoom es menor a x0.5 o la configuración gráfica está en “BAJA”, los objetos y personajes deben de usar sus modelos menos detallados (menos de 10.000 polígonos por instancia).
- RB-Libre-08: Cuando el Zoom está entre x2 y x0.5 y la configuración gráfica está en “NORMAL” o “ULTRA”, los objetos y personajes deben de usar sus modelos de detalle medio (menos de 100.000 polígonos).
Es muy importante señalar que las especificaciones funcionales no deben de definir el guion del juego (al programador a priori debe de darle igual si Zelda es la crush de Link o si el malo mató a sus padres, le han pedido que Link pueda mover rocas grandes y debe de conseguir que Link pueda mover rocas grandes). Con unas especificaciones bien definidas evitamos encontrarnos con sorpresas y reduciremos el número de bugs que puedan surgir durante nuestro desarrollo. Históricamente este documento suele ser el más “gordo” del corpus documentario.
Ahora que tenemos la “hoja de concepción”, el “DAT” y las “SF” (especificaciones funcionales), ¿qué hacemos? ¿Nos ponemos a programar? ¡NO! El siguiente paso es elaborar una campaña de tests para el motor que hemos definido.
Y para poder definir esta campaña hay que definir antes un guion básico que nos permita probar todas las funcionalidades que nos permite nuestro motor. Tened en cuenta que cuando defináis esta campaña de tests, el desarrollo aún no está hecho y aún no contáis con el guion final del juego (el cual puede ser cambiante, según inspiración divina) y que a cada vez que hagáis cambios en las especificaciones funcionales (una vez por iteración de tu prototipo), esta campaña de tests debe de ir evolucionando. Puede sonar a construir la casa por el tejado, pero con unas especificaciones funcionales claras y conociendo de antemano los posibles resultados de una campaña de testing, resulta mil veces más fácil programar las distintas tareas: Te han pedido hacer X y sabes que tienes que limitarte a cumplir con Y y Z, evitando reflexiones triviales como “Si pulso A, ¿Link tiene que mover una roca o también puede mover botijos?… oh, espera, no hace falta, en otro test dice que el botijo debe de estar encima de su cabeza si pulso A”. A este tipo de metodología se le conoce como “Test Driven Development”.
Una forma de crear una campaña básica de testing es creando una habitación vacía y gigante donde podamos testear todas las funcionalidades de forma individual. Un ejemplo de “habitación de testing” (o debug) la tenemos en la mansión del Tomb Raider 1 y 2. Estos dos juegos nos permiten recorrer la mansión de Lara y familiarizarnos con todos los posibles controles que veremos en el juego. Lógicamente, los desarrolladores hacían uso de la casa de lara para poder testear de forma rápida las distintas funcionalidades del juego (disparar a blancos, agacharse, correr, encender bengalas, nadar, activar interruptores, cambios de cámara, etc…) sin tener que guardar 50 save-states. Este tipo de habitación también está presente en los juegos de la saga The Elder Scrolls, pero su uso es menos conocido y sólo es accesible mediante comandos de consola. Esto no quita que cuando acabes tu desarrollo tengas que jugar el modo campaña entero para poder localizar posibles bugs.
En lo que se refiere a las campañas de tests, existen dos tipos:
- TNR (tests de no regresión), que incluye probar todas y cada una de las reglas de gestión y visualización que has creado desde el inicio del proyecto. La realización de una campaña de TNR está recomendada cada vez que vayas a liberar una nueva versión al público.
- De versión, que incluye únicamente las pruebas a hacer sobre las nuevas reglas de gestión y visualización que has creado o que has modificado en la última versión iterativa (no testeas todo, sólo los cambios y los añadidos). Este tipo de campaña es únicamente de tipo interno, para toda versión que no vaya a ser liberada al público. En este tipo de campañas pueden escaparse fácilmente las famosas regresiones, ya que puede darse el caso que la modificación de una parte del código mutualizada por varias reglas de gestión rompa sin querer una o varias de esas reglas. Es por ello que junto a la realización de TNR en las versiones que vayan a ser liberadas al público, intentemos contar en la medida de lo posible con un framework que permita la realización de tests unitarios automatizados.
Y ahora que hemos definido unas especificaciones funcionales, una campaña de testing y somos conscientes de las limitaciones técnicas… podemos por fin programar. Puede parecer pesado, pero como he dicho antes, una vez que has definido el comportamiento (vía especificaciones funcionales) y que además conoces de antemano los posibles resultados a obtener (vía campaña de test), resulta mucho más fácil programar (ayuda mucho a evitar marcianadas, chapuzas y ñapas).
Por cierto, cuando codificamos, una buena práctica es el “code peer review”, que básicamente consiste en pedirle a un compañero que revise el código que has hecho para aplicar las nuevas funcionalidades y lo ideal es hacerlo sistemáticamente cuando consideremos que nuestra rama de desarrollo de una funcionalidad X está lista para ser mergeada en la rama principal de desarrollo. Si en tu proyecto no vas a estar sólo, recomiendo encarnizadamente seguir dicha práctica. La gente suele malinterpretarlo, dando a entender que hay que revisar su código por considerarle un incompetente, pero realmente tiene una labor didáctica: Cuando un senior revisa código de un junior, éste le indica las mejoras a aplicar a su código; Cuando un junior revisa el código de un senior, sólo con la lectura sube en competencias de forma indirecta; Cuando un senior revisa a un senior, puede servir a detectar posibles mal entendidos de funcionalidad; Y cuando un junior revisa a un junior, por lo menos uno de los dos acaba aprendiendo algo. Con ello pretendo decir que el “code peer review” no debe de ir ligado siempre a “senior-revisa-a-junior”, puesto que esto puede crear problemas de saturación o de cuello de botella en el perfil senior.
Existen otros tipos de documentos, como las PTI (proceso técnico de instalación, donde definimos las intervenciones manuales y eventuales a hacer, como por ejemplo instalar nuestro entorno de desarrollo sobre un PC recién comprado o poner en marcha un servidor desde cero) o el DEX (dossier de explotación, donde definimos todos los procesos manuales comunes, como reiniciar un servidor o ponerlo en modo “mantenimiento”)… pero no los mencionaré en esta entrada debido a que no suelen ser pertinentes para proyectos pequeños.
Y muy importante: No incluyáis ningún password en claro (clave de admin a un servidor, token de acceso, etc…) en estos documentos. La buena práctica pasa por crearse un fichero keypass y hacer referencia a él en el corpus cada vez que sea necesario. El mundo está lleno de malas personas e incluso si pensáis que “no pasa nada, este PC sólo lo uso yo”, puede darse el peligroso caso de que realmente no seas la única persona que lo use.
Y hasta aquí la entrada de hoy, muchas gracias por vuestra lectura y os invito a volver el viernes 23 de julio para compartiros más acerca de este proyecto y de las metodologías que empleo para llevarlo a cabo.
Entradas
No hay comentarios:
Publicar un comentario
Si te ha gustado la entrada o consideras que algún dato es erróneo o símplemente deseas dar algún consejo, no dudes en dejar un comentario. Todo feedback es bienvenido siempre que sea respetuoso. También puedes contactarme por estas redes sociales https://linktr.ee/hamster_ruso si lo consideras necesario.