Updates and Remodels

I spent a bit of time reworking the inventory again today, to make it more efficient and informative. I felt the whole thing needed rearranging after I started adding things like keys to the game, which are held in the inventory but don’t have a set space.

I’ve replaced the section labelled “Petals” with a section labelled “Items”, which covers petals, keys and the kokeshi doll acquired at the end of the game. I was very happy with the previous petal indicator, so I’ve simply shuffled this over to the side to allow room for the new indicators:


I’ve left the spacing of the sushi indicators roughly the same, but I’ve added a number next to each icon which tells the player how many of each sushi they are carrying. This is something I haven’t done up until now because I was going to limit the player to one of each, but after watching people play I feel that was a little harsh. The player can now carry an unlimited amount of sushi!


Instead of only displaying the blossoms collected for the current level, I’ve changed the last line of the inventory to display the collected blossoms for all levels. This way, when the player gets to the last level and realises that they can’t continue without 60 blossoms, they can see which level they need to concentrate on most. Altogether, the new menu looks like this:


Except on the last level, where I’ve covered up the petal collection icon so that the player knows they don’t have to collect blossoms in this level.

To conclude the work I’ve been putting into the game’s music recently, I’ve added some new sound effects to the game with the help of SFXR and LabChirp, so the inventory now plays a lot of little blip sounds when selecting, using or cancelling items.

Advertisements

Five Petals

A couple of the new tracks I’ve been working on are sounding pretty close to being finished, although at the moment there is a definite drop in quality from the first track. The “bamboo” track I’ve been trying to make has been taking the longest to finish, as it’s the most different. I’ve also started working on the boss theme, which has been fun. For this piece of music, I’m ignoring most of the rules I’ve read about pentatonic scales and traditional Japanese percussion, and simply tried to keep the themes running through the instruments I’m using and the way I’m using them. The Boss Theme is a little homage to Final Fantasy in a lot of ways, as I’ve taken inspiration from multiple Final Fantasy battle themes for the intro and from the Shinra theme from FFVII for the main drum rhythm.


As the pieces are coming together, I’ve made myself a system in Game Maker to describe which background music to play in which room. Instead of stating the music that should be playing in every single individual room (as I have done for other things…) I’ve started the music playing in each main part of the level, and simply made sure it keeps playing even if buildings and caves are entered. To do this, I’ve made a basic script which is called when the player enters the main stage of each level called soundInit:


This states that if the music is not already playing, the music should play on a continual loop. This script also sets the global variable music from true to false, meaning that the music cannot be changed. When the player leaves the level, I’ve reset the variable to true so that a new piece of music can be played after the previous one has stopped! When this script is called in the level’s creation code, both of the arguments are defined. For example, in the first level the arguments are defined as:

The other thing I’ve been working on today is the game’s petal system. I came up with this idea before I had any idea how to program it, so I’ve left it out until now. I’ve learned a lot from making the game’s menus and inventory systems, and this is basically an addition to the inventory system I’ve made so far. The idea is that each of the game’s characters gives you a petal that they have found, and five petals makes a whole blossom, which is added to the game score. I’ve had a space in the inventory for this for ages, which I’ve recently revamped to make it nicer:


To test the system, I started using the Priest character, as he was the first character I made. I’ve renamed him Bura-san in the GDD. I’ve created two different variables that depict whether or not the character can give the player a petal, shown either as flower_give = true or flower_give = false. If the character’s petal hasn’t yet been added to the itemList DS list, then flower_give is true.


When the player talks to the character by pressing the X button, this activates the petal given by the character and changes the variable to false:


The petal given appears at the top of the screen, and can be seen in the petals section of the inventory.



I’ve created three new global variables called “petalscore” 1, 2 and 3 – one for each level that the player can receive petals. When a petal is received, the petalscore value will increase by one depending on which room the player is in.


This is then drawn into the inventory, so the player will only be able to see their petal progress for the level they are currently in. When the petalscore reaches 5, one blossom will be added to that level’s gamescore, so in order for the player to collect all 30 blossoms, they will also have to collect all five petals in each level. However, the system still needs a lot of work, as my NPC characters currently don’t do very much. Ultimately, I would like to slow the whole process down so that when each character is spoken to, an animation plays where the character takes out a petal and holds it until the player takes it. This way the whole system seems a lot more obvious, as at the moment a petal simply pops up at the top of the screen without any explanation. I’m still working on the AI for most of my current characters too. Bura-san doesn’t move about, so he was easy to try out the system on. “Kaze” who I’ve renamed “Kyo” constantly moves away from the character, but currently gets stuck to walls…


