Haciendo el motor de un juego (I)

¿Qué no es esto?

Para empezar no es una guía, sino una colección de ideas. No va a haber código salvo en casos muy especiales (y ni siquiera tengo claro que eso vaya a ser así), nada de lo que ponga será un dogma ni mucho menos...
Y este primer "artículo" va a ser más calentar motores que algo de verdad, al menos según cómo lo tengo planteado en mi cabeza. Vamos, que hoy no nos llaman para ofrecernos un contrato.


¿Entonces qué es esto?

Como digo, una recopilación de ideas que tengo para hacer las cosas, que iré escribiendo a medida que tenga algo para poner. En ocasiones lo que aparezca será un aburrimiento, a veces dará la impresión de que no se avanza nada... De igual manera no es algo cerrado, la labor de "testers" aquí consiste en sugerir todo lo que se os ocurra que pueda ser llevado a la práctica y creáis que pudiera quedar bien, sugerencias, ideas... ¿No sabes programar? ¿Y qué, acaso no has jugado nunca al ordenata? La idea no es que digas "yo trabajaría con DirectX porque tal y cual", sino que digas "¿crees que se podría poner un objeto que te dejara viajar a otra habitación al usarlo?" o "a lo mejor estaría bien que los enemigos pudieran ser más pequeños que el personaje, y así pasar por debajo de sus piernas": ese tipo de sugerencias valen su peso en oro.
Vamos, que son ideas sobre cómo hago yo algo, pero abiertas a que vosotros deis todas las ideas que queráis.
No hay ningún problema en que cojáis parte o todo de lo expuesto para vuestros trapicheos, y no tendría demasiado problema en pasar el código. Hombre, si os plantearais sacar pelas me gustaría al menos saberlo, pero como dudo que alguien pueda hacerse rico sólo con lo que voy a exponer...

Ah, y por si la gente se mosquea tontamente: en ningún momento voy a afirmar que algo de lo que pongo aquí está creado de verdad por mí. En gran medida es una labor de investigación por varias páginas sobre el tema, hay cosas que quizá sí sean mías (en especial en la implementación, que es muy por libre), pero la mayor parte de las ideas las podéis encontrar por vosotros mismos. Amos, que no me salte alguien con "plaaagiooooo!", que no es la intención tirarme flores con esto. Google es tu amigo, y tener curiosidad es la mejor herramienta de hoy en día.


¿Qué vamos a hacer?

Lo primero es lo primero: no vamos a hacer un juego, sino el motor de un juego. Eso significa que cosas como los gráficos, INICIALMENTE no van a tener ninguna importancia. Vamos a dejar el tema muy abierto a que estos gráficos vayan mejorando, incluso metiendo modelos 3D muy complejos en pantalla, animándolos y demás, pero inicialmente la idea no es conseguir algo apabullante sino algo que funcione, sea sólido (no falle, vamos), fácil de modificar (por si nos damos cuenta de que algo no estaba bien, o por si vemos que queremos añadir nuevas funcionalidades), potente (que lo que vayamos haciendo tenga posibilidades, que no se limite a un escenario sino que podamos añadir interactividad con él, que...) y, esto ya es una manía personal, abierto al usuario (no en el sentido de "toma el código", sino en el de "si quieres meter mapas propios vas a poder").

Lo segundo es dejar las cosas muy claras: hay que ser humilde al hacer las cosas, no podemos pretender empezar la casa por el tejado. Vale, sí, a mí me entusiasmaría hacer algo tan revolucionario como el UT3Engine (nos explicaron cómo funcionaba en breves trazos y es una de esas ideas que hace que pienses cómo no se le ocurrió a alguien antes). Si intentamos hacer algo tan grande lo que vamos a conseguir es, únicamente, desilusionarnos. No vamos a ser capaces de tanto en nuestro primer intento, hay que apuntar más bajo e intentar que eso que hagamos sea bueno: lo importante es que vamos a aprender una barbaridad sólo con este ejercicio tan sencillo.

