More inspirational colour-themed images from Japan in preparation for creating my new orange coloured level!
Monthly Archives: March 2012
Sound Effects
In contrast with the synthy background music track I created, I’ve actually been experimenting with 8-bit NES style noises as sound effects elsewhere in the game. These started off as placeholder sounds so that I could work out what type of noises to include, but they all seem to fit really well.

I’ve been making the majority of my sound effects using a browser-based software called as3SFXR, which generates random 8-bit sounds that you can adapt and customise in your web browser before saving and downloading your generated sound. You can see from the image above that its possible to customise all settings of any sound created, generate sounds based on category or create completely random sounds using the randomise button. You can export sounds as good quality .wav files!
Sound effects I’ve currently created in as3SFXR are:
- jump & double jump
- hurt sound
- door sound
- “flower squash”
- “flower unsquash”
- blossom collection
- sushi box collection
As luck would have it, a couple of days ago an article came up on TIGsource about a lesser known piece of software that could be used to generate multi-channel sound effects called LabChirp.

This works very similarly, you can generate random sounds or create your own very easily. The main difference about LabChirp is that you can use the 8 channels listed down the right hand side of the first window to create complex sounds which utilise up to 8 instruments playing at once. You can see here that I’ve set the category to footstep, which is a category not covered by as3SFXR! I’ve made myself a very simple footstep sound based on a random generation which I customised to be softer and quieter. This only uses one channel, but was much easier to make from the starting point presented by the program. I’ve also made a “death” sound which uses two channels, and plays when the player runs out of health. You can also export sounds created in LabChirp as .wav files.
As I’ve mentioned before, I’m trying to avoid using Game Maker’s built in sound functions because there are much better ways of implementing sound effects and music. I had a go at using the Caster extension for Game Maker, which supports .ogg playback. Ogg Vorbis files are a great alternative to mp3s, especially with the restrictions on mp3 files and as Game Maker support for mp3s is temperamental at best. Game Maker plays .wav files fairly well, but using many .wav files can result in an unnecessarily large game file. Caster uses many of the same sound calling functions as the built in GM functions, but allows better customisation of things like volume and panning. In the end though, I’ve decided to use the SuperSound.dll because it seems to have much more support on the internet. This .dll still support the use of Ogg Vorbis files, and many of the same functions as Caster, but works much differently as it is a .dll rather than an extension.

The Super Sound System comes with several scripts for GM. This example is a script called SS_Init, which is called in any instance where a sound is played. There are several other scripts (you can see some of them in the browser on the left hand side) including scripts to play and stop sound, and change various settings. In order for an external sound to be played, it must first be loaded. This can be done individually within each instance, but to save memory I’ve created an instance which loads all sounds as globals. This is created once, meaning that all sounds are only loaded once but can be played several times.

Here are all the sounds I currently have loaded (this list really needs some sorting out and arranging-it’s a bit messy!) I start off by initialising the Super Sound System, then use the SS_LoadSound function to load sounds from their location in the “Sound” folder. I’ve given each sound a handle, which acts as a unique ID for each sound. for example:
global.musHanami
is the background track which is continuously looped;
global.sndstep
is the sound that the footsteps make.
You can see I’ve also used the SS_SetSoundVol function, which allows you to change the volume of individual sounds. Because my sounds files have been brought in from various places, volume levels are a little erratic! This is only there temporarily, as eventually I’m planning to change the volume of the actual files to decrease the amount of functions called. I’ve been using Audacity to convert my files from .wavs to .oggs, and changing the volume is no problem.

Here’s a really simple example of how a sound is played. This script runs when the Z button is pressed (making the player jump). The Super Sound System is initialised with SS_Init();. If the player is on the ground when the Z button is pressed, the SS_PlaySound(global.sndjump) function is called. The second section of code applies to when Z is pressed and the player is in the air performing a double jump. This plays the global.snddoublejump handle, which is a higher pitched version of the jump sound.
Most of the sound effects have been fairly simple to implement, based on various parameters like the ones above. The most complex so far has been the step sound, which uses a timer between plays that I had to time perfectly to the point when each foot touches the floor! You’ll be able to hear some of these sounds in my next devlog video!
Hanami Theme Tune

For the Hanami main theme I’ve started off with a repeated pentatonic scale played on my “koto” instrument (which is actually just the higher notes of a piano sampler instrument). I’ve harmonised (most of) this scale, using notes 5 semitones below the melodic line. Instead of playing the scale in order or pitch, I’ve rearranged the scale.

