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.

Hanami’s Quick Guide To Sushi

As everyone knows, sushi has healing powers. Most types of sushi will restore 1 hit point when eaten.

Nigiri にぎり

An oblong shaped slab of sushi rice topped with certain types of fish or egg laid neatly over the base. Sometimes nigiri is held together with a strip or “nori” seaweed.

Maki まき

Maki refers to rolled sushi, either with an outer layer of sushi rice or wrapped in nori. The filling runs through the centre of the rice, and can consist of many things from raw fish or meat to bean curd.

Gunkan Maki ぐんかんまき

A roll of nori filled with sushi rice and usually topped with fish eggs.

Temaki てまき

Hand rolled sushi wrapped in a cone of nori, with the filling of fish or fish eggs popping out of the top!

Onigiri おにぎり
(strictly not actually sushi…)

Onigiri refers to Japanese rice balls, often shaped in triangles and wrapped in nori. I’ve included this here because like sushi, onigiri is a food that looks distinctly Japanese!

GUI Design

Based on yesterday’s speech bubble designs, I’ve spent today working out some other interface elements. Apart from the game’s main menu (and potentially a separate pause menu), there are two main GUI elements which will keep a consistent style throughout the game. One of these is the HUD (Heads Up Display), and the other is the game’s inventory.

The HUD

I was previously using a placeholder HUD which shows information about the amount of flowers collected and the player’s health. The reason I placed this here temporarily was mainly as a debug object for me to test when damage was being taken and how well the flower collection ds_list was working. In the finished game, the HUD will be a quick insight into level progress, showing the same information just in a nicer graphical style.

I’ve had a quick look into how other Indie developments have incorporated HUD systems and found that they tend to be very basic, using simple icons and in some cases text only. This example from Ninja Senki is a very clear way of displaying information which doesn’t get confused with any other element on screen.

So, simple is good. There doesn’t seem much point in clogging up the screen with pointless graphics unless they are meaningful or relevant. The HUD should be concise and to the point, so that the player can glance at it quickly and get a good impression of the information displayed.

The Legend of Zelda: A Link to the Past has a fairly complex HUD system, but enforces clarity by using unique icons and indicators rather than using text.

Key:
The Green Bar (far left) represents special ability charge levels
The Bow Icon (left) represents the secondary item equipped
The Green Gem icon represents the amount of rupees the player has
The Bomb icon represents the amount of bombs the player has
The Arrow icon represents the amount of arrows the player has
The Heart Capsules (far right) represents the player’s hit points.

This sounds complicated to explain, but each feature is added into the game gradually, allowing the player time to get to know the HUD and where to look for info. I’ve kept this in mind whilst designing my HUD object, even though mine will only display two pieces of information! Originally, I wanted to swap my HP figure for a sliding health bar, but keep the flower icon to display info on how many flowers had been collected. Giving it some thought, I’ve moved onto a health system which is more like Zelda’s heart capsules. Because Hana will only take 5 hits before “dying”, and each obstacle deals the same amount of damage, I thought it would be more appropriate to create an image which shows each individual hit point. You can see my thought progression in the sketches I did this morning…

I’ve tried to keep the window shape and style similar to that of the speech bubbles, which will now be a consistent theme throughout the GUI. I’ve added the character profile picture partly as a way of indicating “this is player health and partly because of some advice from I found in a forum about pixel art games- A 16×16 pixel character is an extremely distorted version of a character design, and showing a higher resolution image of the character somewhere in the game acts as a little player gratuity. On the right hand side of the image you can see a rough design for a menu/inventory, where I’m thinking of using an even large character image, based on my main concept art for Hana.

The size of the “high-res” head-shot is just over 32×32 pixels, twice the size of the entire original sprite. This took an unpredicted amount of time to create, because of the increased opportunities for detail in the drawing! I wasn’t originally sure what I was going to use as a representation of a hit point, but liked the idea of using something rounded. In the end, I’ve gone for a Japanese coin look!

This now sits in place of the old HUD, the only real similarity is that I’m still using a string of text to display how many flowers have been collected.

The Inventory Menu
I haven’t managed to fully design the inventory yet, but I’ve planned out everything that should go in it! Information like:

• An even higher resolution character image
• Character health
• Health restoration items collected
• Flowers Collected
• Petals Collected
• Perhaps a little info on level (at least some indication of which level the player is currently on!)