Tercero, ya que habéis preguntado algunos: el lenguaje de programación con el que me siento más cómodo es C/C++. Utilizo desde hace un tiempo Borland Builder C++ 6 para programar, me resulta un programa muy cómodo y es sencillo crear programas de ventanas con él. Para los gráficos utilizaremos OpenGL, primero porque es lo que he usado en prácticas y segundo porque es sencillísimo encontrar tutoriales por la red.
Sin ir más lejos, para el que tenga curiosidad puede echar un ojo a http://nehe.gamedev.net , unos tutoriales la mar de majetes de OpenGL que tienen una curva de dificultad la mar de ajustada.

Vale, ¿entonces qué hacemos?

En vez de buscar algo complicadísimo vamos a quedarnos con una idea mucho más sencilla, un juego de cuando yo era pequeño: HeroQuest. Muchos conoceréis este juego de Games Workshop porque cuando la casa MB lo distribuyó en España le dio una campaña publicitaria bastante grande. Se trata de un juego de miniaturas en el que un grupo de héroes (entre uno y cuatro con las reglas básicas) se enfrenta a las fuerzas del mal en una serie de mazmorras. Os pongo un par de enlaces a unas fotos del juego para que veais cómo es y os hagais una idea más acertada:

http://imgshark.com/uploads/46c3a4aafa.j...
http://imgshark.com/uploads/3e11f073f5.j...
(en realidad hay mil imágenes mejores pero no me apetece ponerme a buscar ahora mismo, así que haced un acto de fe)

Vemos entonces que es un juego donde la acción se va a situar, al menos inicialmente (ya veremos más adelante) dentro de "habitaciones", de espacios cerrados. ¿Cómo representar esto en pantalla? Podríamos hacer algo similar a las mazmorras de Vampire: The Masquerade, donde la cámara seguía en 3ª persona al protagonista. Podríamos poner una cámara cenital, que nos mostrara todo desde arriba, podríamos...
Para mi gusto la opción más acertada es la que se usó en la adaptación original de HeroQuest a ordenadores y demás sistemas: vista isométrica, situada a una altura fija y, en principio (aunque ya explicaré cómo se puede solucionar esto) sin posibilidad de girar la cámara.

No suelo hacer esto al principio, pero vamos a hacer un pequeño diseño preliminar de cómo podría ser la interfaz del juego:

Dibujo hecho en 2 segundos FTW. Vemos que hay 3 partes principales en la interfaz:

1) El lugar donde se ve la "acción", donde está la vista en perspectiva isométrica del juego. El personaje deambula por ahí, abre puertas, se pega con todo cristo, coge cofres y más chorradas propias de héroes de acción.
2) La barra de mensajes. Todo lo que el programa le tenga que decir al jugador aparecerá aquí: "puedes moverte 3 casillas más", "fallas el ataque", "te hacen 2 puntos de daño"...
3) La información para el personaje: arriba el minimapa para orientarse bien, por si acaso (y fácilmente para elegir a quién atacar, ya veremos bien esto), justo debajo de éste los cursores de desplazamiento, y más abajo las opciones ("atacar", "moverse", "silbar") así como los datos del personaje (puntos de vida y demás) y un botón para sacar el inventario y equipo.

Simple pero efectivo, ¿verdad? Tenemos una visión limpia del juego, tendremos en pantalla la información que nos haga falta para jugar y todos los comandos que podamos usar estarán en un lugar accesible. Cosas más raras, como cambiar de equipo (por ejemplo usar esa espada tan chula que acabas de encontrar) requerirán abrir una ventanita extra, pero oye, se sacrifica eso por tener algo de claridad.


No quepo en mí de gozo con esa idea, pero ¿cómo se hace?

