Honestly, the past week was not that exciting in terms of game development of Lost Caves. Since the game is feature complete, I’ve really just been continuing to fix bugs and make tweaks while also running through the game to find any bugs that need to be fixed. Last night though and earlier this morning though I started to give out beta copies to a select few individuals to beta test the game and provide feedback. I was pretty selective on it, and wanted people I could trust not to give out the game on their own accord, and also who have given me good feedback in the past and could give further feedback. I prepared a detailed form that has questions for them to respond to about the game, such as the difficulty, level design, and mechanics, and how they felt. Thankfully the beta I sent out is mostly polished. Getting it to that state was quite the endeavor, though.

Last week was rather frustrating since I had to go back and forth to fix bugs that I initially was clueless on what caused them. I really had to put on my detective cap to figure some of this out, and sometimes I wanted to tear my hair out. There’s honestly nothing more frustrating than a bug that occurs in a build, but not in the editor. When that happens, you have very little to go off of because you can’t manipulate the game as easily as in the Unity editor.

One of the bugs I came across involved the treasure inventory. While testing the game, I’d make a new build after making a fix to a bug, and when I loaded my previous save data, I was hit with this in when I opened my treasure inventory.

Aside from that golden shape on the bottom left, NONE of those images are supposed to be treasure, and they seem, for all intents and purposes, completely random. Why did this happen? Well, it’s because of how I save your treasure to a file.

I save all your game data to a json file, and to keep track of what treasure you’ve picked up, I have a list of sprites that correspond to treasure you’ve collected, which gets saved. However, since sprites aren’t text, and json files are text files, that can lead to problems apparently. It gets added to the json, but it has some seemingly arbitrary numerical ID attached to it, and I guess it changes across builds, leading to the random sprites. I’ll have to save the treasure differently. What I ended up doing was saving each sprite to a string list that held the sprite’s internal name. That string list would be saved to a json file, and when loading your game data, it would check for sprites that have those names, and display them accordingly. This makes it future-proof as I won’t be changing the sprite names.

This fix was all fine and dandy, but I had to do some re-coding of the script that would display the sprites in the treasure inventory, and it unfortunately led to another bug. In the build, seemingly random slots in the inventory that should display treasure will just show nothing at all. I was eventually able to solve the problem, though. It’s a bit hard to explain, but basically I have a for-loop that runs that checks for any image files in a folder that match the treasure sprite name saved in the aforementioned string list, but I didn’t have the for-loop run long enough, so some inventory slots would not show a sprite. This was thankfully a simple matter of running the for-loop for a bit longer, which fixed the problem.

Honestly though, one of the most frustrating bugs out of them all that I dealt with for the past week, I was dealing with last night, and it involves keyboard controls in the splash screen. In the splash screen, you can press any key or button on a controller to skip the intro, and when you press ‘enter’ on your keyboard, or ‘start’ on your controller, it would take you to the game data screen. This worked fine in Unity, and it worked fine on my Mac build, but you know where it DIDN’T work? The Windows build. I have a Windows PC that I use for gaming that I tested the game on, but when on the splash screen, I couldn’t hit any keys to skip the intro or go to the game data screen. I could do it with a controller, but not with a keyboard. What the hell is going on? Man, it’s one thing to have a bug that only happens in the build, but a bug that not only happens in the build, but ALSO only happens on a Windows version in the build?! This was not gonna be fun. I went and made a copy of my Unity project and checked it out on my Windows machine after getting the right Unity version on it. Turns out the input problem happened in the editor on there too. What’s going on? I got absolutely zero errors or warnings relating to the issue. I went and dived into the script in question that handled the inputs. I changed things around in the script to try and isolate the issue, but I just could not figure it out. I then realized what it may be. I switched to Unity’s new Input System, which is a replacement for the old Input Manager for handling keyboard or controller inputs, and I realized that, on Windows, it may not play nice with me using the old Input Manager code with the new Input System code. I then got rid of the Input Manager code, but that still didn’t fix the problem. I then learned that I had some code that would check for a controller button using the Input System, but I didn’t have anything that checked for a keyboard. What if this was the problem? It would make PERFECT sense if it was. I then added some code that checked for a keyboard input, and surely enough, the issue was fixed. Thank god. I thought I’d never figure this out.

Unfortunately, I did have one more issue that only happened on Windows, which involved taking screenshots. You could take screenshots with the F key or left trigger on macOS, but it wouldn’t work on Windows. I still don’t know what the problem is, but given that it’s not a crucial issue, I decided to not worry about it. After fixing the input problem though, I went and made a fresh Windows build, and also a macOS build for good measure. I also put together a readme file for beta testers to use, and I then made a zip file containing both the macOS and Windows build, and the readme. Next week, I should have most of the responses from the beta testers. I’ll be sure to share some of the info from them in next week’s devlog!