Objective: Play

My objective for this week is to have a playable prototype level ready. While this will not be an accurate representation of the final game in any way, it will:

• include all graphical features currently made–sprites and tiles
• show an accurate level layout, mainly using placeholder graphics
• have accurate game physics (mainly character physics)
• include a points system when items are collected

So far today I’ve carried on working on my initial mock-up design for the first level of Hanami. Today I’ve been really concentrating on background and decorative parts of the level, finishing off the look of the level as a whole. It gets confusing in places because I mainly used one colour, so when I get the time I’m going to use varying shades of grey to determine depth and which items you can walk in front of.

Key:
Dark Grey: Buildings
Light Grey: Inside Caves
Green: People
Pink: Sakura Blossoms
Red(ish): Red Blossoms
Blue: Water
Half-Blocks: Jump-through platforms (mainly ladders!)

If you look hard enough you can almost see how I’ve based this around the original Kanji, although admittedly it becomes very obscured…

桃色 Pink ~ Momoiro

To test out how the level plays, I reconstructed the Photoshop mock-up in Game Maker using an arrangement of solid block objects. I didn’t worry about wasting my time with large filled in areas, all I needed was a frame for the character to play on.

Apologies for the pink. I was just trying to stay topical.

For the first time I also applied my animated character sprite to the game! I worked out animation speed settings in the character preview, but keep changing my mind as she occasionally looks as though she is walking backwards in game. The pink background was actually an attempt to separate her leg colour from the background colour and show leg movement more obviously.
It’s probably important to point out a slight oversight at this point. The level design is snapped to a 16×16 grid, so some gaps between solid blocks are only 16 pixels high. When I added an extra pixel to my character height, I accidentally designed a flawed character who couldn’t fit into these spaces. Luckily with Game Maker, not all of the character has to be solid. I’ve set the character’s collision mask to allow for a non-solid edge which will not collide with solid objects!

Through a process of trial and error, I’ve settled for these settings so far. I’ve tried to keep movement slow enough to be realistic, and kept jump distances low to make obstacles less easy to avoid. As the game has only environmental obstacles, if they were too easily avoided then the game would have no element of challenge!

S_GRAVITY: 0.3 //a fairly standard gravity setting
S_RUN_ACCEL: 0.3 //a fairly slow acceleration speed
S_RUN_FRIC: 0.6 //slightly high level of friction.
S_AIR_ACCEL: 0.1 //a very low setting, attempting to avoid too much air control
S_AIR_FRIC: 5 //a very high setting, attempting to avoid too much air control
S_JUMP_SPEED: -5.5 // just high enough to reach a platform triple the height of the character
S_DJUMP_SPEED: (N/A really as I am disabling double jump)
S_MAX_H: 1.5 //a low setting, but perfect for walking pace
S_MAX_V: 4 //a decent falling speed!
S_SLOPE_SLOW (not yet tested as I don’t have any slopes!)

Unfortunately (as I am currently using Hypercam…) I can’t guarantee that the speed of this video is anything like the speed of gameplay. You will just have to trust me that the speed is not an issue!

After playing through the level a little, I realised that a lot of the platforms are too close together to act as a challenging level. I will probably add fall damage when I give the character a health bar, so calculating jump distances is vital to play. At the moment, it’s almost impossible to fall in some places, and in other it’s almost impossible to move. I will try to resolve this by spreading the level out. This video actually plays from the beginning to the end of the level, but obviously in order to collect items, the player must play through the rest of the level beneath. I’m not yet sure whether I want to stretch out the width and length of the level too, to increase play time. This may simply come with spreading out platforms.
Just as well. I still haven’t managed to pick up any tracing paper

Edit: I worked out that the illusion of “backwards moving legs” is caused by the similarity in foot and block colour. The problem is resolved mainly by changing the colour of the platforms.

Weekend Update #3

Some More Character Designs subject to change and/or disposal

