Good Luck…


The new timeplan is so far a success- I’ve managed to cross a week off the list, and a little bit of next week too!


This week however has started off a little slow, but I’ve managed to get a lot done. This morning I played through the game from level one to level three for the first time to check that everything worked well in succession, and for the most part it did! One random little bug started to emerge towards the end of the playthrough however, as the framerate started dropping rapidly whenever I passed by a doorway to a building or cave. I managed to solve the problem by tweaking the “teleport” code slightly (I literally moved one line and removed a pair of curly brackets and everything was fine!) In the panic I read through this article on the Game Maker Community forums, which talks about optimizing game performance through various settings and commands, so the rest of the morning was spent tweaking little bits for best optimisation. One of the most vital lines of code I’ve added is this:


These few lines deactivate EVERYTHING that is outside the current view, and activates it when in sight. I had to activate the top corner of each room in the last line of code, as this is where all my control objects are kept including light functions, menu functions, sound functions, HUD functions… By reducing the amount of active instances, the game runs at a very steady 60 FPS constantly, occasionally dropping to about 58. Hopefully this means that even on lower spec machines the game will be very playable.

After this was over, I spent a little time tidying up little bits that I’ve previously started. I’ve replaced my old pink room transition object with an open door sprite, which is drawn onto the screen when the player reaches the right amount of flowers. The door only opens slightly, which is great if you’re nearby when you collect that final flower because it actually looks a bit like the door is opening.


I’ve fixed my save point Furin so that it looks like it is attached by a nail, not just floating next to a rock! I’ve made sure that all my save points are actually within reach of the player, which seems like an obvious task but this really is something I had previously overlooked.


As for the actual saving problems I was having, I’m not sure there’s such a big problem there after all. The problems may be related to the fact that the saves are made in the middle of making a lot of changes to the levels. I’ve also changed the save file to a .ini instead of a .sav, which for some reason saves more of the game information and is the only file extension which will reload sound effects. So until I’ve finished everything in the game, I’m not going to change the way the game saves or loads.

I’ve started to work on the final level of the game, firstly by changing the colours in the tileset and secondly by getting creative with my old tiles again. Up until now, my buildings have been very samey, so I’ve been experimenting with new ways that I can use my existing tiles (again!) I also managed to make a mini bridge from a section of my old bridge tiles.




There are now blossoms to collect in this level, so the HUD displays a total of all the flowers the player has collected throughout the game out of a possible 90. This was simply a case of adding the values of global.itemList1, global.itemList2 and global.itemList3.

Now that I know roughly what I’m going for with the design, I’ll do most of the rest on paper. This building will branch off into rooms, as opposed to having a large open outdoor space to explore. In one of the rooms there will be a door which only opens with an accumulative total of blossoms, so although the player may have made it this far they may still have to backtrack and do some more collecting! The end of the game is through this door, although I’m going to have to go back to the GDD and have a think because I don’t actually know how the game ends yet…

Save/Load Functions

The tricky part of implementing a save/load system is the painful process of working out what Game Maker will and won’t do using its default game_save(); and game_load(); functions.

Based on my original inventory menu, I’ve created two new menus in a similar style which represent the save menu, which is brought up by pressing the menu button at a save point, and a pause menu, which is brought up by pressing return/start and can be used to load up a saved game.

Save Menu


Pause Menu


To activate these menus, I’ve used a similar set of code to that used to activate the inventory menu. In the case of the save menu, when the player is in contact with a save point object and presses “S”, all objects are deactivated and a temporary overlay is created from a still image of the background. The object obj_save is then created, which draws the save menu onto the screen.


I’ve included the object obj_save in my list of instances that are created when the game is started. When initiated by the save point object, it changes the state global.save from 0 (false) to 1 (true), and draws the menu sprite onto the screen as well as the highlight sprite which changes position when the left and right keys are pressed. The options in the save menu are the same size and shape as the menu slots in the inventory menu, so I was able to use the same highlight sprite for this menu. Like the inventory menu, each “slot” (s) is given a value, in this case because there are only two options the values are 0 and 1. If s is 0 when the X button is pressed, the game is saved. If s is 1 when the X button is pressed, the game returns- pauseon and global.save are both reset to 0. Game Maker uses a simple one line of code to save games: game_save(“example.sav”);. However, there are many things that aren’t included in this save file. I already discovered a while ago that temporary datastructures, such as the item lists I use to hold information about collected blossoms, are not saved in save files. To save this information, I’ve had to save each list as a separate text file, so the save code has become quite extensive!


The game here is saved as a file called hanamisav.sav in a designated folder called “save”. I made this empty folder to test if this save function would work, and sure enough the files appeared in the folder straight away.


As a symbol of the game being saved, I’ve made a floppy disc icon which appears at the top of the screen whenever the player opts to save or the game is autosaved. The floppy disc seems to be the universal symbol for “save”, whether used as an icon in software such as Game Maker or as a save point in games such as Cave Story!



On my floppy disc icon, I’ve included the kanji I discovered before for “to save”. This is supposed to look like it written on the standard lined label that you used to get with blank floppies. Like the sushi icon which appears temporarily at the top of the screen, this icon remains for about three seconds before disappearing.


