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.

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!

Weekend Update #3

Some More Character Designs subject to change and/or disposal

These characters are complete rip-offs of a few of the characters from 51 Japanese Characters, so are subject to name and feature changes in the future to avoid being a total copy-cat. While most of the inhabitants of the places in Hanami are effected by the so-called Hanami Crisis, I’ve picked out a few personality types who could have avoided the crisis in various ways. These characters will play very minor roles in the game, they will appear at most once per level, and simply hand over a blossom they have found, or something similar. Everyone’s doing their bit to help!
Left Character: avoided the crisis because he is a monk. Protected by spiritual powers etc.
Middle Character: avoided the crisis because he was stuck inside a Panda costume.
Right Character: avoided the crisis because he fell asleep under a table in a cafe. Details on the “crisis” are still a little vague, so I don’t know how this would have helped him, but it did. Kirainet, the predecessor to A Geek In Japan, has dedicated plenty of its Blog-space to photos of people sleeping everywhere and everywhere in Japan, it seems perfectly acceptable to just fall asleep where ever you’re standing.

I’ll be converting these characters to pixel form soon!

Character Animations
I’ve been plodding along with walking animations for the last week, but found I was taking leaps and bounds this weekend! I scanned through as many TIGsource Forum threads as I could a couple of evenings ago to find good examples of walking cycles that were a similar size and shape to my character sprites. Ultimately, I could only find things vaguely similar enough to help, but while this didn’t provide a pure reference, I was glad to see that I was on to something original. My current cycle too has a few frames which are similar to others I found, but I had to tween using my own initiative for most of the process. Here is my current Hana sprite:

I gave it a go applying this same animation to Za-chan, although it wasn’t always clear how to go because she wears a long dress and you can’t see most of her legs! I will probably tweak this if I have to use it in the game. At the moment, it’s more of a practice in applying one animation to varying sprites:

For the rest of my character animations, I will hopefully be roping in some volunteers to perform for me so that I have photo-references of people doing various actions. Finding examples of various walk-cycles wasn’t necessarily a difficult task, but unfortunately I’m going to need more than that…

Level Design
I’m currently still set on using the Kanji basis for my level design. Over the weekend I just had to grab a pen and piece of paper and get down all my thoughts on the level, what it should consist of and how it should look. It’s slightly more decipherable than previous attempts, although some of the designs cross-over quite confusingly! I tried to draw out the entire level in the bottom half of the page:

According to Peter McClory’s level design technique, the next step would be to draw this out to scale on squared paper. However, I decided to use Photoshop instead, so that the level was easier to edit! Once it’s done I’ll print and trace it as if it were drawn on squared paper. The design currently lacks detail and is not finished, but it’s given my a huge insight into the scaling of the level, which in places in completely different to how I imagined it. Here is a rough idea of the level so far:

My Plan for the rest of the week now is definitely to get this mocked up and playable in Game Maker, possibly before tracing in the details. I still haven’t settled for any particular character physics within the Grandma Engine, so I will have to make sure that the character feels natural to handle whilst working their way around this specific level. Once the layout is finalised, I’ll fill in some detail, but this is a secondary objective to getting a playable level right now.

Some thoughts on sound…
I started to play around with a piece of music creation software called PXTone. It’s a development from Daisuke Amaya, creator of Cave Story, and it sounds as though he uses this himself to make the music for his games. It’s default instruments are all very synthy, but you can combine classic chip-tune instruments with midi-sounding instruments to create something generally retro sounding, yet something original. There are a vast amount of starting instruments, which makes this program easier to get started with than other chiptune software I’ve previously used where you must create your own instruments :S So far I’ve just had a play around to see if it would be appropriate for this project, although I’m still not sure what my music source will be yet. Original music would be a huge bonus, so this is definitely on the list.

Character Sprites: Hana & “Za-Chan”

