Deep Climb demo is now live! Play Deep Climb in its feature complete state (and if you have any feedback, feel free to join the discord and let us know!).

It has been a long road to get here but that has made us all the more proud of the game we have created. Last dev log we discussed the time consuming task of level design and how rewarding that process is, watching the game grow as each level asset is placed into the world. On the flip side of that, this last push has been filled with tasks that are less obvious such as our reactive lighting, save system, and optimisation.

Optimisation in particular has been an interesting challenge for us as we are new to programming. We found the need for this when testing discovered significant and consistent frame drops in some areas, such as that in image 1. We did some research but could find no answers online, so we started a process of elimination where we would remove assets from the nearby location and test to see if it impacted the frame rate. Eventually we found that the culprit was our echoes and checkpoints which run a CPU intensive operation for rotating to follow the player. To fix this problem, we reworked the scripting and removed the functionality from the checkpoints. We still need to be cautious of having too many of these actors in close proximity as the operation is still expensive and will likely need more improvement in the future.

Similarly, adding progression saving has been an interesting challenge as we have had to learn more about the way game data is stored on modern computers. This was most crucial when we thought we found a bug resulting from having multiple versions of Deep Climb installed, causing save information to be kept when it should have been removed. With some researching and testing, we learnt how game save data is stored separately to the game files and as such, is not removed when the game files are deleted. To accommodate for this, we added a ‘new game’ option which sets the game data to be empty and allows players to start a fresh playthrough.

This final push has been interesting as it has been significantly different from every other stage of development. The main reason for this is that the limitations of scope are extremely obvious. For example, in previous sprints, when a new idea was pitched, we would predict how much time/resources we would have in the future to implement it. Whereas, in this final sprint, it is much more obvious how much time we have to implement new ideas, making it much easier to dismiss ideas like graphics settings or implement ideas like lighting which reacts to the player.

If you’ve been reading all these logs, we hope it has been interesting and insightful to see our development progress. We are a small team of uni students trying our best to look like functional indie devs but at the end of the day, we hope we have made a fun game and would love to hear what you have to say.