Que un buen diseño es indispensable para acometer cualquier proyecto informático, lo sabe cualquier persona que haya creado o codificado algo. El mundo del desarrollo de software de entretenimiento se encuentra completamente dominado por diseños muy elaborados. De poco vale tener una idea revolucionaria si no hay un diseño que se encargue de darle forma. Antes de ponerse a trabajar en la creación de un videojuego, por pequeño que éste sea, hay que armarse de papel y bolígrafo y precisar todas y cada una de las etapas por las que tenemos que pasar de una forma clara y concisa. Si nuestro diseño es robusto, está bien realizado y se encuentra perfectamente delimitado (sabemos qué es lo que va y no va a tener), la codificación puede ser algo "trivial". Es preferible pasarse cuatro semanas (o las que hagan falta) diseñando todos y cada uno de los aspectos del juego antes que volverse loco a los siete días de comenzar la codificación.

Es obvio que trabajar en una aventura gráfica no es lo mismo que trabajar en un arcade o en un juego de estrategia sin embargo, todos nuestros diseños o guiones siempre tendrán las mismas etapas o campos "a rellenar". Una aventura gráfica tendrá un buen "taco" de hojas destinadas al guión pero, seguramente, el área destinada a la programación en sí no sea, en principio, tan compleja como el de un juego de acción o un simulador. Del mismo modo, un arcade no tendrá mucho espacio destinado al argumento del juego (y si me apuráis, el guión será nulo), sin embargo, eso no quiere decir que no pueda tener uno complejo.

Un juego, por tanto, debe de ser perfectamente delimitado y estructurado en la etapa del diseño. De lo contrario, nos veremos con que no sabemos bien qué juego queremos hacer (nos surgen nuevas ideas que machacan a las anteriores, no tenemos claro cómo definir las estructuras, nos quedamos atascados en la codificación... no controlamos el proyecto y este nos desborda). El informe que hay que desarrollar no ha de ser tampoco realizado por una única persona a no ser, claro, que sea esta la que se encargue de realizar todas las tareas (en juegos sencillos, y sin demasiadas pretensiones comerciales, es decir, en el aprendizaje, esto es lo que ocurre). Hay que establecer unas partes globales que involucran a todos los miembros del proyecto (programadores, grafistas, guionistas, directores, etc) y otras destinadas a aquellos equipos o personas que se encargan de determinadas áreas específicas.

Como este artículo no pretende ser más que una sencilla referencia o consejo para todos aquellos que tengan en mente comenzar a trabajar en su primer juego, vamos a ver cómo podría ser un breve, pero eficaz, guión de trabajo.

Ideas generales.

Antes de comenzar a trabajar, si quiera en el guión del juego, hace falta tener una idea más o menos clara de lo que queremos hacer (no de cómo vamos a implementarlo). Para ello, debemos de partir de una idea inicial. ¿Qué juego queremos hacer?, ¿una aventura?, ¿un juego de rol?, ¿un shot'em up?, ¿un juego de estrategia?, ¿tal vez uno de habilidad?... Una vez que nos hemos decidido por el género del que va a "beber" nuestro juego, viene la etapa de "brain storms" (tormentas de ideas). Las "brain storms" consisten, básicamente, en que los miembros que van a desarrollar el juego se reúnan en un determinado lugar (una habitación acogedora, una cafetería, un parque... en donde os sintáis a gusto). Es imprescindible que ese lugar ayude a inspiraros. Acto seguido, se comienzan a dar sugerencias sobre lo que debería de existir en el juego como, por ejemplo, opciones a incluir, tipo de perspectiva a utilizar, estilo de los gráficos, ideas generales sobre el argumento, tipo de dificultad, etc. Como es lógico, alguien deberá de ir anotando todas esas ideas generales que van surgiendo y que van pasando por el "filtro" que es el grupo de trabajo. Si da el caso de que no tienes a nadie con quien realizar el proyecto, no pasa nada, basta con que tú mismo te encargues de hacer las anotaciones generales que se te vayan ocurriendo (mientras te encuentras escuchando tú disco de música preferido).

