Steep Difficulty Curves

If the difficulty is poorly tuned, the game can become either impossible or boring.

~Pascal Luban

Today I’ve been designing and building the cave sections of level two, which I’m planning on having two of in each stage. In level one, the caves were the level’s “mini dungeons” and contained many more strategically placed obstacles than the rest of the level, which in turn made the caves more difficult than other areas. I made sure that the level could be finished without actually having to enter a cave, although if a player wishes to collect all thirty blossoms in the level then they would have to! In level two I’ve made sure that the caves must be entered, by placing the end of the level at the exit of one of the caves.

The player finds the first cave fairly close to the beginning of the level, if they choose to move downwards where the path forks. You enter the cave here:

And exit the cave to here, which is a dead end unless the player has collected the 15 necessary blossoms:

The aim of the design is to be more difficult than the rest of level two, but also more difficult than the caves in level one. This creates a difficulty “curve” which the player must adapt to, although more game developers seem to agree that there is no actual curve in game difficulty most of the time! In the blog I’ve pulled the quote from above, one example of a difficulty curve is described like a staircase, rising at intervals but lying flat for a while afterwards. Mine consists more of peaks and troughs, as difficulty is increased by a higher level of obstacles in cave areas but is lowered again when outside. Because Hanami is likely to only have three main playable levels (and a fourth ender level), I’ve aimed to increase the difficulty fairly rapidly, so that the maximum level of difficulty is reached by the end of the game.

In this design, I’ve tried to include platforms specially designed to challenge the player. At the top of the cave, I’ve added sections where the player must time jumps between platform heights between the swings of the spike plant above them. This is based on a part of a level one cave which allowed much more room. This time, I’ve gradually decreased the available space each time the player encounters a swinging spike plant. Another little challenge I’ve included is placing blossoms between two mushrooms, so that the player must accurately land jumps in order to not get hurt by the obstacles on either side of them. Unlike my some of my previous cave designs, I found myself re-scaling and moving parts of this design around quite a lot when it came to place it into the level! This is its finished form in the level editor (the red blocks represent solid platforms)

In this next screenshot, you can see the increased difficulty in acquiring blossoms throughout the first part of the cave:

Throughout this cave the player must be constantly more aware of their surroundings and the timing of their moves. I’ve tried to keep a similar level of difficulty in the second cave of the level, which is an optional cave which doesn’t lead to anywhere else in the level. It is accessed by hopping across a few platforms before reaching the Koinobori Cafe in the levels south-east corner. As you can see, this part of the level still needs a fair amount of work doing to it!

I enjoyed designing this cave as it occupies a wider space than my previous caves which tend to travel vertically. Part of the challenge of this design is that the layout is almost symmetrical, apart from a few blockages caused by mushroom enemies which halt the play from progressing on one side or the other (unless they choose to take damage).

I’ve included some of the same sorts of challenges throughout this design, although I’ve increased the difficulty of this part slightly by creating a cave-bed that cannot be touched if the player falls/misjudges a jump etc. I considered creating a lake of poisonous liquid or some other such over-used game cliche, but for now at least I’ve ended up using my Hello Mushroom enemy to fill the bottom of the cave (as a result I’ve nicknamed this the mushroom cave. I think it’s pretty.) I haven’t placed any blossoms in this cave yet, but I’ve planned for one to go at the bottom of the cave on the left hand side. On the other side, the player is simply met with yet more mushrooms!

That's a lot of mushrooms.

This is definitely the hardest part of the game so far, possibly even the hardest I will make. The difficulty is due to a mix of difficult jumps, awkwardly placed obstacles and the inability to fall safely!

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!