Development Software

Stencylworks


Used as an IDE in which to program and build the flash game. In this project I went from using v1.4 to 2.0 beta. The beta had some initial runtime issues, though once updated and supported properly it proved to be the better of the two releases. 



Inkscape


Inkscape was the program I used to do all my image drawing. Inkscape is a vector drawing tool that allows you to manipulate sketches further than pixels allow you to due to the way the drawing is saved. This program allows the user to achieve a whole manner of tasks that are not so easily accomplished using other basic drawing tools, such as path insertions and differences.



Adobe Photoshop CS5


Photoshop was used in every case where transparency was required and a PNG was needed to be saved in order to maintain layer properties. I have also employed the use of Photoshop to quickly make alterations to animations and tilesets once they have been created in other drawing applications.


Wavepad


Wavepad was used to change attributes of sounds, such as pitch, volume and length. Using this program allowed me to tweak the sounds to sound right and work together. I was also able to convert sound files to file types and frequencies favoured by Stencylworks.

Problem Solving!

Note; this entry is updated to accommodate new found problems and obstacles


Dealing with a Mess

When I began the project, I didn't anticipate the amount of behaviours and actors I would have to produce. I was also rather unaware of how to put multiple behaviours into one link, so that all you had to do was attach the one behaviour to an actor. For some Actors I produced 4 or 5 behaviours that could have just been saved as one. I had also not learned, until the end of the project, that you could apply attributes to behaviours that were specific to the scene that behaviour worked in. Had I have known this, I would have saved myself quite some time programming new behaviours and actors.

Here is a screen capture of my behaviours half way through the project:

Here is a screen capture after I decided to tidy them up into folders and sub-folders:

Once I had tidied up a little, I found myself navigating through file to the ones I desired a whole lot faster than before. In hindsight, I would have sought to do this from the start had I'd known how much more efficient it made me.




Collision Areas and Bloody tiles!


The moving platforms I desired play a large part in the game mechanics. They are completely necessary. I chose to have the platforms assigned to special keys that are only be usable once the platform is on-screen. That part of the programming was simple enough - the tricky bit was getting them to work as platforms (or so I thought). I decided to encapsulate the platforms in building block constraints. I decided to make them up of 10 unique surrounding tiles that could be locked onto the 32x32 tiles (so as to make placing easier). These constraints would work to keep the platform in a set path whilst you apply a direction to it with the specially assigned keys. I chose to have the platforms walk, or climb, through their paths in amongst their constraints.


Using a drawing tool program, Inkscape, I employed vector difference tools in order to smartly capture the points of the constraints I wanted. The program allows you to do and awful lot with shapes, and so I was able segregate all the parts I needed that would surround the moving platform.

The above shows how you have use the 'difference' of shapes in order to cancel out what you don't want into white space, leaving you with the unique shape you set out for:

This is the final product - 10 puzzle pieces that allow you to set any length of course for the platform you desire. At the ends of these courses, the platform fits snug with its walls.

However, after achieving all this, I found myself to have WASTED a large amount of TIME. I accidentally stumbled across a specially coded 4-way direction behaviour that is designed to restrict movement to only the ways specified in the attributes...

Stencylworks 2.0 Beta

For a while I had been struggling with writing behaviours in Stencylworks v1.4. It is undoubtedly a intuitive and remarkable step up from raw programming, though I still felt you had to have a knowledge of flash in order to fully understand the rules the block coding followed. Roll on Stencylworks 2.0! In the beta, 2.0, a lot of common tasks were simplified into single blocks and the system as a whole required you to think much less about syntax, and more about the bigger picture.

For example, the 'On Ground' behaviour went from this:

To just this:

Having this simplicity allowed me to not only create some pretty powerful and solid behaviours, but also to tweak existing packs in order to achieve exactly what I wanted.

Finding, Citing and Editing Sound

Getting the right sound for the game is probably my least favourite of the necessary tasks. Although I appreciate that the right sounds will bring the game to life, I actually find the process of locating it rather tedious. You have to sift through a lot of noise to get to the sounds that are just right for your project.

Here are a list of the sites I used to acquire sound:

http://www.freesound.org/

http://www.newgrounds.com/audio/browse/genre/ambient

http://opensourcesounds.com/

After finding the sounds I wanted I came across another obstacle. I had to edit the sounds in order to suit their application. Cutting the sounds to length was not an issue, that's a very simple task. The issue was that once I had found the sounds, I needed them all to seem like they fitted the same game. To achieve this notion, I had to play with normalisation, pitch and speed. This is why I chose to use Wavepad.

Wavepad is a fantastic open source program that allows you to alter sounds into exactly the right sound you want, and then save them as you prefer. Up until this point, I was doing well with applying sound to my game. However, I came across another problem.

When exporting my game to either Stencylworks-play or as a flash file my sounds did not play. They play fine when testing the build in Stencylworks, but are corrupt once published to a file or site. This is a problem I am struggling to find the cause for.

