For the past week, a lot of development on Lost Caves has been bug-fixing and testing the game. Given that the majority of the features have been implemented, I felt that it was a good time to do another complete run-through of the game, from start to finish. As you may have read last week , I did a run-through, but it was a very short one, as wealth requirements for each level were a lot lower. They were raised significantly, with you needing to get most of the chests in each level to progress (Although I'm sure you could actually skip a level if you spent a lot of time accumulating wealth in other levels, which is fine, given Lost Caves' open style of gameplay). The updated wealth requirements definitely increased the play-time tremendously.

While testing, if I hit any significant bugs, I would go back, work on fixing the bug, and then make a new build, and continue where I left off since my data would be saved. In total, I made 11 builds. Earlier on in the testing, I actually needed to make an adjustment to how doors work in the game. When testing them in Unity though, I forgot that, when you enter through a door, your data is saved, and since I wasn't using my previous save data, it got overwritten, and I had to start over. That was a bit frustrating, but it didn't take me too long to get back to where I left off.

While bug testing, I did come across a couple of game-breaking bugs. One of those bugs would actually crash the game. In the wayward bear mini-boss area, you pickaxe-pogo on a boulder over the chamber to fall down into it to start the fight, but when you break the boulder after the third hit, the game immediately crashed. "What the hell?" I thought, and I went to investigate in Unity. If something was crashing the game, I'd get an exception or error in the console. Surely enough, when I broke the boulder, I got an error. It wasn't anything particularly exciting though. When you break the boulder, it instantiates an object that makes the sound of the boulder breaking. That variable however that stored the object making the sound was never assigned a value though, and was just null, which caused the game to crash. Like I said, nothing exciting, but it was a really easy fix, thankfully.

Another game-breaking bug I hit was with persistent switches. Switch persistence was re-designed to be more similar to how chests are handled, where they have a unique ID (currently defined by their world position and level they’re in) and are stored on a list. I was initially hesitant to do this though, because, unlike chests, which will always remain opened, switches can be switched on or off. Initially, the array of booleans I had, where each boolean corresponded to a switch worked fine; true = on, false = off. A list and ID system would be much more easy to work with though. But you can’t really store a true or false value in an ID stored in a list. When I was in bed one night though, the solution hit me. If a persistent switch is on, add it to a list, and if it’s off? Just remove it from the list. It’s stupid simple, why didn’t I think of that? The next day I added that functionality and it worked perfectly. Now, the game-breaking bug I hit was not exactly about an issue with persistent switches, it was more-so about a switch that was supposed to be persistent, but wasn’t set up properly. Setting up a persistent switch does involve a few parameters to be set, and I forgot to do some of those. One switch controls a side-door (side door being doors that block off sections of a level and don’t take you to different areas like normal doors). That side-door then takes you to a “normal” door that takes you to different area, which causes the level to reload. Since the switch controlling the side-door was not set up properly to be persistent, it would be closed, and you couldn’t go back the way you came, essentially soft-locking you. Even reloading your save data wouldn’t fix the problem, since the normal door you entered from would have saved your game, so you’d be stuck in this door purgatory forever. Luckily for me, I can edit the save data directly and add the switch’s ID in after I make the fix to make it properly persistent. Thankfully it was as simple as that, and the issue was fixed.

While I continued play testing the game, I would fix numerous other small glitches, but on Thursday evening, I finally got through the game and beat the boss. That means that the game can be played entirely from start to finish, and is more or less feature complete. What does that mean? Well, to me, that means the game is now officially in beta! With that in mind, all that’s truly left is fixing bugs, making refinements, and doing more testing. Hitting beta is a major milestone though, and it puts me right on target for my December release. Right now, I’m planning to release it at around December 18th, since that’s when a lot of kids or people in school are gonna be home for the holidays, and a lot of them will want some new games to play, so why not this one?

The rest of the week was, like I said, bug fixing, testing, and refinements. One of those refinements is to the reward you get after defeating the boss, which is an augment to your pickaxe that allows it to behave like a helicopter rotor, giving you glide ability. When falling mid-air, if you held up on your controller, you would initiate the ability and glide for 2 seconds, allowing you to reach much further platforms. The issue with this was the controls, though. In most cases, holding up on a controller or keyboard works fine, but not so much if you’re using an analog stick. It’s kind of hard to hold up to glide while also moving left or right, since your stick won’t be high enough to initiate the glide. I had to do something else. I’m using a modern controller, so I had tons of buttons to play with; shoulder buttons, triggers, stick buttons. I wanted this game to be as simple as possible in terms of controls though. I don’t want players to have to keep track of what buttons do what. Mario is a prime example of having a lot of player movement mechanics on only a few buttons. My plan was that, if you held down on the jump button when descending in the air, you would initiate a glide. The issue initially with this is, if you hold the jump button down to do a full jump, you can accidentally cause Michael to glide, which you may not want. I then decided that it doesn’t just check if the jump button is held down, it instead checks if the button is pressed when Michael is moving downwards, and it’ll start the glide, and when the button is released, the glide stops. This works quite well, although I had to make a couple of other small refinements so that it behaved well with coyote/hang time, and jump buffering.

I almost forgot, I also added a small feature for when players collect items from chests. Whenever you collect an item from a chest, a number will pop up over you that shows how much wealth the item gave you. I think it'll help players know how much wealth they're accumulating, and the general metric for what makes something high value in terms of wealth in the game. Whenever you go up a tier in wealth (there are 5 different wealth brackets in the game so far), you'll also get a pop up letting you know. Before that, and icon on your hot bar would update, which wasn't super noticeable, so I think this will help players know when they've made significant progress.

Anyways, from now on, bug fixing and other refinements will be my main priority. I’ve also composed a list of possible people to bug-test so that I can get various different perspectives on the game. I’m very excited to soon be able to finally release this game after 3 years of development!