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.

Natural Hazards…


This week I’m thinking about all the features I want to have in the game before handing it to others for feedback! I think in my original time-plan I wanted to base the product of this week on feedback from participants, but I’ve gone into some of the graphics in a lot more detail than I was expecting to and as a result have a few other things that need rounding off/actually making… So my goal for this week is to create a working prototype ready for testing either at the end of this week or the beginning of the next.

One of the major things which I have omitted until now is, to summarise, how to loose whilst playing Hanami. I’ve implemented a really basic health system so far, which can currently only go down, and instigate an immediate game-over is it reaches 0 (which it can’t, because I haven’t put enough hazards in yet!) This is one of the things that needs a lot of improvement this week- it especially needs something to build it back up.

I’ve mentioned possible “hazards” or “enemies” before, and I’ve sketched out a few ideas in some of my level designs. The main feature of all enemies/hazards is that they cannot be “defeated” because there is no combat in the game. They are a part of the environment, and will not actively attack but will stand as a hindrance to players. As the collectable items are based on flowers, I’ve also based my enemies on plants, creating a good/evil balance throughout the natural world! Each enemy is also based on a unique movement type, to keep them varied and keep the player actively working out how to evade them.


The first enemy type is one that I’ve been using as a health system test, and is based on the Sakura blossom object. The idea is that it lurks in shadows and looks similar enough to the real Sakura object to lure players towards it, only to hurt them if they make contact. I’ve called this one the deceitful blossom, which is currently a working title name but may stick! Its movement type is nothing, it’s the easiest enemy to avoid as it simply sits in once place.

This enemy type has a few influences from existing games, not so much in terms of visual qualities but in attack style! I’ve looked at items and enemies that disguise themselves and attack at the last second. I thought of Vileplume from Pokemon which disguises itself as a flower, and the mimic from Braid which hides under the soil with a flower under its back. In a way it reminded me of the Mario “know you mushrooms” design seen on bags & T-shirts etc. Many Mario mushrooms look similar, but have very different effects, good and bad if acquired…

The second enemy happens to be a mushroom, but nothing like a Mario mushroom unfortunately. Unlike the other enemy types, a name didn’t pop into my head straight away with this one, so it is currently called Hello Mushroom…for a number of irrelevant reasons… This enemy doesn’t move itself, but it sprays a vertical line of deadly fumes into the air at random times through one of its many sphincters, which will deduct health points if touched. Most of my house mates have a serious aversion to mushrooms and try hard to stop themselves from vomiting when I cook them, so I’ve made this one super gross to fit their opinion of them. I think mushrooms are really yummy personally.

To get the motion of spore-release, I’ve been playing around with the particle functions in Game Maker today. I found a great guideline to all the available functions in a downloadable PDF here, which literally misses nothing! But so far I really have only been messing, so I’ll write up about my proper particle experiments later!
This guy’s kind of inspired by the many monster mushrooms in video games, like Funguar from Final Fantasy VIII, the Fume Shroom from Plants vs Zombies, and of course the deadly mist emitting Black Fungus from Kingdom Hearts.

The final enemy is one that moves horizontally by swinging from ledges and cave roofs etc. I’ve called this the Hanging Adversary, mainly because it was the first enemy I came up with and I wanted to differentiate it from any other potential creations! The hazard here is really sharp leaf-type structures- I said I didn’t want to feature any cliched spike-pits, so this is my original equivalent. I’ve fashioned it after a venus fly-trap to some extent, simply because the venus fly-trap has those naturally evil-looking teeth which make for a great game enemy. I’m sure they’ve inspired many monster creators to make plants that bite.


I had to be careful that this guy didn’t end up looking too much like anything else from the gaming world, although influences can natural be seen to the Mario Piranha Plant, and similarly the Venus Flytrap from Braid which was probably based on the Mario enemy! My favourite of the carnivorous plant monsters from games has to be the Deku Baba from the Legend of Zelda series, which looks so spiky and evil even with the lowest of poly-counts!