I added in a percussion track made of simple wood-block and bell sounds below the koto tracks. This track comes in a couple of bars after the music begins.

The third layer comes in at the same point of the percussion. I’ve used an “aaah chorus” sample for this layer, which is similar to the one used in Hisaishi’s Kaze no Toorimichi. This comes in two parts, which alternate every two bars, unlike the other tracks which repeat every one bar so far.

My top layer holds the track’s melody, which is played by a flute sampler instrument. This comes in gradually, as I’ve noticed it’s fairly infrequent in the tracks I’ve listened to. It starts off in small chunks, before eventually becoming the main emphasis of the track towards the end.

To add a little more emphasis to the end of the track where the melody is played, I’ve added in a new instrument playing a variation on the pentatonic scale. At times this mimics the flute melody.
The resulting track loops seamlessly, and constantly changes in depth and instrument type so hopefully won’t seem too repetitive, despite only being a minute and a half long. It may still need some refinement to make some of the instruments sound nice, but I’m happy with the overall sound of the track.
Music Creation for Games
I’ve tried a couple of programs in the run up to trying to make some good game music, mostly software designed for making great chiptune pieces. In previous projects, I’ve used a program called Famitracker, which produces 8-bit music based on the sounds of the Famicom or Nintendo Entertainment System.

The difficulty with Famitracker is creating the “instruments” or the sounds that the blips make. The image above shows the various settings which can be changed to create unique instruments, and a handy little virtual piano to preview your created sounds. This is where I’ve struggled before. You can just import instruments from other sources, but it is then implementing other people’s instruments into your track that proves difficult.

It would be nice if the virtual piano could be used to lay down the track, but it’s not the end of the world using the keyboard keys instead. In the main window of this image you can see the track visually. It is made up of beats which align horizontally, and channels which are displayed in columns and allow different instrument types to be played at once. The letters and numbers in each space depict the notes or sounds being played, and correlate to a specific instrument. This track is a chiptune version of Welcome Home by Coheed & Cambria which I started to write. In the Square 1 channel I’ve put the main melody. I would usually use Square 2 for harmonies, but haven’t placed any here. The Triangle channel plays a much softer note, and I’ve used this for my base line. The Noise channel plays white noise-like tones which can make a drum beat if programmed well, and I’ve attempted to make one here (although it’s not perfect just yet!) The letters obviously refer to notes, and the number refer to the octave that the note is played it. When you play the track back, it plays from top to bottom. You can hear a little tune I wrote in Famitracker here. This was a piece I used for some motion graphics a while ago.
Another program that I was really excited to acquire was PXTone by Daisuke “Pixel” Amaya, creator of Cave Story. I’ve mentioned this before, because it creates the music that Amaya uses in his games, and everything he makes is just exceptional quality.

This is where you customise the instruments you wish to use. While it’s possible to add effects to instruments, most of the instruments the software uses come in a file with the program. Most of them are short blips and electronic sounds, which aren’t based on the sounds of any specific console but have a chiptune feel to them!

This is a visual representation of when each instrument makes a sound. The beats are spaced vertically this time, with the track playing from left to right. Here I’ve made a melody and a harmony using a similar blip instrument, and a simple drum beat using a drum sample. Most of the programming in PXTone is done visually rather than using letters and numbers, which takes a while to get used to but is nice for those who aren’t familiar with music theory.

Each horizontal line in the image above can be expanded to see the tones that are played. For reference, keyboard keys are displayed on the left hand side of the screen. These correlate to the orange blocks, which represent the tone and timing of the note being played. This track is an experimental track which I worked on for a while to get myself into the software. I originally tried to create something using a pentatonic scale, but found myself making something that sounded like a piece from a Daisuke Amaya game! The best examples of PXTone tracks have to be from Cave Story, so here’s the Cave Story theme to help you get an idea of the type of sound produced:
The software I’ve had most success with so far is one that I’ve only recently discovered. SunVox was recommended to me as a great chiptune creation program, but is also just a very user-friendly sequencer that can be used to create tracks using any sound or sample.

