shibagani48

2025-Aug-4/5

Added 2025-08-25 18:04:35 +0000 UTC

Hello everyone! Thank you as always for your support.
Let's take a look at this week's progress!
Since the dataset required for CPU battles is still not ready, there will once again be no demo update this week.

CPU Development

This week, I implemented the system that allows the CPU to perform combos.
The system is broadly composed of the following classes:

CPU Request Handler
CPU State Switcher
CPU Action Decider
Combo Sequence Handler
CPU Combo Sequence

CPU Request Handler:
Acts as the overseer that ties everything together and bridges with the request manager.
It retrieves the character’s status and shares it with the lower-level classes, while also using them to construct the overall flow.

CPU State Switcher:
Analyzes the character’s status and determines the AI state, which becomes the starting point for branching into actions.
AI states are broadly divided into movement, offense, and defense. More will be added in the future.

◆ Movement States

ENGAGE: Approach the opponent up to the caution distance.
VIGILANCE: Maintain a certain distance from the opponent and observe.
ASSAULT: Close in aggressively with dashes or jumps to apply pressure.

◆ Offense States

ATTACK: Attempt a preemptive strike.
COUNTER poke: Punish an opponent’s whiffed attack.
ZONING: Keep some distance while poking and harassing.
ABARE: Attack in disadvantaged situations (e.g., on wake-up or during the opponent’s offense) to attempt a reversal.

◆ Defense States

DEFENSE: Fully commit to blocking against the opponent’s offense.
CORNER DEFENSE: Make defensive decisions when trapped at the screen edge.
ESCAPE: Create distance from the opponent, for example when needing to recover gauge.

Movement Action Decider:
Based on the AI state, determines which specific action request to execute.
It also manages looping actions like walking or dashing.

CPU Combo Sequence:
A dataset that defines how the CPU executes combos.
Each sequence contains a structure specifying the conditions required for activation.
Additionally, it holds multiple attack action items, which when executed in order, form the combo.
Each action item includes conditions for interruption as well as optional delay settings.
Since a large number of these are needed, I’ll have to design constructors carefully to minimize redundant writing.

Combo Sequence Handler:
The class responsible for actually managing the sequences.
It evaluates whether a sequence’s activation conditions are met, and if so, starts executing it.
While running, it checks for interruption conditions, and if actions have delays set, it queues them accordingly.

Because a manual player-controlled flow cannot simply be reused, I had to prepare a unique flow for the CPU.
This turned out to be more complex than expected.
Challenges included: building the flow to transition into attacks based on AI state, determining the timing for resetting stored sequences and actions, and finding a natural way to insert requests into the cancel-action flow.
But I managed to stabilize it in the end.

However, since the manual and CPU flows differed, a bug occurred where requests that should not have been approved were mistakenly allowed.
As a result, I unified the request-approval flow across all control types: Manual, CPU, and Dummy.

With a basic CPU system now functioning, all that’s left is to keep expanding the dataset of combos and state-branch conditions.
If I keep adding more, the CPU should eventually become a formidable opponent.