Cuando un músico crea una melodía, puede transmitirla a otros músicos (o intérpretes) mediante un lenguaje de diseño como los pentagramas. En esencia, esta notación visual permite capturar la música en términos precisos y estandarizados. Un do es un do, una corchea es una corchea, etc. Cuando un diseñador de juegos crea un juego, lamentablemente, no dispone de un lenguaje de diseño para transmitir su creación a otros desarrolladores. Y en esta línea de investigación, intentamos aportar una notación visual que permita capturar los juegos de forma precisa y estandarizada. Lo que se conoce como un lenguaje de especificación para juegos.
En primer lugar hay que resaltar que estamos capturando únicamente los juegos como conceptos de diseño, sin entrar en los detalles tecnológicos. Del mismo modo, en arquitectura los planos capturan únicamente los conceptos arquitectónicos de diseño y no entran en los detalles tecnológicos de los materiales, proveedores, etc. Esta abstracción tecnológica nos permitirá comunicar juegos que se ejecutan en tecnologías antiguas, tal vez obsoletas, del mismo modo que comunicamos los juegos para las tecnologías más modernas. Del mismo modo, una partitura puede tocarse sobre cualquier instrumento musical, desde los más antiguos a los más modernos. Y esto es una gran ventaja, tanto para el estudio de los juegos del pasado como para el aprendizaje de los juegos que aún están por venir.
Por último, ya que los juegos son artefactos complejos y multi-disciplinares por naturaleza parece lógico que no abordemos la creación de un lenguaje para el diseño de juegos desde una única perspectiva. Hemos dividido el lenguaje en varias vistas, que nos permiten describir los juegos atendiendo a sus aspectos sociales, de reglas y estructurales y de interfaz gráfica. Podrían hacerse más divisiones: audio, inteligencia artificial, narración, etc. Pero hay que empezar por algún sitio, y nos parece que el núcleo de jugabilidad radica en estas 4 primeras vistas.
EL DIAGRAMA DE CONTEXTO SOCIAL:
La perspectiva social de los juegos es evidente y fundamental. Sin jugadores que jueguen al juego, no hay juego. Por ello, empezamos definiendo cuántos jugadores se permitarán en el juego, así como si hay diferentes roles o funciones específicas en el juego. Además, se hace necesario expresar si los jugadores cooperan en equipos o compiten entre sí. Para expresar todos estos conceptos utilizamos diversas figuras a modo de primitivas de diseño.
En primer lugar, el monigote indica que hay un jugador. El monigote puede llevar escrito dos números separados por puntos que indican el número mínimo y máximo de jugadores que se permiten. Si el juego permitiera únicamente de 1 a 2 jugadores se dibujaría un monigote con un 1..2 que indicaría el número permitido de jugadores. En el caso de que no haya un máximo número de jugadores se indica N, queriendo decir "infinito".
En segundo lugar, se pueden rodear monigotes con un círculo discontinuo que indica la presencia de un equipo. Los monigotes que estén en el interior del círculo se consideran los miembros del equipo.
En tercer lugar, se pueden unir con una flecha de doble punta aquellos equipos o jugadores (círculos o monigotes) que compiten entre sí. Si los equipos o jugadores compiten contra el juego puede dibujarse una caja que representa conceptualmente al juego.
A continuación se muestran algunos ejemplos ilustrativos de diagramas de contexto social. Como puede observarse, este diagrama no sólo es válido para videojuegos sino para juegos de todo tipo en que intervengan jugadores.
EL DIAGRAMA DE REGLAS Y ESTRUCTURAL:
Adentrándonos en el interior de los juegos, se hace imprescindible expresar las reglas que definen la jugabilidad del juego. Las reglas pueden expresarse en lenguaje natural, en castellano. Pero esto tiene muchos inconvenientes, como que cada cual lo escribiría de una forma y resultaría muy difícil entenderse. Para evitar este problema, vamos a definir las reglas de nuevo mediante un conjunto de primitivas de diseño.
En esta ocasión sólo hay una forma básica, la flecha que separa el "antes" del "después". Las reglas se definen siempre como un "si ocurre esto, entonces ocurre lo otro". Por lo que describiremos una condición en el "antes" y cuando se cumpla, ocurrirá el "después". Por ejemplo: si el personaje del jugador se queda sin vidas, flechita, entonces el personaje del jugador termina la partida. Bueno, ya he avanzado algunas cosas de más, como los personajes y la partida, pero ahora las iremos viendo poco a poco. La idea es que definiendo un conjunto de reglas sencillas expresamos cómo funcionará el juego. Pero como hemos dicho antes que no vale escribir palabras en castellano, ¿cómo expresamos el "antes" y el "después" de las reglas? Mediante la vista estructural.
Para cubrir la necesidad de expresar con qué elementos vamos a definir las reglas del juego aparece el diagrama estructural. Le hemos llamado diagrama estructural porque define la estructura del juego, qué hay y qué no hay en el juego. Y luego las reglas definirán qué ocurre con todo ello durante el gameplay. Para expresar estos conceptos vamos a utilizar de nuevo primitivas de diseño, esta vez un poco más abstractas.
En primer lugar, una caja representa una entidad de juego. ¿Qué es una entidad de juego? Pues sencillamente un objeto o personaje del juego. Por ejemplo, una caja con "Mario : Player Character" escrito en ella estaría definiendo que hay un "personaje jugador" llamado Mario. En general, separaremos con dos puntos el nombre del concepto del tipo de concepto. Si en la caja pusiera "Seta : Non-Player Character" sería un "personaje no jugador" llamado Seta. Y si pusiera "Moneda : Game entity" sería un objeto llamado Moneda. Los términos "personaje jugador" y "personaje no jugador" os serán conocidos a los más roleros, y como siempre, los vamos a abreviar con PJ y PNJ (o en inglés PC y NPC). Los PJ son entidades de juego que maneja algún jugador, los PNJ son entidades de juego que no maneja ningún jugador y que por tanto maneja el sistema de juego, lo que en el caso de los videojuegos suele llamarse inteligencia artificial. Por último, cada juego debe tener obligatoriamente una caja con el nombre del juego que representa el sistema de juego en sí mismo, ya que en algún momento querremos hacer reglas sobre el juego en general. Pongamos por ejemplo una caja "Super Mario Bros : Juego" que indica que el "juego" se llamará Super Mario Bros.
En segundo lugar, dentro de las cajas podemos incluir atributos y eventos. Los atributos y eventos son lo que diferencian a Mario de una Seta o de una Moneda (sin entrar en el nivel gráfico de que Mario lleva bigote). Los atributos describen variables que miden algo sobre las entidades de juego. Por ejemplo, Mario tiene un número de vidas, por lo que dentro de la caja Mario habrá una línea que diga "número de vidas : número natural = 3" queriendo decir que Mario tiene una variable llamada número de vidas que cuenta mediante números naturales las vidas de Mario y que empieza con un valor igual a 3 vidas. Los PNJs y los objetos también pueden tener variables, como los "puntos : número natural =100" que indica que una Moneda almacena 100 puntos para cuando Mario la recoja. Los eventos, por otro lado, describen sucesos o acciones del juego. En el caso de Mario, podría definirse "saltar : acción", indicando que Mario puede realizar una acción llamada saltar. Los objetos son pasivos, pero podrían definirse eventos como "ser recogida : evento" indicando que la Moneda puede ser recogida por algún personaje.
De este modo, podríamos definir a Mario, la Seta y la Moneda para posteriormente hacer reglas con ellas de la siguiente forma. "Mario.número de vidas = 0, flechita, Mario.fin de partida" que se leería "si el número de vidas de Mario llega a 0, entonces Mario termina su partida". Puede que estés pensando que antes había dicho que queríamos evitar escribir en lenguaje natural, y sin embargo hemos terminado poniendo algunas cosas en lenguaje natural, como "Mario", "número de vidas" o "fin de partida". Vale, es verdad. Pero fíjate en que si cambias "Mario" por "Sonic" y "número de vidas" por "number of lives" o cualquier otro texto, la regla sigue siendo la misma. Es decir, la regla no depende del bigote de Mario, ni de las zapatillas de Sonic. De hecho, la regla solo depende del significado que se le de a cada elemento en las reglas, aunque para eso hay que entrar en más detalle. Fíjate, además, de que gracias a esta forma de definir las reglas podemos establecer similitudes y diferencias con un criterio objetivo. La regla "Sonic.número de vidas = 0, flechita, Sonic.fin de partida" es la misma regla que la de Mario, es decir, son reglas sinónimas. Y, sin embargo, no es la misma regla que "Sonic.choca con Enemigo, flechita, Sonic.número de vidas-1". Y también fíjate que hemos ganado mucho en concisión. Las reglas que estoy poniendo se escriben en una línea, y puede describirse un juego como el Super Mario Bros o el Sonic en un puñado de 10 a 30 reglas. Seguro que si hubieras intentado describir en tus propias palabras estos juegos hubieras utilizado mucho más de 10 a 30 líneas.
DIAGRAMA DE INTERFAZ GRÁFICA:
Una vez expresado el contexto social y los aspectos internos del juego, hace falta definir los aspectos de interfaz, es decir, cómo se muestra el juego a los jugadores. En esencia, los gráficos de los juegos intentan mostrarnos visualmente la información más importante del juego. Afortunadamente, en la vista estructural hemos definido todas las entidades de juego importantes, así que ahora solo hay que decir cuáles de esos elementos vamos a mostrar y cómo.
En primer lugar, podemos dibujar un rectángulo grande para representar una pantalla. Cada pantalla puede contener a su vez multitud de indicadores de información, que llamaremos contenedores visuales porque contienen información y la representan de forma visual. Los contenedores se dibujan como rectángulos dentro del rectángulo grande de la pantalla y se indica qué variable de juego contiene la información que van a mostrar. Así, un cuadrado que contenga "Mario.número de vidas" mostrará en pantalla el número de vidas de Mario durante el juego. Sin embargo, esta información se puede postrar de diversas formas: textualmente, con imágenes o con barras de progreso.
En segundo lugar, tanto los rectángulos grandes de las pantallas como los rectángulos con iconos de los contenedores visuales pueden tener flechas gruesas en sus lados para indicar que la pantalla o el contenedor visual no está fijo. Así, una pantalla con flechas gruesas horizontales indicaría que la pantalla puede moverse hacia izquierda o derecha para mostrar más escenario, en lo que habitualmente se conoce como scroll lateral. Igualmente, una pantalla con flechas gruesas verticales podría moverse hacia arriba o abajo, en scroll vertical. Y si la pantalla tiene flechas gruesas en los cuatro lados, la pantalla podría moverse en todas direcciones haciendo un scroll bidireccional. A simple vista se hace de nuevo evidente que los juegos 2D pueden catalogarse según el tipo de scroll de sus pantallas: Tetris sería un buen ejemplo de juego sin scroll, es decir, fijo. Los juegos de lucha como Street Fighter 2 o Streets of Rage 2 serían buenos ejemplos de juegos con scroll lateral. Los juegos de aviones como 1942 son buen ejemplo de scroll vertical. Y juegos como Starcraft son buen ejemplo de scroll bidireccional.
En tercer y último lugar, pueden dibujarse flechas finas entre pantallas para representar el cambio de una pantalla a otra. Por ejemplo, desde la pantalla de juego podría salir una flecha que llevara a la pantalla del menú principal o a la pantalla del inventario. Esto nos ayuda a dibujar el flujo de pantallas que el jugador podrá navegar mientras juega. Además, se puede dibujar mediante un punto grueso una pantalla especial que no existe, pero que nos ayuda a representar qué pantalla será la primera en mostrarse. La pantalla a la que apunte el punto grueso será la pantalla inicial.
Y esto es todo por ahora. Ya tenemos un lenguaje visual para diseñar juegos. Está incompleto, pero por algún sitio hay que empezar. Con el tiempo completaremos las demás vistas para describir los juegos completamente. Pero mientras tanto ya puedes diseñar juegos en un par de hojas de papel y comunicárselos a tus amigos o compañeros de desarrollo.
En primer lugar hay que resaltar que estamos capturando únicamente los juegos como conceptos de diseño, sin entrar en los detalles tecnológicos. Del mismo modo, en arquitectura los planos capturan únicamente los conceptos arquitectónicos de diseño y no entran en los detalles tecnológicos de los materiales, proveedores, etc. Esta abstracción tecnológica nos permitirá comunicar juegos que se ejecutan en tecnologías antiguas, tal vez obsoletas, del mismo modo que comunicamos los juegos para las tecnologías más modernas. Del mismo modo, una partitura puede tocarse sobre cualquier instrumento musical, desde los más antiguos a los más modernos. Y esto es una gran ventaja, tanto para el estudio de los juegos del pasado como para el aprendizaje de los juegos que aún están por venir.
Por último, ya que los juegos son artefactos complejos y multi-disciplinares por naturaleza parece lógico que no abordemos la creación de un lenguaje para el diseño de juegos desde una única perspectiva. Hemos dividido el lenguaje en varias vistas, que nos permiten describir los juegos atendiendo a sus aspectos sociales, de reglas y estructurales y de interfaz gráfica. Podrían hacerse más divisiones: audio, inteligencia artificial, narración, etc. Pero hay que empezar por algún sitio, y nos parece que el núcleo de jugabilidad radica en estas 4 primeras vistas.
EL DIAGRAMA DE CONTEXTO SOCIAL:
La perspectiva social de los juegos es evidente y fundamental. Sin jugadores que jueguen al juego, no hay juego. Por ello, empezamos definiendo cuántos jugadores se permitarán en el juego, así como si hay diferentes roles o funciones específicas en el juego. Además, se hace necesario expresar si los jugadores cooperan en equipos o compiten entre sí. Para expresar todos estos conceptos utilizamos diversas figuras a modo de primitivas de diseño.
En primer lugar, el monigote indica que hay un jugador. El monigote puede llevar escrito dos números separados por puntos que indican el número mínimo y máximo de jugadores que se permiten. Si el juego permitiera únicamente de 1 a 2 jugadores se dibujaría un monigote con un 1..2 que indicaría el número permitido de jugadores. En el caso de que no haya un máximo número de jugadores se indica N, queriendo decir "infinito".
En segundo lugar, se pueden rodear monigotes con un círculo discontinuo que indica la presencia de un equipo. Los monigotes que estén en el interior del círculo se consideran los miembros del equipo.
En tercer lugar, se pueden unir con una flecha de doble punta aquellos equipos o jugadores (círculos o monigotes) que compiten entre sí. Si los equipos o jugadores compiten contra el juego puede dibujarse una caja que representa conceptualmente al juego.
A continuación se muestran algunos ejemplos ilustrativos de diagramas de contexto social. Como puede observarse, este diagrama no sólo es válido para videojuegos sino para juegos de todo tipo en que intervengan jugadores.
EL DIAGRAMA DE REGLAS Y ESTRUCTURAL:Adentrándonos en el interior de los juegos, se hace imprescindible expresar las reglas que definen la jugabilidad del juego. Las reglas pueden expresarse en lenguaje natural, en castellano. Pero esto tiene muchos inconvenientes, como que cada cual lo escribiría de una forma y resultaría muy difícil entenderse. Para evitar este problema, vamos a definir las reglas de nuevo mediante un conjunto de primitivas de diseño.
En esta ocasión sólo hay una forma básica, la flecha que separa el "antes" del "después". Las reglas se definen siempre como un "si ocurre esto, entonces ocurre lo otro". Por lo que describiremos una condición en el "antes" y cuando se cumpla, ocurrirá el "después". Por ejemplo: si el personaje del jugador se queda sin vidas, flechita, entonces el personaje del jugador termina la partida. Bueno, ya he avanzado algunas cosas de más, como los personajes y la partida, pero ahora las iremos viendo poco a poco. La idea es que definiendo un conjunto de reglas sencillas expresamos cómo funcionará el juego. Pero como hemos dicho antes que no vale escribir palabras en castellano, ¿cómo expresamos el "antes" y el "después" de las reglas? Mediante la vista estructural.
Para cubrir la necesidad de expresar con qué elementos vamos a definir las reglas del juego aparece el diagrama estructural. Le hemos llamado diagrama estructural porque define la estructura del juego, qué hay y qué no hay en el juego. Y luego las reglas definirán qué ocurre con todo ello durante el gameplay. Para expresar estos conceptos vamos a utilizar de nuevo primitivas de diseño, esta vez un poco más abstractas.
En primer lugar, una caja representa una entidad de juego. ¿Qué es una entidad de juego? Pues sencillamente un objeto o personaje del juego. Por ejemplo, una caja con "Mario : Player Character" escrito en ella estaría definiendo que hay un "personaje jugador" llamado Mario. En general, separaremos con dos puntos el nombre del concepto del tipo de concepto. Si en la caja pusiera "Seta : Non-Player Character" sería un "personaje no jugador" llamado Seta. Y si pusiera "Moneda : Game entity" sería un objeto llamado Moneda. Los términos "personaje jugador" y "personaje no jugador" os serán conocidos a los más roleros, y como siempre, los vamos a abreviar con PJ y PNJ (o en inglés PC y NPC). Los PJ son entidades de juego que maneja algún jugador, los PNJ son entidades de juego que no maneja ningún jugador y que por tanto maneja el sistema de juego, lo que en el caso de los videojuegos suele llamarse inteligencia artificial. Por último, cada juego debe tener obligatoriamente una caja con el nombre del juego que representa el sistema de juego en sí mismo, ya que en algún momento querremos hacer reglas sobre el juego en general. Pongamos por ejemplo una caja "Super Mario Bros : Juego" que indica que el "juego" se llamará Super Mario Bros.
En segundo lugar, dentro de las cajas podemos incluir atributos y eventos. Los atributos y eventos son lo que diferencian a Mario de una Seta o de una Moneda (sin entrar en el nivel gráfico de que Mario lleva bigote). Los atributos describen variables que miden algo sobre las entidades de juego. Por ejemplo, Mario tiene un número de vidas, por lo que dentro de la caja Mario habrá una línea que diga "número de vidas : número natural = 3" queriendo decir que Mario tiene una variable llamada número de vidas que cuenta mediante números naturales las vidas de Mario y que empieza con un valor igual a 3 vidas. Los PNJs y los objetos también pueden tener variables, como los "puntos : número natural =100" que indica que una Moneda almacena 100 puntos para cuando Mario la recoja. Los eventos, por otro lado, describen sucesos o acciones del juego. En el caso de Mario, podría definirse "saltar : acción", indicando que Mario puede realizar una acción llamada saltar. Los objetos son pasivos, pero podrían definirse eventos como "ser recogida : evento" indicando que la Moneda puede ser recogida por algún personaje.
De este modo, podríamos definir a Mario, la Seta y la Moneda para posteriormente hacer reglas con ellas de la siguiente forma. "Mario.número de vidas = 0, flechita, Mario.fin de partida" que se leería "si el número de vidas de Mario llega a 0, entonces Mario termina su partida". Puede que estés pensando que antes había dicho que queríamos evitar escribir en lenguaje natural, y sin embargo hemos terminado poniendo algunas cosas en lenguaje natural, como "Mario", "número de vidas" o "fin de partida". Vale, es verdad. Pero fíjate en que si cambias "Mario" por "Sonic" y "número de vidas" por "number of lives" o cualquier otro texto, la regla sigue siendo la misma. Es decir, la regla no depende del bigote de Mario, ni de las zapatillas de Sonic. De hecho, la regla solo depende del significado que se le de a cada elemento en las reglas, aunque para eso hay que entrar en más detalle. Fíjate, además, de que gracias a esta forma de definir las reglas podemos establecer similitudes y diferencias con un criterio objetivo. La regla "Sonic.número de vidas = 0, flechita, Sonic.fin de partida" es la misma regla que la de Mario, es decir, son reglas sinónimas. Y, sin embargo, no es la misma regla que "Sonic.choca con Enemigo, flechita, Sonic.número de vidas-1". Y también fíjate que hemos ganado mucho en concisión. Las reglas que estoy poniendo se escriben en una línea, y puede describirse un juego como el Super Mario Bros o el Sonic en un puñado de 10 a 30 reglas. Seguro que si hubieras intentado describir en tus propias palabras estos juegos hubieras utilizado mucho más de 10 a 30 líneas.
DIAGRAMA DE INTERFAZ GRÁFICA:
Una vez expresado el contexto social y los aspectos internos del juego, hace falta definir los aspectos de interfaz, es decir, cómo se muestra el juego a los jugadores. En esencia, los gráficos de los juegos intentan mostrarnos visualmente la información más importante del juego. Afortunadamente, en la vista estructural hemos definido todas las entidades de juego importantes, así que ahora solo hay que decir cuáles de esos elementos vamos a mostrar y cómo.
En primer lugar, podemos dibujar un rectángulo grande para representar una pantalla. Cada pantalla puede contener a su vez multitud de indicadores de información, que llamaremos contenedores visuales porque contienen información y la representan de forma visual. Los contenedores se dibujan como rectángulos dentro del rectángulo grande de la pantalla y se indica qué variable de juego contiene la información que van a mostrar. Así, un cuadrado que contenga "Mario.número de vidas" mostrará en pantalla el número de vidas de Mario durante el juego. Sin embargo, esta información se puede postrar de diversas formas: textualmente, con imágenes o con barras de progreso.
- Si el rectángulo tiene una T mayúscula dibujada en su interior, el número de vidas de Mario se mostrará textualmente, es decir, con dígitos y letras. Si Mario tuviera 3 vidas, se mostraría un 3. Otros ejemplos típicos más ilustrativos serían los puntos en los juegos arcade tipo Space Invaders o el tiempo en los juegos con reloj digital como Street Fighter 2.
- Si el rectángulo tiene una i minúscula dibujada en su interior, el número de vidas de Mario se mostraría mediante imágenes. Para que se entienda mejor, recuerda el caso de la salud en Doom, donde se mostraba el estado de salud del PJ mediante diversas imágenes del protagonista.
- Si el rectángulo tiene una flecha en su interior, el número de vidas de Mario se mostrará como una barra de progreso. La flecha podría ser horizontal, vertical o circular ya que se puede mostrar el progreso de diferentes maneras. Pongamos como ejemplo de barra horizontal la salud de los luchadores en Street Fighter 2, como ejemplo de barra vertical la fuerza del golpeo en los juegos de golf, o el maná en Diablo 2 (sí, a pesar de que tenga forma circular, el maná baja cuando se agota y sube cuando aumenta, por lo que es una barra vertical con un precioso dibujo en forma de pócima redonda). Ejemplos de barra circular son más difíciles de encontrar, pero es típico en juegos de carreras para indicar la velocidad del coche (la aguja gira describiendo un ángulo mayor para 2 Km/h que para 100 Km/h, luego es una barra de progreso circular).
En segundo lugar, tanto los rectángulos grandes de las pantallas como los rectángulos con iconos de los contenedores visuales pueden tener flechas gruesas en sus lados para indicar que la pantalla o el contenedor visual no está fijo. Así, una pantalla con flechas gruesas horizontales indicaría que la pantalla puede moverse hacia izquierda o derecha para mostrar más escenario, en lo que habitualmente se conoce como scroll lateral. Igualmente, una pantalla con flechas gruesas verticales podría moverse hacia arriba o abajo, en scroll vertical. Y si la pantalla tiene flechas gruesas en los cuatro lados, la pantalla podría moverse en todas direcciones haciendo un scroll bidireccional. A simple vista se hace de nuevo evidente que los juegos 2D pueden catalogarse según el tipo de scroll de sus pantallas: Tetris sería un buen ejemplo de juego sin scroll, es decir, fijo. Los juegos de lucha como Street Fighter 2 o Streets of Rage 2 serían buenos ejemplos de juegos con scroll lateral. Los juegos de aviones como 1942 son buen ejemplo de scroll vertical. Y juegos como Starcraft son buen ejemplo de scroll bidireccional.
En tercer y último lugar, pueden dibujarse flechas finas entre pantallas para representar el cambio de una pantalla a otra. Por ejemplo, desde la pantalla de juego podría salir una flecha que llevara a la pantalla del menú principal o a la pantalla del inventario. Esto nos ayuda a dibujar el flujo de pantallas que el jugador podrá navegar mientras juega. Además, se puede dibujar mediante un punto grueso una pantalla especial que no existe, pero que nos ayuda a representar qué pantalla será la primera en mostrarse. La pantalla a la que apunte el punto grueso será la pantalla inicial.
Y esto es todo por ahora. Ya tenemos un lenguaje visual para diseñar juegos. Está incompleto, pero por algún sitio hay que empezar. Con el tiempo completaremos las demás vistas para describir los juegos completamente. Pero mientras tanto ya puedes diseñar juegos en un par de hojas de papel y comunicárselos a tus amigos o compañeros de desarrollo.
No hay comentarios:
Publicar un comentario