This morning I put the lock and key system in place in level 4, so that the final Boss stage can only be accessed when enough blossoms have been found. I was originally going to suggest 80 as a possible amount of blossoms needed for the second door to open (only 10 blossoms not discovered throughout all three levels…) But after a little volunteer play-testing I’ve decided to reduce this to 60. The player only needs to collect 45 blossoms to advance to the last stage, so my participants ended up with between 50 and 60 blossoms in their inventory by the time they got this far. That leaves thirty undiscovered blossoms throughout the game, which I will probably allow the player to collect later.
If the player doesn’t have a total of 60 blossoms, they will be confronted with this when they enter the house in level 4:
In this instance, they will have to go backwards through the game and try to collect more! All the doors that the player has previously opened will remain opened indefinitely, so the player can travel backwards and forwards through the levels as much as they like at this stage. If they have managed to collect 60 blossoms, the door will be open:
The player can then go into the next room and grab the key, which then appears at the top of the screen in the same way as the sushi and other collectable items. As I don’t have a space for it in the inventory (yet…) the key is visible just above the inventory to assure the player that they are carrying it!
In order for the key to work, I’ve created two new states which describe whether or not the player has acquired the key. To begin with, global.key is set to false, meaning that the back door will not open. When the player collides with the key object and presses the X button, the object is added to the itemList DS list and global.key is set to true, so as long as the key is part of the itemList datastructure global.key will always remain true. If the player presses X when near the lock object, this will deactivate the object and activate another new state, global.door. This draws an open door sprite over the top of the closed door tile, and allows the player passage.
Other than this, I’ve spent most of my day today tidying up messy pieces of code. The play-testing revealed to me a couple of things that were eventually quite detrimental to the performance of the game when played from beginning to end! For instance, I’ve realised how important it is to place lines of code in the right event. Most of my objects consist of at least two events, create and step. Code placed in the create event is called once, and consists of things like speed settings which are consistent while the instance exists. Code placed in the step event is called every “step”, which basically equates to frames per second. Hanami runs at 60 FPS, so each step event is called 60 times a second, and can reduce the FPS if overloaded! I’ve spent a lot of time shuffling code around so that all functions are called properly, and I seem to get a consistent 60 FPS, but I won’t be sure until I have another play-through in debug.
I’ve also been trying to remedy my screen view to account for varying monitor shapes and sizes, as I’ve now started running the game on other computers and notice some significant differences, mainly where GUI such as the HUD and inventory are involved. I’ve discovered that there is a built-in Game Maker function which can determine the display size it is playing on, but after a while of trying to apply this I haven’t had much luck in getting anything that runs as smoothly as it currently does now. So I may try to find another way around this.
Lastly, I’ve created a second new Sakura Tree object to replace one of my older designs. I’ve placed this very sparsely through the levels, as a rarity and a treat. It looks a lot nicer in smaller doses, so I’ve left the main tree background to my Bonsai and Bamboo objects.