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


I’ve been pretty unhappy with my old dialogue system for a while for two main reasons. The first is that it didn’t actually work very well. The best I could manage was a square to appear as the player passed by a non-playable character which contained the character’s “dialogue”, as I didn’t manage to figure out how to stop the player so that a proper dialogue situation could be initiated. The second reason I wasn’t happy with the system was that it was potentially detrimental to the game itself because it was fairly resource heavy.

The idea was to use a system where the player could get the gist of what NPCs had to say, but without the NPC using words. The reason for this is for the player to get the feel of language barriers faced by people in foreign countries. You can talk all you want, but it’s mostly gestures that will allow communication between two languages. This is why I had decided to use images instead of strings of text. A similar but less vague system is used in Machinarium. In this game developed by a Czech team, images and short move clips are used in speech/thought bubbles to depict dialogue. I’d imagine this was one of the keys to the game’s success abroad, because a minimal amount of translation would have been involved to export the game!

To make a system like this in game maker requires a lot of resources. I’d already made two simple “text box” objects that could be used universally throughout, but the content would have to unique for every instance. This requires a different sprite for each talking character, and some with several sub-images if the images scroll or are animated. This also takes a lot of my time as I was drawing new images for every time a character spoke! So I’d already decided that I would change the way this works, in the interest of my time and the performance and size of the game!

To help me really refine the system and create something that actually worked well, I went to the Game Maker Community forums and found a downloadable example similar to the one in this video.

The basics for a decent system are all here, including stopping the character when dialogue is initiated, scrolling text that progresses as if the character is talking and NPC interactions. I managed to adapt the code to create a very similar yet customised system so that when the player chooses to interact with a character, dialogue is initiated inside a text box and the player must sit through everything the character has to say before they can move on. I tested the system with a basic white text box and black text to make sure it ran smoothly.

The first thing I did after checking everything through was create a new larger text box sprite to replace the abominable white square I had made. I’ve made sure the box keeps the themes of the GUI and to make it similar to the previous text box, however I’ve flipped it over so that it always sits below the character who is talking. This way, it shouldn’t ever cover up anything important on the screen.

The next thing to change was the language. I figured instead of presenting the player with decipherable images, it would be even more convoluted to present them with a written language that they couldn’t understand. This is the real deal, as if they were really in a foreign country where everything that the people said was simply a jumble of sounds (or in this case letters!) The first complication with trying to achieve this is that it’s not easy to display the Japanese alphabet(s) in Game Maker. Although Windows comes equipped with fonts designed for displaying Japanese characters, Game Maker doesn’t seem to recognise the characters as letters. In the editor, the “unknown” box appears as a substitute, which is translated in the game as a series of question marks…

So I’ve had to think of a clever way around this. Instead of using the Japanese character glyphs from romanised typefaces, I’ve found this font which displays roman letters as Japanese characters. It’s actually a replica of the typeface used in the original GameBoy versions of the Pokemon games, which comes with English, katakana and hiragana versions. Unfortunately the letters don’t seem to be in any logical order, so I’ve had to spend some time working out which qwerty key results in which Hiragana character! For example:

& = は “ha”
% = な “na”
0 = み “mi”

So if I wanted to write “Hanami is Great”, I would do so like this:

English: Hanami is great
Japanese Romaji: hanami wa sugoi desu
Japanese Hiragana: はなみはすごいです
PokeFont: &%0 & 5c* d5

I’ve written some VERY basic lines of dialogue for each character, which I’m pretty confident in translating without too much worry. With the system I’m using, each character can have three lines of dialogue which are scrolled through by pressing X on the keyboard or A on the controller. The strings for the first character are written like this:

But in-game, they appear like this:

This is Bura-san saying hello! I will still need some indicators of the objectives of the game somewhere, however I’m considering using things like sign-posts instead of direction from non-playable characters. As I’ve mentioned before, in the first conversation with Bura-san the Zashiki Warashi character is also introduced. This currently involves the screen being covered with an overlay of the large Za-chan image I made before, so the game being set fairly well from the beginning now.

By the way “wakarimasen” means “I don’t understand”, which I thought would be an appropriate blog title 😛

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!

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!