Lo más normal es que durante este periodo de "brain storms" nuestro juego adquiera unas características descomunales, en otras palabras, que para concluirlo haga falta un equipo de 20 personas altamente especializadas. Por este motivo, y para prevenirnos de las emociones, es indispensable que una vez que hayamos "volcado" todas nuestras ideas en una sencilla hoja de notas, vayamos desechando las que se escapen de nuestras propias posibilidades (me temo que incluir esa pantalla de presentación va a necesitar un "Silicon", que para realizar ese juego de acción 3D va a ser necesario contratar a Javier Arévalo, o que para saber incluir todo esos aspectos estratégicos, vamos a tener que llamar a Gonzalo Suárez) y las que no resulten coherentes con lo que queremos realizar. Esta fase es, probablemente, una de las más importantes de todas pues los programadores y grafistas deben de ser honestos consigo mismos y decir si pueden o si no pueden realizar todo lo que pone en esa "inocente" hoja de notas. Si nuestro juego es excesivamente (y si me apuráis, un poco) ambicioso, habrá un 99.9% de posibilidades de que nunca se acabe. Más vale hacer juegos poco complicados pero bien pulidos y trabajados, que intentar ser los mejores desarrolladores del mundo con el primer título. No lo olvidéis nunca, sed realistas y no intentéis conquistar el mundo a la primera.

Informe general sobre el juego.

Una vez que nos hemos quedado con unas cuantas ideas factibles, llega el turno de hacer un guión o informe más o menos estable sobre lo que será nuestro juego. Aquí, sería bueno que la persona que haya estado tomando las notas se ponga delante de su procesador de textos favorito y vaya escribiendo lo que va a ser nuestro juego, las opciones que va a tener y las posibilidades del mismo. No se trata de construir el guión. Se trata, simplemente, de escribir de forma seria todas las ideas que han sobrevivido a la "brain storm". No hay que utilizar frases del tipo "el juego podría incluir..." sino frases del tipo "el juego incluirá...", es decir, se trata de establecer qué es lo que va a existir en nuestro juego. Hay que hablar del género del mismo, por ejemplo, "El proyecto X (sería bueno ir asignando un nombre al proyecto), va a ser un juego de estrategia por turnos ambientado en la época medieval fantástica...", de las opciones generales que va a tener explicando, a su vez, qué es lo que podremos encontrarnos dentro de ellas (lo que podremos hacer). Un ejemplo de esto último podría ser el decir "Las opciones generales van a ser [Partida Nueva] [Cargar Partida] [Ver Créditos] y [Abandonar Juego". A continuación, se explicaría cada una de las mismas. Por ejemplo, basta con decir que si se pulsa en "[Partida Nueva]" el jugador comenzará un nuevo juego y le aparecerá una sencilla pantalla de presentación para ponerle en situación. A continuación, vendría otra en la que podría elegir el héroe a encarnar, el bando, y la dificultad. Todas estas explicaciones, se encuadrarían en un primer nivel sobre el que poder situarse.

Lo importante, como veréis cuando trabajéis en equipo, es que todos seáis capaces de ver el mismo juego en vuestra imaginación porque, de lo contrario, surgirán infinidad de problemas después.

Una vez que se definen las opciones generales, y lo que aparecería nada más acceder a ellas, pasamos a la segunda parte del "Informe general sobre el juego". Ahora debería de estudiarse lo que nos ofrecerá el juego en sí, es decir, cómo se representaría el juego en pantalla, qué opciones tendría disponible el usuario o con qué estilo se plasmaría todo. Se trata de realizar vistazo exhaustivo a todas (no hay que dejarse nada en el tintero) las características que van a existir en el juego de cara al usuario. Para completar con éxito esta parte, buscaremos las ideas que habíamos seleccionado en la "brain storm" y comenzamos a ponerlas de forma ordenada y coherente en el informe. Así, si nuestro juego es de estrategia, debería de figurar el modo de representación (2D vista desde arriba, isométrico, ¡¿3D?!...), las opciones de acción que tendríamos sobre nuestras unidades (si podremos moverlas animadamente, si podremos atacar, si tendrán energía, si podrán mejorar a lo largo de los combates, si podrán llevar armas, si conversarán, qué tipos de unidades existirán, etc), sobre las ciudades que haya, si es que hay (qué opciones podremos realizar en una ciudad, si podremos reclutar unidades, construir edificios, recoger impuestos, utilizar minas, etc), sobre el interfaz (estilo de los menús, botón del ratón, etc), y cualquier otra característica (si podremos obtener información de la parte del mapa que pulsemos, si habrá diferentes tipos de terreno y si éstos tendrán influencia en el movimiento de nuestro personaje, si habrá cambios meteorológicos, posibilidad de consultar un mini mapa, de grabar partida y de recuperarla, de consultar estadísticas, etc).

Como veis, se trata de hacer un informe bastante serio de lo que existirá en el juego. Todo lo que aquí se plasme se deberá de seguir tajantemente y, sobre todo, hacerlo.