This morning I set myself a goal to finish two sprites for the two game characters I have so far, which initially seemed like an easy task but has consumed most of my day so far. I’ve learned in the past that a good way to create a pixel-art sprite is to draw it by hand first, scan the image and reduce it in size. This blur of pixels normally roughly shapes out a sprite, which can be traced with something like the pencil tool in Photoshop and transformed into some semblance of order. If you try to use this method for a sprite measuring only 16 pixels in height, you kind of end up with a grey square. So that method was pretty much out of the question! Time to rethink.
As a cheeky starting point, I figured I could see what works well by creating a Hana character in the style of existing games. I chose four really different sprites, which have similar measurements but use really different styles.

Top left: Gomez from Fez
Top right: Quote from Cave Story
Bottom left: something from Rogueline (I don’t know much about this game but the art looks really great. Check it out!)
Bottom right: NPC from The Archer
Right: Sylva from Somnium! This was my own project, which acted as my introduction to the world of game design. Obviously, the sprite is double the size of the other examples, I just though I’d throw it in there for fun.

Hana in each of these games:

Surprisingly, I quite like the fat-girl Hana based on my previous character sprite from Somnium, and tried reducing this in size to see if it could work:

My second favourite had to be the Gomez clone, as it resembled the style I used in my original concept art cartoons. The style I chose to draw in was simply a quick way to get a good impression of a character, however the star-shaped figures seem to translate well into the pixel world. I tried to conceptualise what this style would look like in a small, simplified way which I could use to create an original character sprite!

The two characters I currently have are the main character Hana and the antagonist Zashiki-warashi, which I have abbreviated to Za-chan for now until I properly name her! The sprite designs are based on my original drawings, and things I like about my Fez and Somnium character clones. Here is my pixel interpretation of the two:

Both a prone to refinement over the next few days, as I try to animate them etc. Also, if they resemble sprites from other games too much I will have to re-think the design completely.

Yesterday, I added a little bio for Za-chan* to the GDD, which explains a lot about her past and her motives for causing mischief. It’s a little long-winded, but the story is starting to come together at least:

Za-chan chose residence in a large house in the late fifties, and decided to stay permanently due to the welcome of the family and the space and qualities of the old house. The family consisted of a married couple and twin girls, who she frequently played with when they returned from school. Za-chan felt like she was part of the family, and almost forgot her naturally mischievous nature. While Za-chan was around, the family received a hefty income, the ageing house remained in good condition and Sakura always bloomed for long periods in their garden. The parents made a Za-chan kokeshi doll as a gift for their daughters, and a thankyou to the spirit for the bringing of fortune. However, as the girls grew up they forgot their friend and often stayed away from the house for long periods of time while Za-chan started to feel increasingly lonely. One day, Za-chan decided to go outside of the house and climb a Sakura tree to see where the two girls were going. As soon as she left the house, it started to creak and warp very slightly. She continued to leave the house to watch the two girls, jumping from tree to tree and every day getting slightly further away from the house. Every day, the house would start to crumble a little more. Eventually, Za-chan became angry with the girls for leaving and never went back to the house. She stayed in a Sakura tree where she could watch people and feel less lonely, and eventually picked up her mischievous ways once more by throwing things at passers by. Her old house fell to disrepair, and the family moved away. They boarded up the house, leaving the kokeshi doll inside as they considered it a sign of bad luck.
Eventually, bored of annoying pedestrians, and ultimately more lonely than ever, Za-chan conjured up her most mischievous act yet. She burrowed into her Sakura tree and spread her consciousness out among the blossoms. As they began to fell around the crowds of people around the tree, she used the blossoms to kidnap the souls of her new “friends” and bring them to the spirit world where she could satisfy her loneliness.

*In Japan, the suffix chan is applied to the end of the name of a child, or among female friends. I’ve noticed in anime that older characters abbreviate younger characters’ names to the first syllable and add “chan”. Za-chan doesn’t have a particularly nice ring to it, but I’m working on a real name RIGHT NOW.

Tiles & Sprites