La técnica que se va a usar es realmente antigua, y al decir esto no estoy usando una frase hecha sino que me refiero a que en los tiempos de NES era una de las más frecuentes: el uso de baldosas o tiles para representar la imagen.
Vamos a ver un ejemplo con un juego clásico donde los haya, The Legend of Zelda:

Si os fijais bien, vereis que en realidad los gráficos no están hechos de una vez, sino que se forman repitiendo una y otra vez unas "baldosas". Por ejemplo tenemos una que representa el suelo, otra que tiene una piedra, otra que tiene una pared... ¡incluso Link y sus enemigos son una baldosa! Por si acaso no quedara suficientemente claro, mirad esta imagen:

Ahora ya no cabe duda, ¿verdad? Hemos dividido el mapa en coordenadas, y por ejemplo vemos que en la casilla de las coordenadas (0,0) (abajo a la izquierda mismamente) hay una pared, en la (7,5) una piedra (bueno, creo que es esa pero no me apetece fijarme bien)...

Trabajar con tiles es Muy sencillo, aunque tiene un problema grande: vamos a tener que trabajar mucho para que nuestro juego esté preparado para recibir los mapas que le demos... ¡pero una vez tengamos esa "base" bien, el resto del trabajo será inmediato! Es que, y aquí no exagero, una vez hayamos hecho el esqueleto no tendremos que tocar absolutamente nada para que el juego coja los mapas, será completamente automático. ¿A que no pinta nada mal?

¿Y cómo se pasa esto al ordenador? Lo vamos a hacer de una manera muy sencilla: utilizando ficheros de texto. Tal cual suena.
La idea es la siguiente: daremos un "nombre" (un número, en realidad) a cada baldosa que vayamos a usar, y en ese fichero nos saldrá dibujado el mapa con esos números.
Por ejemplo, si llamamos "baldosa 0" al suelo, representado con un cuadradito verde, y "baldosa 1" a las paredes, representadas con un cuadradito marrón, codificar una habitación muy simple de tamaño 8x8 baldosas sería tan sencillo como se ve en este dibujo:

(imagen hecha en medio segundo non-jutsu!)
La conversión es inmediata: allá donde el ordenador encuentre un "0" pondrá una baldosa de suelo, allá donde vea un "1", una de pared.

Ahora imaginaos que en vez de tener sólo esas 2 baldosas (el suelo sobre el que podemos movernos y las paredes que no podemos atravesar) tenemos muchos tipos de ellas: a las paredes y suelos (con varios diseños) podríamos añadir trampas, puertas, escaleras, trampillas... Cada tipo de baldosa compartiría propiedades (siempre podemos caminar sobre los suelos, cuando pisemos una trampa se activará, si buscamos puertas ocultas las encontraremos...), pero es que además podríamos crear baldosas de efectos especiales (¿qué tal poner una baldosa que resbale y haga que podamos caernos? ¿Y una de lava, que nos haga daño al estar sobre ella? ¿Y una fuente de la eterna juventud que nos cure las heridas?).

Como veis, el sistema es muy, muy simple, pero tiene unas posibilidades inmensas (de ahí que se haya usado tantísimo). Es más, aunque los ejemplos estén en 2D no es nada difícil adaptarlos a las 3D... con lo que vemos que es una elección más que adecuada para lo que queremos.


Y, bueno, esto ya se ha alargado bastante para unas primeras ideas. En el siguiente artículo veremos cómo organizar las mazmorras de forma que sea fácil para el ordenador entender todo, y quizá veamos cómo empezar a pasar las cosillas a un lenguaje. Aún no hemos empezado a toquetear cosas del ordenador porque no es necesario de momento, y es mejor tener las cosas bien planificadas que lanzarse al peligro como un animal y ver luego que no tenemos nada preparado y que no hacemos más que tropezarnos por esos detalles que podríamos haber evitado fácilmente.
Espero que os haya entretenido, y aunque de momento no hay casi nada donde rascar cualquier duda, comentario o sugerencia es bienvenida.