After getting to grips with the enlarged head image that I drew earlier, I thought I’d work on the full character image first! As the menu is likely to take up the majority of the screen, I’ve created this image at a height of 100 pixels (which is scaled up to 300 when displayed in the game). This is basically a pixelated version of one of my previous sketches.

To give you an indication of size relative to the game sprite and other elements, I quickly whipped up this scary little image where I placed the new drawing into the game:

Evil Botanicals

As a slight side-track to my main objectives today, I spent a little time refining and reworking some of my quickly made “enemies”.

This is the new animation I’ve come up with for the deceitful blossom. I felt that the best way to animation the flower was to give it a stalk and plant it into the ground, as this gave the blossom a base to pivot on. It looks infinitely more menacing than before, potentially raising awareness of its presences.

After seeing the flower in the game, my immediate reaction was that I wanted to jump on it to destroy it- in a Super Mario fashion. I’ve always said that I wanted obstacles to be “evade only”, but this so far has led to boring sections of gameplay and not a huge amount of variation in play strategies. So I though I would give it a go, except that by jumping on the flower the player can only temporarily squash and disable the flower- it will eventually pop back up. During the time it is “squashed”, the player can walk over it and not receive damage- otherwise damage will be taken if the player approaches the flower from the side rather than from the air.

Coding for this has been quite a challenge for me, as there are a lot of parameters to set up in regards to when the player takes damage and when the player is fine to pass by, but I’ve come up with a unique system which unfortunately cannot adhere to me previous obstacle parent object.

When the flower is in its normal state, I’ve created a variable that states that “damage” is true (damage = 1;). When the player makes contact with the flower, damage is taken. If the flower is approached from a greater y value or the flower has been jumped on, the value of “damage” changes to 0.

if damage = 1 && y>obj_player.y {
damage=0;
obj_player.vspd = S_JUMP_SPEED;
sprite_index=spr_flower_squash;

if damage = 0 {
alarm[0]=90;
}
}

The alarm sets an amount of time that damage remains at 0, before it is reset and changes back to 1. The flower will always reset after 90 steps, giving the player just enough time to occupy the same space as the obstacle. This is handy for jumps like the image above, where jumping over the flower would be impossible.

As promised, I’ve also changed the suspicious-looking sprite for the swinging spike plant object. This is not a finished version, but represents what I’m hoping to do with the new sprite. Before, I was using Game Maker’s draw function to draw a line from a connection point to the spike plant and used some maths to give the object velocity. This looked fine in my opinion, but the problem was that the collision mask remained static, no matter position of the drawn sprite. I had the option to create a custom collision mask, like I have done for the Hello Mushroom object, but id I was going to do that then I figured I might as well make my own swinging sprite. This sprite covers a similar distance to the previous sprite, but I think it may move slightly slower. Unfortunately, unless I do a whole load more tweening, the animation will never look as smooth as before, but it may fit in better with its surroundings. All issues with the collision mask are naturally fixed.

Intelligent Thoughts

To begin designs for user interface, I’ve started up the style I want for graphical elements with these speech bubble text boxes. These simple square boxes are designed to float above the character speaking or thinking, and display mainly images depending on what it is that they need to communicate. The idea is to keep dialogue to a minimum- due to the communication problems associated with foreign languages. I was mainly inspired to use speech bubbles in this way by the anime short Cat Soup, which uses a lot of visual techniques to represent dialogue.

This isn’t the first time a similar technique has been used in a game. The hand-drawn Indie game Machinarium doesn’t have a single line of dialogue, and uses images and animations in speech and though bubbles to provide the player with gameplay hints and set the story.

I was initially thinking of using a very simple square design, but at the last minute came up with the swirly square design based on the “auspicious cloud” design. The design sort of evolved as I worked out what worked best in a small space with the swirl in the corner.

In Game Maker, I can use one image as a parent object for all “dialogue”, and simply change the content of the box using a sequence of sprites which appear to be inside the box. I tested this on the pacing cat I created yesterday, making sure the box followed the cat. This was simply done with one piece of code with makes the x value of the box the same as the x value of the cat:

x=obj_maneki_neko.x;

I then incorporated a timing system to time the image in and out based on a set time, so that the cat periodically thinks about fish- as long as he pacing and not following the player.

I’ve also created another example of a very small dialogue sequence for the newly placed character-the Shinto Priest. This polite character stands outside the Ryokan and bows as the player passes by. When the player gets within a certain distance, the speech bubble appears displaying the objective and the amount of blossoms needed for progression, although I’m not sure how effective this is as a method of instructing the player in the initial level.

