Devlog Video 2

I’ve tried to get all recent updates into this video, although compared to the previous rate of progress things are moving fairly quickly now and I feel like I’ve probably missed something! Hopefully it’s starting to look better already.

I also found my first tester today to try out the room I’ve shown in the video! I’ve been worried that the play route is not obvious enough and that people will get stuck or bored, but feedback suggests that the level is open enough that you can just go anywhere and see where it goes! There are a lot of dead-ends, but they don’t take you too far off route. Hopefully this will motivate the player rather then bore them.
My only real negative feedback was about the resolution. I was initially planning to promote this as a game designed for mobile devices, but I can’t really claim this any more… So I will start to consider what resolution the game should be and if I can implement a full-screen mode to adapt to monitor sizes for PC.

Animations Update

Now that the game includes a jump command, I needed to come up with a jumping animation. This only really requires two new sprites: one for the ascent and one for descent. This is what I came up with:

This so far has been fairly tricky to implement, because the sprites need to be timed to various parts of the jump rather than simply looping at a certain speed. I’ve atleast got the ascending and descending sprites in place for now.

Now that there are quite a few sprite sequences in my game, it’s very important that they are correctly aligned according to the engine, so that the transition between sprites is smooth and doesn’t offset the image. I discovered today that the origin of my sprites were not in the correct centre, so turning from left to right sometime meant strange collisions with walls or unpredicted jumping about!

This is the origin for my main character animation (shown visually by the black cross!). The canvas size is 70×70 pixels, which I’ve tried to keep consistent with most sprites so that the origin is always exactly the same. With animations which span a wider area such as the “cosy” animation, the canvas is much wider. The origin is always in the centre of the character, not the canvas.

Each sequence must also have a collision mask, which maps the solid part of the image where collisions are concerned. This is the collision mask for the main character animation:

Automatically, the collision mask is set to “precise”, which masks the precise outline of the image excluding any alpha. For me, this would include the tail and other protruding parts. It is advised to avoid including these parts to avoid getting caught on walls etc. I’ve actually made mine very small, covering only the main body part. This is also consistent throughout every sprite.

Code Update

Apart from the respective spriting for each kind of movement, my new code is coming along very well. The article from the Game Maker Community forums which I ended up basing my code on involves setting custom variables which fill in for numerical values, so the code is really easy to adapt and change without having to find every value on a long page of code! You can read the thread here. The values act like game settings, rules and regulations:

• Gravity: 0.7
• Gravity Direction: 270 (downwards!)
• Player Speed: 3 (pixels per step)
• Image Speed: 0.3 (the speed the sprite images loop)
• Player Friction: 0.2
• Jump Speed: -9
• Climb Speed: 3
• Maximum Up Angle: 5
• Maximum Down Angle: 6

Following these variables give a continuous, consistent movement. They are very rarely ignored, with the exception of the climb speed which ignore the pull and direction of gravity!I would also like to mention a bit of a personal achievement; I’ve lifted a burden which I’ve been carrying during this whole project. GML uses a lot of symbols to lessen the task of the coder. For example,
“=” means “is equal to” (as you may have guessed)
“&&” means “and”
“||” means “or”
“!” means “not”
and so on. The ones I have always embarrassingly struggled with are:
“<” less than
and “>” more than.
No matter how hard I tried, I just couldn’t remember which one was which, and was often using trial and error when it came to implementing them. I tried writing down the meanings and memorizing them, but nothing was working. I googled my problem to find the cure and found this from mathsisfun.com (this makes me laugh). Now I can’t believe I ever had a problem!

Coding for Keyboard Input

After all the time I’ve spent researching motion planning and methods of getting an object to follow the mouse, coding for keyboard input is entirely different and I can hardly use anything I’ve previously programmed (although right now I’m holding my head up high and counting everything as a good learning experience!)

On a completely flat horizontal surface, there are a couple of really easy ways to code movement from key input. At the most basic level, you can code the keys to affect the horizontal speed that an object travels (or vertical speed if you include up and down).

This is great for flat surfaces. Because my level involves travelling up and down slopes, this would prove problematic! For my horizontal travel, I’ve used a variation on this next example which programs the object to travel to a certain point along the x-axis.

the “x+” and “x-” figures show that the figures are relative to the position of object, otherwise the object would jump to point 4 or -4 along the x axis. This method is generally more accurate, and speed can be changed by increasing or decreasing the number of steps the object moves at once. Using this means that the code can be adapted easily for points where slopes are met by programming in movement along the y axis.