Interface

Initial Designs for Menu UI

I decided against having too much going on in the corner of the screen. Although the above features as common practice with flash screens, I chose to put all my features into one menu. That way, the user would expect to have to go to the menu in order to reach any option they required. 

Here are screen captures of how the menus played out in the end:

Notice the fade-out of the game in the background. I felt the need to have the game visible in the background so as to let the play know their game is paused whilst they are in the menu. The fade-out was to reduce focus on it, as focus is now on the menus. I also implemented a hover effect on buttons  to allow interactive feedback to the player.

Level Design

I am posting these pictures to show the sort of ideas I have documented for level design. These are few of many obstacle courses I have dreamt up, though not all are drawn.

In this example, the player has to avoid periodically spawning and falling spikeballs in order to ledge jump up and up through the level.

Here is a quick and simple idea involving repeatedly shooting cannons that will be offset in their timings, making it more challenging for the player to pass through in a closed environment.

The above shows a situation where the player must stomp through a breakable block in order to alter the course of continuous spikeballs and pass through the once dangerous path they took

Here, the player must time there entry into the path of spikeballs in order to move with them and get out the other side.

I am keen on using all of these ideas in various levels I am preparing for the demo of Paper Escaper.

Animating

I have started drawing animations for my character. At the moment it is undetermined how many different animations I will need as I have not yet decided how many actions the player will have at their disposal. By this point, I have decided on a few actions the player will be able to carry out. The player will be able to do the following:

1. walk
2. jump
3. falling (animation only)
4. duck
5. grab ledges  (animation only)
6. jump from grabbed ledges
7. push objects
8. ground stomp

I have downloaded a platform resource pack on Stencylworks that offers a few extra behaviours. The following are behaviours I am considering:

1. running
2. double jump
3. wall sliding

I will only be able to decide whether it's worth having the above once I have had a better look at designing levels. The reason for leaving these behaviours until later is because they remove certain limitations on where the player can navigate to. Using the above behaviours allow the player to travel further, faster and access areas that may have previously been harder to get to.

Walking and Jumping

Using the above video as a reference I have been manually drawing my animations in Microsoft Paint. I stopped the video at 5 different frames in total and used them as a point of reference to animate the 'walking' behaviour. Below are my working examples.

The next step was to take these individual snapshots and put them into Adobe Photoshop CS5 and tweak the position of limbs from frame-to-frame over one another. Doing so in photoshop using mulitple layers allowed me to ensure the origin position of the player's head. This allowed me to produce a fluid walking animation which looped steadily.

I did followed a similar approach to achieve an animation of the player somersaulting for a jump animation, ending in a falling animation. 

I found this process of animation to be rather tedious, yet affective, as I was able to save and alter any frame as I pleased in order to accomplish a good animation.

Refining Rules and Concept

Strangely enough, my concept became refined halfway into the design process. It's well stated on this blog that I haven't been entirely sure of what my 'edge' is but I think I've finally found it with a change of thought with a particular actor. 


Escape Point


I was designing the end point at which the character exits the level and I came to the conclusion that a door was too cliché and rather out of place. After designing a few of the mobs and interacting actors, I noticed my game was taking more or a paper-sketched feel than anything else. I made the decision that the player would reach the endpoint and jump into a hole. 

With this in mind, I decided to start treating the game as a sketch game. The playable character had already taken place as a stickman, which follows the trend, and so I decided to take it further and really make the game its own. I designed my own sketch-like tileset on a 96x128 pixel sheet. The sheet comprises of main 32x32 pixel tiles that are cut up into their own once imported into Stencylworks.


Tileset

To apply the finishing touches to this concept and roll with it, I snapped a photo of crumpled paper to use as a parallax scrolling background:

Unfortunately, this background became too small to use as a parallax scrolling background, and not suitable enough to use as a repeated background. I knew that I wanted to stay in keeping with this idea so I sourced out a open source tileset site and choose from there so that I may achieve a fluent repeating background.

Obstacle Design

In order to come up with ideas for levels for the game, I have had to come up with just a few lifeless mobs and obstacles that will pose a threat to the player. With this concept in mind, it's the levels that are designed around the defined obstacle 'courses'. Below are a few designs for a couple or periodically spawning mobs:

Shooter

This actor will spawn and shoot projectiles across the screen until they collide with something. If it hits a player, the player will die and reload. If it hits a wall, it will shatter or explode. Initially I decided on daggers, though I went back on the idea and followed with a cannon shooting cannon balls.

Spikeballs

These are a few design ideas for the spawning, rolling balls that are designed to wipe out the player on contact. They will be spawned from a flashing spawn point and have them move across the screen on a set path. 

The player will be expected to avoid the rolling balls by either jumping or moving amongst them in time with their motion.

Final Designs

Cannon:

Spikeball & Spawner: