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

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

This week, I finally implemented a feature I had been considering for some time, as frame-by-frame data has become crucial for debugging.
With this tool, you can calculate frame advantages by analyzing attack startup, active frames, recovery, and the defender’s situation.
The feature is working well, but it has also revealed several new bugs:
1-frame lag: There’s a 1-frame delay between the frame an attack hits and when the damage animation begins.
Modius's 5C issue: If you don’t cancel Modius's 5C on hit, for some reason, Modius ends up at a disadvantage.
Problems that were once vague have become much clearer with this tool.
Please use it to report any bugs you find!

Reporter: lucky
Issue: During hitstop, the hitbox of the defender doesn’t update.
Fix: This was caused by all processes stopping during hitstun. I added a new process to update the hitbox when the state changes.
Reporters: yeayea9988, cool guy
Issue: If a super move grazes the opponent, they remain stunned and unable to move.
Fix: This stun loop was actually intentional, as the attack’s hitbox is so large it’s almost guaranteed to hit. However, thanks to your reports, I’ve learned there are edge cases where it doesn’t. Now, the stun loop will automatically end after 60 frames. If the opponent recovers, they’re lucky!

Reporter: Me
Issue: When blocking a stationary attack while pressed against the screen edge, hit knockback doesn’t occur.
Fix: This was tricky to figure out. The issue mainly affects Zdrada's 5A, allowing the attacker to make the defender endlessly block. It turned out the problem stemmed from a fix I applied earlier to prevent characters from swapping sides when pressed against the edge. I added a condition to apply that fix only during attacks.
Reporter: Blake Belladonna
Issue: Settings changed in the menu don’t apply immediately or save properly.
Fix: I’ve updated practice mode settings so they now save and apply instantly.
There are still unresolved bugs, but this is how far I’ve gotten this week. I’ll keep working on fixes!
Added startup, active, and recovery states to attack actions. These can now be checked in practice mode.
Cancelling chain combos now only works during recovery frames, which has made combo timing stricter, with a 2–3 frame delay overall.
Updated the state info window in practice mode to remove unnecessary details and make it more compact.
Added the ability to return to the previous screen using the cancel button on all selection screens.
Why focus on improvements instead of new features?
Because messy old code becomes exponentially more expensive to fix after adding new characters.
Here are updates to backend systems you won’t notice visually:
Improved parameter management for each action. Other than frame data, most parameters are shared across all characters, so I’m working to streamline this.
Related to the above, I’m also revisiting how scriptable objects are managed. They’re convenient but risky—changing a parameter name erases all entered data.
Thanks to a discussion on Discord, I learned about a custom editor example that manages flags in a timeline format. However, since editors must be tailored to each project, I can’t use it directly.
I’d like to build one myself, but creating an editor is as costly as developing a small app, so for now, I’ll stick with brute-force solutions.
Migrated character states to the Character Manager. The existing Character Manager had become obsolete, so I’ve dismantled it.
Removed the outdated Player Information class and merged it into a Data Holder class. This broke the character select screen.
The character select screen had layers of unnecessary class inheritance, making the code incredibly convoluted, so I took this as an opportunity to rewrite it from scratch. What used to take 1–2 weeks to build was finished in a single day this time.
The code is now more readable, and I feel my coding skills have improved.

We received around 100 applications again this time!
Since fighting games tend to have a high-energy vibe, many applicants seemed influenced by that and didn’t meet the three key conditions: a very deep voice, a quiet yet ominous tone, and subtle audio effects.
Even so, several ideal candidates made it to the final selection, making the decision very difficult.
We’re gathering opinions here, so feel free to share your thoughts.
Currently, option B is the most popular, but are you all listening all the way through?
As sycros mentioned, initial choices tend to leave stronger impressions.
I plan to contact the final hire next week.
Start studying English listening.
Finalize the narrator selection.
Debugging.
That's all for this week. Thanks to everyone's support, we can continue development! Much appreciation.
Have a great weekend!