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 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 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.

Rough Inventory Menu Design

Based on the designs I’ve been looking at from previous games, here’s my template design for the Hanami Inventory menu:

The window design has been greatly inspired by the simple blue menu windows in Final Fantasy Tactics Advance. I’ve emphasised titles by giving them a strong background rather than using bold text. At the moment, the type face is an image which I have drawn. I’m currently using DejaVu Sans in all my development work and for the text in my HUD, but I might change this later. The typography here has been custom made to fit best into the space, so I feel that it’s the best option.

The Petal progress diagram is very rough and unfinished. This is for a feature that I haven’t implemented yet, where collecting five petals in each level will result in the collection of one full flower. This information is displayed entirely visually, like the Triforce diagram in The Legend of Zelda or the Orb collection diagram in Final Fantasy. I’ve taken a lot of layout ideas from the original Final Fantasy menu system. The only interactive parts of the menu are on the left hand side, while the right hand side contains information about items and the character. However, instead of linking to pages of lists of items, I’ve used a more visual approach similar to the one used in Harvest Moon More Friends of Mineral Town. The player can scroll through each collected item in the three available slots and see information about each on the right hand side, where there is a designated blank space for written information.

The health diagram in the right-hand column is similar to the health bar in the HUD, so that player can see which stats it correlates to. This is currently fully interactive, so when the player eats a sushi item one coin is restored to its slot.

In Game Maker, information on each item in the inventory is stored in a 2D array. This stores information about the name, description and start amount of each item (in that order!)

I have a script called itemAdd which is called every time a piece of sushi is acquired. This tells the engine to draw the correct sprite into the menu when the “S” key is pressed on the menu, ie

if global.inventory[0,2] > 0
//here, [0,2] refers to that specific information in the array

Another draw code tells the engine to draw the strings of text for name and description in its designated place on the screen. This is a general code where the figure indexing each individual item is replaced by “s”, meaning this one code will cover all instances where “s” is a figure.

The left and right keys are programmed to direct a “highlight” sprite above each slot in the inventory in order to select an item. This is simply achieved by programming an X and Y coordinate for each time the button is pressed. When an item is selected using the “X” button, this code controls the processes of restoring 1 point of health and removing the item from the menu.

To make sure the player cannot restore more than 5 points of health, I’ve programmed all figures above 5 to equal 5.

Lastly, I have a code which pauses the game by disabling all other objects and drawing a static background based on the objects on screen when the inventory was opened. This is based on a process I used for a pause menu in my last project, where I create a state called pauseon which is true when the menu is open and false when the menu is closed and the game is running.


You can see the new system work in my latest Devlog Video here!

Menu/Inventory Design in Games

Traditionally, I think the HUD was the most appropriate display of information for Platform games. GUI designs and formats seem to be very genre specific, and dependent on the type of information the player needs to customise. If the customisable info is limited, then a simple and very minimal system is required. For games where play is based on the customisation of various items and objects, the system is more complex.

If you look back to the original Super Mario Bros (which I know I refer to all the time, but you’ve really got to consider it to be the great grandfather of all great Platformers to follow!) all the information that the player needed to know were displayed in a dedicated space at the top of the screen. On the left you have player information: the player’s score and the amount of coins collected. On the right you have the level information: the current level and the time that the player has left to complete the level. Items are collected throughout the game, but they are put to effect immediately.

Adventure game Legend of Zelda had a greater need for an inventory system where the player could scroll through items that they had collected. In LoZ, the player must collect many items which have various uses. Some are offensive items such as bows and arrows or explosives, others are keys which unlock certain parts of the level, and of course, the player must find and collect the three parts of the Triforce. This need led to a specific menu design where items were arranged according to type. At the top you have selectable items which the player is carrying but may not necessarily be equipped. Having a list of stored items allows the player to pick and choose when items are used. Below this are un-selectable bits of information which cannot be changed or customised. In the middle there is a little diagram showing how many Triforce pieces have been collected. The bottom row of information is the same as the play sees in the HUD, and is a quick breakdown of map position, money and keys collected, items equipped and health points.

The RPG (Role Playing Game) Final Fantasy (the great grandfather of a dying breed of great RPGs) takes the inventory menu to the next level. Here we have a grid of information which is split into three sections. The diagram in the top left corner shows the amount of elemental orbs that player has collected. Below this is the amount of money the player has collected. Both of these pieces of information are non-customisable, and are simply a display. In the bottom left hand corner is a list of links to separate menus containing information about the customisable items that the player has collected such as magic, weapons and armour collected. The success of the game revolves around decisions that the player makes in these menus- if ignored the player cannot progress. The right hand side of the screen is dedicated to displaying character information. This is a quick overview of each character, and is easily accessible as there is no HUD system in this game.

These three games were all designed for the Nintendo Entertainment System in the 1980s, but these GUI types have run with each genre throughout gaming history. As Hanami is essentially a 2D Platformer, history dictates that an inventory menu is unnecessary. However, it has evolved and changed at times. In Super Mario Bros 3, the player was given the chance to collect an item at the end of each level. Up to three items were then stored which the player could choose to use between levels, essentially creating an inventory system which was a part of the HUD- shown at the bottom right of this screenshot.

Although it makes a game more challenging to use items immediately on collection, there’s something fair and tactical about allowing players to save up items and use them at their discretion. This is why I’ve chosen to allow the player to collect healing sushi throughout Hanami and only consume when see fit. This gives me the chance to provide a window of extra information for the player, or previously displayed info in more detail! I’ve taken design inspiration from a range of existing menu designs in games. As I was looking through various games that I’ve played, I realised that coincidentally most of my favourite menu designs are from Gameboy Advance games. For reasons I can’t explain, it just seems like they put a lot of effort into awesome menus for GBA titles.

What I like about…

…The Harvest Moon More Friends of Mineral Town Inventory

It’s simple, colourful and interesting! The inventory has a certain amount of slots which are either empty or occupied by an image of an item. When an item is hovered over, information is displayed in the info box at the bottom. The system is easy to use and understand because it is set up into a nice grid system and split into two categories: tools and items. The colours and thumbnail pictures are just nice.

…The Final Fantasy Tactics Advance Menus

Far from simple, this menu system actually takes a while to get your head around. Once you do, you can start to appreciate how attractive the whole thing is, and how consistently stylised it is, even in very varying circumstances! Most things that the player must control are inside blue-window boxes, while statistics and other pieces of information are placed in a non-accessible background. Like the example from Harvest Moon, clear information is shown before the player makes critical choices.

…The Kingdom Hearts Chain of Memories Menus

The menu system in Kingdom Hearts stretches across hundreds of pages, but all of these pages are very accessible with only a few clicks. The system has been designed so that they player can view only the information they want to view very easily, using things like menu tabs to flick through pages.