Curso RPG: 2 Motor de movimiento

Ir al Indice
Construir un motor se debe a una simple razon: No tenemos algo hecho que nos valga, por lo tanto tendremos que hacerlo.
El motor debe ser lo mas simple posible y a la vez ser lo mas eficaz posible.
-------
Bien, esto es lo que teniamos:
[Tienes que estar registrado y conectado para ver este vínculo]

Lo primero que se nos ocurre es sustituir nuestro cuadrado, que tiene toda la pinta de ir bien, por un sprite (active con 8 direcciones).
Bien, vamos a hacerlo. A ver que pasa.

[Tienes que estar registrado y conectado para ver este vínculo]

Vemos que hay distintos problemas. La identificación de los problemas y la forma de solucionarlos es lo que nos va a permitir construir nuestro motor de movimiento.

Pbma 1. Se queda atascado en las colisiones con el background.
Pbma 2. Nos haría falta algo que nos indicara la dirección de la colisión. Esto será necesario mas adelante.
Pbma 3. El tamaño de nuestro sprite hace que las colisiones laterales y superior no sean con la aproximación adecuada. No nos interesa que se pare cuando la cabeza llegue a una puerta, sino lo conveniente sería cuando lleguen los pies.
Pbma 4. El tamaño de nuestro sprite es el que va a determinar por donde va a poder pasar. Esto no nos conviene.

Por tanto, adoptamos unas astucias para corregir estos pbmas y algún otro.

1. Vamos a seguir trabajando con un active de 32x32 para nuestro movimiento de 8 direcciones y haremos que el resto se ajuste de forma automática a este movimiento.

2. Como detector de colisiones pondremos una simple barrita que esté siempre al frente de nuestro movimiento. Lo llamaremos DTC.

3. Como no queremos que nuestro cuadrado supere 32x32, lo haremos un poco mas pequeño, a partir de ahora lo llamaremos DIR. Al añadirle la barrita anterior nos siga dando los 32x32.

4. Ajustaremos nuestro sprite de Link para que se mueva al compas de nuestro DIR, con su direccion. Cuando este quieto, haremos que la animacion sea de Stop y cuando se mueva que se ponga en modo walking.

5. Queremos que nuestro Link tenga los pies en el centro del DIR. Esto exige un ajuste. La solucion es hacer el calculo de diferencia de Hot Spot.
Pondremos esta diferencia de ajuste en X e Y en unas variables globales.
Podriamos hacer un ajuste directo, pero prefiero este sistema.

6. Añadimos unas pequeñas astucias mas para que el movimiento sea correcto. Son faciles de entender. Ver el MFA.

Todo ello nos da lo siguiente:
[Tienes que estar registrado y conectado para ver este vínculo]
Descarga mfa: AQUI
Le he añadido la posibilidad de ver todo esto en tiempo real, para una mas facil comprensión:

space: Ver capa de colision (background) (CCNL)
z: Ver Detector de Colisiones (DTC)
x: Ver DIR
c: Ver Link nuestro PJ.

Sencillo, verdad ?

---

Como siempre, se cuenta todo lo necesario, aunque de forma somera.
Según necesidades se irá aclarando o ampliando esta explicación.

Muy Bueno

Son todas estas astucias lo que hacen que el juego quede más profesional.

activando lo de detector de colisiones se ve mas claro como funciona... muchas gracias

Veo que lo que realmente manejamos es el cuadrito, el detector siempre se sitúa delante y el sprite de link va ocupando la posición del cuadrito

Con las variables Des_X y Des_Y se corrige la posición del Sprite de link con respecto al del cuadrito

pero... por qué prefieres hacerlo así y no hacerlo de forma directa?

Zonacas escribió:

pero... por qué prefieres hacerlo así y no hacerlo de forma directa?

Siempre es mejor usar un detector para los movimientos y colisiones y que el sprite solo acompañe, imaginate un juego de plataformas con un personaje que tenga una espada, si usas el sprite para las colisiones en vez de un detector (cuadrado o rectangular) si la espada toca la plataforma, detecta la colision y el personaje queda en el aire, o si un enemigo toca la espada, se detecta como golpe..... y así por el estilo varios casos.
saludos!

Zonacas escribió:

Con las variables Des_X y Des_Y se corrige la posición del Sprite de link con respecto al del cuadrito

pero... por qué prefieres hacerlo así y no hacerlo de forma directa?

------------------
La razón es muy sencilla.
Cuando se trabaja con un frame, nos puede dar un poco igual.
Pero si tenemos nuestro motor de movimiento en 30 frames y resulta que queremos corregir la posición (por la razon que sea) de nuestro muñeco con respecto al DIR ... con tocar el par de variables globales lo tengo arreglado, de la otra forma tengo que ir frame a frame.
-----------------
Hay un scroll que es el que suelo utilizar y del que todavia no hemos hablado que hace lo mismo que el que estamos usando pero que en nuestro ejemplo en vez de hacer uso de un frame para todo el mapa utilizaría 4 frames.
Como puedes ver el uso de frames se puede disparar y es conveniente estar protegido por si queremos realizar cambios que afecten a nuestros motores.

Ah comprendo

siempre hay que mirar con la perspectiva de facilitar las cosas por si en un futuro se quiere modificar algo...

Una buena planificación nos ahorra dolores de cabeza después...

es algo como lo que me paso con el mapa que hice sin tener en cuenta el scroll y me quedo una entrada mitad en un pantalla y mitad en otra...

Está quedando un Tutorial muy bueno con todos estos detalles

tengo ganas ya de que link tenga una espada