Lo que vendrá ahora serán las formas de abordar los problemas de codificación o representación de lo que se pretende ofrecer en el juego. Se debe de partir del hecho de que, con un "poco" de esfuerzo, se logrará hacer todo lo que hemos puesto que va a existir. Que no hay nada que se escapa completamente de nuestras posibilidades como programadores o grafistas.

En ésta segunda parte del Informe debe de estar todo pulido al máximo y aceptado por todos y cada uno de los miembros del equipo. Todos han de tener clarísimo lo que se va a realizar. Cualquier nueva idea que pueda amenazar mínimamente a las bases que aquí se escriban no deberá tenerse en cuenta. De lo contrario, nos veremos ahogados en mil y un cambios. Lo que aquí se escriba será lo que se haga. No haremos más pero tampoco menos.

Argumento y guión del juego.

Puede que nuestro juego carezca por completo de estos dos factores, puede que tenga un argumento simple y nada de guión o, puede que haga uso más o menos exhaustivo de estos dos recursos. El argumento del juego se encarga de crear una historia en la que empezar a situar al jugador. Es la historia o universo sobre el que construimos nuestro juego. Un guión, por el contrario, es la parte que se encarga de llevar los diálogos que puedan existir entre el (o los) protagonistas del juego y el resto de personajes que pueblen nuestra creación (a los cuales se les conoce como NPC <No Player Caracter> o, en castellano, PNJ <Personajes No Jugador>).

En una aventura, ya sea conversacional o gráfica, ésta debe ser la parte más completa de todo el informe pues es aquí donde residirá el "alma" del juego. En un arcade, el guión suele carecer de sentido, sin embargo, no es bueno desaprovechar la oportunidad de crear un argumento con el que dar profundidad a lo que ofrecemos al jugador (independientemente de lo simple que lo hagamos). Queda mucho mejor ofrecer una pantalla que nos comente cuál es nuestra misión que hacer que en el momento que se pulse "Nueva Partida" nos encontremos masacrando todo "bicho" viviente. Otro cantar sería si nuestro juego no se aferra a un género determinado, es decir, si bebe de muchas fuentes como aventura, arcade o rol. En ese caso, será esencial hacer un buen argumento y guión.

En conclusión, los juegos son "películas" en las que el usuario es el protagonista por eso, conviene hacer que nuestra "película" cree una situación concreta con unos hechos concretos y en un universo también concreto, en otras palabras, es aconsejable crear siempre un argumento. Si además vamos a tener la oportunidad de relacionarnos con el entorno, de hablar con otros personajes, etc, deberemos de construir un guión sólido. Los únicos juegos que pueden prescindir (aunque no tiene por qué ocurrir siempre) de estos dos factores serían los de habilidad o inteligencia ("Tetris" por ejemplo).

Estudio de las principales estructuras de datos.

Una vez que hemos escrito todas las opciones del juego, todo lo que el jugador podrá encontrarse en él, y tenemos una idea más o menos general de cómo implementarlas, llega la hora de definir las principales estructuras de datos, las especificaciones generales de nuestros archivos y, en líneas generales, la estructura interna de cara a la codificación.

Este es el momento de definir qué vamos a utilizar para poder, por ejemplo, almacenar los escenarios, las animaciones, los gráficos estáticos, las conversaciones o los datos auxiliares. Esta parte, además de ser la más importante de cara a que la codificación sea, ya no infinitamente más rápida y efectiva, sino correcta, es (o debería de ser), una de las más lentas de desarrollar. Hay que discutir los mejores caminos para implementar nuestro juego. Si utilizáis programación orientada a objetos (que deberíais a estas alturas), sería el momento de definir las clases generales, las posibles herencias, etc.

Por poner un ejemplo y siguiendo con el del juego de estrategia por turnos, aquí deberíamos de decidir cómo implementar los "Tiles"; si en un array estático o bien con listas dinámicas. Qué información se almacenará por cada casilla de mapa. De si se debe de mantener en todo momento los datos del mapa en memoria o sólo las partes sobre las que estamos actuando. De las dimensiones que tendrá nuestro juego (memoria que vamos a destinar al mapa). Sobre el formato que llevarán los gráficos estáticos (uno propio, un PCX, GIF, etc) o cuántos frames tendrán las unidades en el juego, etc.