These characters are complete rip-offs of a few of the characters from 51 Japanese Characters, so are subject to name and feature changes in the future to avoid being a total copy-cat. While most of the inhabitants of the places in Hanami are effected by the so-called Hanami Crisis, I’ve picked out a few personality types who could have avoided the crisis in various ways. These characters will play very minor roles in the game, they will appear at most once per level, and simply hand over a blossom they have found, or something similar. Everyone’s doing their bit to help!
Left Character: avoided the crisis because he is a monk. Protected by spiritual powers etc.
Middle Character: avoided the crisis because he was stuck inside a Panda costume.
Right Character: avoided the crisis because he fell asleep under a table in a cafe. Details on the “crisis” are still a little vague, so I don’t know how this would have helped him, but it did. Kirainet, the predecessor to A Geek In Japan, has dedicated plenty of its Blog-space to photos of people sleeping everywhere and everywhere in Japan, it seems perfectly acceptable to just fall asleep where ever you’re standing.

I’ll be converting these characters to pixel form soon!

Character Animations
I’ve been plodding along with walking animations for the last week, but found I was taking leaps and bounds this weekend! I scanned through as many TIGsource Forum threads as I could a couple of evenings ago to find good examples of walking cycles that were a similar size and shape to my character sprites. Ultimately, I could only find things vaguely similar enough to help, but while this didn’t provide a pure reference, I was glad to see that I was on to something original. My current cycle too has a few frames which are similar to others I found, but I had to tween using my own initiative for most of the process. Here is my current Hana sprite:

I gave it a go applying this same animation to Za-chan, although it wasn’t always clear how to go because she wears a long dress and you can’t see most of her legs! I will probably tweak this if I have to use it in the game. At the moment, it’s more of a practice in applying one animation to varying sprites:

For the rest of my character animations, I will hopefully be roping in some volunteers to perform for me so that I have photo-references of people doing various actions. Finding examples of various walk-cycles wasn’t necessarily a difficult task, but unfortunately I’m going to need more than that…

Level Design
I’m currently still set on using the Kanji basis for my level design. Over the weekend I just had to grab a pen and piece of paper and get down all my thoughts on the level, what it should consist of and how it should look. It’s slightly more decipherable than previous attempts, although some of the designs cross-over quite confusingly! I tried to draw out the entire level in the bottom half of the page:

According to Peter McClory’s level design technique, the next step would be to draw this out to scale on squared paper. However, I decided to use Photoshop instead, so that the level was easier to edit! Once it’s done I’ll print and trace it as if it were drawn on squared paper. The design currently lacks detail and is not finished, but it’s given my a huge insight into the scaling of the level, which in places in completely different to how I imagined it. Here is a rough idea of the level so far:

My Plan for the rest of the week now is definitely to get this mocked up and playable in Game Maker, possibly before tracing in the details. I still haven’t settled for any particular character physics within the Grandma Engine, so I will have to make sure that the character feels natural to handle whilst working their way around this specific level. Once the layout is finalised, I’ll fill in some detail, but this is a secondary objective to getting a playable level right now.

Some thoughts on sound…
I started to play around with a piece of music creation software called PXTone. It’s a development from Daisuke Amaya, creator of Cave Story, and it sounds as though he uses this himself to make the music for his games. It’s default instruments are all very synthy, but you can combine classic chip-tune instruments with midi-sounding instruments to create something generally retro sounding, yet something original. There are a vast amount of starting instruments, which makes this program easier to get started with than other chiptune software I’ve previously used where you must create your own instruments :S So far I’ve just had a play around to see if it would be appropriate for this project, although I’m still not sure what my music source will be yet. Original music would be a huge bonus, so this is definitely on the list.

“Practical Game Design”

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

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

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

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

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

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

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

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

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

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

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

Easy Lighting Extension for Game Maker

One thing I’ve picked up on by reading developer’s forums and various articles on the Internet is that while Game Maker can do almost everything you could want it to, it doesn’t necessarily do it well.

