Estoy intentando crear un juego de plataformas para móvil el cual me pasa lo siguiente:
Tengo 2 botones para izquierda y derecha que funcionan correctamente.
Un botón de salto que funciona correctamente.
Un botón para el Dash que funciona correctamente.
El problema viene cuando tengo un botón de ataque que al “pulsarlo” solo funciona un frame de la animación que tengo asignada (en total son 4 frames)
Me lo he mirado y remirado pero no encuentro la manera de que funcione
Muestro la hoja de eventos para ver si pueden ayudarme y mostrarme como se debería hacer:
hola, estoy usando un traductor, Puede resolver fácilmente ese problema agregando una condición en el caso de que la animación quede inactiva. Actualmente, los eventos cancelan cualquier animación y todo el estado de la animación siempre que el jugador no se esté moviendo. En tu condición necesitas verificar si la animación actual no es igual a la animación de ataque/disparo. También es posible que necesites otro evento para que la animación vuelva a estar inactiva cuando finalice la animación de disparo. puedes hacer uso de la animación actual y la condición de finalización de la animación g para eso.
Gracias por la respuesta e intentarla hacerla en mi idioma
Sigo sin poder ver el problema (disculpa soy muy novato. Estoy aprendiendo)
Enlace de mi idea:
He entendido que se tiene que comprobar si la animación actual no es la de ataque. Si hay otra animación puede parar la de ataque (que entre en conflicto)
Pero no se ver cual es, la que se me a ocurrido es alguna animación que este comprobado que el objeto “PJ” esta en el suelo, añadir “comprobar que a finalizado” para solucionarlo.
+++ En vez de asignar directamente la animación de ataque al presionar el botón B, te recomiendo usar una variable. Por ejemplo, un booleano que ese llame “atacando”. “Atacando” debería ser “falso” por defecto y debería cambiar a “verdadero” cuando tocas el botón.
+++ En esa misma condición donde verificas si el jugador está tocando el botón B, deberías agregar una condición para verificar si la variable “Atacando” es “falso” y también una condición “Ejecutar una vez”. De esta manera el jugador debe soltar y presionar el botón de nuevo para atacar, a menos que desees un ataque continuo.
+++ En la sección de animaciones se debería configurar la animación a la de ataque si “Atacando” es verdadero.
+++ La animación de ataque debe estar configurada para correr una sola vez, NO cíclicamente (continuamente) y en algún lugar debería existir un evento que regrese “Atacando” a “falso” si la animación es la de ataque y si esta ya ha terminando. De otra manera, en personaje quedaría estancado eternamente en el último frame de esa animación.
+++ Por último, ya que las animaciones son totalmente independientes, creo que no tiene sentido que el jugador pueda avanzar, hacer dash o saltar antes de que el ataque haya terminado, de lo contrario se vería como que el personaje se eleva o se desliza hacia los lados mientras ataca. Entonces, creo que sería buena idea que cualquier acción solo se pueda iniciar si la variable “Atacando” es “falso”.
Creo que así eliminarías la posibilidad de que la animación se reinicie constantemente o de que interfiera con otras, pero deberías probarlo.
Entiendo el problema.
Las indicaciones que te dí anteriormente son para solucionar justamente eso.
¿Ya lo intentaste?
Si necesitas ayuda para aplicar los cambios que te dije en el mensaje anterior y así evitar que la animación de ataque solo muestre el primer frame antes de reiniciarse, con gusto te ayudo, pero tendrías que mostrar tus eventos o facilitar una copia de tu proyecto para poder hacerlo.
Ok, el asunto es que mi GDevelop está en inglés y no te va a ser fácil entender las capturas de pantalla. Sería mejor si subieras una copia de tu proyecto a Google Drive y me mandaras el enlace por mensaje privado, así yo podría hacer rápidamente las correcciones y poner comentarios para que entiendas lo que voy a hacer.
Logré hacer que las animaciones funcionaran como quieres, pero te hago un par de advertencias:
Los frames de las animaciones del personaje tienen diferentes tamaños (lo más recomendable y sencillo en el desarrollo de juegos 2D es que todas las imágenes de todas las animaciones de un personaje tengan el mismo tamaño con el personaje debidamente centrado y acomodado en el frame según las necesidades de cada animación), esto puede provocar “saltos” y efectos extraños en la reproducción de las animaciones. problemas de detección de colisiones y problemas secuenciales en los controles y animaciones que dependan de detección de colisiones para su correcto funcionamiento (como por ejemplo saber si un personaje está sobre el suelo o si se está moviendo).
Las animaciones están funcionando en el proyecto corregido, pero si piensas añadir más acciones o hacer cambios al sistema de controles y animaciones es probable que encuentres problemas debido a lo anteriormente mencionado y el hecho de que se necesitaría una “máquina de estados finitos” más depurada y refinada (una “máquina de estados finitos” o “finite state machine” es cualquier sistema que define el estado actual de algo, en videojuegos se usa para muchas cosas, y su uso más frecuente son las animaciones y controles del personaje, así como la IA de los enemigos… por ejemplo, el sistema de controles y animaciones de tu juego es una “finite state machine”; hay un artículo muy interesante que aunque incluye mucho código y programación, puedes ignorar esas partes y solo seguir la lógica de los ejemplos para aprender al respecto, realmente es algo mucho más sencillo de como suena y se refiere a cómo organizar el algoritmo, código, script, eventos, como le llamemos, que definen los estados de un elemento: finite state machines)
También te recomiendo buscar aquí en el foro ejemplos de cómo otros usuarios han implementado estos sistemas, o copiar la lógica básica de los ejemplos de juegos de plataformas que inlcuye GDevelop y desarrollar sobre eso como punto de pártida. También sería genial si vieras algunos vídeos y tutoriales sobre como recortar y/o preparar tus sprites antes de importarlos.
Aquí hay algunas capturas de pantalla del proyecto:
