Desarróllame

¡Muy buenas a todos! Ya he vuelto de Londres (estuve fuera desde octubre), y vuelvo a la carga con los tutoriales sobre diseño y programación de videojuegos. Para retomarlo, empiezo con algo suave, y creo que bastante interesante que escribí el jueves tras la charla de Daniel González en la Universidad Politécnica de Madrid con motivo de la II Edición del Game Spirit.

Si hay una materia que, en mi humilde opinión, se quedó algo flojita en el Máster en Diseño y Programación de Videojuegos de la Universidad Europea de Madrid que cursé el año pasado, desde luego ha sido Diseño de Niveles. Y no es precisamente un tema baladí, pues va a ser sobre los niveles donde se desarrollarán nuestros videojuegos. Para que veamos lo importante que puede llegar a ser un buen diseño de niveles, voy a poner un par de vídeos que hablan por sí mismos:

Por eso no he querido perderme la conferencia que ha ofrecido hoy en la Universidad Politécnica de Madrid  Daniel González, autor del libro Diseño de Videojuegos de la editorial Ra-Ma, profesor en Gametopía, creador de la revista digital Vive la Live y autor de Advertainmen, un blog con información jugosa sobre desarrollo de videojuegos.

Así que con su libro en una mano, y el bloc donde he tomado apuntes esta tarde en la otra, me dispongo a dar una serie de pautas y recomendaciones sobre diseño de niveles.

Pero me va a ser imposible porque no me quedan manos para escribir, así que antes voy a dejarlos sobre el escritorio.

Ya está.

Bueno, humor absurdo aparte, lo primero que hay que saber es quién diseña los niveles. Obviando el tema de que estamos en el país en el que contratan a una persona para hacer lo que deberían hacer dos o tres (para que luego digan que no somos productivos), la tarea del diseño de niveles recae sobre dos profesionales muy distintos: el guionista y el mapeador. Aunque lo más probable es que en un estudio pequeño el game designer, el guionista y el mapeador sean la misma persona, es importante saber distinguir el rol que vamos a tener cada momento, aunque sólo sea para estructurar nuestras tareas.

¿Qué hace el guionista?

El guionista debe describir cómo debe ser el escenario que debe crear el mapeador, pero, como siempre, tiene algunos límites no muy bien definidos para no hacer lo que no le corresponde. A groso modo, sería:

• Historia: Los escenarios deberían tener cierto nivel de profundidad, una historia de trasfondo que dé significado a todo lo que nos vamos a encontrar en él, y que nos haga sentir que ese lugar es algo más que un decorado. Un escenario con una buena historia puede dar lugar a quest secundarias que den más horas de diversión al jugador.
• Ambientación: No es tanto el apartado visual como la sensación que pretende transmitirnos: si queremos darle al jugador una sensación de agobio o de tranquilidad, si queremos que parezca gélido o tropical, inhóspito o familiar… puede que queramos causarle miedo, o melancolía. Un buen artista sabrá interpretar correctamente estas sensaciones y plasmarlas en el escenario.
• Dimensión: Cómo queremos que sea de grande nuestro nivel. Sencillo.
• Jugabilidad: Un aspecto que muchas veces olvidamos, es que un buen diseño de niveles debe aportar en cada escenario una jugabilidad que lo diferencie de los demás. Puede que en unas misiones prime la infiltración, y en otras la acción, que tengamos un tiempo límite para el escenario, alguien a quien debamos proteger, o que el propio nivel sea nuestro enemigo (como sucede en los juegos de plataformas).
• Personajes: Debemos definir a los enemigos y el resto de personajes que aparecerán en el nivel, y cómo interactuarán con él. Puede que alguien se esté escondiendo entre la maleza o en un intrincado laberinto, o que un enemigo esté usando sus poderes para arrojarte partes del escenario. O a lo mejor sólo es un pueblo tranquilo lleno de mercaderes. Quizás algún protagonista tiene una relación con ese sitio: ¿ocurrió algo en ese lugar? ¿quizás fue su hogar, ahora destruido?
• Items especiales: Remarco lo de especiales, ya que no me refiero a los típicos ítems de munición, vida, etc. que serán trabajo del mapeador, sino a los que encierran algún vínculo con el nivel. Una espada poderosa puede estar custodiada en ese templo, o a lo mejor es uno de los fragmentos de gema que estás buscando. Puede que consideres que ya va siendo hora de darle al protagonista algo de artillería pesada. El guionista tiene que tener claro dónde van a encontrarse esos items, y ser capaz de darles cierto protagonismo.
• Requisitos de entrada y de salida: Qué tenemos que hacer o tener para poder entrar en este nivel (quizás necesitamos ciertas habilidades, una llave, o haber completado otro nivel), así como qué es lo que tendremos que hacer para salir de él (llegar a un sitio, localizar algo o a alguien, acabar con un enemigo, etc.).
• Diálogos y cinemáticas: Su función está supeditada a todo lo anterior: contar algo de la historia, ambientar la acción, guiar en la jugabilidad, o presentar personajes e items especiales. En cualquier caso, es trabajo del guionista desarrollarla y no pasarse con ellos (que es algo que nos encanta a todos los guionistas). Recuerda que el jugador quiere jugar, no ver una película.

