shibagani48

Weekly report Mar 1/4, 2025

Added 2025-03-11 16:19:04 +0000 UTC

Hello everyone!
Thank you as always for your support.
Let's take a look at this week's progress!

Sorry for the delay! I was finally able to stabilize the demo, so it's time for an update after a long while.

Demo Update

download it from here. The new password is "L.:-/kLkY7+99=w".

The voices of three narrators—Soren, Dylan, and Imp—have been officially implemented.
You can change them from the settings in the main menu!

Additionally, I have finally completed the internal processing for frames, which I had been working on for a long time.

Completion of Action Switching Process

This was extremely complicated and gave me a lot of headaches, but in the end, I was able to solve it by performing action switching in three stages within a single frame.

Stage 1: If there are forced requests such as landing or wall bounce, or automatic requests at the end of an action, the switch is performed. If none of these occur, the current action is updated.
Stage 2: If there is a request due to player input, a second action switch is performed.
Stage 2.5: (Collision detection)
Stage 3: If there is a request due to a collision, a third switch is performed. At this point, animation updates are executed for the first time.

By following these stages, multiple action switches can now be performed within the same frame, eliminating the processing delays that had been an issue.
Let’s take a look at how each problem was resolved.

Problem A: Canceling an attack and executing an input buffer required experiencing one frame of recovery.

The process of transitioning from an attack's active frames to the recovery state is handled in Stage 1.
If an input buffer is present, it is applied in Stage 2, allowing the buffered action to execute immediately within the same frame.
As a result, the player never visually experiences the recovery frame, but internally, the recovery state is correctly registered.

Problem B: On the frame immediately after an action ends—such as right after a backstep—input would not be accepted unless the player first experienced one frame of standing idle.

This happens because all ground actions transition back to standing idle when they end, effectively creating an unavoidable 1-frame gap.
The automatic transition to the next action upon action completion is handled in Stage 1, regardless of player input.
However, if there is player input, Stage 2 performs a second switch accordingly. For example, if the down direction is input, the character transitions to crouching idle.
Since this happens within the same frame, the player never sees the standing idle state after a backstep—it appears as if the character instantly switches to crouching idle.
Of course, internally, the system observes the standing idle state and verifies that player input is being received.

Problem C: When an attack lands, the hit detection takes one frame, so the opponent transitions into a damage motion on the next frame. This gives the opponent a 1-frame window, leading to unintended trade situations.

Attack hit detection occurs in Stage 1. Since character movement is processed in Stage 2, if the opponent moves forward during the same frame, their new position will be included in the hit detection calculation.
In Stage 2.5, the actual hit check is performed, and if a collision is detected, Stage 3 immediately transitions the opponent into a damage motion.
As with A and B, these processes occur within the same frame, ensuring that the damage motion switches instantly upon hit detection.

I know this explanation might be a bit hard to follow. But just trust me—it works!
Since this update fundamentally changed the system, I was swamped with fixing all the small bugs that kept appearing.
I’ve fixed everything I found, but there are probably more remaining, so please let me know if you find any!