To get familiar with the program, I start to create my own synthesised version of Joe Hisaishi’s Kaze no Toorimichi from My Neighbour Totoro (although it still needs alot of work because the timing is really weird). At the top you have a similar layout to Famitracker, where rows represent beats and columns represent layers of instruments. The tones are similarly represented by letters for notes and numbers for octaves, although in this case notes can be added using the virtual piano in the row below. This just makes life so much easier! I often find myself making mistakes whilst trying to remember which note belongs to which keyboard key, although this input method is still available.

The “02” next to each note shows which instrument is being played. The instruments are shown visually here. You can see that “02” is a sampler instrument, in this case a midi piano sound. By experimenting with the program I noticed that the high notes of this particular instrument sound a little like a Japanese plucked string instrument, with a little imagination! Most of my instruments are samples, although the generator is what really makes the chiptune-like elements of the track. In this example, each instrument is connected directly to the output, but filter and effect modules can easily be placed between the two to change the sound of the instrument.

This makes a very weird sound! You can see the levels here in each instrument and the output as the track is playing. The track plays from left to right in the bottom window, where the little patterned blocks are aligned. Each block represents a segment of the music which can be layered, copied and pasted and changed by moving blocks around. I haven’t done it here, but you can customise the patterns to have more meaning! Repeated patterns show places where I have repeated parts of the track, which is very useful for creating drum tracks and base lines.
I had a go at using some of the Japanese music theory I’d learned to create a track in SunVox which used a broken pentatonic scale as a basis. I’ve carried on using the suspicious piano instrument and a flute sample to create a melody. This is written in E flat major, but has quite a dark, serious tone to it. I didn’t take it much further as I hoped to create something a little lighter. I have screencap issues so please forgive the audio only!
Traditional Japanese Music
So far throughout this project I’ve had a pretty good idea of what I wanted Hanami’s music to sound like, so it was about time that I actually gave the game some sound.
The music has really been inspired by two things:
Traditional Japanese Music
This is very typical of the sort of thing that comes to mind when you mention traditional Japanese music. The music is held together by hand-beaten percussion, accompanied by the plucked strings of instruments such as a koto and a woodwind melody. The music is then layered with additions of extra percussion from bells and wooden blocks or clappers. There are a couple of things that really stand out from the examples above. The second piece from Traditional Japanese Music 2 shows a very steady drum beat, unlike a lot of the examples I’ve listened to in research. This has resulted in a very “full” sounding tune throughout, in contrast to other tracks that use minimal percussion. I liked Flower because although it probably isn’t the best example of “traditional” music, it uses the same instruments and elements. This is a lot thinner, but often uses a harp sound as a base, rather than percussion.
Studio Ghibli Soundtracks
A lot of the Studio Ghibli films are set in or based on locations in Japan, and as a result have ended up with traditionally Japanese-sounding OSTs. One of the most obvious examples is the soundtrack from Pom Poko. The film itself is about a struggle against a modern way of life which destroys tradition, and this trailer showcases about three of the different types of music that the film captures. My Neighbour Totoro also shows a very traditional way of life, set in rural Japan. The track I found most inspirational from Totoro is Kaze no Toorimichi, “Path of the Wind”. The composer Joe Hisaishi, who also wrote the soundtracks to many Ghibli films including Spirited Away, Princess Mononoke and Ponyo, manages to balance traditional Japanese instruments with a modern orchestra brilliantly. This is an orchestral version of Kaze no Toorimichi, which is just as good as the original but unfortunately without the sound of traditional Japanese instruments.
It’s very difficult to find examples of Ghibli OSTs online that haven’t been met with copyright restrictions, so there’s not a lot more I can show! You can listen to some of Hisaishi’s music here.
Traditionally, Japanese instruments were tuned to pentatonic scales which consist of five notes per octave. This is why if you punch out a tune using only the black keys of a piano it can often sound very Eastern! The Western piano is tuned in C major, which uses seven notes per octave. Most traditional Western music is played in a major and minor heptatonic scale key signature, which is partly why traditional Western and Eastern music sound so different even on similar instruments.
There are various types of pentatonic scales which have specific names in Japanese. One example is the In Sen scale, which is often used as the tuning for wind chimes. In the key of C, In Sen plays:
C Db F G Bb (repeat C…)

For Hanami, I’ve chosen to use the E flat major pentatonic scale. I’m not sure if this was a scale that would have been used in traditional Japanese music, but when I was trying to work out the key signature for Hisaishi’s Kaze no Toorimichi it was the one that seemed to fit best (I’ve tried to work this out from the video, but can’t really be sure…) The scale of E flat major consists of Eb, Ab and Bb, and the pentatonic scale looks like this:
Eb F G Bb C (repeat Eb…)