¿Qué hace el mapeador?

Pues el mapeador hace, precisamente, todo lo demás. Que no es poco.

• Mapa del nivel: En su libro, Daniel González recomienda la utilización de software como AutoRealm, aunque también se pueden utilizar otros como Tiled Map o editarlo directamente en nuestro motor favorito (Unity 3D, UDK, etc).
• Obstáculos: Muchos de los obstáculos vendrán dados por la descripción que nos haya dado el guionista, pero su distribución dependerá del mapeador. Pueden ser puertas cerradas, pasadizos ocultos, caminos bloqueados, cámaras de vigilancia si tenemos que infiltrarnos sin que nos pillen, etc.
• Enemigos y otros personajes: El guionista nos dice qué personajes va a haber, o con qué tipo de enemigos nos encontraremos, pero la distribución en el nivel depende completamente del mapeador.
• Puntos de guardado: Previamente, el game designer tiene que haber definido cómo va a guardarse la partida. Si existen puntos de guardado o checkpoints, corresponde al mapeador decidir dónde estarán situados.
• Items: Como ya comentamos, el mapeador también se encargará de distribuir los items estándar por el escenario (munición, items curativos, fuentes de maná, magias, etc). Es recomendable distribuirlos siempre después que los obstáculos y los enemigos, para mantener el equilibrio.

El trabajo del diseño de niveles es especialmente importante, ya que nos va a definir una serie de elementos clave que marcarán el trabajo del resto del equipo:

• Balance: Lo controlaremos mediante la distribución de los ítems. No es lo mismo ir sobrado de pociones de vida, que tener que administrarlas con cuentagotas.
• Ritmo: Lo marcaremos con la distribución de enemigos. Un mapa repleto de ellos será frenético respecto a otro que prefiera utilizar los obstáculos como elemento principal.
• Duración: Con los obstáculos aumentaremos la duración del juego.
• Curva de aprendizaje: Los puntos de guardado (si los tenemos), se irán distanciando a medida que avancemos en el juego.
• Trama y ambientación: Los diálogos y las cinemáticas del nivel no sólo deben darnos información sobre la historia, sino que además deben introducirnos en la acción. Esto es importantísimo: la forma de dar cierta información no será la misma en mitad de un tiroteo que en la Sala de Instrucciones de nuestro Cuartel General.

Recordemos que el diseño de niveles forma parte de la acción, del guión, y de la jugabilidad, pero sobre todo de la DIVERSIÓN. Si nuestro nivel no es divertido, da igual lo bien marcados que estén los ritmos, lo perfecto que encaje en nuestra historia, o lo distintiva que sea su jugabilidad.

