Weekly report

Hello everyone!
Let's check the progress!

#Demo update

Download here. New password is "2pXSQVJH3FLdZrr".
Most of the changes are internal this time, so there are very few changes to the game. (There is a possibility that new bugs are increasing.)
However, what a game size reduction from 11GB to 1.6GB has been realized!

#Texture Packer or Sprite Atlas?

I completed my custom pivot reset script last week, but it won't be necessary if we use a texture packer. This week, in order to manage the spritesheets, we have to choose between using a sprite atlas or a texture packer. It's regrettable not to use the script I created, but we opted for the texture packer, which allows us to reduce the internal data size and provides easier handling. In conclusion, this was the right choice, but it will lead to some unfortunate consequences later on.

#Switching Image Display Component to Sprite Renderer

We have been using the Image component primarily to display images, but if we adopt sprite sheets, we need to switch everything to SpriteRenderer since Image doesn't support pivot adjustments. This means recreating all animation clips with SpriteRenderers and adding new curves to them.

To save ourselves from this tedious process, I decided to develop a script that automatically copies the keyframe data from the Image component to the SpriteRenderer. However, tragedy struck while experimenting with how to retrieve Unity's animation curves.

I mistakenly timed the script to remove unnecessary curves, and as a result, I ended up deleting all the necessary animation curves too! The worst part is that the script's actions cannot be undone.😨

I felt utterly hopeless at that moment.💀

#Data Recovery on GitHub

After a brief period of escapism, I decided to utilize GitHub for data recovery, as it allows version control for past project data. To be honest, GitHub's long processing times and complex concepts have made me avoid using it in the past, but in this situation, there is no other option.

I wanted to download only certain directories from past versions, but authentication errors were blocking me. I even tried using access tokens, but they didn't work, so I ended up having to download the entire project.

While navigating GitHub, which I'm not familiar with, I mistakenly thought I had saved the latest data and accidentally deleted them. To make matters worse, the last version I saved was in early May, which means I'll have to recreate some of the data from scratch.😨

I felt even more hopeless now.💀

#Animation Correction Script

For now, I decided to avert my eyes from the losses and started developing an animation auto-correction script. I struggled with retrieving curve data, but once I learned to differentiate between directly related properties and properties of separate objects, it became much easier to understand and handle.

Moreover, when adding curves programmatically, I had to differentiate between numerical and non-numerical data, which required using different functions.

In this regard, GPT provided incorrect information, so it took me some time to realize the mistake. They are not infallible either.

Additionally, I discovered a new bug in Unity, where you can add curves from different objects even if their types don't match, but Unity fails to link them to the objects that should exist. Unity can be quite a challenging tool to work with. 

After numerous difficulties, I have successfully completed the automatic sprite and curve switching tool. This script replaces the current sprite with the one of the same name in the specified folder. As a result, I can now switch all animation sprites instantly at any time. It's incredibly convenient!

#Sprite Replacement

With the script ready, I proceeded with adjustments for each sprite. Zdrada's data being the oldest, I needed to fix naming conventions and some data. I converted the corrected images into sprite sheets using a texture packer when the tragedy I mentioned earlier happened. When updating the data and changing the sprite sheet to which a sprite belongs, the keyframe data within the animations disappeared. Additionally, I discovered that SpriteRenderer and Image components have different coordinate rules, which meant I had to reset all the coordinates. These two components share similarities but have different property names, making it challenging to replace the data programmatically. As a result, I had to redo all the data for the third time this week.

Feeling despair, I resorted to drinking and fell into a sulking slumber.

#Redo, and Redo Again

Fearing reliance on the script, I decided to manually correct all the animations, which was time-consuming but yielded accurate results. I also resized and converted the sprite sheets for the effect sprites, just like I did for character sprites. This led to pivot issues, requiring a switch from Image to SpriteRenderer. This, in turn, led to changing sizes, coordinates, and sprite links, necessitating a complete recreation of the effect animations.

Upon checking the selection screen and round start effects for the demo update, I realized they were broken, likely due to the animation playback method change I made at the beginning of the month. Without any emotions left, I quietly redid them.

#Build

Finally, all the work was completed, and the only thing left was to build. However, new errors occurred. It turned out that using the UnityEditor namespace in the script prevented the build. I was using UnityEditor to obtain the crucial animation end timing for character state transitions. While there was an alternative method using the Animator class, it executes from the next frame when playing an animation, causing the data retrieval to be off. Nevertheless, I found a solution by using AnimationClipInfo to obtain the latest animation information without actually playing the animation.

I attempted the build once more, and this time it was successful! However, the character sprites were displayed coarsely for some reason. I initially thought it might be due to a change in the game screen resolution, but since the editor displayed them correctly, I speculated that implicit image compression might be happening during the build process. After searching for any overlooked build settings, I discovered that Unity's texture compression settings are retained individually for each data and even separately for each output platform.

I noticed that the maximum texture size for PC was set to 2048, and since the sprite sheet size was 4098, I thought this was the cause, but I was wrong. I continued my attempt to adjust various settings, and finally, disabling mipmaps resolved the issue.

I had never encountered a bug that caused texture display issues before, so I still don't understand the exact reason for its occurrence or resolution. Perhaps the newly introduced texture packer's import settings caused some internal changes.

I successfully completed the build. Let's measure the loading time!

#Loading Time

In the June build, the loading time was 1 minute and 43 seconds. I had expected it to be 10 minutes, but waiting time always feels longer. For this build, the loading time was only 5 seconds! All the effort was worth it. Some sprites may have incorrect resolutions or pixel artifacts, but I'll fix those later. The game's file size also significantly decreased from 14GB to 1.6GB. This is partly due to the drastic reduction in large textures and also because I isolated past build data that was stored within the project.

Loading time and processing load have been long-standing concerns, so I'm really glad I managed to solve them this time!

#Next week plan

• Background art

There are many difficulties in making a game like this, but thanks to everyone's support, I can concentrate on the project and develop it. thank you for always!

That's all today.
Have a nice day!