I’ll hopefully get all of this into the game tomorrow, and adapt the health system accordingly!

“Practical Game Design”

From Practical Game Design: The Rule of Threes on Gamasutra
In the first level of any game, there are three introductory steps which the player should experience before being thrown into the game. These are demonstrated perfectly in the original Super Mario Bros for NES:


1. Introduce the Challenge as simply as possible
In Mario, the “threat” of an approaching Goomba is built up gradually. The player must learn how to avoid or defeat this enemy, and in order to learn the enemy must appear in its simplest form.

With this challenge, the designer tells the player:
“There is such a thing as a Goomba.”


2. Do it again, with a slight variation
After the first threat is defeated, another one appears but in this case, the environment is different and therefore the behaviour of the enemy is changed. The player is learning that challenges will present themselves in different ways.

With this challenge, the designer tells the player:
“The land around the Goomba can take different shapes”


3. Step 3: Do it again, with another twist
In this example, the threat is doubled, but there is more space for error. Is it a more difficult or easy challenge than before? Or is it just that it is different?

With this challenge, the designer tells the player:
“The Goomba will not always come alone.”

These challenges take place in the first 10 or so seconds of the game, but it is the only introduction that the player needs. After this is over, the game can change shape and form and the player knows to expect this and react accordingly.

I’ve taken this into account for opening of Hanami, I may even include a single room at the beginning of the game which acts as the “tutorial level” before the player is taken to the rest of the village. At the moment, I’ve taken a slightly different angle and instead of presenting the player with challenges, I’m thinking of introducing the objectives.


For example, here you the Ryokan on the left. As the player moves to the right, they are immediately met by a Cherry Blossom, which is collected as the player passes over it. The player now knows “the objective of the game is to collect cherry blossoms”. The next two blossoms involve the player climbing and jumping, so the player is now familiar with environmental change. The last blossom is a new idea. It’s a red blossom which damages the character’s health. If the player isn’t paying attention, they may be tempted to try to acquire this deceitful blossom, but here I’m trying to show the player that they should avoid it! I’m currently trying to think of more environmental hazards; spikes are so over-used in 2D games so trying to think of more realistic “enemies”!


In Game Maker, I’ve started to test level design with various character physics settings, to try to get the right jump distances etc. My wood structure tiles make great place-holder blocks for test levels! I’ve used them here to test this very basic opening level (although currently the flowers don’t do anything when they are collected. I’m still working in a modified version of the Grandma Engine and haven’t actually started an original project yet!)

The Up/Down/Left/Right Scrolling Platformer

So far I’ve been referring to terms like Platform Game and Side-scrolling Platformer in a similar way, but I’ve been thinking about how different these two terms are, and how this effects what I’m doing.

In my original Synopsis of Study, I stated that I would be making a Side-scrolling Platformer. In its most basic from, this simply refers to a game which is viewed from the side, and generally plays from left-to-right. The reason for its significance in history is due to its impact on the standard “Platform” game.

Donkey Kong is among the original and most notable Platform games. The game was played on one single screen at a time, which would only move onto the next by completion of the level. The game actually only consisted of three levels, which repeated until the player ran out of lives or reached the game’s “kill screen” which ended the game mid-level.

Super Mario Bros transported the hero of Donkey Kong into a much larger world by creating a screen which was simply a view of something much larger. Dedicated technology could process the game’s larger levels by drawing a slither at a time, as the character moved from left to right. Thus the Platformer became the Side-Scrolling Platformer.
Having a game that moved from a starting point to a finishing point meant that the game had a more obvious end, rather than simply repeating screens.


One game that astonished players with its non-linear gameplay was the original Metroid for Nintendo Entertainment System. The beginning of the game acted like a normal side-scrolling platformer, but at times would also allow the player to travel up and down.

Here you can see a cross-road where the player has the choice to continue jumping onto the platforms above, or open the door on the right and travel horizontally. The vast map made Metroid one of the first games that a player could get lost in, and part of the challenge of the game was simply to get from start to finish. I am quite ashamed to say that I’ve never finished the original Metroid, partly due to the frustration of being lost!
The vastness of the game can be seen in its map as a whole:

So can you call Metroid a side-scrolling platformer? It’s played from a side-view, but moves in four directions.

Obviously, as technology improved, games were able to draw larger levels and the ability to free-roam 2D levels became more common. A great example of this is the Gourmet Race from Kirby Superstar for SNES. Traditionally, the Kirby games have always been Side-Scrollers, with the occasional ascent and descent here and there. The Gourmet Race demonstrates the progression from side-scroller to free-roam platformer in three levels, and proves how this adds challenge to gameplay. In level one, the object is to move from left to right, but by level three, the player must make swift path choices which could help or hinder them without warning. As the level zig-zags, the player is more disoriented and the end more unpredictable. But as well as getting from start to finish in a limited time, the player must avoid obstacles and collect items, so there’s a lot to concentrate on!

I’ve played this level on Kirby Superstar now several times to work out how to start my level design for Hanami. The pace will be much slower, but in terms of objectives they are quite similar. I want to present the player with options which could end up with positive or negative or simply unpredictable results. Ultimately, the player must reach the end of the level with all items collected. So, in conclusion I don’t think the term Side-scrolling Platformer is really relevant, more of an up/down/left/right scrolling platformer really.

Edit: I found site dedicated to Video Game maps which has a great high-def map of the each of the Gourmet Race stages. You can see the third (and most complicated) stage here.

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!

What Makes A Platformer?

From David Perry on Game Cliches:

The platform action game is one of the oldest game genres, and there have been multitudes of variants on the theme. Naturally, there have been some tried-and-true design decisions over the years, and many of them have become clichés of the genre.

Do Re Mi Fantasy for SNES


1. Millions of items to collect
Usually, the item being collected is does nothing on its own, but can grant the player something special if enough are collected.

Megaman 2 for NES


Special power-up and pick-up items
Some items instantly grant the player the ability to do something extra, or will restore previously lost stats like health, ammo or lives.

Super Mario Bros for NES


Plenty of low-level NPC enemies to fight
Enemies are usually defeated by simply jumping on them, throwing something at them or using a special character skill.

Prince of Persia for SNES


Your character is very acrobatic
The playable character of a platformer must be able to reach hard to get areas by running, climbing and jumping about and being very flexible!

Sonic The Hedgehog for Sega Megadrive


There are many animals as main characters
Here the protagonist is a speedy hedgehog. Interesting.

Tombi for Playstation


Oddball storylines
In Tombi! the world is taken over by evil Pigs who have stolen an ancient amulet, and must be captured in magical purses to restore order. It’s undoubtedly a good game setting.

Abe's Oddysee for Playstation


Jumping
Obviously, platformers consist of an arrangement of platforms which in many cases are reached by jumping.

Limbo for XBLA


Climbing
Although in traditional side-scrolling platformers to objective is to travel from left to right, in order to reach you destination the path will often take you up and down.

Rayman for Atari Jaguar


Moving platforms
In Platformer games, some platforms scroll left and right or up and down for no apparent reason other than to add an extra challenge to the player. Miscalculating a move on a moving platform can result in an unwanted casualty!

Super Meat Boy for PC


A game world in a Platformer consist of levels, usually increasing in difficulty. Each level differs slightly, although the game mechanics are usually very similar.

Earthworm Jim for Sega Megadrive


Bosses
A “Boss” in a platformer is a tougher enemy, which usually makes an appearance at the end of a level. Losing to a Boss will halt progress until the Boss is defeated. The final Boss is usually the game’s main villain.

Kirby Superstar for SNES


Keeping Score
By collecting items, defeating enemies or simply reaching a destination in a certain time, the player gains points which will either grant the player a bonus or get saved on a list of high scores, which the player can later try to beat.

Braid for XBLA


Minimal Story
An example of a classic Platformer story is a Mario scenario where a damsel in distress is kidnapped and must be rescued by the protagonist. The game represents the journey the hero must face in order to save his love. Interestingly, this reference in Braid does not fully represent this scenario, as Braid has a reputation for its especially convoluted back-story!

