shibagani48

Weekly report May 5/5, 2025

Added 2025-05-31 16:53:07 +0000 UTC

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

Due to the reworking of the core system, the game is no longer in a working state, so there will be no update this week.

Refactoring of Movement Processing

As a goal for the future, we need to control the movement speed of actions. This is because currently we have issues in the following cases:

During juggling at the edge of the screen, positions are likely to get swapped.
When movement is large, characters can pass through each other, causing positions to swap.
Basic movements are all controlled by scripts, but only the pushback detection relies on Unity’s physics engine, making it a black box.

Regarding the pass-through issue, currently it does not occur because the character's movement is suppressed below a certain threshold, but this prevents dynamic movement. The Assault Rush implemented last week would be easier to land and more fun if it could advance further, but right now it’s in an incomplete state.

Creating our own pushback detection to replace the physics engine would be very time-consuming, so I was planning to do that after the public release. However, as long as this issue exists, it’s hard to make detailed adjustments to the action behavior.

Once again, I must face the challenge of refactoring, which I have failed many times before. This time, based on previous experiences, I decided to narrow the scope and remake it on a smaller scale. Until now, the MoveUpdate class handled movement processing, but this class also handles state transitions and action instructions on a per-frame basis, making it almost a semi-god class. Therefore, I decided to extract only the movement processing part, separate it into a new class, and also implement our own physics calculations.

First, I need to start by organizing the dependencies. MoveUpdate is used by the CharacterManager, but it also directly modifies the values in CharacterManager, which is a complete dependency anti-pattern.

The correct dependency relationship should be that higher-level classes use lower-level classes unidirectionally. The lower-level movement class should wait to be used without modifying other values. To achieve this, I reviewed all movement cases to identify what processes are required:

A: Processes that can be completed within the movement class itself:

Voluntary movement by player input: walking, attacking, jumping, etc.
Gravity-based movement while airborne.
Movement limits at the stage edges.

B: Processes that require information about the opponent:

Forced movement during throws or restraints.
Movement restrictions based on the distance between characters.
Pushback during attacks when the opponent is in the corner.

A is straightforward, but B is the problem. Previously, characters directly referenced their opponent’s instance information, but from a dependency perspective, it’s not correct for a lower-level class to directly reference anything else. It should be the BattleManager—a higher-level class that can handle both characters simultaneously—that manages opponent distance and pushback processing.

The best practice for CharacterManager, a lower-level class under BattleManager, to obtain information from the upper-level class is to use interfaces. This finally solved the dependency issue. If the BattleManager also manages the physics calculations class and can pass calculation results via interfaces, then success is within reach.

However, this week ended with only the decoupling of existing movement processing. Untangling the tightly coupled architecture is extremely abstract, requires patience, and takes time. Ignoring dependencies and quickly building features is faster, but when you want to make fine adjustments later, you realize that this approach fails. Changing one part causes a ripple effect that breaks many unknown parts of other classes. Trying to fix those classes leads to more new errors. This is why I have failed so many times at refactoring in the past.

In that sense, this time actually went pretty well!

Public Release Schedule

It was supposed to be within May, but unfortunately, I couldn’t make it. I’m sorry! But the end is in sight. Really!!!! Please forgive me!!!!!

Plans for Next Week

Due to family circumstances, I’ll be house-sitting for my family who will be on a long trip, so I might not be able to use my main PC. I should be able to work on the sub-PC I set up last time, but since this is the first time, I have no idea how it will go.