Modelo IV: Juegos de Carreras

[Güarmigue]

Siguiendo con el estilo de hasta ahora voy a hablar de juegos de carreras 2D, por ahora estoy presentando modelos de juego que no requieran de un gran equipo o una gran inversión, para todos aquellos que estamos empezando.

Definición: Juegos de carreras son aquellos en los que varios jugadores compiten con un vehículo por llegar antes a la meta o dar antes un número de vueltas a un circuito. Sobre todo me centraré en el aspecto bidimensional, ya que el objetivo de estos articulillos es repasar mecánicas.

Jugabilidad: En este tipo de juego el gran aliciente es la competición, sobre todo con otros jugadores humanos. En los casos en los que el juego cuente con un gran nivel de simulación (marchas, física realista, daños en el vehículo, importancia de la meteorologías, elección de neumáticos, tipo de tracción, etc...) El reto de conducir al máximo y no morir en el intento puede resultar muy interesante, así como en los juegos más arcade pueden incluir elementos de ataque-defensa como armas, aceite o clavos (o plátanos ;)) para la carretera, o simplemente una física y mecánicas de juego que nos permitan darle un empellón al coche de al lado sin morir nosotros también. Dependiendo del tipo de juego que queramos construir potenciaremos una cosa u otra (no podemos poner metralletas en el moto GP porque el jugador ya está bastante entretenido con aprenderse el circuito, seguir la trazada y demás como para andar dando tiros, además de que no es lo que busca...) De la misma forma no podríamos complicar el Mario Kart con boxes, elección de neumáticos, daños realistas o cosas así, porque perdería toda la diversión.

Dificultades técnicas: Como se ha podido ver el apartado anterior, este tipo de juegos varía mucho dependiendo de si preferimos un arcade o un simulador. El primer caso se parece mucho a implementar un asteroids con una nave para cada jugador y poco más. Es el caso más simple, Para este caso solo tendremos que implementar una física mínima en cuanto a fuerza de empuje y velocidad resultante:

 

Dibujo1 muestra un ejemplo de juego de carreras cenita, Dibujo2 de uno con vista trasera 2D

Cada coche (o lo que sea) tendrá una velocidad y una fuerza de empuje actual (la flecha negra) así como una fuerza de empuje de dirección para el siguiente paso (la flecha azul, que en este caso indica que el jugador ha pulsado "girar a la izquierda") La fuerza resultante para el siguiente paso será la suma de ambas, con lo que conseguimos que haya "inercia" y el coche no responda únicamente a las teclas de dirección. Además tendremos una tecla "acelerar" y otra "frenar" la tecla acelerar aumenta el tamaño de la flecha resultante, mientras que la de frenar la disminuye. Por tanto, en cada frame tendríamos:

1. Comprobar si está pulsada alguna tecla, en cuyo caso creamos el vector dirección asociado. En caso de estar acelerando o frenando, aumentamos o disminuimos la variable "velocidad" del coche.
2. Sumar el vector dirección*velocidad más el vector inercia*peso_del_coche, el resultado es el nuevo vector inercia, sumado a la posición del coche será su nueva posición.

La forma de calcular los vectores dirección será distinta dependiendo del tipo de vista que escojamos para nuestro juego. Tanto si la vista es cenital, como si el juego es 3D estos vectores tendrán la forma del dibujo 1, y por tanto dependerán del vector director del coche. Es decir, al vector que indique hacia donde mira el coche, le sumaremos 90 grados para el vector izquierda y restaremos 90 para el vector derecha. En el caso de un juego en plan Road Runner es más sencillo, ya que el vector izquierda y derecha siempre serán los mismos, solo variará la velocidad del vehículo, su peso y la resultante en cada caso, pero todo esto nos da igual a la hora de implementar la función.

Con esto y ajustando un poco los parámetros podemos conseguir una conducción arcade entretenida. Para añadir elementos de simulación habría que tener en cuenta otros muchos detalles. Como ejemplo se me ocurre implementar estos cálculos de vectores la parte trasera y delantera del vehículo, así podríamos aplicar el vector dirección*velocidad solo a las ruedas con tracción mientras que el vector inercia afectaría a ambas partes. También podríamos implementar el desgaste de las ruedas de forma que si el desgaste en las rueda izquierda aumenta el coche tenderá a ese lado... Al final todo se reduce en una serie de vectores en el plano XY que modifican la posición del coche.

Por tanto, y a modo de resumen podríamos decir que el modelo más sencillo es el Dibujo2. Luego vendría el Dibujo1 (en plan micromachines) y la dificultad aumentaría al meter más física, más simulación o física 3D o de colisiones, por ejemplo.

En este caso la IA la voy a dejar como pregunta ¿Como implementaríais un coche controlado por computador? ¿lineas de trazada, puntos de control?

En cuanto a la parte gráfica necesitaremos un poco más de trabajo que en en el último modelo de juego. Deberemos dibujar o renderizar un sprite para cada una de las posiciones posibles del coche (en el dibujo1 serían mínimo 8, una cada 45 grados, en el Dibujo2 podría bastarnos con 3 o 5...) Además de distintos coches, o al menos distintos colores (debemos poder diferenciar los distintos vehículos) Y un escenario. Además, los efectos de sonido son una gran ayuda en este tipo de juegos, motores, frenazos, golpes y demás ayudan a dar vidilla y verosimilitud al juego, así que aquel programador que tenga previsto seguir mi orden e implementar primero el ajedrez, luego el tetris y luego un juego de carreras, que para este último comience a trabajar en equipo y se busque a alguien que le haga unos gráficos graciosos y le busque efectillos de sonido, además así aprenderá a llevar un proyecto con otra persona, algo que puede ser tan enriquecedor como frustrante...

