The Realms Of Shadow…

Warning! This post contains the indecent exposure of pixel people…

Last week I proposed the idea of shadow NPCs, stating that:

If I try this and it makes sense, then I’m putting it in.

The first step to experimenting with this idea was to come up with a bunch of generic-looking non-playable characters, and being the resourceful and efficient person that I am, I’ve based these character on structures of my existing characters. With a little adjustment and the removal of clothes, I had the perfect template for a gathering of normal people! You can probably recognise features in the line up below.

I’ve balanced out the gender gap a little but transforming a couple of my previously male characters into female ones, so my new NPC characters currently exist of four women and five men. To increase the amount of available characters even more, I’ve created nine outfits per gender, which with a mix and match process increases the amount of available women combinations to 36 and the men to 45.

Women’s outfits:

Men’s outfits:

What concerned me original was how I was going to all the different character variations into the game, without having to make each one of the 81 possibilities and importing them as sprites. The solution I came up with actually uses a very minimal amount of code to select a random head and set of clothing and draw this onto a set body shape. I took each individual head and set of clothes and made a single sprite for each of these categories:


Each sprite is made up of several sub-images which consist of the combination possibilities. These come on various shapes and sizes, so it was really important to make sure they align through the images origin.


I then made two objects called obj_npc_male and obj_npc_female. In the create event for each of these, I placed this code:


Here, I’ve set up two custom variables called “head” and “clothes”. Where these variables are involved, a number between the range shown will be selected at random. In this case, these numbers refer to the sub-image of a particular sprite. Next, I’ve used this code in each object’s draw event:


The code in brackets represent sprite, sub-image, x value and y value. The first line of code draws the body sprite, which only had one sub-image so I’ve used 0 here. I haven’t had to worry about x and y values, as I’ve determined this with the sprites’ origin alignment, so they simply remain “x” and “y”. The second line of code draws the head sprite. Instead of giving sub-image a numerical value, I’ve written head, which will refer back to the original code and pick a different number for each instance. I’ve done the same thing for the clothing sprite.

I made a temporary room to test these sprites in. I placed four of each object in a line and ran the game three times. Each time, the characters were drawn at random! Here were my results:

Try 1:

Try 2:

Try 3:

The main negative point about this system is that because it is random, similarities between characters seem to occur more often than I would like, but on the positive side I’ve used minimal resources and code to create a working random NPC generator! However, according to my original plan, they only need to look this way after they have been saved at the end of the game. In order to create a silhouette style version of each, I’ve used the more complex command draw_sprite_ext to determine temporary opacity and colour. Whether the game has been finished or not depicts whether the global variable global.kokeshi is true or false, so I’ve used this to determine whether or not the character is “complete” or in shadow form:


The values in draw_sprite_ext show (in order): sprite, sub-image, x value, y value, x-scale, y-scale, rotation, colour, alpha value. When the game has yet to be finished and global.kokeshi=false, the sprites are drawn in black with a slight drop in opacity, which makes them look like shadowy silhouettes. Then when the game has been finished once the characters are drawn in full. Unfortunately, using this system there is little I can do to get a lot of movement into the characters, so at the moment they are very static. Here’s a look:

Creepy shadows hanging around the cafe…

A lovely afternoon of tea ^_^

A Few NPC Updates

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!

Weekend Update #5

My new time plan seems to be working pretty efficiently- I’m almost ahead of where I expected to be, although a couple of the things I’ve crossed off the list are works in progress and will still take some time. I’m still making and placing NPCs into the levels so that five petals can be collected in each level.

One of the characters I’ve worked on is the Monk character who I “pixelised” quite a while ago. I’ve given him a walk animation so that he can pace around. The interesting thing about animating this character was getting the timing of the staff right, although I’m still not sure how I feel about it!

I’ve also re-made the “nap” character I created a while ago, based on Japan’s casual outlook on sleeping anywhere and everywhere! Before, this guy stood up and looked sleepy, but I’ve remade him to sit down with his head against a table. When the player walks past he will stir, but take little notice and continue sleeping.


In terms of the petal system, I’m still currently looking at ways that I can improve this by adding extra animations and stopping all keyboard input to create a dialogue “cutscene” sort of scenario. I will hopefully finish the system in the coming week, as well as working on the game’s physical elements such as disc and box art and the inclusion of the all important game manual.

