Plataformas 2D sin nombre.

Lo que tengo implementado hasta ahora es:

• Físicas 2D predictivas. Implementadas a mano encima de Unity, porque usar un motor de físicas basado en fuerzas/impulsos es una mala idea para un plataformas. También porque sólo quiero AABBs (rectángulos sin rotación). También porque es una espinita que tengo clavada desde hace tiempo y quiero hacerlo y aprender.

  Físicas predictivas significa que en vez de mover los objetos, detectar solapamientos y corregirlos, uso el Separating Axis Theorem para detectarlos antes de que ocurran, y colocar los objetos en el punto/momento de colisión y seguir en la dirección de deslizamiento.

• Movimiento básico de saltar, correr, agacharse, más el SMASH que tenía implementado para la jam.

• Squash and stretch, para simular la deformación de objetos manteniendo el área, dando la impresión de animación básica.

• Triggers (con eventos Enter, Stay y Exit).

• One-way Platforms. Se puede subir a ellas pero no descender, por ahora.

• Escaleras verticales. No terminan de funcionar bien aún.

NO implementado aún:

• Soporte para más de un objeto moviéndose. Ahora mismo todo es estático excepto el personaje.
• Rampas de ningún tipo.
• ... un wishlist enorme de cosas que quiero añadir.

Se ve algo así:

#3 Bueno, era una afirmación tajante, evidentemente no es tan sencillo. La idea es que si intentas hacer un juego en el que la respuesta del mundo y los objetos y personajes tiene que ser perfecto, y quieres poder definir parámetros que no son puramente físicos de bajo nivel (masa, coeficientes, cosas así) sino más de comportamiento (velocidad máxima, altura máxima, tiempo en el aire...), quizás tiene más sentido pasar un poco de la realidad y usar algo más ad-hoc.

En el artículo que enlazé hay algunos ejemplos de casos concretos en los que Box2D podría tocar un poco los huevos, mientras que una solución específica diferente lo podría tener fácil por defecto.

Encima, yo en concreto estoy reimplementando cosas que podría usar de Unity, como los triggers, pero ya que estoy haciendo un "motor de físicas 2D", he ido a hacerlo todo. Más o menos, la idea es que teóricamente pudiera usar el mismo código C# tal cual fuera de Unity sin tener que hacer muchos cambios (excepto los callbacks de Updates, las modificaciones de Transforms y los tipos básicos rollo Vector3, etc.). No porque lo vaya a hacer nunca, sino por la propia práctica.

Y por supuesto, que si sólo quisiera hacer un juego plataformas no me mataría con esto, usaría algo ya hecho. El problema de tener este tipo de inquietudes es que te hace perder el tiempo que usarías para avanzar proyectos reales

TL;DR: He implementado Spatial Hashing.

He avanzado un poco. Quería añadir una plataforma one-way a la parte superior de la escalera. Pero por la forma en que tenía implementadas las físicas ahora mismo no podía.

Hasta hoy, para buscar vecinos para encontrar colisiones utilizaba la grid de los tiles del mapa. Es decir, tengo un array 2D para pasar de ID de tile a el tile concreto. Esto tiene el inconveniente de que sólo hay un objeto por tile, y para hacer lo de la escalera necesito dos objetos en el mismo cuadro (el trigger de la escalera, y el bloque one-way).

Podría haber hecho la chapucilla de hacer que el array 2D contiene una lista de tiles, pero como igualmente iba a cambiar esto en algun momento, lo he hecho bien ya.

Como hasta ahora sólo hacia colisiones Player -> Mapa, para poderlo extender necesitaba algun tipo de sistema broad-phase para encontrar tanto vecinos estáticos como dinámicos. Podría haber implementado un quadtree pero al tener mapas acotados y que están ya en forma de grid, he preferido usar Spatial Hashing. Es bastante sencillo de implementar y como optimización ya irá bastante bien. No voy a pensar en eficiencia hasta que no sea un problema, está claro.

En esta imagen se pueden ver en rojo los objetos potenciales de colisión en este frame. El resto de gizmos son: En amarillo los triggers, lila las paredes de colisión (se hace culling de las paredes colindantes con otras paredes), y blanco para el hitbox del player.

Voy a mejorar un poco la física para poder coger rocas y lanzarlas. He probado de poner más objetos dinámicos para ver que el cambio que hice es correcto: las colisiones van bien con varios objetos moviéndose.

Quiero poder tener la base típica de un plataformas 2D, con los elementos básicos. Quiero implementar lo básico para aprender, y también para poder tener la barrera más baja para hacer jueguillos de plataformas. Es decir, que sólo haga falta arte, programar cosillas específicas, y hacer niveles (sé que nunca es tan sencillo, pero se me entiende).

Sé que hay cosas ya implementadas de este tipo, pero como me lo paso bien programando y pensando como hacer estas cosas, pues he tirado por aquí.

Más específicamente, tengo un juego en mente que creo que voy a empezar a implementar una vez tenga hecho lo que necesito. Pero no lo tengo muy definido aún. Más o menos voy a ir haciendo tres cosas en paralelo: implementar el "motor", definir el juego en términos de mecánicas, en papel, y intentar hacer algun mockup para la estética del juego.

Desde hace unos días (luego de un año justo sin tocarlo) me he metido a arreglar algunos bugs de físicas que tenía, actualicé a la última versión de Unity, pasé a usar Sprites 2D en vez de quads, cambié todos los sprites para que fueran más molones, y añadí Image Effects que quedan muy bien.

Tadáaa!

Me encanta el efecto vignette + aberración cromática <3

He añadido el código que tengo a GitHub.

#17 Gracias! La estética es básicamente placeholders, la escena es de prueba para ir probando las físicas. Intenta ser algo inspirado en diagramas técnicos, estética neutra / genérica, etc.