This code is repeated for the “right” key with the values reversed, which sorts out all horizontal movement! This code was greatly adapted from one that I found on the Game Maker Community forums, as I was struggling with slopes before I found this!

GDL – 20/11/11

The new (and hopefully now <emfinal) movement system doesn’t require a lot of the paths I’ve been creating for previous versions, so today I’ve started apply paths to the levels from scratch. I’ve also adapted the look of the levels slightly to try to add some depth and structure to the very flat tree trunk.
Before:
After:

This should make the level easier to follow and determine where there may be a path. Before, the player was able to wave the mouse in a direction and the character would automatically move along the path (or that was what was supposed to happen anyway!) Now the player must work out the path themselves, which I’m sure won’t be such an easy task due to the amount of clutter I’ve placed around the level…
The level design in Game Maker now looks a little more like this:

Due to gravity now taking effect, the path only needs to act beneath the player. Gravity will top the character from travelling upwards! The pink areas show climbing areas where gravity is temporarily disabled so that the character can move vertically. Where there are no barriers, the character will fall to the nearest floor if moved outside of the climbing area. Some barriers are placed to stop the character from getting completely lost in space!

In order to move up and down small spaces, I’ve also programmed a jump command by pressing the up key. I originally wasn’t going to include a jump command, but because there is gravity set, I didn’t see a reason not to! To make a character jump, the simplest code is to set a minus vertical speed, which will make the character move upwards. The gravity then stop the character from jumping too high and brings the character back down.

//to make the character jump:
if keyboard_check(vk_up) && place_meeting(x,y+2,obj_guide) //jumping has no effect on the pink area
{vspeed=0;
climbmode=true}
else
if keyboard_check(vk_up) and !place_free(x,y+1) //otherwise, if there are no obstacles
{climbmode=false;
vspeed=-9;} //vertical speed is mins 9
if keyboard_check_released(vk_up) //the character will start to fall if the up key is released
{vspeed/=2;}

GDL – 18&19/11/11

RIGHT.
Not long after writing up yesterday’s post about how it was well past time to move away from creating movement systems and that I should concentrate on other things (to summarise…) I spent the rest of yesterday working on other possible motion systems, using keyboard commands, mouse commands, gravity systems…
I found a great example of how to make the character walk up slopes, which was the reason I had to employ motion planning in the first place ¬_¬ and then tried desperately to implement this, adapting it from a keyboard input system to a one-button mouse input system (this was NOT easy.) The results were BRILLIANT as long as the character was only walking horizontally up and down slopes. The problems, and the reason this took me so long yesterday, came when I wanted the character to drop down or climb up something- mainly due to the fact that this new system used gravity settings to keep the character on the given path.
For future reference, the script can be downloaded from the Game Maker Community forums here. I really hope I can use this someday, it’s a really great piece of code!

So this has led to more developments. I tried to find a simpler version of code which allows characters to walk up and down slopes without getting stuck on jagged pixels, and found a really great example which it looks like I’m now using. There are still problems with using the mouse as the only form of generating movement. This is because I’m trying to code one button to do absolutely everything depending on various conditions, and it seems like it’s been a waste of my time to not program movement through the keyboard. I really wanted to prove that I could make a game with the simplest possible input to attract a wide audience, but in doing so I’ve complicated the development by more than it was worth. For my first crack at a real game, I feel like I should have stuck to basics.

But from here on, I can really get a move on with things. I still have to adapt the code slightly to include climbing which temporarily cancels the gravity and change variables such as the maximum speed. I’ll post more about this once I’ve got a solid code in place!

Improved Movement System (GDL 15+16+17++/11/11)

I think I mentioned in my devlog video and possible several time before that I was having trouble coding the movement for the little dude. The problems mainly lie in creating a flexible but sometimes very strict path for the character to follow, while only setting a vague direction with the mouse. Several advanced techniques seem to not work with my level, which have taken me days (maybe weeks!) to research, test and evolve, and has proven a great problem to me! I was not planning to spend a lot of time coding for this project, and feel that this setback may compromise the visual qualities of the game if I spend much more time working on a completely bug-less system.

I’m still using the mp_potential_step code, but have now combined it was a pre-made script which I downloaded from here which sets basic waypoint pathfinding. To make the code a little more accurate than it was before, the little now will aim to move towards the nearest “waypoint” to the mouse position (I tried something like this before, but with little success…) rather than the position of the mouse itself. The waypoint objects are only placed on the set path, so if the mouse is in a random location, the character will never try to leave the path.