I’ve purposely left out a lot of instruction throughout the game in order to encourage the use of a physical game manual, and it’s become very apparent to me how vague the objectives of the game are to a player who has had no introduction. So the game manual has two purposes: one is to set the scene of the game in terms of back story and character bios, and the other is to inform the player how to actually play the game, what to look for and how to achieve goals. I haven’t started any designs yet, but I’ve come up with the table of contents:

    1. What I’ve referred to as “boring but essential” info- technical stuff and system requirements etc.
    2. Story Synopsis- briefly setting the story of the game.
    3. Hana and Zashiki Warashi character bios and backstories- I want this to be a double page spread so that the characters are seen side by side. This will take the story further to concentrate on the back-story for each character. None of this is touched on in the game.
    4. NPC bios- this will be very brief, mainly displaying a portrait and name info for all of the NPCs.
    5. How To play- this will be split into these sections:
      5a. Controls – including diagrams with controls for keyboard and controller
      5b. Menu Navigation
      5c. Understanding the HUD
    6. Game Items- a list of items, what they do and how to use them
    7 Hints and Tips
    8. Credits and thankyous

In terms of art style for imagery in the manual, I am considering continuing to use pixel art instead of using higher definition imagery. I’ve started working on some images that I can potentially use in the game as stills, but could easily adapt these for print. I’ve been thinking of clarifying the setting at the beginning of the game, and introducing Zashiki Warashi early on. I drew this kokeshi-style Za-chan so that the player knows what they’re up against:


I’ve also been working on some still images of events that happen in the hours preceding the game in a similar style. I’m not sure if I will use these, but if I do they will appear as a slideshow when the player starts a new game. None of these images are finished, but I’ve compiled some of the new images of Hana from these here:

Five Petals

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.

Boss Battle

I went back to the GDD this morning and tweaked little bits of information that have “evolved” during the development of Hanami. I took a look at the list of events that I wrote right at the beginning of this project, to try to work out how to conclude the game. So far, motivations for playing the game have been about progression, so I finally needed to realise a result of the player’s hard efforts!

The best way I could think to conclude the game was to have a Boss Battle, which was something I wasn’t originally planning but feel that the player would be let down if the game ended without one final challenge. So, the final door that is opened will lead to a “battle” with the Zashiki Warashi spirit, resulting in the spirit transforming back into her Kokeshi doll form. This essentially solves the “Hanami crisis”, and the player will be able to roam the world obstacle free in order to collect the remaining blossoms. There shouldn’t be many left (about 10 or so?), but only be collecting EVERY SINGLE LAST BLOSSOM will the game truly end.

The terms “Boss” and “Battle” are strong words, but it’s the best way to describe this glorified final obstacle! I haven’t introduced any new techniques to the battle, the Zashiki Warashi spirit can be de defeated in the same way as the Deceitful Blossom, by jumping on the enemy’s head. The main difference is that this enemy has a 5 health points and a projectile attack! The battle is really based on the sort of sub-boss battles you’d fight in old Super Mario games, where jumping three times on a Koopa’s head will let you pass to the next stage. I’ll record a video to show what I mean if I get the time!


EDIT: Here you are, Boss fight footage recorded exclusively recorded for this Blog:

For this stage, I’ve created three new game assets. The first is the Za-chan object, which controls everything that the enemy does. She works with three alarms, one which instigates “attack 1”, another which instigates “attack 2” and a final alarm which determines how long she is static for when hit. She has her own health counter, which is shown by my second new asset which aligns with original HUD:


The third new asset I have (half) created is an object called obj_attack. At the moment, this object is represented by my Gunkan Sushi sprite, as I haven’t actually drawn anything to go here yet… So, when the enemy shoots her attack towards at player, she is currently shooting sushi. This has been fun to test, and I will almost be sad to see it changed! This has been the easiest to program, as it’s only job is to move steadily towards the player. If the player is hit, then the projectile is destroyed, to avoid being hit twice by the same attack.