Artificial Intelligence?

What happened to week eight?? It was definitely there, but I must be getting lazy at making progress flowers.

This week my focus is on the little interactive bits that make videogames what they are, which includes working on menus and non-playable characters (NPCs). As part of my feedback from last week I was told to not move on to create a new level without finishing this one, and while most of the graphical elements are in place, its lacking occupants and and a real start to the game. The little photo above shows the little progress I’ve made with the new level over the weekend, although it’s much easier to draw on tracing paper in good light so I’m going to have to start putting some day-time into drawing it.

Today I began work on the first character that the player can interact with, the Maneki Neko. Ultimately, I’d like the game to begin with a short cutscene and the cat awakening Hana in a foggy dream-like state, and this may even be possible now that I have some extra animations. My plan is to look at the Spelunky source code to work out how the opening cutscene has been programmed, as I’ve had some problems working Game Maker around cutscenes in the past.

My first task was to create a walk-cycle animation for the cat, which somehow proved much easier than animating only two legs! I kept the leg length to a constant 2 pixels and tried to use as few frames as possible, as this animation won’t actually be seen much in the game at all. I used this video for reference, although only picked out the more “essential” frames.

The human walk cycle I developed uses eight frames, four for each leg forward. I ended up only using four for the cat, as it easily gives the illusion of having either foot in front of the other!

The tricky part was getting the cat to walk on his own, without player input. The game’s main character relies on the intelligence of the player to not walk into walls and avoid obstacles, but the cat would have to rely on a set of calculations in order to move around. There are several ways you can achieve this in game maker, but several that became unavailable to me because of the nature of the movement.

I wanted the cat to constantly pace from left to right, turning back on contact with a wall. I also wanted its behaviour to change when in close proximity to the player, so that it follows the player briefly. Luckily, I found an example that someone had already made that has a similar thing- except that the pacing objects are enemies which move to attack when in proximity with the player! You can have a quick look at that here. Based on the code from this example combined with the movement mechanics which came with the grandma engine, I came up with this little bit which makes the cat pace while the player is far away:

This basically sets up a timer which which turns the cat around after a certain period of time. The “counter” moves up in intervals of .25 until it has reached 60- in this time the cat will move left. After from 60 until 120 the cat will move to the right, and at 120 the counter restarts from 0. This is only while !can_see, which is while the cat “cannot see” the player.

While the cat can see the player, I’ve simply set a constant speed in the direction of the player. This speed is faster than its previous pacing speed, but not as fast as the speed of the player. As long as the player is moving, the cat will never catch up!

There are a few more lines to prevent the cat from walking through walls and an image_xscale code which turns the image around when walking left. Otherwise, this code is the cat’s brain. It’s not perfect- for example, if the player stops then the cat will just continue to walk past until it begins pacing again. I don’t think this is much of an issue for an object that only appears in the first room of the game!

Weekend Fix!

My quick play-test session on Thursday left me with quite a few things to think about. It’s been a couple of days since I last posted any progress, this is mainly due to time spent looking into new ideas and ripping the internet apart looking for decent sound effects.

Feedback and Solutions

1. “There are too many collectible items. Lower then amount of flowers needed to proceed to the next level, or players may get stuck and frustrated!”

I always intended for the levels of Hanami to be an explorable open world, meaning players must play extra attention to avoid being lost or confused. But this is a very good point. At the moment, you must collect 30 blossoms in order to progress, which is quite a lot. If a player cannot locate just one of these flowers, then they are stuck in that level forever. My solution is to keep all 30 blossoms in the level, but allow the player to progress after locating just 10 of these. In the next level it will be 15, and the third level will be 20 to increase difficulty. There will be a specified bonus for locating all 30 flowers, but this may just be something minor like a high score or alternate game ending.

2. “It’s a bit quiet…”

Yes it is, and it’s about time that it was a little louder. As I’ve mentioned, I’ve spent about four days looking through various downloadable sound effects trying to find suitable sounds. I’m pretty sure I’ve settled on a footstep sound, jump sound and running water sound so far. More info on this to follow. My issues with incorporating these sounds have been with the Supersound.dll I’m using to play .ogg format sounds, but as I’m new to using the system I think it’s just going to take some getting used to. As for background music, everyone present at the play test agreed that it should be something “gamey” but calm- and obviously something that sounds naturally Japanese.

3. “Dying is annoying”