I may have been wrong in a previous post where I stated that character sprites were often double the height of a single tile in 2D games. I’ve been working out some background tile to character sprite ratios, and firstly have found that there are very few recurring ratios, and secondly that there are a lot of games which use character sprites that are exactly the same height as their background tiles.

Most interestingly is that I hadn’t noticed this yet in any of the game I’ve previously written about on this Blog. In my head, I think I assumed that character sprites needed the extra detail provided by double height.

In Fez, Gomez measures the exact same height as the background tiles (with the exception of The Fez which sits on top of this height).

Again, in The Archer the character sprite and tile height are very similar, except for hats which seem to cause the illusion of height in games!

In Jonathan Lavigne’s Ninja Senki, the character sprite is not only the same height as the background tiles but is a pretty similar width too!

And in Cave Story, the character sprite for main character Quote is the exact same height as the tiles, however the NPC character is slightly taller.

What confuses me about this selection of new(ish) games, is why they all decided to work to these proportions. From an aesthetic point of view, I think it makes everything look neat and tidy, as every aligns nicely to a consistent grid. I can imagine that from a gameplay perspective, these proportions work in the favour of the player who must calculate jump and fire distances etc. However when I looked back at old NES platformers like the original Castlevania, Contra, Ghosts ‘n’ Goblins and Metroid it seemed that traditionally, character sprites were double the size of the background tiles (actually, in the case of Contra I couldn’t decide what size the tiles actually were, so I could be wrong!)

Background tiles half the height of character sprites:

One slight exception I found amongst old NES platformers, was the original Super Mario Bros, and similarly Kirby’s Adventure. In Super Mario Bros, Mario starts the game as a half-sized sprite, which is roughly the same shape as the background tiles.

However, this reduced size is probably just a way to leave room for growth when a mushroom is eaten:

This might similarly explain Kirby’s small size in Kirby’s Adventure, as Kirby expands when swallowing an item or enemy.

In this case, it’s probably just more likely that Nintendo have tried to show how small Kirby is in comparison to the world!

Even as we move into the world of 16-bit, sprite sizes remain consistent with previous versions of games. In Super Mario Bros 3, the sprite proportions remain pretty much the same as the original. In Super Matroid for SNES, character Samus seems slightly taller than before. She does wear a helmet though, so this additional height is another one of those hat things…

So the question is “who is right??”
After reading various forums, the general consensus is that it all dimensions are entirely the choice of the designer. There is no right or wrong, or good or bad. Which leaves me at a point in development where I need to make a choice… So for now, I’m going to concentrate on creating a sprite equal to the height of my (hypothetical) tiles. This means creating a sprite which is 16 pixels in height, rather than the 32 I was expecting to be using. Personally, I think this makes the game look nicer and hopefully will make it play fluently. I will have to convert if I find it difficult to add a decent amount of detail to my sprites, or if the space limitations make it difficult to animate, although I’m feeling pretty confident and inspired by my Indie Heroes who have proven 16px sprites to be ideal!

Early Art Development

Phil Fish’s devlog for the upcoming game Fez begins with a Photoshop mock-up of his game idea, made in the exact style that the game would be made in. With my cute character in mind, I started to get some ideas of how I wanted the game to look, and the kinds of colours I wanted to use, that sort of thing. So I thought I’d do the same thing. This would also act as my introduction to making tilesets for games, which is something I’ll be doing for the first time during the development of Hanami. I drew up the sketch above to get me thinking about what sort of objects would appear in the game a lot, and tried to assemble them into a small demonstration of the look of the game. It also led me to think about scale for the first time, as games are often way out of proportion. In a screenshot of Fez, a fan pointed this out for example:

However, the strange proportions are necessary based on the size of the tiles used. I worked out that Fez uses tiles which are 8×8 pixels in size, but these are expanded by about 5x when the game is played. This gives the game its very square feel, as there is little room for small details within each tile.

Games like The Archer and Cave Story use 16×16 tiles. While these don’t have to be more detailed, the opportunity is there, so for now I’m planning to create tiles which measure 16×16 pixels. By applying tiles to the sketch, I came up with this solution, which is by no means refined or finished:

