October Progress Report

Falling into place.

Infinite Level game discussed: The Future Project

Enough time has passed and enough progress made that I feel it's time to give you all a new update on The Future Project development. You'll note that, a few weeks ago, I posted a dev blog stating that The Future Project has been delayed into 2023. Fortunately for us, that doesn't mean progress has slowed down. On the contrary, I think these past few months have perhaps seen the most progress in comparison to previous progress reports. As I mention in the delay announcement, the reason for the delay is more because I underestimated just how much there is to do in the game. It's a big game, the biggest I've worked on in fact, and thus I just need the time to make this game as good as possible. We've got bug fixes, world developments, enemies, and new features to discuss, so let's dive right in.

Starting with perhaps the most significant of changes – the player can now lock on to enemies! What this means is that a player can aim at an enemy or special object and then, at the press of a button, lock onto that enemy and follow its movements without additional input from the player. Now, you might be wondering why I implemented such a mechanic in the first place. Was it on the original design? Was it requested by a playtester? The answer to both of these is actually “no”. This was an idea that came about several months ago that I've only now implemented properly into the game. As for what prompted the idea? To be honest, it was for pretty selfish reasons...I hate playing shooters on controllers. But, I of course still wanted players to have the option to play on controllers, so I've been making sure that players can do everything in the game that a mouse and keyboard user can. Even so, playtesting The Future Project on controllers is pretty difficult for me. I simply don't understand how people can aim with analog sticks. So, to work around my own shortcomings, I came up with the lock on feature specifically for controller users, thus making my playtests with controller much more enjoyable. Though it was born of selfish reasons, the lock on feature will certainly be great for those who struggle with aiming, whether that be with analog sticks or a mouse, or for those who simply don't want to strain their muscles maintaining their aim. Of course, it should go without saying that you don't have to use the lock on if you don't want to. Everything in the game was originally designed around manually aiming at targets, and that hasn't changed. It's probably better to think of this more as an accessibility feature, a useful tool to allow more people to enjoy the game.

Another major development is the game's boss fights. Over the past few months I've worked to finish the boss fights of all the major worlds in the game. And I'm happy to say that, aside from playtesting and balancing, that is indeed complete! This means that the only boss fight remaining is the final boss game of the game, which I plan to do shortly after setting up the level for the final area. While one of these finished fights is actually bringing back a battle from earlier in the game, the other is quite unique. In fact, it wouldn't be wrong to say that it's technically two boss fights in one. Every boss battle in The Future Project brings some kind of unique gimmick, even if said gimmick is subtle. The Apex Devourer of Jeweled Tundra, for instance, flies around mid-battle. This new boss is split into two parts, with the first half focused on ground combat and managing distance while the other is more aerial focused and works to incorporate the player's newly acquired double jump ability. In terms of the arena it takes place in, it's perhaps the most unique battle in the whole game, but I'll refrain from spoiling the details. As I said, this all means that only the final boss remains, and once that's implemented the game will actually be completely playable from beginning to end. That's going to be a pretty big step! But, there's several more steps I have to take before I get to that one. Still, this is a great position to be in.

Our next major development note concerns the third major world specifically, Hand of the Water. As of this writing, this world is now 99.9% complete! The map is ready and enemies are placed throughout along with any world-specific obstacles. And of course, we also have upgrades, items, and the boss of this world. So, what's the remaining .1%? It's mostly story bits and a proper model for an item. Past those small things (and of course playtesting through it), the world is completely playable. On a similar note, I've also finished implementing all the enemies and obstacles of the game's last major world, as well as most of the progression elements. That world still needs an addition to its map that, coincidentally, ties into entering the final level of the game. Funnily enough, a lot of what I'm doing now is work that needs to be done in order to make the final level accessible. I feel like I say this a lot, but it's all about making that cohesive package.

This next item isn't so much about a new thing, but rather a big change to an established mechanic. Like any metroidvania, The Future Project has various locked areas that can only be destroyed with a missile or element projectile. Originally, these were signified by showing a “crack” texture on the wall, and the crack's color would be different based on which projectile was required. Makes sense, right? Well, some playtesters came back to me and said that they were having trouble differentiating which cracks called for which projectile. So now I've got a problem! What do I do to make these cracks more informative? My solution was to create a new texture for each crack. The missile cracks would have the same texture, but fire, ice, earth, and electric cracks have all been given a completely unique texture to make them stand out from each other. You can see the new fire crack texture in use in the screenshot above, where I was testing to see how it would look in my test map. This actually helped address problems I was facing in other maps. Hand of the Water, for instance, has a post process volume that's applied whenever you enter the volcano, and that's how that area gets its red colored glow. It works great, but even I would occasionally have difficulty distinguishing the missile cracks and fire cracks in the volcano. I originally thought I'd have to adjust some settings in the post process volume, but now that I've made this change to the textures, that problem is no longer present. Talk about killing two birds with one stone!

