Weekly report June 1/4, 2025

Hello everyone!
 Thank you as always for your support.

And I’m sorry for the late update.
Let's take a look at this week's progress!

Due to hosting a friend from afar, house-sitting at my parents’ place, and taking care of their cat, I wasn’t able to make much progress on development this week. As a result, there’s no demo update this week.

Since I’m away from home, I couldn’t use my main PC and had to rely on my sub-PC for the first time for any serious work. Other than some issues with character encoding, I was able to continue development without major problems.

This week’s report is still a progress update and mostly covers abstract programming topics. Normally, I’d prefer to include diagrams to help explain things, but since I’m away from my usual setup, I couldn’t prepare any visuals (though coding itself can be done anywhere). If that’s okay, I’d appreciate it if you’d give this a read.

🔳 Physics System: Progress Update

# Value Relay

It’s been a tough journey learning new architecture, but a big takeaway for me has been learning to write safer code. Until now, I’ve often directly referenced properties between classes, but that’s a major source of tight coupling, which is a well-known problem. Keeping properties private and avoiding direct external access is a key step towards writing cleaner code.

The very first trigger for the physics calculations comes from the push detection boxes, which are the lowest layer in the system’s hierarchy. In the past, higher-level classes would reference these values directly, but in light of the lessons learned, I decided to unify the physics system by retrieving values exclusively via methods.

In practice, the value relay goes like this:

Box → BoxSet → BoxSetManager → CharacterManager → BattleManager → PushDetectionClass.

Of course, I’d love to just pass the value directly to the final class, but as I’ve said before, direct references are a breeding ground for bugs. It might feel roundabout, but I adopted a relay system where each higher-level class calls methods on its subordinate classes to get the values it needs. There might actually be a more efficient way to do this—my knowledge is still growing.

# Custom Collision Detection

Collision detection is triggered when both characters’ boxes overlap. Up until now, Unity handled all of this automatically. When building it myself, I realized I had to determine overlaps based on box sizes and positions. However, since the box size is affected by the parent class’s scale, simply getting the local scale wouldn’t yield the correct result. This led to bugs.

By multiplying the local value by the lossy scale, I was able to get the correct size that factors in the parent’s scale. I don’t fully understand the underlying logic, but it worked—sometimes that’s just how it goes.

# Speed Correction During Pushing

Originally, I planned that if the opponent wasn’t moving, the moving character would push with 100% of their force. But in testing, this felt unnatural. Other games tend to slow down the character when colliding, which reinforces the sense of impact. So I implemented a 50% speed reduction when pushing.

I also had to account for cases where both characters are moving toward each other. Ideally, the value would be adjusted based on their relative speeds, but for now, I went with a setup where the faster character pushes with 0.7 and the slower one is pushed back with 0.3. I haven’t fully tested this part yet.

# Anti-Swap Mechanism

When an action is too fast and there’s no overlap frame for the boxes, the characters can end up swapping positions. To prevent this, I implemented a process where each character’s position is saved, compared to the previous frame, and forcibly corrected if their Z-axis overlaps after swapping.

The tricky part is that this requires a separate process from the pushback calculations. For pushback, I update the position by adding the value to the current position, but for swap correction, I have to overwrite the value.

In the BattleManager, I get the swap detection result from the PushDetectionClass and branch the process accordingly. However, this still isn’t working as intended—by the time the position is corrected, the swap has already happened, and the result is that they’ve swapped positions anyway.

To fix this, I’d need to calculate the predicted position by adding velocity to the current position and then compare those positions. But doing that would require a review of the entire processing order in the BattleManager.

# Other Remaining Issues

• Currently, boxes are assumed to share the same position as the character, but I need to consider the position of each individual box.

• Deciding when to apply screen-edge movement restrictions.

# Next Week’s Plans

• Continue implementing the custom physics system.

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