Hello everyone!
Thank you as always for your support.
Let's take a look at this week's progress!
This week, I had initially planned to share a new demo version after making significant progress on the Story Mode.
However, due to the need for a major overhaul of the game flow and the setup of assembly definition files, I was unable to prepare a demo that functions properly.
As a result, there will be no update this week.
Further details are explained below.
Following the results of the previous task poll and feeling fatigued from working only on battle scene improvements, I decided to shift focus to Story Mode.
Some might see this as an unnecessary feature, but I anticipate that Story Mode will likely be the mode most players engage with when the game is released to the public.
The conversation scenes were completed without major issues. However, the challenge was multilingual support.
To implement localization, I initially tried Unity's Localization package.
The idea was simple: by preparing strings for each language via a special editor, dialog content could automatically switch based on language keys.
However, the Unity editor-based system only allowed updates through my manual input.
If demand for additional languages increases in the future, maintaining it this way would be unfeasible.
So, I came up with the idea of linking it with Google Spreadsheets.
This would allow authorized contributors to update dialog content directly.
However, setting up Auth connections between Unity and Google Sheets proved extremely complex, involving unfamiliar DLL downloads and security token configurations.
Moreover, this system would require an active internet connection, essentially turning it into an online feature.
Introducing an online dependency solely for localization was unreasonable.
Additionally, strange issues like asset reference losses occurred when switching languages, so I abandoned this approach.
I remembered that the original "Helltaker" also supported multiple languages.
Upon investigation, I found it simply switched referenced text files based on language—an approach that's simple for both editors and developers.
Implementing this method turned out to be surprisingly easy.
Now, let's enjoy the conversation between Zdrada and Modeus!

Currently, only English and Japanese are supported, but additional languages can be added easily if requested.
Please note, however, that translation will need to be handled by the requester.
Next, I needed to prepare a continue screen that appears if the player loses during Story Mode battles.
Previously, I used Coroutine and DOTween to handle time-based animations and processes.
However, I learned about a superior tool called UniTask, so I decided to give it a try.
Although I had avoided it due to a preconceived notion that it was complicated, it turned out to be very straightforward and allowed me to write much cleaner code.

Thus, the continue screen was completed.
I reused the heart animation artwork that was created earlier for counter-hit effects but was left unused.
With conversation scenes and the continue screen ready, all that's left is to integrate them into the main game flow.
However, integrating these scenes exposed a bigger problem:
Up until now, other game modes had a relatively simple, one-way structure like:
Title → Side Select → Character Select → Stage Select → Battle → Victory
But in Story Mode, the branching became far more complex:
Title → Side Select → Character Select → {Story Mode → Battle → (If lost) Continue → (If no continue) Return to Title} × n → Story Ending
In the previous structure, each scene manager simply referenced the game mode and decided how to branch.
But with this new complexity, managing scene transitions comprehensively with the old method became extremely difficult and prone to bugs.
To solve this, I decided to create a centralized Game Flow Manager to manage all scene transitions in one place.
Here too, the recently introduced UniTask greatly helped streamline the implementation.

Thanks to the new system, I was able to cleanly insert loading screens and fade transitions between scenes.
As part of the overhaul, I also rebuilt the Side Select screen, which had been based on an outdated menu system.
However, currently, only the Story Mode flow is functional—other modes are not yet operational.
I initially considered sharing just the Story Mode part, but while testing, I discovered many bugs resurfacing on the Battle Mode side.
Additionally, I received a large number of bug reports from yeayea, but due to the workload, I couldn't address them this week.
The root cause of these recurring bugs lies in the current structure of the scripts.
For example, best practices suggest keeping a script under 300 lines, or 500 at most.
However, my BattleManager class has ballooned to about 1700 lines, and CharacterManager sits at about 1300 lines.
These major classes have become so bloated that following the flow has become difficult, making them breeding grounds for bugs.
Another major problem is the lack of management classes.
The recently implemented Game Flow Manager was a step forward, but there is still no overarching Game Manager class.
Scene managers operate independently without understanding the overall flow, further contributing to instability.
For simple games, this level of refactoring might not be necessary.
However, for a fighting game where assets and processes are massive, the absence of management layers effectively means death.
I've finally come to realize this through painful firsthand experience.
Moreover, the codebase has grown so large that even modifying a single line now triggers 2–3 minutes of compilation time in Unity.
Every single time.
This not only eats into development time but also severely drains morale.
To address this, I plan to create assembly definition files for each script directory.
However, before doing so, I need to clean up the project—there are outdated, unused scripts, and the current directory structure ignores dependency relationships.
Thus, I decided to use this opportunity to comprehensively clean up the project, reduce compilation times, and eliminate bug sources.
As a result, the game is currently in a non-functional state, and I had to cancel this week’s demo update.
Given the above situation, it is now impossible to meet the May 11th deadline.
Even if the cleanup were completed, I still wouldn't have time to fine-tune the all-important game balance for public release.
Therefore, I've decided to set a new target: May 31st.
I will continue pushing forward without slowing down.
To be honest, setting a hard deadline like this really boosted my development speed.
Deadlines really are powerful motivators.
Continue refactoring
Debug Battle Mode
Prepare scenarios for Story Mode
Make CPU opponents extremely strong
That's all for this week. Thanks to everyone's support, we can continue development! Much appreciation.
Have a great weekend!