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 ^_^

Advertisements

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!

Good Luck…


The new timeplan is so far a success- I’ve managed to cross a week off the list, and a little bit of next week too!


This week however has started off a little slow, but I’ve managed to get a lot done. This morning I played through the game from level one to level three for the first time to check that everything worked well in succession, and for the most part it did! One random little bug started to emerge towards the end of the playthrough however, as the framerate started dropping rapidly whenever I passed by a doorway to a building or cave. I managed to solve the problem by tweaking the “teleport” code slightly (I literally moved one line and removed a pair of curly brackets and everything was fine!) In the panic I read through this article on the Game Maker Community forums, which talks about optimizing game performance through various settings and commands, so the rest of the morning was spent tweaking little bits for best optimisation. One of the most vital lines of code I’ve added is this:


These few lines deactivate EVERYTHING that is outside the current view, and activates it when in sight. I had to activate the top corner of each room in the last line of code, as this is where all my control objects are kept including light functions, menu functions, sound functions, HUD functions… By reducing the amount of active instances, the game runs at a very steady 60 FPS constantly, occasionally dropping to about 58. Hopefully this means that even on lower spec machines the game will be very playable.

After this was over, I spent a little time tidying up little bits that I’ve previously started. I’ve replaced my old pink room transition object with an open door sprite, which is drawn onto the screen when the player reaches the right amount of flowers. The door only opens slightly, which is great if you’re nearby when you collect that final flower because it actually looks a bit like the door is opening.


I’ve fixed my save point Furin so that it looks like it is attached by a nail, not just floating next to a rock! I’ve made sure that all my save points are actually within reach of the player, which seems like an obvious task but this really is something I had previously overlooked.


As for the actual saving problems I was having, I’m not sure there’s such a big problem there after all. The problems may be related to the fact that the saves are made in the middle of making a lot of changes to the levels. I’ve also changed the save file to a .ini instead of a .sav, which for some reason saves more of the game information and is the only file extension which will reload sound effects. So until I’ve finished everything in the game, I’m not going to change the way the game saves or loads.

I’ve started to work on the final level of the game, firstly by changing the colours in the tileset and secondly by getting creative with my old tiles again. Up until now, my buildings have been very samey, so I’ve been experimenting with new ways that I can use my existing tiles (again!) I also managed to make a mini bridge from a section of my old bridge tiles.




There are now blossoms to collect in this level, so the HUD displays a total of all the flowers the player has collected throughout the game out of a possible 90. This was simply a case of adding the values of global.itemList1, global.itemList2 and global.itemList3.

Now that I know roughly what I’m going for with the design, I’ll do most of the rest on paper. This building will branch off into rooms, as opposed to having a large open outdoor space to explore. In one of the rooms there will be a door which only opens with an accumulative total of blossoms, so although the player may have made it this far they may still have to backtrack and do some more collecting! The end of the game is through this door, although I’m going to have to go back to the GDD and have a think because I don’t actually know how the game ends yet…

Save/Load Functions

The tricky part of implementing a save/load system is the painful process of working out what Game Maker will and won’t do using its default game_save(); and game_load(); functions.

Based on my original inventory menu, I’ve created two new menus in a similar style which represent the save menu, which is brought up by pressing the menu button at a save point, and a pause menu, which is brought up by pressing return/start and can be used to load up a saved game.

Save Menu


Pause Menu


To activate these menus, I’ve used a similar set of code to that used to activate the inventory menu. In the case of the save menu, when the player is in contact with a save point object and presses “S”, all objects are deactivated and a temporary overlay is created from a still image of the background. The object obj_save is then created, which draws the save menu onto the screen.


I’ve included the object obj_save in my list of instances that are created when the game is started. When initiated by the save point object, it changes the state global.save from 0 (false) to 1 (true), and draws the menu sprite onto the screen as well as the highlight sprite which changes position when the left and right keys are pressed. The options in the save menu are the same size and shape as the menu slots in the inventory menu, so I was able to use the same highlight sprite for this menu. Like the inventory menu, each “slot” (s) is given a value, in this case because there are only two options the values are 0 and 1. If s is 0 when the X button is pressed, the game is saved. If s is 1 when the X button is pressed, the game returns- pauseon and global.save are both reset to 0. Game Maker uses a simple one line of code to save games: game_save(“example.sav”);. However, there are many things that aren’t included in this save file. I already discovered a while ago that temporary datastructures, such as the item lists I use to hold information about collected blossoms, are not saved in save files. To save this information, I’ve had to save each list as a separate text file, so the save code has become quite extensive!


The game here is saved as a file called hanamisav.sav in a designated folder called “save”. I made this empty folder to test if this save function would work, and sure enough the files appeared in the folder straight away.


As a symbol of the game being saved, I’ve made a floppy disc icon which appears at the top of the screen whenever the player opts to save or the game is autosaved. The floppy disc seems to be the universal symbol for “save”, whether used as an icon in software such as Game Maker or as a save point in games such as Cave Story!