I noticed this myself during my last Game Maker creation when it came to audio. Despite the fact that it gives you the option to use .mp3 format audio, it turns out that it doesn’t support most types of .mp3 (or some such nonsense.) I ended up using some hefty .wav files, which Game Maker compressed during the gameplay and completely changed. The majority of my sound effects seemed to sound like static! This is why people with the technological know-how have stepped in to save non-programmers by providing downloadable extension software for GM, including several which improve audio handling, which seems to be GM’s lowest point.

When it comes to in-game lighting, I’ve previously found ways to cheat by overlaying semi-opaque objects on top of light-emitting objects. In Somnium I used this to make some objects appear to glow, however this ultimately had no effect on the game’s lighting on the whole. The image above is an example of an extension called EasyLighting V7.0.2, which handles light generation in Game Maker. It is the same extension which Gabriel Verdon uses to create his moody, atmospheric lights in The Archer.

As you can see from the top example, there are two types of light generated. One is a dim, yellowish light and the other is a bright white light which casts shadows off the objects around it. Both of these lights use the same sprite image, which is a circle shape with a radial gradient. This is similar to my previous lighting “objects”.

However, the extension settings are used to draw these sprites to certain specifications, rather than simply overlay the same image in the same way repeatedly. This reduces the amount of sprites and used, and helps game performance.
You can read an in-depth description of all the extension’s functions in this tutorial here, which also runs through how the extension works and how to implement it!

The advantages of using a lighting system like this one is that it can help create the game’s desired atmosphere. The lights work by first applying a colour overlay, which immediately changes the tone of the game. Each light then has its own individual colour and brightness, which can give a really good sense of light and dark in the game.

To test the extension, I made some street-light style lights in the Grandma Engine. I recorded a quick little demo of the lights in action so you can see how effective they are in changing the ambience of a room. I’ve tried to capture the difference in the colour of the character (square) when under and away from a light source. These lights worked especially well at highlighting objects when several were placed close together.

“Elderly Platforming”

I’ve already mentioned that for this project I will be using Matt Thorson’s Grandma Engine for Game Maker, to give the game code a head-start. I’ve listed some of the advantages to working this way below.

Character Sprite Testing
The engine provides a default character sprite, which is a 16x16px red square. This can be swapped for any sprite of any size, although in my case I don’t need to make too many changes to the sprite size! All movement codes and physics are pre-determined, which presents a great opportunity to test character sprites and animations etc. without having to provide basic code before hand. I don’t currently have any sprite animations ready enough for testing, but I swapped the red square with my Hana sprite in order to get a feel for size and proportions. You may notice in the video that I’ve edited the sprite slightly again, because I felt that the sprite’s colour scheme should match the scheme used by the flowers more closely. I don’t know if this will stick yet.

Physics Testing
The grandma engine has cleverly listed all physics-defining code as one list of custom variables, which can be easily changed by anyone who isn’t familiar with GML or game coding. This is useful for defining your own game-specific physics, and can be swiftly changed and tested in the Grandma Engine before being applied elsewhere!
From playing around with the default settings, I think it’s fair to say that the movement is perhaps a little too fast and the jump distance probably unnecessarily high. This is good for initially experimenting with the engine, but I will eventually slow everything down a little.

Level Design Testing
The engine comes with essential default level design assets, in the form of blocks and slopes which join together to make the platforms of platform games! As well as the standard solid blocks which prevent the player from an infinite drop, the engine provides jump-through platforms, which the player can access by jumping up from underneath but will not drop back through. This is useful for a range of platform types, and something I regret not using in previous developments. I placed flowers around the preset level build to get a sense of how the size of the flowers felt in comparison to the block sizes, and to my surprise they don’t look bad at 16×16. This may all change when the blocks become actual tiles.

Extra Functions Test
There are a couple of nice but unnecessary things that the Grandma Engine provides for you. Things like an optional double jump, which can be turned on and off easily. A more useful function is a warp square, which transports the character from the square to a specific location in any room in any part of the game. This is useful for doors between rooms, rather than using the default scroll room transition.