shibagani48

Weekly report Jan 4/4, 2025

Added 2025-02-03 02:04:35 +0000 UTC

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

Movement State Transition Overhaul

This week, I worked on revamping the movement state transition system, which had long been a source of bugs. Since this was a massive task, the entire game flow is currently broken, and the game is not functioning properly. As a result, there will be no demo update this week.

Battle Manager Cleanup

As a prerequisite for the transition system overhaul, I also reworked the Battle Manager class, which serves as the core of the battle scene. This is one of the oldest classes in the project.

Since I wrote it when I had limited knowledge of Unity, it contained many issues such as redundant code, unnecessary variables, and overly complex reference relationships. The current code was too messy for the upcoming tasks, so I needed to clean up the flow and make it more understandable.

Deleting unnecessary code felt like wiping away built-up grime during a deep cleaning session—it was oddly satisfying! As a result, I managed to reduce the number of unnecessary variables to about one-tenth of what it was before. The code is much cleaner now!

Reviewing Movement State Transitions

I investigated a bug reported last week by yeayea9988, where actions were not transitioning correctly. As suspected, the issue stemmed from action requests triggered by key inputs being overwritten by other requests.

Currently, multiple systems can request actions for a character, not just player input. For example:

After an attack ends, the character automatically returns to standIdle.
If a character gets launched and hits a wall, a wall bounce occurs.

Because the priority of these requests wasn't clearly defined, conflicting requests often caused unintended behavior. The movement state transitions were especially chaotic, so I need to clearly define the priority of requests.

Additionally, I discovered that damage motion transitions occur one frame later than the hit frame.
However, in most fighting games, attack execution, hit detection, and damage animation transition all happen within the same frame.

Frame-Based Flow Rework

Currently, motion transitions only occur once per frame. Here’s how it works:

Phase A (Hit Detection Frame)
- The system checks for collision between the hitbox and hurtbox.
Phase B (Next Frame: Damage Transition)
- If a hit is detected, the character transitions to the damage motion on the next frame.

This creates an unavoidable 1-frame delay in the damage animation.

To fix this, everything needs to be processed within the same frame. However, this requires major changes because hitbox detection, stance information (standing, crouching), animation, and sound effects are all processed simultaneously.

For example, if Phase A was meant to play a taunt sound, but the character immediately transitions to a damage motion upon hit detection, playing the taunt sound would be incorrect.

To address this, I am restructuring the flow as follows:

New Frame-Based Flow

Update hitbox based on the ongoing motion from the previous frame.
↓
Check for hit detection.
↓
If a hit is detected:
- Transition the character to the damage motion.
- Reset the animation frame to 0.
- If no hit occurs, continue the existing motion.
  ↓
Update visual elements such as sound and animation.

Currently, steps 1 (+4) and 2, 3, 4 are processed in separate frames.
The first priority is separating step 4 into its own process.

Since Unity has some limitations where certain processes can only happen once per frame, handling two motion transitions in a single frame will require some creative solutions. This part is still under experimentation.

Fixing movement state transitions is currently the biggest challenge, as it's the root cause of many reported bugs. It will take a little more time to complete, but I appreciate your patience!

Narrator Voice Actor

After the voting process, we have officially selected one of the candidates!

I know you're curious, but given the previous setbacks, I’ll announce the name once he has completed a significant portion of the work. Recording is currently in progress!