Alpha Testing Outcomes v0.6

Alpha testing is done, and here are some important outcomes. This is a post that wasn't supposed to be necessary, as there were only supposed to be minor bugs and such in the alpha, but as you can see from the current date, and my target release of a few days ago something went wrong.

When it comes to error and bugs, things went as expected. Alpha testers found the usual small bugs that I missed, etc. Nothing special here.

However, there was a little big problem that was found. Memory usage. Now, my computer has a lot of RAM, so memory usage has never been an issue for me when testing, which led to me not thinking about checking up on it. However, during alpha testing the game was constantly crashing, and entering a non responsive state when loading new areas. It was then that it was discovered that the game was using on average upwards of 7 GB of memory, with it peaking at around 9 GB. This, was, bad.

This meant that the game was straight up unplayable on anything with 8 GB of memory, or under. And really, only something with 16 GB or more would be able to run the game properly.

This is a type of issue that I hadn't faced before, and thus didn't know how to solve, so there was a bit of investigating and learning done on this front in order to be able to tackle this issue.

Anyhow, turns out, Unity loads into the memory every single image that is referenced in an area, even if they are not being in use. And because of all of the events and all of the CG sprites being referenced in them. The number of CG sprites loaded into memory is constantly in the hundreds. Furthermore, as it turns out, the compression algorithm I used on most sprites, apparently only makes the file size smaller, and it doesn't affect the memory usage, as it decompresses the images when loading them into memory. So, while the file size of an average CG sprite was less than 1 MB, they would end up weighing around 20 MB per CG sprite after they were decompressed and loaded into memory, and there are hundreds of these being loaded into memory. 

So, we had a little big problem, for which I could only think of 2 solutions. Solution number 1, make it so that things are only loaded into memory when they are being used. I looked into this one, as it is technically the proper solution. However, this solution would've ultimately required a complete overhaul of how a lot of systems work, and I probably would've had to recreate every single interaction/event in new files that would be compatible with such a system. No, just, no, this was not doable at this stage in development. It would've been an unrealistic amount of work. 

So, this bring me to solution number 2. Compress everything properly. Fairly simple solution, but there was a problem here. There are resolutions that Unity doesn't like, and all of the CG sprites and a few other sets of sprites had resolutions that Unity doesn't like. This was something that I didn't know up until a few updates into the game, but by the I opted to continue making the sprites in those resolutions for the sake of everything having a same, even resolution. However, because Unity didn't like those resolutions, CG sprites and a few other sets of sprites couldn't be compressed with proper compression algorithms. And instead had to be compressed with the one I mentioned earlier, which apparently only helps with file size, but not memory usage.

So, for this solution all of the relevant sprites had to be cropped into a resolution that would keep Unity happy. For this task I got some software and such to make life easier. However, while it was a fairly simple process, the workload ended up being more than 3000 sprites. Sprites that had to be run through a cropping process, then reimported into the engine to replace the previous sprite, then recompressed with a proper algorithm. Each of these tasks alone take some time, but all three of them combined led to a very lengthy process. A lengthy process which had to be done more than 3000 times. It should be understandable why the update was delayed.

Now, as for the results, memory usage is now sitting at a comfortable 2 GB, with it peaking at 2.5 GB, which is a great range. This solution didn't solve the issue of hundreds of unused sprites being loaded into memory, but that issue has become kind of pointless now that the memory usage is in a good place. 

Another good thing that came out of this was an even smaller file size. Now the game is roughly half of what it was before.

Lastly, while investigating the source of the crashes and such, I thought it was the way loading works. Basically loading a new area and such was done in an instant, which would lead to some devices crashing, and some other to seem like they crashed while they loaded the new area. To solve this issue a new loading system was made, and an actual loading screen system to go with it as well. So no more empty black screens, and no more "Game is not responding" issues while loading a new area. Keep in mind that every instance of an area being loaded during a routine and such had to be replaced with this new system, which broke a couple things here and there, so even more testing had to be done because of these new issues. Overall another this was another unexpected thing that consumed a great deal of time.

The only downside from this, was that resources had to be moved into making the loading screens and such, which led to the sprites of some NPCs and some minor missing CG sprites being pushed back. I would've liked to just those things into another v0.6 build, however, I'm really starting to feel the burn from this update, so I'll be moving them to the final version of the game.

A bit of an unexpected lengthy post here. Just wanted to explain what the delay was about, without cluttering the beta post with this. Speaking of which, beta will be up shortly so keep an eye out for that.

For the curious alpha testers. Here are the changes done from v0.6 (Alpha build), to v0.61 (Beta build):

• There's now a save point during the prologue once the intro sequence is done, and the player takes control
• A new loading system has been added, it should stop lower end devices from potentially crashing when loading a new area
• A new loading screen system has been added, and 2 different loading screen CGs have been added to it
• Removed a lot of Mei's dialogue as it was obsolete and some of it was causing some issues. Will replace it with updated dialogue for the final version.
• During the prologue the desk lifeguard, and the bartender will now have an exclamation icon if Hana hasn't interacted with them
• Bed will become undone after sleeping
• The UI will now remain disabled while Hana is in a routine
• Hana's world sprite can now reflect taking off the maid bikini when wearing the lewd maid uniform
• Added a routine to the level 1 pool bed event
• Added a brief CG scene at the level 0 level up event when Hana acquires the erotic panties
• Added a few crowd NPCs to the pool in the earlier levels so as to avoid it being empty at certain times of the day 
• Added working hallway lights to the Inn
• Added missing assets and NPCs for the Inn bed making events
• Fixed not being able to walk inside of the tub at the bathing area while using the Bathhouse
• Fixed Hana appearing in the center of the Infirmary when entering it, as opposed to the entrance
• Fixed being able to use The Crater multiple times in a single lewdness level. This POI is intended to be a once per level thing
• Fixed the areas worked at not being reset after Hana slept at the end of level up events
• Fixed the camera colliding and tethering to the PUB tables
• Fixed an issue causing Hana's walking sprite to stutter while walking in a few routines
• Fixed the pool reception's female NPCs still spawning at level 5
• Fixed the pool female NPCs spawning during the level 3 level up event, when they shouldn't
• Fixed some issues with the falling leaves colliding with stuff they shouldn't
• Fixed light bleeding issues various POIs
• Fixed issues with various NPCs