I’ve assigned the pause menu to the return key or start button on the SNES controller. Pressing either of these buttons will do exactly the save as all pause functions I’ve implemented so far, but will draw the pause menu sprite onto the screen. The options are actual strings of text which are drawn over the top of this sprite, according to the array I’ve set up in the object obj_pause.


This list of text acts differently to the slots I’ve used in my previous two menus, so I wasn’t able to use the same highlight sprite to hover over options in this case. Instead, I’ve used two different colours to show whether the text is highlighted or not. The lighter colour shows the option currently selected.


At the moment, both the “continue” and “main menu” options will simply resume the game, as I don’t have anything that acts as a main menu yet! I may later change this option to “quit”, and simply make it close the game. To load the game, I’ve had to make sure that all five files are loaded and properly restored. I’ve written out the code in the opposite way to the save code, so that each text file is loaded then applied to one of my global.itemLists. As for the rest of the game’s properties, I’ve so far relied on the default game_load(“save/hanamisav.sav”); function to restore everything else.

Loading the game shows some….interesting results. Each of the text files are actually restored properly, this was the part that I was mainly worried about! Everything in the GUI returns to exactly how you left it, including level progress, health and collected sushi. However, I’ve noticed a couple of things that the aren’t restored properly due to faults in the default Game Maker save file. The sounds aren’t loaded, possibly because the SuperSound.dll doesn’t exist in the “Save” folder, and weirdly enough the mushroom’s particle system isn’t restored. Another MAJOR issue is that 8 times out of 10, the game will crash after you’ve taken a few steps from the restore point. Of the remaining 2 times out of 10, 1 of those will produce an error message stating that a non-existing background cannot be deleted, which is probably due to a fault in my code for the temporary pause background. Because of these problems, I’m going to look at alternative ways of saving that don’t use the default save functions. I may also make slight tweaks to the menu interfaces, but not too much.

Remember Save Points?

What was going to be a relaxed weekend of casual doodling has somehow turned into a few brain-mangling hours of discovering everything that’s wrong with Game Maker’s built in save and load functions. I figured I still haven’t sketched all the characters I’ve planned in the GDD- this is something I want to do, even if some of them don’t make it into the game. The next semi-important character I’d planned was a pervy guy with a camera who will “take a snapshot” of the player and save the game (remember the camera guy in Rayman? A bit like that… I can’t find a decent screenshot online, but it looks like they’ve done the same thing in Rayman Origins which I still haven’t managed to play yet)


I was inspired to design this guy after reading about perverted Japanese guys who like to get close to women on crowded subways etc, and somehow thought “that would make a good save/load system!” Well, I drew a little design of the guy, camera at the ready, and just wasn’t sure if he was right for the tone of the game…


I even got round to making a pixel version, which I might use later on for a less important NPC if I’m stuck for time. It’s difficult to make someone look creepy in such a small space, and more difficult to make a camera that actually looks like a camera, so all round this wasn’t a huge success.


So, back to the drawing board. It seems like these days you can save most games whenever you like, which is certainly convenient. This was pretty much unheard of until the past 10 years or so- up until then you would have to wait until you reached a designated “save point” if you wanted to save your game, and these were elusive and unpredictable little objects a lot of the time. In the harshest scenarios, such as the original Resident Evil, you had to collect items in order to use a save point, so the amount of saves were extremely limited.


My plan for Hanami is to include one save point in each level, which can be used infinitely as long as the player reaches it! The game will also autosave at the beginning of each level, so if the character dies they will either return to the last save point, or the beginning of the level- whichever occurred most recently. Instead of using a character, I tried thinking about more Japanese symbolism that could be used as an emblem of a save point. You can see my ideas in the sketch above, as I’m running out of sketch book pages and I’m trying to conserve paper :S

My first idea was to use a Hanami Dango, which is a special type of mochi on a stick eaten at Hanami. This was actually a coincidental discovery for me, as they popped up in the film Tekken: Blood Vengeance which I watched recently.


I considered placing a Hanami Dango stick on a sort of pedestal to create a sort of Hanami Save Alter, and this is where I got with that. The kanji means “to save”.


I didn’t quite finish this design, as I felt it didn’t really capture what I hoped it would. I don’t like wasting cool little things like this though, so there are plenty of food outlets throughout the world of Hanami that the Dango will probably make their way into! As I’m still trying to capture an overall image of Japan, I tried to find a nice little artefact to use rather than trying to keep within the realms of the Japanese spring time. After all, a lot of traditional save points were random emblems. I mean, what was the save point from FF7 supposed to be??


I had a look on the internet to see if there was anything seriously Japanese that I had missed out, and I found this article about must-have Japanese souvenirs! It includes a lot of imagery that I have already included in the game in some way, such as Maneki Neko, Hand fans, Umbrellas (Wagasa), Lanterns, kokeshi dolls, koinobori… On this list, I rediscovered Furin bells. I thought these would be a nice point at which a player can save their progress, as their inevitably interactive and look nice too 🙂 The bell consists of a domed glass case and a single glass chime running on a rope through the centre. A tag is placed on the end, where little bits can be written (I was considering trying to get a bit of kanji onto this, but haven’t managed to in such a small space yet!) I might yet put a design onto the glass, but for now I’ve settled for a simple Furin bell design:


On contact with this new object, the player can open up a new menu which asks whether or not they would like to save their game. I originally envisaged the object hanging from a rock outcrop or something like this, although I realised from a bit of play-testing that this object is too high up ¬_¬