Weekly report Apr 3/4, 2025

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

Demo Update

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

Enhanced Counter Effects

A flashy hit stop effect now occurs when landing certain strong attacks. This idea was inspired by GGST.

I also made a heart animation for the game-over effect following the original game, but it made the screen too cluttered, so I scrapped it. I plan to reuse it in another effect later.

So far, I’ve avoided dealing with the process for pausing the game during such special effects, but it’s about time to clean this up. Thankfully, with the new event-driven system, it looks like I can finally organize this part of the code.

Improved Burn Effects

I further enhanced the burn material created last time by adding new flame VFX.

With this,

I succeeded in setting Modius ablaze.

Adoption of New Techniques

With various systems layered on top of each other, the scripts in Hellversus are becoming increasingly difficult to understand in terms of their reference relationships. In particular, adding new special effects that simultaneously control sound, camera, and character behaviors requires constant switching between multiple scripts and adding dedicated variables to each, making the process very bug-prone and highly challenging. Strengthening VFX and presentation cannot avoid confronting this issue.

To address this, I decided to experiment with a new approach: event-driven programming. Normally, when coordinating timing between scripts, one must obtain a reference to the other and directly call its functions. However, if script A refers to B, and sometimes B needs to refer to A, and then C comes into play, it quickly turns into spaghetti code. This method requires that before starting work, A must keep track of the names, addresses, and roles of both B and C and give individual instructions.

With event-driven programming, however, scripts don’t need to reference each other. The manager, A, only needs to shout, “Start working!” B and C, though unable to see anyone’s face, can detect the start trigger and synchronize their processes. It’s like remote work where employees don’t have to see their boss in person.

This is a revolutionary approach for our project, with the potential to fundamentally improve the code structure, so I decided to adopt it. As usual, though, this new technique also led me straight into a new labyrinth of bugs.

Unfamiliar and Mysterious Bugs

Event-driven programming made things easier to organize, and progress was smooth—until a mysterious error suddenly caused the game to stop. I narrowed down the conditions under which it occurred, but the phenomenon was unlike anything I’d encountered before.

The first time I played in the Unity Editor, everything worked fine. But if I stopped and then started play again, I’d get a null reference exception error specifically in the event-driven code. In essence, it was an error saying, “the object you’re referencing doesn’t exist,” but all references seemed perfectly valid. I’d never before encountered a bug that depended on how many times I played the game.

Since I was using an external package called DOTween at the error location, I suspected it might be the cause, but I had never seen such errors from DOTween before. I searched the web for similar issues and posted to the community, but got no answers. As a stopgap, I found that removing DOTween code from the event-driven actions prevented the error, though the reason remained unclear.

In the end, it took time, but I was able to solve it. The same error happened in another location where DOTween was not involved, confirming the cause lay elsewhere. The real culprit turned out to be that remnants of the previous play session’s data persisted in event-driven programming. In event-driven systems, classes must “subscribe” to relevant events to know when to start processing. When you start and stop play in Unity, normally all objects are destroyed. But, for some reason, the subscription data alone persisted, so to speak, like a ghost searching for its lost body, resulting in errors. By adding code to clear subscriptions when objects are destroyed, I was able to fix the issue.

Because of this bug, I lost a lot of precious time and was writhing in frustration.

Debugging

I fixed bugs reported by yeayea.

• The direction of the smoke effect during backsteps was wrong.
  → Applied a temporary fix. The scripts responsible for effect generation are some of the oldest in the project and a mess, but I ran out of time to clean them up.

• UI was not displayed when pausing.
  → The display order of the UI was not set correctly. As far as I can tell, it’s now fixed. Probably.

• After a cross-up attack, the direction of damage knockback didn’t reverse.

  
  → Reproducing this was difficult. I couldn’t do it manually, so I used a macro. This person is clearly skilled at fighting games! Tracking down the cause was also tough. It turned out that when the same action was executed consecutively, some processes were being skipped. This logic was originally to avoid bugs in actions that require loop processing (like dash or walk), but it caused new bugs for other actions.

  

  Since loop-type actions are now identifiable by property, I updated the skip condition to solve the problem.

Plans for Next Week

Only three weeks remain until May 11. The general plan is as follows. If I focus on one, I can probably get it into decent shape, but I’m unsure how to proceed.

• Strengthen VFX and presentation

• Improve controls, adjust the behavior of each action, and add a new cancel system

• Enhance CPU AI, add a level-up versus mode, and implement a novel part

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