Weekly report Feb 4/4, 2025

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

Demo (Non) Update

To get straight to the point, the demo's stability has not been achieved this week either. My apologies!
However, since it's been a while since the last update, I’m sharing the current demo link again.

download it from here. The password is "Yrnbf8g5YBL354B".

New Issues

Let's review the problem. Previously, one frame had to be spent to process hit detection, causing a one-frame delay in switching to the damage motion.
This issue was resolved last week, and I was working on restoring the system to a normal state. However, in the process, new issues became apparent.
The one-frame delay in action switching is not limited to collision detection. So far, I have identified the following three cases:

A: Action cancels via input buffering occur during the recovery state. This means the canceled action always incurs a one-frame delay.
B: Most grounded actions are set to transition back to the standing idle state. As a result, even if the down direction is held, the character briefly enters the standing state for one frame before transitioning to crouching.
C: Similar to B, but even if the next input is completed at the moment an action ends, it won’t be processed unless the character is in an idle state. This causes a mandatory one-frame idle state.

B is particularly critical, as it periodically creates moments where low attacks become unguardable.
Possible solutions at this stage include:

A. Predicting the next frame: By anticipating the character’s next state in advance, actions can switch immediately without actually experiencing that frame.
B. Implementing an input buffer: Similar to input buffering, this stores the previous frame’s input and applies it upon action switching. However, this causes a one-frame delay in execution.
C. Evaluating input and conditions within the same frame: Before switching an action, inputs are checked, and if conditions are met, the action is overwritten. This is the ideal approach but requires complex logic.

If C is implemented, multiple action overwrites must be considered, such as:

• Auto request

• Buffered input request

• Newer input taking priority over buffered input

• Damage request if a collision is detected

A new flow must be constructed to support this logic.
Looking further ahead, if rollback-based online play is implemented, a prediction system like A will be necessary, making it a strong candidate for the core solution.

As these details became clearer during development, I considered working through Sunday, but I concluded that organizing the logic and coding a new system in time was impossible. Instead, I decided to submit this status update as the weekly report.
In fact, I still haven’t fully sorted out the issue.
This discovery was only made possible after implementing the frame display feature.

While it’s frustrating that the workload has increased, it’s better than remaining unaware of these problems.
I understand that supporters who want new characters might be annoyed by this long battle with abstract issues.
However, frame-level precision is crucial in fighting games, so I’d appreciate your patience and understanding.

Next Week’s Plans

• Tax Filing

• Demo Update

#Doodle

That's all for this week. Thanks to everyone's support, we can continue development! Much appreciation.
Have a great weekend!