I started by applying the 16×16 grid to the image, and draw a rough outline of the shapes as they would fit into that grid. Obviously, only background imagery really has to fit the grid perfectly. Objects and game items don’t have to consist of tiles, although in this case the tree seems to stand out a lot from the rest.

I mainly tried to concentrate on the tiles for the ground, as this was a single strip of tiles which were very easy to place and repeat. The difficulty was making enough that they weren’t too repetitive! I also tried to make sure they weren’t too overcomplicated at this point. Most of the tiles could be repeated and placed anywhere, but I made special end tiles with rounded corners which would only ever be placed on the ends!

As well as seamless tiles, I tried out creating single tiles. This closed type of tile is used in all three of the example games I’ve given in this post already, and make it even easier to repeat tiles into any form. In this case, each tile has an edge and stands out on its own, rather than fitting in to a bigger pattern.

I later added in a little more detail to the grass line, and made basic block-colour tiles for the background of this image. The tree is pretty much freehand at this point, and doesn’t adhere to grid or guide. I’m not sure if this is something I want to use much for background imagery, however it seemed to work well for the clouds in the very background. This image ended up looking very bright, and in my opinion a little too bright. The colours at this point are very inspired by Fez, but only for experimental purposes!

The placeholder character silhouette fits into a 32×32 square, which is a pretty standard character measurement in classic games. In terms of proportions, this means that tiles can sit at half the character’s height, representing accessibility. Tiles which create a vertical surface equal to or above the height of the character represent inaccessible areas, without having to take up too much room on screen.

EMP Countdown 6 – 2 More Days…

Interestingly enough, over 50% of my chosen Indie heroes are Canadian. Today I’m broadening my world a little by focusing on Daisuke Amaya, the Japanese creative genius behind Cave Story.

Cave Story has been brought to the attention of the masses in the last year, gaining a make-over for the Wiiware and Steam versions of the game, and a complete conversion to 3D for the upcoming 3DS release. But years before all of this, Cave Story was a simple 2D shooter which gained appreciation from a small cult audience. It was this audience who created an English translation patch for the game, gradually spreading the phenomenon worldwide.

And this all happened way before the whole retro pixel-art movement really took off (in the Western world at least!). The chosen graphical style was an echo of the game’s genre and functions- ultimately the player is required to traverse a 2D world acquiring weapon upgrades in order to shoot and gain experience from anything in the way, very reminiscent of early Metroid games. There is a story to follow, and if the player wishes, gameplay can be quite linear. However, if the player decides to backtrack at certain times, progress can twist and turn and secrets can be revealed. It has an exploration undertone which adds a layer of enjoyability to the game.

From these you can see how Cave Story adheres to traditional development, therefore appealing to the player’s sense of nostalgia….
1. Indoor shots contain the player in a small space, surrounded by a black screen.
2. Outdoor shots show a full-screen world. Text boxes showing dialogue appear at the bottom of the screen. If a non-playable character is speaking, then quite often a character portrait would appear next to the text. Noticeable in this example: the HUD disappears while a message is displayed.
3. Powerups appear as capsules and health pickups appear as hearts. It’s just tradition. The HUD here allows the player to scroll through each weapon, and also displays weapon progress and player health stats.
4. The inventory menu allows the player to scroll through carried items and weapons, displaying information on each.

Rumour has it that Cave Story took years for Amaya to finish as he took on every production role personally. The game was then released as PC freeware, which I think is because Amaya creates for love not money. As fortune would have it, his game went to gain huge commercial success… And it’s success is probably due to its nature. It is a very traditionally made game, with all the features of a traditional side-scrolling shooter, however it surprises the player with unpredictable additions, which occur if the player chooses to play non-linearly.

Links for Daisuke “Pixel” Amaya:
Amaya’s Online Development Log
English Cave Story Fan Site
Official Japanese Cave Story Website
Cave Story+ on Steam