Un nivel siempre debe ser divertido.

Espero que estas pautas básicas os hayan servido tanto a vosotros como a mí.

Muchos de vosotros os preguntaréis para qué os sirve un cuadro de selección si los juegos de estrategia os importan un pimiento. Pues antes de que dejéis de leer os aviso de que, aunque vuestro juego no incluya este elemento, a lo largo del tutorial veremos cosas tan básicas e imprescindibles como tirar «rayos» desde la cámara para ver qué tenemos delante de nuestro puntero (la base de cualquier shooter) o cómo pasar coordenadas de mundo a coordenadas de pantalla.Así, en este tutorial vamos a aprender a:

– Enfrentarnos a un proyecto real, utilizando las distintas herramientas que nos ofrece Unity 3D.
– Construir un código ordenado que responda a nuestros requerimientos.
– Crear GameObjects desde el código a partir de Prefabs.
– Utilizar los valiosos «Raycast» para detectar elementos de nuestra escena presentes en un determinado vector.
– Pasar coordenadas de mundo a coordenadas de pantalla.
– ¡Ah, sí! Y a crear un cuadro de selección :P.

Aunque voy a reutilizar algo del código de Bellum, para no liaros he decidido crear un nuevo proyecto.

En un alarde de originalidad, lo he llamado «Tutorial_SelectionBox».

¡Volví de vacaciones!

Y lo hago con un tutorial que considero básico e imprescindible: cómo funciona un videojuego. A la hora de enfrentarnos a cualquier cosa, lo más complicado suele ser saber cómo empezar, cuál es el origen de todo lo que vamos a hacer después. Y creo que esta preocupación ocurre tanto a la hora de programar, como de enfrentarse a una hoja en blanco o al pedir nuestra primera subida de sueldo.

Con los videojuegos algunos motores nos darán esta base, y a partir de ahí podemos mirar un montón de tutoriales para seguir haciendo cosas, pero si no sabemos qué es lo que hace funcionar a nuestro juego, o en qué parte actúa el API que estemos utilizando, muchas veces iremos a ciegas. Y como todos ya nos conocemos el refrán «ojos que no ven, ostiazo que te pegas» vamos a intentar arrojar un poco de luz sobre todo esto.

Pues bien, un juego no es más que un bucle continuo llamado game loop:

1. void run()
2. {
3.     bool playing = true;
4.     while (playing)
5.     {
6.         ReadInput(); //Leemos las entradas del teclado
7.         Update(); //Actualizamos el estado de los objetos
8.         Render(); //Los dibujamos en pantalla
9.     }
10. }

Todo juego tiene una estructura similar, pero tenemos que tener en cuenta el API sobre el que estamos trabajando.

ReadInput()
Aquí comprobamos el estado de los distintos dispositivos de entrada (ratón y teclado sobre todo, pero podría ser un joystick o un joypad, una pantalla táctil en el caso de un smartphone, o incluso un micrófono). Es altamente recomendable separar la lógica del ReadInput de la del Update(), y utilizar flags que indiquen el estado del input para que el Update actúe en consecuencia.

También es ideal que almacenemos las teclas en variables, de este modo podremos cambiar fácilmente el mando del juego.

No recomendado:

1. void run()
2. {
3.     bool playing = true;
4.     while (playing)
5.     {
6.         ReadInput(); //Leemos las entradas del teclado
7.         Update(); //Actualizamos el estado de los objetos
8.         Render(); //Los dibujamos en pantalla
9.     }
10. }
11. void ReadInput()
12. {
13.     //Cada API tiene su función para leer el Input.
14.     if (isKeyPressed(Key.Space))
15.     {
16.         Jump();
17.     }
18. }

