Fighter & Gunship AI Loop

Fighters and gunships are offensive units that actively focus on attacking the player. They first search for the player units within their move range + action range. The implementation of this search method is explained later.

When the enemy AI finds a valid target, it attacks first and then checks whether it can move directly in front of the player’s gunship or fighter. This behavior takes advantage of the plane unit’s rule of being forced to move forward every turn, allowing the enemy to obstruct the player’s path or even tempt the player into a collision that destroys both units.
If no target is available, the enemy AI searches for nearby clouds and enters to increase the evasion rate.
The following is more specific demonstration of Fighter & Gunship AI Loop.

Enemy AI evaluates player units in the following priority order: Balloon > Gunship > Fighter.

Balloons have powerful abilities such as altering terrain but are extremely fragile, being destroyed instantly by any attack. Thus, the enemy AI prioritizes intercepting balloons. If the player considers the balloon crucial for future strategy, they must surround it with ally units or place it beside a thundercloud to ensure safety. On the other hand, the player may choose to sacrifice the balloon to lure enemies into a trap.
Gunships have a very large action range and can attack twice per turn, giving them high strategic value. Therefore, the enemy AI prioritizes attacking gunships if there is no balloon within the range. The player can leverage the gunship’s large movement and action range to escape to positions unreachable by enemy units.
Fighters always receive 50% reduced damage, making it the lowest priority target. The player should anticipate enemy movement and position fighters in advance or place them near other allied units so that they can absorb incoming attacks in their stead.

This AI behavior gives players the impression that the enemy is an intelligent opponent that fully understands the game’s systems. New players can learn effective tactics by observing enemy actions, while advanced players can exploit the AI’s predictable traits to attempt bold and creative strategies.

Enermy Turn Loop

The enemy AI logic is combined with a state machine to process tasks cleanly.
When the Event Enemy Beginning is called by the GameManager, a blueprint controlling the state machine, all current enemies are added to the Enemies in Sequence array. The first element of this array becomes the active unit, and the AI begins operating on that unit.
After the AI finishes its related processes, the turn state changes to Enemy Finishing.
If there are still enemies left in the array, the current enemy is removed, and the system returns to the Enemy Searching state to process the next enemy.
If the current enemy is the last one, the Turn State transitions to Ending, closing the turn and starting a new one.

Behavior Tree Task: Can Attack

The currently active enemy searches for player units through its Behavior Tree. This is handled by the behavior tree task “Can Attack.”
The fundamental logic I designed for detecting whether a target exists within the enemy’s move range + action range works as follows:

The enemy iterates through every tile in its movement range. For each tile, it simulates expanding its action range from that position to determine whether a target unit exists within it. Here are the details:

When Event Can Attack is triggered, the enemy first calls GetCoordinateValidityMap(), which retrieves the coordinates and validity of all tiles within its movement range based on its current coordinate and facing direction. This method uses the same logic as GetValidMove() described earlier.

Next, the enemy collects all player units of the type (Balloon, Gunship, or Fighter) and sorts them in order of proximity. This allows the enemy to evaluate targets from nearest to farthest.
With preparations complete, the system begins scanning using two Customized For Each Loop with Delay executions.
The first loop iterates over the sorted player-unit array. The second loop iterates over all movement-valid tiles.

Within these nested loops, the enemy simulates its actions: It assumes its position to be at the tile from the second loop, expands its action range, and checks whether the target unit from the first loop lies within that simulated range.
Because the simulation must consider the unit’s movement range, action range, direction, and coordinates all at once, implementing this logic required significant time. Specifically, restructuring everything into a clean, unified system took the most effort. To accomplish this, I refactored GetValidMove(), IsValidFire(), and the direction-setting event SetDirection so that both player units and enemy units could use the same shared logic.

If IsValidFire() confirms that the target unit from the first loop is within attackable range, the enemy moves to the tile found in the second loop and attacks the target. To prevent other AI units from running prematurely or skipping logic during movement or attack animations, the system calls Event Enemy Move Finished after the movement. This ensures that the behavior tree task registers as succeeded.
Modifying this event so that both enemy units and player units could use the same Event Move Finished required additional adaptation.