The system also requires a much less strict path, as the character will generally stick to the path without so many barriers in place. This meant going back into my room layout and rearranging some of the “block” objects, another very time consuming process. I’ve still only managed to achieve anything in the top three rooms, but as this is where the game begins, this seems like the most important area to focus on!

Like I say, I’m an artist, not a coder… There’s still the occasional glitch, but at this point in time there is just nothing I can do about it. In the world of Indie game design, I’m the one with the ideas and the ability to show them visually.

Animation Testing in Photoshop

I think it is a little known fact that Photoshop can be used to create frame-based animations by bringing up the animation timeline window. By default, the timeline is set to 0, so all layers can be accessed at once. By adjusting the size of each layer of the Photoshop document in the timeline, it is possible to flick through the layers in succession to create a sort of flip-book animation.

In this example, I’ve had to change the starting and ending point of each layer as my images have no background! Otherwise, a simple way to use the timeline would just to bring in layers at later points in the timeline. As all my animation frames have been imported from Graphics Gale into Photoshop, I’ve used the animation tool to test how the animation will look, how the timing needs to be adjusted and whether the sequence needs more or less tweening. The sequences are only imported into Game Maker once they have been tested in Photoshop.

Today’s New Animations

Concept for the "cosy" animation

Now that my game is starting to act like an actual game, I’ve looked at the playable environment and the level script and come up with an updated list of character animations to create. I’m almost certain that not everything on the list will be made ~or~ made the way I see it all in my head now, but if I have the time I will try to get as many varying animations into the game as possible:

A couple of animations I’ve been working on over the last couple of days have been:
Stationery/sitting down animation

It’s difficult to see from the picture, but there is a subtle movement in this sequence which makes it look like the character is breathing. It prevents there from being too much stillness on the screen and therefore won’t look like the game has crashed!

Unlike many animations, this one will not loop. If no keys are pressed for long enough, the character will sit down and have a rest until the player presses a mouse button again!

Getting Cosy
^as I have been calling it. I though it would be nice if the little dude sits in certain leaves that look comfy.

This one involves the little dude turning to face the opposite direction, and uses a wider canvas than the other images. It may be more difficult to implement, but I really hope I can use it!

Updated GDD and Game Info!

It really was getting to the point where my head needed to be that little bit clearer about the bigger picture. As a result I’ve finished the Game Design Document (to its current standings- there is still time for updated versions.) I’ve also written out a game story overview, based on more guides from the Computer Games Design Course book:
Story
Backstory:
Ever since human beings have existed, they have had thoughts, dreams, and aspirations. Whenever a person dreams, a certain energy is created. This energy can be seen in the deep glow of a dreamer’s eyes. Some people build their dreams into their reality, but some forget the aspirations of their youth, or cease to believe that dreams can come true. The energy leaves; these people have dull eyes. But like all energy, it cannot be destroyed. It floats towards the sky, then beyond the atmosphere, and heads unconsciously towards the edges of space. It becomes lost- unless it is intercepted by a certain tree on a small, strange planet which orbits our Earth: the tree of life. The tree, now only spoken of in myths and legends, disconnected itself from our world several thousand years ago, taking with it a chunk of earth which over the years has taken a planetary form. The tree has the ability to capture wasted positive energy from Earth and produce life in the form of small, spirit creatures called Sprites. These conscious beings have the choice to return to earth and replace the aspirations lost by human beings, inspiring people to be dreamers again. No one can see them, unless you catch a glimpse of them reflected in the eyes of those who have regained the ability to dream.
Plot Point 1:
Our character is seen as a flower dangling from a high branch in the tree. The flower acts as a cocoon, until his eyes open and he drops onto a soft leaf below.
Plot Point 2:
The tree calls the being to the very top of the tree, where a fox symbol appears and tells the creature about his existence and his life’s significance. He tells the creature to travel the small planet and learn about the meaning of life, so that he can eventually fall to earth.
Plot Point 3:
The first obstacle the creature must overcome is travelling down the great tree to the ground below, where he can begin his quest around the planet. On the way down, he sees plants, the moon and the stars…His quest has already begun.

End of Demo.

Game Info:
Name: Somnium (possibly Lignum…)
Tree Name: Artifex*
Character Name: Sylva

*Artifex is Latin for architect/creator/author… that sort of thing. According to Dream Moods.com:

To see an architect in your dream indicates that your creativity is being put to work. You are taking on a new project which will require such creativity.

To dream that you are an architect suggests your need for visual stimulation.