The Panda character that I recently put in runs about frantically, but again sometimes seems to get stuck on uneven terrain. I like this character because there is no way of catching up with him, you have to chance running into him and pressing X at the right moment!

My latest character is called Koto, and is the game’s instrumentalist. She appears in the first three levels, and sits by her koto playing each level’s music. This character was originally going to be male and called Camui after the Japanese singer Camui Gackt, but when I checked on the internet for a character basis it seemed that koto players were generally women. I found a lot of images of koto players dressed in traditional Japanese kimonos, so my koto player is also dressed very traditionally.


And in her pixel form:


All of these characters are placed in all three levels, but I’m hoping to create one unique character for each level to make up for the fifth petal.

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.

Screenshots:



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.

Sushi Get

Inspired be the healing properties of sushi, I’ve decided to use these various types of sushi as the health items in Hanami. Eating food to restore health in video games is quite a traditional system. For some reason, eating chicken found on the rough streets of Streets of Rage was perfectly acceptable, and in fact, good for your health. Here’s Axel, eyeing up a yummy looking apple in Streets of Rage 2:


What’s more, finding a fully cooked roast chicken in a barrel was nothing out of ordinary. It’s not really a gaming aspect that has survived, for whatever reason…

Trying to place tiny little pieces of sushi in a game where the character is only 16 pixels tall isn’t without its complications. I started off trying to draw sushi into 8×8 squares so that they wouldn’t look unnaturally out of proportion. Although proportionally this worked, I wasn’t happy with the limitation of how much detail I could put into each item.


These tiny little pieces were also very difficult to place into the game. Either they stood out immensely, mainly because of the colour differences, or they were completely lost in amongst the scenery. So, instead of having somehow healthy pieces sushi just lying around the place, I decided to give them a container. This is the equivalent to chests in adventure games, or the item boxes in games like Crash Bandicoot and Super Mario. Open the box, get an item! It’s a simple concept.


I think if you were to buy sushi in a box, it would probably be a sort of takeaway bento, which unfortunately for me isn’t very distinctive. So, for now atleast, I’ve decided to cheat with this takeaway noodle box. This is much more recognisable, and at least its contents are expected to be food… For those who recognise Japanese kanji in pixel form, I’ve managed to squeeze in the symbol for “life” onto the front of the box.

The idea is that when the player approaches the box and presses the “x” key, the box reveals its contents and that type of sushi is added to the inventory, which I’m currently in the process of making. I’ve decided to use a similar system to the one used for collecting mushrooms in Superbrothers: Sword & Sworcery EP. You can’t see it well in this image, but there is a collectable mushroom on the right hand side of this image:


In S:S&S EP, mushrooms can be found which allow the player to see spirit beings, but eating a mushroom will also restore the player’s health. When a mushroom is collected, a mushroom icon appears at the top of the screen which indicates to the player that they are now carrying a mushroom. When a second mushroom is collected, the same thing happens but a quantity is added, so the number 2 will appear next to the mushroom icon. The player can only hold three mushrooms at once, which is annoying as most of the way through the game the player has five hit points, coincidentally the same amount as Hana in Hanami.

So now I have two items, one container item which contains one sprite image of the noodle box. The other is a “sushi” item, which contains 4 16×16 subimages of the various sushi/onigiri. I’m infinitely more happy about being able to draw larger sushi sprites with that added amount of detail.


When a noodle box is acquired, one of these images is called at random to the top of the screen. This indicates to the player that they have acquired a piece of sushi from the box! Calling a random image saves me the time and pointless effort of assigning a specific subimage to each individual instance of the sushi box, but ultimately makes no difference to the player as each item has the same effect.



Looking at this screenshot now, I feel like I could perhaps create extra HUD space to act as a background for the sushi so it stands out a little more? As I currently don’t have an inventory to place the item into, the item disappears after a few seconds never to be seen again. I’ve spent a little time practising making inventory screens and think I know the system I’m going to implement. There are ultimately two methods of creating an inventory in Game Maker- one is have a designated room where all the inventory information is held, and the other is to call an inventory object which sits above the imagery on-screen. I will be using an object, as I feel this won’t interfere with persistent room settings etc. which could get quite complicated. I’m also familiar with temporarily disabling on-screen activity for pause menus, so I kind of know what I’m doing! Before I can really get started, I need an inventory design (or atleast template) which I can work to. I’ve got a few designs in mind, I just need to work out some layout issues mainly.