Como siempre me gustaría obtener opiniones y experiencias personales, ¿os gustaría que me explayara más que hablara mas de programación, del gameplay? ¿Porque casi nadie cuenta nada de sus juegos o intentos de juegos? Sería muy enriquecedor para los demás y se supone que esto es un foro de desarrolladores ¡Alguien tiene que haberlo intentado al menos!

(Editado: ya están las imágenes y las negritas, esta vez no me gusta mucho como ha quedado, me rezarciré en el siguiente si puedo, los dichosos algoritmos genéticos me traían de cabeza...)

[Mars Attacks]

Bueno, creo que éste es "el bueno" porque tiene las imágenes. El otro día estaba dándole vueltas al tema (que me parece que has expuesto de forma muy clara, y me has resuelto muchas dudas que tenía sobre el funcionamiento de derrapes y demás), y me asaltó una duda. Afortunadamente, salí corriendo mientras no miraba. Decía así: ¿Cómo implementaría(i)s el "espejo retrovisor" (en el estilo Dibujo2)?

[Güarmigue]

Ok, podemos decir que este es el bueno, siento el desaguisado :P

En cuanto a la pregunta, me has hecho pensar un poquito, no había hablado de cómo dibujar este tipo de juego, así que vamos un poco a ello:

En el modelo de carreras con vista trasera y sprites se me ocurren dos representaciones completamente distintas:

La primera sería tener un mapa del circuito de la misma forma que lo tendríamos en el de vista cenital y según la posición en la que se encuentre nuestro coche dibujar el sprite de escenario adecuado:



En el dibujo, el punto blanco es nuestro coche, los puntos verde oscuro son árboles y las lineas azules marcan el horizonte y el punto más cercano a cámara. La linea roja imagina que es perpendicular a la azul y coincidente con el coche, de esta forma tenemos el punto central de la visión, y podemos saber como de a la derecha o a la izquierda queda la carretera y dibujar uno de los sprites de la derecha, o sus invertidos, según convenga. Para el caso del retrovisor sería igual, solo que hacia atrás.  Esto es muy visual y es lo primero que me vino a la mente, pero es muy engorroso de programar e innecesario. Luego añadiríamos los sprites de los árboles y los coches enemigos (en celeste) más o menos lejos según donde estemos en el circuito. Y eso me lleva a la segunda implementación.

La segunda opción, que veo mucho más cómoda de implementar y más versátil incluso al ser más procedural es:
Tenemos una batería de sprites de fondo como los tres dibujos de la derecha, todos los necesarios. Los sprites de los árboles o lo que queramos y demás. Y el circuito en este caso es simplemente una lista o array de duplas: (distancia,tipoDeCurva) y otro de tuplas con los elementos del escenario: (distancia,posiciónHorizontal,objeto) De esta forma, solo tenemos que tener en cuenta cuánto avanzamos en función de nuestra velocidad e iremos recorriendo el array y dibujando el sprite que apunte tipoDeCurva cuando nuestra posición sea mayor o igual a distancia. Con los objetos, si   la distancia del objeto menos nuestra posición es menor que un determinado valor (horizonte) lo dibujamos en una altura proporcional a este esta diferencia. Con los coches enemigos igual. Para el retrovisor de nuevo solo tendríamos que tener sprites adecuados (tal vez escalando e invirtiendo los de la carretera...¿?) y marcar una distancia de horizonte negativa para representar objetos y enemigos (ahora de frente, eso son algunos sprites más ;P)

Como verás esta representación es más abstracta pero mucho más potente y cómoda de implementar. Operando un poco sobre el array/lista en tiempo de ejecución podríamos tener una carretera infinita que no se repitiera o ir cambiando el tipo de escenario gradualmente apuntando a distintos frames de fondo...

[senior wapo]

Dado que es un juego 2D que simula la pista 3D...

Tener sprites de la carretera por cada ángulo de curva consume mucha memoria y es poco flexible.

Es mejor dibujar la pista mediante tiras de pixels horizontales (scanlines) y solo hay que calcular el desvío del centro de cada tira en función del ángulo de la curva. El desvío lo sumas o lo restas al centro en función de si es vista frontal o retrovisor.

Una recta es desvío 0 en todas las tiras pues todas están centradas.
Una curva de 90 grados tendrá la tira inferior centrada (desvío 0) y la superior desviada casi (anchopantalla/2) con las intermedias interpoladas con una curva, no linealmente.

Por ejemplo, si el escenario ocupa la mitad inferior de la pantalla:
desvio(filapantalla) = sin( 90grados / filapantalla-(altopantalla/2) )

Ajustando los calculos para que el parámetro del seno (o coseno) este entre 0 y 1.0, que lo he puesto sin calcular mucho y me da pereza comprobarlo.

Que compense o no dependerá de las características del hardware claro...

[Güarmigue]

Tener sprites de la carretera por cada ángulo de curva consume mucha memoria y es poco flexible.

Evidentemente, si estamos tratando con móviles por ejemplo tendremos que optimizar todo lo posible y la fórmula que propones sería mucho mejor. Si estamos en PC o en las portátiles actuales (ds, psp...) no creo que fuera un problema tener 5 o 6 frames para cada tipo de escenario (cesped, desierto, etc) que darían para de sobra para representar curvas más y menos cerradas y es más sencillo de implementar.

Si es cierto que en la fórmula que propones sería más suave, más frexible en cuanto a introducir lineas de carretera o irregularidades y claro está, más barato en memoria. Como dices, habría que ver si merece la pena en cada caso...