Returning to new features, at the request of playtesters I have also added a damage indication system. There's actually two variants of the system. The first is what you might already be used to in games – a little UI image that pops up whenever you get hit, orienting itself to the direction that damage came from. You've likely seen this in many other first person shooter games. This type of system is quite commonplace, and for good reason. It's helpful information to give to the player when they're getting hit, and can quickly tell them where the damage came from and how they have to orient themselves to fight back. The other variant is the fall damage version, where the edges of the screen flash red after taking fall damage. Although it's primarily for fall damage alerts, you will see it here and there with other attacks in the game, usually ones that are large, telegraphed, and easy to see. For me, this has been a good example of how important the small things like these can be. When you play other games, you likely don't actively think about those damage indicators because, well, that's what games do. It's sort of like sound effects in that regard, where you don't really think about it in the moment but you absolutely notice when it's not there. As soon as I implemented the feature, I thought to myself “I can't believe I didn't think to do this before!” Generally, ideas for features and mechanics are pitched way in advance, so there's often little that the developer hasn't already thought of, especially in larger studios. But we're also human, and so occasionally we might forget about these small things that may otherwise seem obvious. Fortunately, the system is in place, though I'll admit it's got me thinking about what other “obvious” things I'm missing.

Finally, I always enjoy sharing some interesting bugs with readers. I think people like hearing about these things from game devs (I know I do), and it should also give a greater appreciation for the video game making craft. Since I mentioned the new lock on system, let's start with that. Normally, the way the mechanic works is that you lock onto an enemy, and then the lock on is deactivated whenever you push the button again or defeat the enemy. Deactivating the lock on is especially important when defeating enemies, as it no longer makes sense to target a defeated enemy. That was working well enough, but I quickly found out that you can simply lock on to a dead enemy shortly after the lock on was deactivated. Enemies fade out on death in The Future Project, so they're still interactable in a sense until that fade out occurs. So, I had to figure out how to prevent locking on to enemies that had already been defeated. I ultimately did this by disabling the collider that tracks when and where the lock on prompt is fired, which is fairly simple but I did have to do that with each enemy, so it was a little tedious. Another odd bug was the overlapping audio issue I was experiencing for a while. It was not uncommon, especially in Jeweled Tundra for some reason, to suddenly have two songs playing over each other. I even once had a moment where I had three songs playing on top of each other! You can imagine how obnoxious that must have sounded. My ears were quite relieved when I figured out how to take care of that problem.

But wait, there's more! There was also this curious “loop fall” bug where, if you fell off any kind of moving platform into a pit, you'd respawn where you were last standing on that platform. Of course, that platform had since moved, so you'd just repeat your fall until you die. This was a pretty involved issue, and even now I still test it to make sure I truly fixed it. Thankfully, the problem hasn't repeated itself so far. A far more serious issue I ran into was saving and loading data, which I thought I had previously addressed. I suspect the issue returned due to some changes I made to saving and loading data, but those changes were necessary thanks to the new data that I needed saved. Explaining the exact problem would put us in pretty technical territory, so I'll spare you the techno-babble and just say this. Basically, the game wasn't doing a good job of tracking where save game files were. And because of its poor tracking, you couldn't really save your game after the first save. Why could you save only once? That's a great question, and one that, again, would put us in technical territory. What's funny is, it clearly knew which save file to save to the first time, but then it would just sort of forget. It was a curious little bug, but thankfully it's working very nicely now. Now I just need to make sure I don't break it again in future.

Well, that's everything there is to say about the major developments. As always, everything else tends to be simpler bug fixes, small visual changes, or balance adjustments. Nothing that would be especially interesting to read about, I think. Right now, I'm currently working to bring the fourth major world into that 100% complete club alongside Distant Sibling, Jeweled Tundra, and soon Hand of the Water. At the same time, I've also begun designing the map of the final world, which is basically a small handful of rooms that take you to the game's final boss. The final boss is intended to be one of the last things I put together for the game, so the fact that it's nearing time to start developing it is great! And of course, there's still plenty of playtesting and bug fixing left to be done before sending this game out into the world.

Until next time!

-Lance T.