This is by far the most complex AI controlled NPC character I’ve created so far. The character moves in relation to two objects, the player and a “block” object, which keeps the enemy within a certain space. Za-chan moves slightly slower than the player, so it is possible to catch up and jump on her head! If the player is quite far from the enemy, the enemy will move towards the player. If the player is very close to the enemy, the enemy will move away in evasion. As well as this, there is a certain distance from the player that Za-chan will simply stand still and spam the player with attacks, however this will only happen if the player is also standing completely still. This system works well enough to keep the enemy moving about, but I noticed that it was possible to defeat her too easily by trapping her in a corner. So, I’ve added a final line of code that states that the enemy must move towards the player if she gets too close to the “block” object, even if this means a collision with the player. Colliding with the enemy actually causes player damage, so this in itself acts as a sort of attack mechanism.


Za-chan’s two “attacks” are thrown when each of the first two alarms go off, and this code simply resets each one so the enemy constantly attacks at an even rate. Attack 1 throws one sushi, and attack two which is less regular throws 2 sushi!


I’ve used almost exactly the same code as the Deceitful Blossom to program what happens when Za-chan is jumped on. I’ve simply changed the squashed flower sprite to a new sprite, and ensured that during this time she can neither deal or receive damage, and she cannot move! I thought it would be appropriate to make a new sprite animation where she sits down and rubs her poorly head after having an full grown woman jump on top of it…


Once she has been defeated, I’ve also created a new “transformation” animation which turns her from spirit form to Kokeshi form. To do this, I created a cloud which passes over her to reveal the doll underneath. I’ve made this in the same style as my previous “auspicious clouds”, and drew out the animation first to make sure the swirls moved bout fluidly:


And here is the final result:


At the moment, I’ve set the battle out in the most final stage I have made, even though this is currently far from finished. The aim for the rest of this week is to finish the inside of the building and build a proper “Boss Stage” level for the battle to be held in. I’ve recorded a video of the battle so far, although I think I still need to make some tweaks to the rapidity and speed of attacks. I’ll probably have to get back onto SunVox too to create some epic Boss Battle music!

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.

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!

Hazard Evasion

Hazard progress is well underway, and has led me to discovery a whole range of previously untouched Game Maker functions. Here’s a run down of what’s gone on in the process…

The Deceitful Blossom

Not quite so evil-looking at 16 pixels high… This has been the easiest obstacle to create. I’ve created an obstacle parent mask that means that I only need one collision command when the player runs into any obstacle. When this mask object is contacted, the global.health setting (which controls player HP) is reduced by one, as this is a constant for all obstacles! I’ve added a character flash-to-alpha effect when an obstacle is touched, which temporarily disables health from being reduced for a set amount of time while the player has a chance to get away. Those familiar with 2D platformers will be familiar with this, and would definitely expect something similar. I’ve compiled this video montage so you can see what I mean…

In the case of the Deceitful Blossom, the obstacle is destroyed on contact. This prevents the player from frustratingly walking into the same blossom more than once.

Hello Mushroom

yummy!


With the Hello Mushroom, I’ve looked into particle functions in order for the object to release periodic spore clouds which cause damage to the player. I’ve used particles before in motion graphics, and Game Maker’s handling of particles is very similar. You can completely customise particle aesthetics and behaviour without having to create a sprite first. For my small spore cloud, I’ve gone for a short release of small particles which shoot straight up into the air. They have a slow speed and a short life-span to make them look light and airy.



I’ve placed the Hello Mushroom in this cave here, and you can see a part of the cloud dissipating. I’ve essentially used a timer to create a period burst, and custom collision masks so that the spores cause damage as well as the mushroom itself. I used this little tutorial for help with a custom collision mask, as Game Maker doesn’t allow mask changes for objects that don’t change shapes themselves, and won’t allow collisions with particles.

The Hanging Adversary
The green thing that looks like an upside-down cannabis leaf in the screenshot above is my Hanging Adversary sprite, which currently swings like a pendulum and takes advantage of Game Maker’s abilities to draw connecting lines. This is another example where the darker green line isn’t part of a sprite which I have pre-made, but is constantly being drawn, refreshed and redrawn by the software. The clever part is, the swinging process isn’t based on a set movement, but is defined by settings such as mass and velocity…


The drawn elements originally created looked a little like this. This was adapted from a code I found on the Game Maker Community forums, which creates randomly swinging circles on these very long lines! The grey lines demonstrate the boundaries of the swing, so it was really simple to get from this to a smaller, non-random swing motion.




I think the sprite may need changing for this one… I made all of these sprites really quickly to get them into the game, so expect changes.

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!