Upon “dying”, the game is currently completely reset. This includes my datastructure list which holds information about collected flowers, so when the player runs out of health all the flowers reappear and that player must start again from the beginning. Firstly, I will create a “death animation” which gives the player time to come to terms with a limited amount of lost progress, and secondly a will create a memory system which takes the player back to a point in the game without loosing progress. One suggestion was to use a certain amount of “lives”, which are reduced when all hit-points are lost. Loosing all hit points in one life will result in loosing a small amount of progress, but loosing all lives will result in a game restart (or perhaps a level restart!) I will probably work on this when I improve my current HUD system.

4. “Where’s the end of the level? Does it ever end??”

Yes, it does. In fact, the end is of the level is reached if you walk in a straight horizontal line from the beginning of the level. Perhaps I will signpost it better, or make objectives MUCH clearer when I add NPC help and input.

5. “The graphics are really good, but they need finishing.”

Well, obviously. I’ve actually spent a chunk of this weekend filling in the level grid with rock edges, which has resulted in this:

I still need to fill in vertical walls…

6. “The lights look great and even make the retro style seem more contemporary, but the level still feels really dark.”

There are a couple of solutions to this problem. Either I can make the ambient overlay a lighter colour, or make my lights larger so that they affect the overall brightness of everything around it. The ambient overlay is probably the key to the success of the lights, so I will probably try to extend the reach of the outdoor lights.

My own personal feedback: character animations don’t overlap well…
This hit hard when I found this video demonstrating some of the character animations for a game called Trixie Treasure, which is currently in development. The animations here are so seamless and natural- I’m not even sure you could accomplish this level in Game Maker.

I especially commend the ladder climbing animation, which unlike mine, takes into account step size and arranges the character’s limbs accordingly :S

I tried to use this as a basis for a new ladder climbing animation, although My ladder steps are MUCH further apart, and making them closer together doesn’t work so well aesthetically. I could make it work better if I reduced the width as well as the step size of the ladder, but I’m not sure this is a process worth going through at this point in time. Still, I updated my animation to seem more life-like. I also want to incorporate some sort of ladder hang frame, instead of allowing the player to move left and right while climbing ladders.

Quick Fixes

Today I’ve been fixing up little bits here and there, rather than concentrating on something bigger…my intention is to clean up some of the game’s little blips before moving onto anything excitingly new. This is following on from my previous to-do list, which as the days go on gets increasingly longer…

Apply more accurate collision masks to objects

This I have done today, although most of the problems with collisions were solved by reducing the collision mask around the player object.
Previous mask:

Based on head dimensions

New mask:

Based on lower body dimensions (much thinner!)

This stopped the player from gradually sliding down corners and standing on thin air! This also means that collisions with obstacles are more accurate, as it is often the body that contacts that obstacle sprite rather than the head. I’ve increased the masks for the mushroom and swinging enemies to accommodate for this reduction, but only slightly.

Improve environmental tiles

I haven’t done much to improve the tileset, but I’ve cleaned up some of the edges by adding corner details and rotating some of my existing tiles to fit in more instances.

Make new sprites

There were just a couple of things from the end of the level that I’ve omitted to draw so far, so I figured it was probably time to put these in. Among the sprites still to create was the “end object”- the door to the next level. This stays closed until all the flowers are collected (although I haven’t coded for it opening yet as there is nowhere to go!) The idea for the new sprite came from this lonely little place, that sparked my imagination.

The orange doormat represents the colours of the next level…

As well as these items from my previous list, I started to work on some more minor details that I wanted to be ready in time to demonstrate to others. I’ve spent a lot of time working out a parallax scrolling system which affects the rate that the background imagery moves at, although this isn’t quite finished yet as it produced quite a jittery result. I’ve also added in a code to randomly generate the cloud sprites I previously drew. This works by producing a small amount of cloud sprites just outside of the player’s view, scrolling each cloud along at a set pace and deleting them once they are off the screen at the other side. The code then regenerates each sprite at the same coordinates back on the first side of the screen, resulting in an endless amount of clouds.

This seems to work fine, until you enter a cave or building and exit back into the main level. Instead of randomly generating cloud sprites at this point, they seems to align along the Y axis and scroll across together. This is probably a fault with my coding, however I haven’t figured out how to solve the issue yet…

So I’m kinda just creating more problems for myself right now! As a de-stress technique, I’ve been sketching details into my new level design, which looks a little like this right now:

Personally, I think this level looks a lot more like its original kanji than the previous design, but it’s still pretty tenuous!