I’ve been working on some new promotional art because frankly, I want something that represents the game other than pixel art. While pixel art has its benefits, like being very easy to edit and achieve great accuracy, it’s also very restrictive. This new image started off as a fineliner drawing which I scanned with the contrast setting up really high, and ultimately I’m not 100% happy with the way the line art has turned out. But this can be very easily fixed, I’ve just got to work out how! Please let me know if you-mr/mrs/miss reader-have any tips!
For now I’ve blocked in some really simply colour and added some dodgy Photoshop effects, despite the fact that I hate overusing these. In this case it doesn’t seem so bad though. I felt that the drop shadow was totally necessary to add some depth to the image.
I’ve also gone on to use this as part of my first box-art concept, “wrapping up” the game’s physical designs. I discovered an online company called weEco” that make lovely eco-friendly media packaging. One of their products is called the WowWallet with Die Cut Window, which is a cardboard sleeve with a window on the front which allows you to see the inlay, and a slot for a disc in the back panel. I really liked this idea, as it promotes the inlay as well as the CD itself. As I’ve put a lot of emphasis on the important of the game manual for Hanami, I decided it would be appropriate to use the inlay cover as box art in a similar way. Actually, I would use the back of the manual, which would be the same as the front minus the line that says “instruction manual”! So, from the front you would see something like this- a cardboard case with a window to the inlay inside:
The inside would consist of another window, allowing the user to see the front of the game manual. On the opposite side is a slot for the disc. My initial idea for the CD art is to use my new promo art. This stands out really well in contrast to all the other dark colours.
Compact Disc Digital Mock Up:
Inner Sleeve Digital Mock Up:
As for stock, I think a thick, matte black cardboard would work really nicely for the outer sleeve. The inlay would probably similar to any CD inlay, the kind of paper that your fingerprints show on too easily 😛 For now this is staying in its conceptual stage, I’m not planning to print anything for a good while…
This GDD began life as a humble OpenOffice Writer document, and has been abused constantly throughout the project. As a reward for all the help it’s been to me I’ve given the whole thing a makeover and transformed it into this hybrid Game Design Document/Post Game Documentation. The new document groups together the initial plans for the game with a look back on how everything turned out, so it’s been pretty interesting to make. It pretty much summarises everything on this blog!
You may or may not have picked up on the fact that my amended timeplan jumps from week 15 to week 17. Unfortunately the dates are right, so I haven’t gained any time. It’s all just typos. They told me I would need basic maths to survive in the real world…
Luckily it seems, the deadline for the project is NOT the 9th of May like expected but some time around the 15th, giving me a hugely important extra few days than expected. I won’t write another new timeplan to accommodate for this extra time, instead it will just be an extension of my last week. The plan for this week is to “wrap up any physical designs”. As it happens, the manual is incredibly near completion so I’m going to start work on casing design and potentially some further and more refined character designs that could be classed as “promotional art.” There are just a few minor tweaks that may have to be made before finalising the manual, and I’ll probably wait until the end of the project to make any changes, just in case. Here is the manual as it stands:
This slideshow requires JavaScript.
I’ve now started work on a designed version of the original Game Design Document, so I will be revealing this to the world for the first time very soon (like tomorrow.) Other than everything I’ve listed already, I’ve spent a bit of time sitting down and thinking “right, what else does the game need?” I still haven’t finished the ending, so that will be the first and most essential game element to work on. Other than that, here’s a list of some other things I’ve thought of:
1. “Flower Give”
I’ve implemented this flower give system where talking to NPCs places petals in your inventory. So far, I haven’t figured out a way to only place the flower after a “flower give” animation has played, so it actually looks like the character is giving you a petal. This is the least polished part of the game so far, and while it works, it seems to me like a half-assed attempt.
2. “Shadow” NPCs
Hanami is all about a group of people inflicted by a sort of “curse”, however the only other characters in the game at the moment are those who haven’t been affected. I’ve explained this so far as “those who are affected have drifted off to another realm…” or some such excuse, but if I have time I think it would be nice to place semi-transparent silhouette people around the levels, representing the people who have been taken away. They will probably be seen sleeping or standing around saying “help!” or something. If I try this and it makes sense, then I’m putting it in.
3. New Game Plus
I’ve recently finished playing Fez (I went on about this game ALOT at the beginning of the project. It FINALLY came out last weekend) and the game bears some uncanny similarities to Hanami. This was probably my subconscious copying ideas that I thought were good, although I couldn’t have known everything before the game came out! In Fez you must collect a certain amount of cube pieces to complete the game. You can easily finish the game without finding every single collectable item, but once you’ve finished it the first time you can start the game again with all your progress saved from your first playthrough. This is nothing new to the world of gaming. The first “New Game Plus” I encountered was in Chrono Trigger, which came out in 1995. But I thought it would be nice to do something similar at the end of Hanami. You only need 60 blossoms out of a possible 90 to complete the game, so why not let the player go back and try to get the ones they’ve missed? Acquiring all 90 blossoms can result in an alternative ending. I assume Fez does this too, but I wouldn’t know as I haven’t got there yet…
I’ve started off designing the manual with the front cover, because it seemed like a good place to start. I wanted this to be similar to the opening screen of the game, so I started off by making a higher resolution version of the game’s logo. I tested out various ways that I could make the Hanko stamp in Illustrator, using various line styles and shapes.
Hanko stamps seem to come mainly in either square, circle or oval, although on some sites I’ve found rectangular ones. The problem with using Hiragana instead of the more appropriate Kanji is that it needs some sort of alignment to make sense, otherwise I would rearrange the letters to make a formation that best fit any of these shapes! For this reason, I felt that a rectangle would be best. I tested each shape out with the title, and definitely felt that rectangle suited best.
To accompany the logo, I’ve also been working on a background image for the pages of the manual. This pattern is based on the auspicious cloud patterns I researched earlier for cloud design. I used the pen tool in illustrator to create this outline first:
I’ve then adapted this in Photoshop. I’ve created two variations- one for the cover and a more subtle version to be used on the other pages of the manual. The more subtle variation uses a white version of this outline with a very pale purple background. This is the same colour as the menus and the title screen in the game.
The version I’ve made for the front cover is slightly more elaborate. I’ve used darker colours to closely resemble the game’s title screen, and I’ve merged the line colour with the background colour. I originally planned to place the logo in the first third of the grid, but after a little rearranging and testing I realised it actually had much more impact in the centre. I don’t want to add anything more to the cover now, so it makes sense to sit in the centre of the page.
I’ve started filling in the first few pages of the manual, but haven’t finished any single page yet. The contents page is looking the most finished right now, as there wasn’t much to put in it in the first place! I’m working on little bits like the number tabs on the side of the page which resemble the style of the game’s GUI to keep the document consistent with the game.
One addition I’ve made since I wrote up the original contents is a “travel guide” in the back, which contains a table of Hiragana and a few Japanese phrases that the player can look out for in the game, although not everything will be included. If the player really wanted to, they could use the Hiragana table and run the romaji through a translator to see what comes up. This could turn up some pretty good results. As a test, I ran one of the phrases I’ve used through Google Translate and ended up with this:
I have it under good authority that the phrase I typed, “onaka ga suite imasen”, means “I am not hungry”, although obviously this doesn’t translate well literally!
I’m going to plan the game’s instruction manual as though it were going to be printed and physically distributed, although at the moment it seems most likely that the game won’t have a physical form for a while. The finished result of this project will probably be a beta version at best, as I would quite like to carry on refining and changing things after the May deadline. Still, there’s no reason why a digitally distributed version of the game can’t come with a PDF version of the instruction manual.
Initial Idea
The shape and size of the document will be a square measuring 120×120 mm. Why? Firstly, because there are not such things as cubes and secondly, because this is the size and shape of a CD inlay. While PC games tend to come in DVD sized cases, my personal opinion is that this wastes a lot of space/plastic/paper/everything. And they take up a lot more room than CDs, honestly I’m not sure why the cases have to be so big. In my opinion, Sony have always managed to make good use of casing space. Playstation 1 games for example came in what were essentially bulked up CD cases, also with 120x120mm inlays. And you could pack a lot into those inlays. I seem to remember the Tekken 3 inlay coming in about 5 languages and was almost as thick as the case itself.
Playsation 2 games were the size of DVD cases, but had space above the disk to store your PS2 memory card. Playstation 3 cases are less tall than DVD cases and waste considerably less material by simply chopping the top off. Compact is good. Ultimately, as I’m a fan of nice eco stuff, I would like to design a cardboard sleeve for the game rather than a plastic case. I recently discovered a limited edition version of a Stemage’s latest album on Bandcamp, which comes in an “eco-wallet” with bunch of other paper goodies. There’s something seemingly special about getting a disk in a cardboard case, if the stock is nice. They make plastic cases seem like tack.
Limited Edition Zero Over Zero by Stemage
Initial Design
When I design for print, I like to start by setting up a grid in InDesign which I can use a template for design. I set up the new document like this (I add grids and guide later…):
I’ve chosen to use a 3×3 grid for this document. I tend to use odd numbers of rows and columns when I need to centre a lot of the content. Based on some of the content I’ve already made for the game, such as the intro slides, I’d say this is going to be fairly important. I want to try to continue the style where possible. On my master pages, I’ve also marked the centre of the page, and where each quarter of the page sits. I’ve also marked three elements that will exist on most pages- title, running title and page number. To plan other content, I’ve printed this template to draw over:
I’ve planned the first couple of pages as an example of planning from here on… The first page is the front cover, which will include the game’s logo (which I’ve decided will also run vertically as opposed to horizontally across the page), and a subtitle which will read something like “instruction manual”, also running vertically.
The second page is a double page spread. On the first side I’ll put some game info and the game’s system requirements (which I’m currently in the process of working out) and the second page will be a table of contents. I’m marked on this design where the title, running titles and page numbers will be. I’ve kept all of this at the top of the page, to reduce clutter or odd little bits elsewhere.
Back in InDesign, this currently looks like this (using placeholder text). I’m not sure yet whether to move the running titles into the centre rather than on the edges, but I’ll work this out when there’ more content in the document.
From here I’ve been able to work out paragraph styles for the titles, running titles, page numbers and body, which should be pretty much everything covered. All copy throughout the document will use Dejavu Sans ExtaLight, unless it’s part of an image or under some other special circumstance. Titles are in point size 12, as the page size itself is very small. I did a print text using a larger point size and it seems anything larger just dominates the page!
There are a few things you must always remember when designing for print, which I’ve reminded myself of in my notebook just in case. All images must be in CMYK at 300 dpi, which I know I’m going to forget at some point as I’ve been designing graphics for screen for so long now! Background and large images have to take into account the document’s 3mm bleed. All text must align to the baseline grid (which I haven’t shown, but I’ve set this up to the leading size of the body text.) And the grid is king.
I’ve been busy making sure all my NPCs work well now that they can speak and things. I’ve added a new sprite animation for my frantically running panda character, so that he will actually stop and talk when the player chooses to interact with him, instead of continuing to run about. I’ve tried to make it look like he’s breathing heavily from all the running!
After the conversation is over, he continues running about. I’ve also placed Ji-sama into the first level, who is one of the two characters in this level who don’t give away any petals and are actually pretty pointless. If you happen to understand Japanese, he actually asks the question “have you found 5 petals?”
The final character I’ve placed in level one is a character called Renaldo. I originally based this character on Tsukimi from 51 Japanese Characters. Tsukimi is the act of moon watching– “tsuki” means moon and “mi” means watch. When it came to think up an original name for the character, I decided his name should be an homage to Renaldo Moon from Ghibli’s The Cat Returns (simply because his name has “moon” in it!). I recently decided that because Renaldo isn’t a particularly Japanese name, this character should be another English speaking character, who has also been thrown into this strange world and is just as confused. Renaldo however isn’t much of a man of action, and would rather watch and wait instead of rise against the strange problems occurring. I’ve placed him near the end of the first level, where the landscape is elevated and he can get a good view of what’s going on around him. Before you approach this character, he faces away, passively watching the world…
When you come within a certain distance of him, he will turn around. I’ve used the same font I’ve used for the menu when he speaks, so that he actually speaks in English, although he’s pretty useless in the end. The # symbol in strings of text represent a drop in the line, to make sure all the text fits neatly into the text box:
While Renaldo faces forwards, I’ve animated him to have a little smoke while he casually stands and watches. He’s just that cool.
I’ve been writing each character’s lines in an OpenOffice Writer document and pasting them into Game Maker as this way its easier to see what the text looks like in its proper Japanese form! And I can keep track of the English and Japanese romaji versions of what each character is saying, here’s a glimpse of the “script” so far… Please forgive typos and formatting errors as I put this together pretty quickly and well, you’re reading my Blog so you probably know how useless I am at typing and more importantly checking what I’ve written!
I’ve been pretty unhappy with my old dialogue system for a while for two main reasons. The first is that it didn’t actually work very well. The best I could manage was a square to appear as the player passed by a non-playable character which contained the character’s “dialogue”, as I didn’t manage to figure out how to stop the player so that a proper dialogue situation could be initiated. The second reason I wasn’t happy with the system was that it was potentially detrimental to the game itself because it was fairly resource heavy.
The idea was to use a system where the player could get the gist of what NPCs had to say, but without the NPC using words. The reason for this is for the player to get the feel of language barriers faced by people in foreign countries. You can talk all you want, but it’s mostly gestures that will allow communication between two languages. This is why I had decided to use images instead of strings of text. A similar but less vague system is used in Machinarium. In this game developed by a Czech team, images and short move clips are used in speech/thought bubbles to depict dialogue. I’d imagine this was one of the keys to the game’s success abroad, because a minimal amount of translation would have been involved to export the game!
To make a system like this in game maker requires a lot of resources. I’d already made two simple “text box” objects that could be used universally throughout, but the content would have to unique for every instance. This requires a different sprite for each talking character, and some with several sub-images if the images scroll or are animated. This also takes a lot of my time as I was drawing new images for every time a character spoke! So I’d already decided that I would change the way this works, in the interest of my time and the performance and size of the game!
To help me really refine the system and create something that actually worked well, I went to the Game Maker Community forums and found a downloadable example similar to the one in this video.
The basics for a decent system are all here, including stopping the character when dialogue is initiated, scrolling text that progresses as if the character is talking and NPC interactions. I managed to adapt the code to create a very similar yet customised system so that when the player chooses to interact with a character, dialogue is initiated inside a text box and the player must sit through everything the character has to say before they can move on. I tested the system with a basic white text box and black text to make sure it ran smoothly.
The first thing I did after checking everything through was create a new larger text box sprite to replace the abominable white square I had made. I’ve made sure the box keeps the themes of the GUI and to make it similar to the previous text box, however I’ve flipped it over so that it always sits below the character who is talking. This way, it shouldn’t ever cover up anything important on the screen.
The next thing to change was the language. I figured instead of presenting the player with decipherable images, it would be even more convoluted to present them with a written language that they couldn’t understand. This is the real deal, as if they were really in a foreign country where everything that the people said was simply a jumble of sounds (or in this case letters!) The first complication with trying to achieve this is that it’s not easy to display the Japanese alphabet(s) in Game Maker. Although Windows comes equipped with fonts designed for displaying Japanese characters, Game Maker doesn’t seem to recognise the characters as letters. In the editor, the “unknown” box appears as a substitute, which is translated in the game as a series of question marks…
So I’ve had to think of a clever way around this. Instead of using the Japanese character glyphs from romanised typefaces, I’ve found this font which displays roman letters as Japanese characters. It’s actually a replica of the typeface used in the original GameBoy versions of the Pokemon games, which comes with English, katakana and hiragana versions. Unfortunately the letters don’t seem to be in any logical order, so I’ve had to spend some time working out which qwerty key results in which Hiragana character! For example:
& = は “ha”
% = な “na”
0 = み “mi”
So if I wanted to write “Hanami is Great”, I would do so like this:
English: Hanami is great Japanese Romaji: hanami wa sugoi desu Japanese Hiragana: はなみはすごいです PokeFont: &%0 & 5c* d5
I’ve written some VERY basic lines of dialogue for each character, which I’m pretty confident in translating without too much worry. With the system I’m using, each character can have three lines of dialogue which are scrolled through by pressing X on the keyboard or A on the controller. The strings for the first character are written like this:
But in-game, they appear like this:
This is Bura-san saying hello! I will still need some indicators of the objectives of the game somewhere, however I’m considering using things like sign-posts instead of direction from non-playable characters. As I’ve mentioned before, in the first conversation with Bura-san the Zashiki Warashi character is also introduced. This currently involves the screen being covered with an overlay of the large Za-chan image I made before, so the game being set fairly well from the beginning now.
By the way “wakarimasen” means “I don’t understand”, which I thought would be an appropriate blog title 😛
Again, apologies for the offensive way that I try to represent a similarity to kanji… Here I’ve tried to write “Week 15: Nihongo ga dekimasu”, which roughly translates as “I speak Japanese”, which above all else is a lie, although the little bits that I do know have been pretty useful today!
One of the things I realised probably should have been given more attention in the new time plan is a main menu for the game. I realised that before I could really go on to start preparing for physical designs, I had to give the game a real identity, and this is normally seen for the first time in the game’s opening screen/main menu (where there isn’t a physical casing involved!). A while ago I started out planning ideas for the game’s logo, mainly working out typographical layout solutions to combine a simple title with a small hiragana subtitle. So far I’ve been using the typeface Dejavu Sans for pretty much EVERYTHING, from use on this blog and in my devlog videos to in-game typography (although this becomes very distorted with the anti-aliasing off). I picked the font out a while ago for the Pecha Kucha because it was clear and clean, which made it great for the presentation. I felt that it set a neat tone for the game, as I was hoping to avoid creating messy graphics, and it suits contemporary Japanese “Zen minimalism”. So I’ve rolled with the font until now, and I was also planning to use it for the game’s logo, although I did stray a little into wandering what other typefaces would look and feel like…
The one that I felt worked best was probably the first design I made where the hiragana sits on top of the title, although I wasn’t really sure about the placement of any sort of logo or icon like the sakura blossom in the dot of the i.
The other typographical ideas I had were based more on traditional Japanese writing styles. The logo for the Wii game Okami does this very well using traditional black, white and red, where the red is also a representation of the Japanese flag (if only I’d got there first…)
You’ll also notice the little red mark at the end of the text. As far as I’m aware, this is a Japanese Hanko, which is like an official stamp used as a signature in Japan. Where there is handwriting in traditional Japanese texts, you will often see a little red stamp below it to mark who wrote it. The ink used to write was traditionally black, which is why the colour scheme seems so Japanese! I felt as though I should change the Hiragana in my logo to red, and started to experiment with brush-written typefaces to compare the effectiveness in context.
The problem with introducing this style here however is that the rest of the game would be very inconsistent, and I don’t like to use more typefaces than necessary in any one project. I started to like the hand-written look of the title, but decided that I couldn’t really use the same font for the menu’s options without changing fonts throughout the rest of the game. I feel like the hand-painted style typography is more appropriate to the game than the contemporary Dejavu sans, but should be restricted to the main title and not body copy. I found another typeface called Paul’s Kanji which I felt suited the game and had a very hand-written look, so I started to experiment with some new layouts using this font. Without adapting the typeface, the logo started looking more like this:
However, I’ve adapted it slightly for legibility and to keep it simple:
I also tried this font out written vertically, as traditionally Japanese test was often written in columns:
I haven’t managed to find a similar style font for the Japanese Hiragana subtitle here yet, but I may work on drawing over this myself to keep the style going. I will either make it appear in brush strokes or in the style of a Hanko. For in game uses, I’ve created a pixel version of this logo to keep the retro themes running throughout. For the main menu screen, I’ve used a silhouette of one of my Sakura tree designs to emulate a Japanese inked painting and used the vertical style logo at one side. The image below isn’t the finished title screen, but starts to set the basis for the game’s identity which can be applied elsewhere. The spotlight-style circle shape is taken from the still images I have been drawing for the game’s introduction, and I’m planning to use a similar effect where large still images are concerned throughout the game.
When placed in the game, the “main menu” will appear in front of the tree beside the logo, giving the player the options to start, load or quit the game. For the rest of this week I want to finish this and the rest of the game’s introduction slideshow, and from here continue to use the game’s emerging identity for other game elements and physical designs. As the Font River site suggests, I would like to thank Paul for his great work.
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.
This morning I put the lock and key system in place in level 4, so that the final Boss stage can only be accessed when enough blossoms have been found. I was originally going to suggest 80 as a possible amount of blossoms needed for the second door to open (only 10 blossoms not discovered throughout all three levels…) But after a little volunteer play-testing I’ve decided to reduce this to 60. The player only needs to collect 45 blossoms to advance to the last stage, so my participants ended up with between 50 and 60 blossoms in their inventory by the time they got this far. That leaves thirty undiscovered blossoms throughout the game, which I will probably allow the player to collect later.
If the player doesn’t have a total of 60 blossoms, they will be confronted with this when they enter the house in level 4:
In this instance, they will have to go backwards through the game and try to collect more! All the doors that the player has previously opened will remain opened indefinitely, so the player can travel backwards and forwards through the levels as much as they like at this stage. If they have managed to collect 60 blossoms, the door will be open:
The player can then go into the next room and grab the key, which then appears at the top of the screen in the same way as the sushi and other collectable items. As I don’t have a space for it in the inventory (yet…) the key is visible just above the inventory to assure the player that they are carrying it!
In order for the key to work, I’ve created two new states which describe whether or not the player has acquired the key. To begin with, global.key is set to false, meaning that the back door will not open. When the player collides with the key object and presses the X button, the object is added to the itemList DS list and global.key is set to true, so as long as the key is part of the itemList datastructure global.key will always remain true. If the player presses X when near the lock object, this will deactivate the object and activate another new state, global.door. This draws an open door sprite over the top of the closed door tile, and allows the player passage.
Other than this, I’ve spent most of my day today tidying up messy pieces of code. The play-testing revealed to me a couple of things that were eventually quite detrimental to the performance of the game when played from beginning to end! For instance, I’ve realised how important it is to place lines of code in the right event. Most of my objects consist of at least two events, create and step. Code placed in the create event is called once, and consists of things like speed settings which are consistent while the instance exists. Code placed in the step event is called every “step”, which basically equates to frames per second. Hanami runs at 60 FPS, so each step event is called 60 times a second, and can reduce the FPS if overloaded! I’ve spent a lot of time shuffling code around so that all functions are called properly, and I seem to get a consistent 60 FPS, but I won’t be sure until I have another play-through in debug.
I’ve also been trying to remedy my screen view to account for varying monitor shapes and sizes, as I’ve now started running the game on other computers and notice some significant differences, mainly where GUI such as the HUD and inventory are involved. I’ve discovered that there is a built-in Game Maker function which can determine the display size it is playing on, but after a while of trying to apply this I haven’t had much luck in getting anything that runs as smoothly as it currently does now. So I may try to find another way around this.
Lastly, I’ve created a second new Sakura Tree object to replace one of my older designs. I’ve placed this very sparsely through the levels, as a rarity and a treat. It looks a lot nicer in smaller doses, so I’ve left the main tree background to my Bonsai and Bamboo objects.