Se trata de que los problemas principales de codificación encuentren la idea general de diseño para poder trabajar con una referencia clarísima e inamovible. Se debe definir todo de tal manera que resulte robusto, eficiente y no se venga abajo transcurridos 5 días de codificación. No hay que implementar los algoritmos, "sólo" diseñar las estructuras de datos a utilizar para poder realizar y construir nuestro juego, las funciones (si trabajamos en la arcaica programación estructurada) o las clases (si nos aprovechamos de las posibilidades de la programación orientada a objetos).

Aunque a primera vista pudiera parecer que esto es sólo tarea de los programadores, no lo es en absoluto pues los grafistas, por ejemplo, deben de saber con qué formato van a tener que trabajar, de qué tamaño tendrán que crear las unidades y figuras, qué tipos de "tiles" deberán de construir, qué paleta tendrán que implementar o de cuántos colores dispondrán para dibujar y cuáles serán reservados para las rutinas de codificación (es un buen momento de definir, por ejemplo, el color transparente que va a utilizar nuestro juego, o de las posiciones de la paleta, en donde almacenaremos los colores que van a ser rotados, etc).

Esta es la etapa, por así decirlo, crítica pues si no hacemos todo de forma eficiente y coherente, nos encontraremos con un programa redundante, lento y que aprovecha mal la memoria con lo que, transcurrida un par de semanas de codificación os volveréis locos al añadir más y más líneas de código.

Análisis del flujo principal.

Todo juego se compone de un flujo o, más bien, bucle principal en el que se deben de ir ejecutando todas las comprobaciones tales como pulsaciones de teclas, colisiones, actualización de los movimientos de los enemigos, etc. Resulta muy útil, por no decir esencial, crear un flujo de programa general. El objetivo vendría a ser que, mediante un pseudocódigo muy elemental, plasmáramos el funcionamiento interno del programa.

Un ejemplo podría ser el siguiente. Imaginar que el juego es un comecocos:

Carga_Mapa.

Inicializar_Estructuras.

Situar_Fantasmas.

Situar_Jugador.

Mostrar_Mapa.

MIENTRAS (No Salir_Juego)

HACER

Actualizar_Pos_Fantasmas.

SI Algún_Fantasma_Come ENTONCES Salir_Juego = Sí.

SI Pulsa_Tecla ENTONCES

SI Tecla=Movimiento ENTONCES Mover_Dirección.

SI Tecla=Pausa ENTONCES Detiene_Juego.

SI Tecla=Salir ENTONCES Salir_Juego = Sí.

FIN MIENTRAS

Como veis se trata de un flujo que describe el funcionamiento de un "Comecocos" realmente simple no obstante, nos sirve perfectamente para tener una idea de los algoritmos que debemos de implementar para hacer funcionar a nuestro programa y de cómo disponer el bucle que evalúe las iteraciones del jugador con el juego (movimientos, pulsación de teclas, etc) así como las actualizaciones constantes que han de realizarse.

Una vez que tenemos las estructuras de datos generales en donde guardar o representar los datos del juego y el flujo que nos indica el camino a seguir para implementar el código, pasaremos a estudiar los algoritmos más importantes a realizar.

Análisis de los principales algoritmos a implementar.

Este es el paso de más "bajo nivel" que debe de plasmarse en el informe. Realmente, corresponde por entero a los programadores aunque, en muchas ocasiones, dichos algoritmos podrán funcionar más eficientemente si los grafistas, por ejemplo, trabajan de una determinada forma sus gráficos. Es decir, siempre habrá que tener al tanto de lo que aquí definamos al encargado en dirigir la creación gráfica (si tiene algo que ver, claro está, lo que estamos haciendo con los gráficos).

El objetivo de este paso es el de escribir aquellos algoritmos más complicados en código directamente o bien, especificar más claramente ciertos pasos. Si nos ceñimos a nuestro ejemplo del "Comecocos", sería bueno especificar más claramente lo que hay que realizar cuando el usuario pulsa una tecla. Así, una de las cosas que podríamos hacer sería:

Estudio sobre Mover_Dirección.

Cuando se pulse aquí, llamaremos a una rutina que, recibiendo el valor de la tecla pulsada, deberá de actuar en consecuencia. He aquí un flujo muy poco optimizado pero muy ilustrativo.

Rutina_Movimiento (tecla_pulsada)

EMPIEZA

SI tecla_Pulsada = ARRIBA ENTONCES

EMPIEZA

// Comprueba colisión (Límites_Mapa).

SI Colisión(x,y) ENTONCES SALIR Rutina_Movimiento

// Comprueba colisión (Fantasmas).

SI Colisión (x,y)

// No hay colisión por lo que movemos

Mueve_PacMan_Posicion(x,y)