On my floppy disc icon, I’ve included the kanji I discovered before for “to save”. This is supposed to look like it written on the standard lined label that you used to get with blank floppies. Like the sushi icon which appears temporarily at the top of the screen, this icon remains for about three seconds before disappearing.


I’ve assigned the pause menu to the return key or start button on the SNES controller. Pressing either of these buttons will do exactly the save as all pause functions I’ve implemented so far, but will draw the pause menu sprite onto the screen. The options are actual strings of text which are drawn over the top of this sprite, according to the array I’ve set up in the object obj_pause.


This list of text acts differently to the slots I’ve used in my previous two menus, so I wasn’t able to use the same highlight sprite to hover over options in this case. Instead, I’ve used two different colours to show whether the text is highlighted or not. The lighter colour shows the option currently selected.


At the moment, both the “continue” and “main menu” options will simply resume the game, as I don’t have anything that acts as a main menu yet! I may later change this option to “quit”, and simply make it close the game. To load the game, I’ve had to make sure that all five files are loaded and properly restored. I’ve written out the code in the opposite way to the save code, so that each text file is loaded then applied to one of my global.itemLists. As for the rest of the game’s properties, I’ve so far relied on the default game_load(“save/hanamisav.sav”); function to restore everything else.

Loading the game shows some….interesting results. Each of the text files are actually restored properly, this was the part that I was mainly worried about! Everything in the GUI returns to exactly how you left it, including level progress, health and collected sushi. However, I’ve noticed a couple of things that the aren’t restored properly due to faults in the default Game Maker save file. The sounds aren’t loaded, possibly because the SuperSound.dll doesn’t exist in the “Save” folder, and weirdly enough the mushroom’s particle system isn’t restored. Another MAJOR issue is that 8 times out of 10, the game will crash after you’ve taken a few steps from the restore point. Of the remaining 2 times out of 10, 1 of those will produce an error message stating that a non-existing background cannot be deleted, which is probably due to a fault in my code for the temporary pause background. Because of these problems, I’m going to look at alternative ways of saving that don’t use the default save functions. I may also make slight tweaks to the menu interfaces, but not too much.

Technical Updates

Until now, each level has only existed on its own, completely unlinked from any of the other levels I’ve currently created. This is mainly because the pink square that I’ve been using as my warp between rooms can only be used if the destination is in the same coordinates as the square on both sides. This is useful for entering and leaving buildings and caves, which I’ve made to line up with the main level structure -all buildings and caves are the same dimensions inside and out. However, in the transition between level one and two for example, the player jumps from an X coordinate of 2992 to an X coordinate of 688, so I’ve had to create a new item specially designed for transition between levels. The new icon uses all my artistic abilities and has formed this go faster arrow shape to differentiate itself from the standard warp square.


On contact with this object, I’ve set up variables who’s values are defined in the individual instances on the map. In the collision event I have:

room_goto(rm); //goto “rm”
obj_player.x = X; //the player object’s new X coordinate
obj_player.y = Y; //the player object’s new Y coordinate

Then, in the individual instance these figures are defined as something like:

rm = rm_2_1; //Level 2 part 1 (main)
X = 688; //new X position
Y = 178; //new Y position

This allows transition between any level regardless of score, so I’ve had to make only allow transition if a sufficient amount of flowers have been collected. Before now, I’ve used one datastructure list to hold information about the collected blossoms, but as this figure changes depending on the level the player is currently on, I thought the best course of action would be to create a unique datastructure for each level. In my GameInit script which runs at the beginning of the game, I now create four lists instead of one:


The first list controls collected sushi boxes. This was previously the same list used to hold information about collected blossoms, but as I’ve had to change everywhere in my code that uses one of the new lists it was simpler to leave this list there. The other three lists correlate to the three levels. I’ve also had to set up three different “gamescore” variables, which display the amount of flowers collected in the HUD and in the inventory. Because these are persistent global variables, each value will remain even if the figure doesn’t show. So when the player leaves and returns to level one for example, the figure will return to the previous global.gamescore1 figure.


The value of each is increased by one whenever a flower is collected, but now the room that the player is in affects which gamescore value is increased. I don’t know if this is the simplest method of achieving this, but I’ve set up the system in this lengthy but fool-proof way:


The || symbol represents the word or, so the top line of the code states that the following actions only apply if the player is in room 1_1 or room 1_2 or room 1_3 etc. The corresponding gamescore is increased by 1, the item collection sound is played and the information added to the appropriate datastructure list. The instance (the individual flower item) is then destroyed, as it has been collected and shouldn’t appear again! I haven’t had to create three different HUD objects as the player’s health remains constant throughout the entirety of the game, instead I’ve simply had to state which gamescore should be drawn depending on the current level. It’s a very similar process to before:


In order to determine whether a level transition will work depending on score, I’ve simply stated that gamescore1 must be over 9, gamescore2 must be over 14 and gamescore3 must be over 19. If not, the player won’t be able to progress to the next stage.


At the moment, the open transition is marked by my beautiful pink square sprite, so next on my to-do list is create an open door sprite to replace this with! You can now play all levels from beginning to end (as far as I’ve made, anyway.)

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!

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!