So yes, we do have game clichés. Like all entertainment media, games have developed some clichés — situations and actions that are recognizable or that lead to predictable results and other predictable stereotypes.
Although clichés are useful because they allow players to operate within a familiar environment and they allow game designers to assume certain elements of a game and predict some of the responses of the players, they can also be an opportunity to throw some surprises into the mix…

Synopsis of Study- What I’m Doing And Why I’m Doing It

My learning agreement is nearly complete! The main bulk of the learning agreement consists of the Synopsis of Study, which briefly outlines what I’m doing in as much detail as you can fit into a brief statement. It’s helped me clarify some things which have either gone unmentioned or were simply missing- so here’s an informal breakdown.

Character Sprite concept & inspiration from Adventure Time with Finn & Jake: Memory of a Memory. It's nearly relevant.


What I’m doing
The plan is to create a contemporary 2D side-scrolling platform game. This is a very traditional genre, born from the limitations of early game design. My aim is to use the typical characteristics of this style of game to create something new and fun to old-school players who are familiar with the genre. The object of the game is to collect items and progress through levels, which is pretty much the objective of any 2D platformer if you think about it! Platformers usually follow a simple narrative which explains why the character is running from left to right picking up , and my plot is about revolves around the Japanese tradition of Hanami (for me details see the rest of the Blog).

Mario runs from left to right to collect coins and progresses through levels to find the Princess.

Why I’m doing it
The popularity of 2D platformers has wavered throughout the past couple of decades, but with the strong emergence of Indie game developers since about 2008 they’ve risen to popularity again. From a design perspective, it’s an incredibly easy genre to develop, which is probably why small teams of Indie devs picked it up again. There is now potential to incorporate stunning high-resolution graphics into these games, however the retro “pixel-art” style remains ever popular amongst developers and players. I too intend to use implement a retro graphical style into my game, because it’s such an important factor in the history of computer technologies. If you were to ask what made Super Mario Bros so good?” part of the reason would be that its low-res 2D graphics had a sort of “mysterious digital-world magic” to them. 2D platform games and pixel art are almost synonymous with retro. Mario’s original silhouette is still universally recognised by gamers.

You know who it is.

How I’m doing it
I’m going to draw all game assets myself, using a combination of Photoshop and pixel-art drawing program Graphics Gale. The game will be made in Yoyo Game’s Game Maker 8.1, which is almost the perfect tool for creating 2D games of any genre.
John Sandoval:

Game Maker can do anything.
It’s magic.

(from somewhere on The Archer Devlog!)

For a better insight into the game-making possibilities of Game Maker, see this post from a previous Blog. I initially chose to use Game Maker because it was free and very easy to pick-up. In the creation of games, I’m an asset artist before a coder, so it was important for me to use an engine which didn’t require years of programming knowledge to be able to use well. Since I wrote the post on my old Blog, I’ve bought the standard version of Game Maker, which has opened up even more possibilities.
During this project, to help me focus on asset creation rather than using up valuable time on coding, I’m going to use Matt Thorson’s Grandma Engine, which runs in GM and acts as an easily adaptable platformer basis.

To clarify, I’ve prepared a list of things the Grandma Engine does not have in common with the stereotypical grandma:
Old
Slow

To highlight the positive features of the engine, I also found it necessary to provide a list of the things the Grandma Engine does have in common with the stereotypical grandma:
Gives you candy

Other features of the Grandma Engine include a custom movement system (meaning it does not use the built-in Game Maker movement system), slopes, jump-through platforms, and an An Untitled Story-style room system.


The image shows the building blocks of the engine, which make up the solid platforms in a platform game! When the game is complete, these black blocks will be invisible to the player, replaced by more aesthetic visuals.
As for sounds, I will be looking to sites like freesound.org for sound effects. For background music, I’m going to keep an eye open for any willing composers, if not I will probably use a few royalty-free tracks.