// Comprobamos si hemos comido bola

Comprueba colisión (Bola).

SI Come_Bola ENTONCES

Elimina_Posicion(x,y)Bola

SALIR Rutina_Movimiento

FIN SI MOVIMIENTO ARRIBA

SI tecla_Pulsada = DERECHA ENTONCES

.

.// Resto de instrucciones

SALIR Rutina_Movimiento

FIN SI MOVIMIENTO ARRIBA

SI tecla_Pulsada = ABAJO ENTONCES

.

.// Resto de instrucciones

SALIR Rutina_Movimiento

FIN SI MOVIMIENTO ARRIBA

SI tecla_Pulsada = IZQUIERDA ENTONCES

.

.// Resto de instrucciones

SALIR Rutina_Movimiento

FIN SI MOVIMIENTO ARRIBA

FIN Rutina_Movimiento

Con este ejemplo vemos que hay que implementar determinados algoritmos más claramente. Por ejemplo, habría que hacer uno sobre colisiones, otro para saber si nos comemos una bola, etc. Estos algoritmos deberían de escribirse en algún sitio antes de proceder a codificar. Esto es así, para evitar caer en el error de programar mediante la improvisación (ni se os ocurra poneros a programar sin algo de pseudocódigo o código escrito en papel). Como es lógico, no hace falta, ni mucho menos, codificar todos y cada uno de los algoritmos que existen en el juego. Basta que a aquellos más complejos les dediquemos una atención principal. El resto, podrán "montarse" fácilmente mediante una consulta al pseudocódigo.

Librerías, "tools" y "engines" necesarios.

Una vez que tenemos muy bien definidas todas las estructuras que utilizará el juego, llega el momento de ver qué es lo que necesitamos para poder acelerar lo máximo nuestro trabajo, así como de qué "engines" o sistemas de representación necesitaremos. Las "tools" son las herramientas que se crean los programadores para que, bien ellos o bien los grafistas, animadores o músicos, puedan trabajar de manera más específica y rápida. Así, si estamos haciendo un juego de estrategia por turnos basado en "tiles", sería bueno que nos creáramos un editor de escenarios para que los diseñadores fueran creando los mapas Este editor, luego se grabaría en un formato que el "engine" interno del juego sería capaz de utilizar correctamente. Por ponernos un ejemplo, si no nos creáramos un editor de escenarios, nos veríamos obligados bien a crearnos "a pelo" un archivo con todos los datos de un mapa (algo realmente horrible) o bien, a hacer aún más el bestia, a meter en el propio código todo lo referente al escenario. Puede que si tu juego no utiliza mapas excesivamente grandes (y tiene expansibilidad nula), estas dos últimas fórmulas no resulten muy descabelladas, pero en el momento en que quieras hacer algo mínimamente complejo, te será imposible trabajar de este modo.

Otras de las herramientas que pueden ser interesantes son las de dibujo y creación de animación. Naturalmente, si tenéis licenciado algún programa que se encargue de realizar todo este trabajo, no merece la pena perder tiempo en ello. De todas formas, siempre que hagáis algo medianamente complejo, necesitaréis de alguna herramienta que os acelere alguna parte de la creación del juego muy concreta.

Esta parte del informe se encargará pues, de especificar las "tools" y los "engines" necesarios o recomendables. Puede ocurrir que no necesitéis ni lo uno ni lo otro. Un juego del tipo del "Tetris" (un "Tetris" en 2D de lo más simple) realmente no necesita nada por el estilo, ni un editor de animaciones, ni un editor de escenarios, ni un engine complejo. Todo es perfectamente representable sin necesidad de recurrir a un sistema específico.

Anotaciones "work in progres".

Por mucho que nos hayamos trabajado el informe, siempre quedará algún resquicio que no hemos tenido en cuenta lo suficiente. Será muy importante ir anotando todas esas pequeñas correcciones que nos hemos visto obligados a realizar (a la hora de programar, siempre se nos puede haber pasado por alto algún detalle al ver que había algún otro camino para hacer lo mismo pero más rápidamente). Si hemos conseguido realizar un informe bien definido y robusto, estad seguro que éstas variaciones serán triviales, mínimas. Si, por el contrario, habéis pasado por alto el realizar un buen informe, os encontraréis improvisando continuamente y, al final, os quedará (si es que lográis acabarlo) un juego desastroso internamente (al menos, habréis aprendido para la próxima vez lo que nunca deberéis de hacer).

ÚLTIMA REVISIÓN EN FEBRERO DE 1999