and a belated happy new year! I wish you all good luck, health and fortune in 2019. This blog I am giving you a brief update on the latest changes to the menu (yay, floating background enemies!) and the first feedback from close friends of mine who did the first playtests.
A little follow up on the DevBlog#7: as I wrote in the comment section there, I have added some obfuscation to the highscore file, so that it’s not that easy to manipulate the scores.
I added a little orange indicator for the last round’s achieved score. This way it’s easier to track, where you placed in the last run.
The last menu functions that have been missing are now included. Such as a list of previously used names, as you can see below, and the sorting and storing of them in a save file. For this to work I had to also add a function that updates the displayd data for the menu, so name-switches also reflect in other parts of the menu when you type the name. Oh and the sub menu also needed an indicator for the currently active name, so the player gets some feedback for when he actually selects one of them.
The whole menu gained some spicing with the addition of basic enemies wandering in the background. To achieve this I had to split up the menu into a foreground and background object to allow the enemies to be displayed in between. I could have rendered everything on one surface, but I think this was the easiest approach. This way, I have three layers to work with. Since the enemies in the background are instances of actual ingame enemies with the same properties I also needed to take care that the ones I spawn in the menus get properly destroyed when going back into the game without triggering the stats and rewards. Or worse, to allow for the enemies to swap over to the ingame state, where they may cause different problems like instant player death. This also made me think about the whole pause menu and the state transitions. Right now I am taking the “easy” route of the instance_disable_all() function. I may eventually have to swap to a ds_list based model where I can finely control which instances to de- and re-activate. But I will have to think a bit more on that before I implement such a system.
My save file system got a tiny addition, too. Thanks to a conversation with juju I implemented a super simple versioning to my save files that, in the current iteration, simply deletes the old settings files when there is a version mismatch. Later on, when I already have a few players actually playing the game after release, I can then expand on this versioning to ensure I can transfer the old settings and only delete/modify the settings I actually changed the structure of to avoid conflicts. This would then maintain user friendliness for the player and help keep compatibility levels high.
While I also did some code and script cleanups, the last thing I want to write about is that a few of my closest friends got the first version to playtest. The feedback I got was surprisingly positive for such a small amount of actual gameplay and this makes me extremely proud and motivates me to further develop fun content. The gameplay seems to be satisfying and fun enough for them to enjoy their play sessions. I also received feedback on my menus, their structure and behavior. In that aspect I still need to unify the functions a bit, but overall it was okay. We also found a weird bug with a PS4 controller(in combination with a gamepad remapper tool) attached, resulting in broken keyboard controls. That one still needs to be pinned down and fixed, though.
That’s it for today. I thank you again for your interest in the development of GreyHole and leave you with kind regards,
If you like this entry, you can read up the next blog post “damage types and a new enemy” or the previous one “Highscore and Saving and more”. You can also sign up to the newsletter, so I can inform you about new blog posts. Or you can get involved on my Discord server.GreyHole - #DevBlog -