Because it’s a major scale, it can have a very “happy” feeling. When I’ve asked other people what they think the music should sound like, they’ve mostly all agreed that the music should be calm and create a light atmosphere, rather than being too dark or energetic. Some of the examples in the first video Traditional Japanese Music 2 sound very serious, but Flower definitely shows a more relaxed and carefree musical experience.
“Momoiro” Finishing Touches

Today has been pretty similar to yesterday. The first level Momoiro is now looking pretty finished, from now until the end of the project I’ll probably just be tweaking little bits rather than making huge changes. In the screenshot above you can see the second cave part of the level, which probably has way too many lights! So there’s something that could do with some rearranging.

Here’s a screenshot from another part of the level, which leads down to the cafe. I was previously trying to play around with things I could do with the red brick tiles and some of the shadowy overlay tiles, but in the end I’ve decided to try and keep things simple.


The part of the level which has been changed the most today is the cafe itself. To set this apart from other buildings, I’ve added outdoor table arrangements and a unique flag which reads カフエ “cafe” in katakana. I’ve also added a new table light, which shines a small circular light which at the moment is the same colour as the hanging lights. It might be a little too bright at the moment, so I might dim this later. Also, I’m trying to work out how to create a flickering effect to make it seem like candle light, but I’m not currently sure how to do this with the EasyLighting system.
Other than that, there’s not much more to do, except for adding the extra characters and working on the background imagery. I’m still happy with the silhouette at the top of the level, but the rest of the level looks very dull without anything in the background. I’ve also got to add the trees back in before I forget!
Some of the characters are more developed than others. This afternoon I started working on Kaze, a resident of Momoiro who wears a face mask and scarf due to his cold. I’ve given him a walking and climbing animation so that he can manoeuvre around his home, but haven’t programmed any movement in the engine yet.
Getting Ahead of Myself?
It turns out I jumped the gun a little last week as I was advised to “finish the first level to move on…” I checked back to my time plan this morning and my goal for this week was to add UI elements like the HUD and inventory menus. These are now well under way, so I feel like I’m doing well for time, although I know in my head that this can only mean I’ve omitted to do something a long the way. Obviously, graphics are still a working progress. The reason I wanted to start placing UI elements now is because I felt the natural graphical style would be evident enough to start expanding from background assets to the other areas, like the UI, title menus etc which will start to take form over the next couple of weeks. Right now, I’m still filling out my days with level refinement and perfecting areas which have been left overlooked for a while. So that I can’t miss A SINGLE THING, I’ve started at the beginning of the level and worked my way, changing and improving on specific things as I’ve gone along.

In a lot of places, parts of the level simply needed filling out slightly. You can see some improvements to the graphics here where I’ve added little plants and bushes and filled out large plain areas with small rock details etc, so that every part of the level has a unique combination of my existing tiles and assets. What may of may not be noticeable from this image is some adjustments to the lighting which I’ve made. I’ve expanded the sprite I use for these lights so that it covers a larger area and isn’t so concentrated on a small space, which brightens up the level significantly and adds more light variation across the level.

One major addition to the tileset has been these grassy edge tiles, which droop over the edges of platforms and just round them off nicely. They make everything seem a lot more finished, and eliminate a lot of the very hard, straight edges that were causing problems before.

Another significant change has been to the lighting system inside caves. I’ve made the ambient light nearly black, which almost makes the background invisible, except where there are lights. I’ve made these lights much brighter than the outside lights as they are significantly more essential more gameplay. I think this change make the level more interesting visually as well as in terms of how the player plays the game. Instead of looking at an entire surrounding area, the player is constrained to one small space. In this image, you can also see some improvements I’ve made to the Hanging Adversary sprite, which is now finished and working very nicely.

When it came to animating the Hello Mushroom sprite, I admittedly got a little stuck. My original design didn’t give me much space to work with, and I felt like I could only accomplish very minimal movement. This would have been fine, except my other obstacles are now much more active in comparison! So, I redesigned the shape of the mushroom to be more flexible. This new mushroom still releases spores in exactly the same way as the old design, but this one now dances about a bit. The smaller mushrooms are harmless and (I think) create a nice little piece of scenery, but warn when there is a nasty mushroom around!
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.































