C++ / Diseñando el loop del juego

Bienvenidos sean a este post, hoy hablaremos sobre el verdadero «nucleo» del juego.

Si vienen de los posts anteriores ya hemos visto que un juego esta compuesto de muchos elementos y que muchas cosas suceden al mismo tiempo. Por ejemplo, un lector puede estar finalizando una libreria, una barraca creando un soldado, soldados siendo atacados por el enemigo, el jugador comanda a las unidades para moverse, construir, atacar, etc. El loop del juego se encarga de manejar todo esto, y por lo general un buen game engine se encarga de proveer un buen diseñado loop del juego.

Como mencionamos en este post, este loop se ejecutara mientras corre el juego y cuando finalice este tambien finaliza al juego en si. Como mencionamos anteriormente, este se encarga de manejar todo lo que sucede en el juego; controlar las unidades, mostrar los elementos en pantalla, controlar los estados de estos, etc. Tambien se encarga del ratio del gameplay, tambien conocidos como Frame-per-Seconds (FPS). Este tipo de iteracion en el loop del juego se lo denomina como frame, lo cual por esta razon debemos tener mucho enfasis en los FPS para usarlos como la velocidad del gameplay. Supongamos que diseñamos un juego a 60 FPS, cada frame toma alrededor de 16ms. En este post, mostramos el siguiente codigo como ejemplo:

while (true)
{
  procesarAccionesJugador();
  updatejuego();
}

Este codigo simple correra rapido mientras el usuario no haga ninguna interaccion o sea ejecutado en un equipo potente. Nuestro objetivo sera que el frame no supere los 16ms. Esto nos obliga a esperar un poco despues de procesar las acciones y actualizar el estado del juego. Para entenderlo mejor, veamos el siguiente diagrama:

Como pueden ver cada actualizacion avanza el juego en una cantidad fija de tiempo, la cual lleva una cantidad de tiempo del mundo real para procesarlo. Pero si toma mas tiempo del que especificamos para cada frame nos llevara a que el juego funcione lento. Como pueden imaginarse, la gran mayoria de lo que sucede en el juego es en el momento de la actualizacion, en este ejecutaremos una gran cantidad de operaciones al mismo tiempo. Cuando hablamos de los ataques en este post, mencionamos que tendria una cierta demora entre ataque y ataque, asi como tambien la creacion de una unidad o un edificio. Siendo algunas de estas tareas que ocurren en el fondo o background. Por lo que si queremos hacer un juego mas detallado, debemos tener en cuenta que la construccion de un edificio tendra dos estados: inicio y final.

Tomemos este ultimo ejemplo, si lo llevamos a la parte grafica debemos tener dos imagenes que representen a estos estados. Siendo la del estado inicial como una representacion con una base y algunos piedras y el otro estado con el edificio concluido. Vamos a suponer que mandamos un lector a construir una casa, donde primero mostraremos el estado inicial al jugador. Cuando lo terminemos, se procede a reemplazar la primera imagen con la imagen de la casa terminada. Y para dar una simulacion mas natural le agregamos una demora para que tome un poco mas. Esto comentado, es de una forma simple pero lo ideal seria tener varias imagenes con el proceso de la construccion y deberiamos reemplazar los distintos pasos con estas imagenes pero involucran mas estados y demoras.

Si volvemos a ver el diagrama anterrior, despues de actualizado el juego debemos esperar una X cantidad de tiempo en milisegundos. Mientras mas milisegundos esperemos hara que el flujo del juego sea mas parecido a la vida real. Pero y que sucede si la actualizacion toma demasiado tiempo y esto genera retrasos para el usuario? Aqui debemos analizar el juego y optimizarlo para ajustar el tiempo del frame a los mas optimos a la experiencia del jugador.

Vamos a suponer que el jugador creo un imperio vasto, con muchos edificios y soldados atacando a los enemigos. Esto involucrara a cientos de operaciones, las cuales son desde moverse del punto A al punto B, atacar a un enemigo, construir un edificio, etc y todo eso mientras se representa en pantalla y como podemos hacer eso tambien? Aqui entra en accion el enfoque del multithreading para que cada accion actue de forma independiente para modificar el estado de un objeto, tanto los dinamicos como los estaticos y/o decoracion. Con esto finalizariamos nuestro juego y como pueden darse cuenta (si vienen de los posts anteriores) este es un tema complejo donde no solamente debemos tener en cuenta muchas cosas sino que se aplican muchas de las tecnicas que provee el lenguaje mediante OOP. Tales como herencia, virtualidad, singleton, y conductas propias.

En resumen, hoy hemos visto de forma teorica al loop del juego, que es, como se compone, que controla, asi como algunos detalles en el mismo para tener en cuenta. Espero les haya resultado de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.