¿Cómo organizar el flujo de estados de un personaje en Game Maker Studio? La respuesta empieza con un diagrama de estados que conecta idle, move y ataque antes de tocar una sola línea de código. Esta guía es para quien ya tiene un personaje funcionando y quiere darle estructura clara a sus scripts.

Cuando agregas más comportamientos a tu videojuego, el código se vuelve confuso. Por eso, antes de programar, conviene dibujar qué debería pasar y cuándo. Abrir una herramienta tan simple como Paint y crear tres círculos (uno por cada estado) te ayuda a entender tu propia lógica, no solo a explicársela a otras personas [01:00].

¿Qué estados tiene el personaje y cómo se conectan entre sí?

El personaje maneja tres estados: idle (quieto), move (movimiento) y ataque. El juego arranca siempre en idle, y desde ahí se abren los caminos [00:30].

Las conexiones del diagrama de flujo funcionan así:

• De idle a move: cuando presionas arriba, abajo, izquierda o derecha.
• De move a idle: cuando dejas de presionar cualquier dirección.
• De idle a ataque: cuando presionas el botón de ataque.
• De ataque a idle: automáticamente, cuando termina la animación.

Un detalle importante del diseño: move y ataque no se conectan entre sí. Para atacar, el personaje debe estar primero en idle [02:00].

¿Por qué hacer un diagrama de flujo antes de programar? Porque traduce ideas abstractas en círculos y flechas concretas. Así sabes exactamente qué estado va a cuál y bajo qué condición, antes de escribir el código.

¿Cómo paso el diagrama de flujo a código en el obj player?

El primer paso es abrir el obj player y comentar el código viejo que mezclaba todo con ifs dentro del mismo step. Comentas con una diagonal y un asterisco al inicio, y un asterisco y diagonal al final. El código se pone en color rosa y el programa lo ignora al dar play, pero queda como referencia reutilizable [03:30].

La lógica se reparte así:

• En el idle state: si presionas cualquier dirección, pasas a move state; si presionas ataque, pasas a attack state.
• En el move state: agregas un if que verifica que no estés presionando right, left, up ni down. Si ninguna está activa, el state vuelve a idle [05:00].
• En el attack state: el regreso no se controla con una tecla, sino con la animación.

Este reparto ordena los scripts según el flujo que dibujaste, y hace el código mucho más limpio.

¿Cómo regreso a idle cuando termina la animación de ataque?

El regreso automático desde el ataque usa un evento nuevo. Vas a agregar evento, luego other y seleccionas animation end [06:30].

El evento animation end se ejecuta cada vez que el sprite actual del objeto termina su ciclo. Pero como solo quieres que el regreso ocurra durante el ataque, agregas una condición: if state == script_attack, y dentro, state = idle.

Aquí aparece una duda común de programación: la diferencia entre == y =.

¿Cuál es la diferencia entre == y = en programación? El doble igual == compara dos valores dentro de una condición, como en un if. El igual sencillo = asigna contenido a una variable. En state = idle no comparas, le das valor a la variable.

¿Por qué reiniciar el imageIndex al atacar?

Hay un detalle que puede arruinar la consistencia del ataque: la variable imageIndex [08:00].

El imageIndex indica la posición actual del sprite dentro de sus frames. El sprite de ataque tiene 10 frames, y cada uno es una posición numerada desde cero. Si pides el imageIndex, te regresa el número del frame donde está la animación justo en ese instante [08:30].

El problema es que ese índice corre indefinidamente. Imagina que la animación de idle tiene cinco frames y estás en el frame cuatro cuando presionas ataque. La animación de ataque no arrancaría desde el principio, sino desde ese frame cuatro. El resultado: a veces el ataque se ve más corto, a veces más largo, siempre inconsistente [09:30].

La solución es directa: cuando presionas ataque, reinicias el imageIndex a cero. Así la animación siempre se ve completa y mantiene la misma duración.

¿Cómo compruebo que el flujo funciona?

Para probar todo, usas F5. El personaje arranca en idle, se mueve en cualquier dirección, y al soltar las teclas regresa a idle. Al presionar J ataca y vuelve solo a idle cuando la animación termina [11:00].

Ese comportamiento es exactamente el que dibujaste en el diagrama. La fuerza de este método está en que el código corre tal como lo planeaste gráficamente, sin sorpresas.

Con esta estructura de estados lista, el siguiente reto es crear el primer enemigo y aplicar la misma lógica de diagramas y estados a algo que interactúe con el personaje. ¿Qué otro estado agregarías a tu personaje? Déjalo en los comentarios.