1. void run()
2. {
3.     bool playing = true;
4.     //Input Keys
5.     const Key KEY_JUMP = Key.Space;
6.     //Input State
7.     bool jump;
8.     while (playing)
9.     {
10.         ReadInput(); //Leemos las entradas del teclado
11.         Update(); //Actualizamos el estado de los objetos
12.         Render(); //Los dibujamos en pantalla
13.     }
14. }
15. void ReadInput()
16. {
17.     //Cada API tiene su función para leer el Input.
18.     if (IsKeyPressed(KEY_JUMP))
19.     {
20.         jump = true;
21.     }
22. }
23. void Update()
24. {
25.     if (jump)
26.     {
27.         Jump(); //Esta función terminaría con un jump=false;
28.     }
29. }

De este modo, separaremos de forma lógica ambas funciones y tendremos un código más ordenado, lo que nos ayudará enormemente cuando tengamos un Update complejo en el que tengamos que tener en cuenta un montón de variables.

Update()
Aquí desarrollaremos toda la lógica de juego, pero no os abruméis. Un juego no es más que unos cuantos objetos con una serie de estados, que realizan funciones. Así, en función de su estado, cambiaremos su posición en la pantalla, pero también deberemos de acordarnos de controlar la vida, la munición, los puntos o el resto de variables que estemos utilizando.

Dentro del Update deberíamos tener en cuenta también la física, pero por lo general nos la manejará automáticamente nuestro motor, por lo que no tendremos que preocuparnos. Si no lo hace, hoy en día existen motores físicos para absolutamente todas las plataformas que seguro podremos utilizar. Unity 3D, por ejemplo, tiene su propio manejador de físicas, por lo que sólo nos tendremos que preocupar de establecer en nuestro objeto una serie de propiedades físicas.

Los cálculos físicos suelen ser los últimos que se realizan en el Update

Render()
Cuando trabajamos con un motor gráfico, lo que hace básicamente es manejarnos automáticamente la función Render() (aunque luego pueda resolvernos más cosas, como la física), ya que es la que trabaja directamente sobre las librerías gráficas (DirectX u OpenGL), y muchas veces en nuestros juegos nos bastará con añadir nuestros elementos a un Graphic Layer (una capa que se encarga de dibujar todo lo que haya en ella), o heredar nuestros objetos de alguna clase que contenga toda la lógica de renderizado.

¿Dónde encaja todo esto en Unity 3D?

Efectivamente, en Unity 3D nosotros no vemos este bucle por ningún lado.

Antes que nada, hay que comprender que Unity 3D sigue una arquitectura basada en componentes, que es ligeramente distinta a la más familiar POO (Programación Orientada a Objetos). La diferencia entre un objeto y un componente es que los primeros necesitan ser instanciados, es decir, partimos de una clase que define un tipo de objeto que nos servirá de molde para crear objetos similares (por ejemplo, la claseEnemy nos podría servir para crear multitud de enemigos). Mientras tanto, los componentes se asemejan más a scripts, trozos de código que dan una funcionalidad determinada al objeto al que se anexan, y cuando uitilicemos la palabra clave «this«, no referenciaremos al componente, sino al objeto sobre el que está alojado.

De este modo, si en Unity creas un GameObject (que es cualquier cosa que actúe en el juego), tendrá toda la funcionalidad básica de un objeto del juego, pero si además le añades, por ejemplo, un componente RigidBody, el GameObject tendrá física, y si también le pones un componente Player, en el que defines la lógica del jugador, esteGameObject ahora responderá a las acciones del jugador.

Ambas arquitecturas pueden combinarse, y de hecho lo hacen. Tú, por ejemplo, puedes crear un componente cuya lógica utilice instancias de clases, y después agregarlo como componente a un GameObject.

Muy bonito todo este inciso, pero seguimos sin ver el game loop del que os he hablado al principio. La razón de esto es que Unity lo está manejando de forma transparente, sin que nosotros nos demos cuenta. Cada vez que Unity da una vuelta al bucle, llama a una serie de funciones contenidas en el MonoBehaviour. Por eso, cuando creamos un script en C# (el lenguaje recomendado), veremos que hereda de esta clase. Así, lo único que tenemos que hacer cuando creamos un script es definir estas funciones. Por defecto Unity nos creará Start() y Update().

Unity 3D nos ofrece la documentación de las funciones que utiliza en esta web: http://unity3d.com/support/documentation/Manual/Execution%20Order.html

Es imprescindible que tengáis en cuenta que cada vuelta al loop puede tomar un tiempo distinto en función de la carga del procesador, por lo que tendréis que utilizar este espacio de tiempo en vuestros cálculos. Para ello, Unity pone a vuestra disposición la variable Time.deltaTime, que no es más que los segundos que ha tardado el juego en completar el último frame.

La excepción es FixedUpdate(), que tiene un tiempo de llamada específicado en la variable global Application.targetFrameRate.

Aunque para trabajar con físicas FixedUpdate() es la función recomendada, debemos tener mucho cuidado al utilizarla, ya que procesos muy cargantes o frameratesdemasiado pequeños pueden hacer que nuestro juego haga cosas raras o nos vaya a saltos.

Ahora que comprendemos el game loop de un juego y sabemos cómo interactuar con él en Unity 3D, podemos empezar a hacer nuestros primeros scripts sin cortocircuitarnos en el intento ;).

1. Lo primero que haremos va a ser bajarnos la última versión completamente gratis desde aquí: http://unity3d.com/unity/download/.

Con este artículo estrenamos Desarróllame, una nueva sección de n3dsworld donde iremos publicando artículos sobre el desarrollo de videojuegos y entrevistas con profesionales del sector.

Si quieres hacer un videojuego, ya has dado el primer paso de un largo camino, que es precisamente querer hacerlo. Puede que parezca una perogrullada, pero no lo es. Eso sí, debes estar muy seguro de que realmente quieres hacerlo.

Si es tu primer juego, el recorrido probablemente será largo y duro, y no puedes dudar en ningún momento. Ármate de paciencia y de motivación, y sé sincero contigo mismo: no va a ser fácil, puede que tengas que dar muchos rodeos antes de alcanzar tu objetivo, y existen muchas posibilidades de que en algún momento decidas que el esfuerzo no merece la pena.

Si llegados a este punto sigues leyendo, puede ser por dos cosas: te pica la curiosidad o realmente estás dispuesto a sacrificar tiempo y paciencia para hacer tu juego.

Un recurso que puede ayudarte a enfocar tus esfuerzos y a sincerarte contigo mismo, y que debería hacerse incluso antes de plantear tu idea, es un análisis DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades), seguido de la estrategia a seguir basándose en este, y una conclusión. Este concepto que parece tan empresarial, no tiene por qué ocuparos más de una página (aunque podría extenderse todo lo que se quiera), y es una forma de ser realmente consciente de nuestras capacidades.

Este es el DAFO a partir del cual decidimos desarrollar Bellum (mi proyecto de fin de curso):

• Fortalezas: Son los campos y recursos de los que dispondremos a la hora de hacer el juego.
• Debilidades: Hay que ser sinceros para saber qué cosas nos va a costar más, o directamente no podremos hacer.
• Oportunidades: Son los factores externos que nos ayudarán a cumplir nuestro objetivo.
• Amenazas: Todos los factores externos que pueden perjudicar el desarrollo del proyecto.

• Estrategia ofensiva: De qué modo podemos utilizar nuestras fortalezas para aprovechar las oportunidades.
• Estrategia defensiva: Cómo vamos a utilizar nuestras fortalezas para combatir las amenazas.
• Estrategia adaptativa: Cómo aprovecharemos las oportunidades para suplir nuestras debilidades.
• Estrategia de supervivencia: Qué vamos a hacer para que las debilidades no supongan el fin del proyecto frente a una amenaza.