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:

Character Abilities

At this point I know what I want my game to consist of, though I am not entirely settled on the overall concept. My game does not yet have a particular selling point that defines it. Currently, it is still a platform jumper that involves obstacle manoeuvring and various aspects of level control. I have a feeling it will be based around telekinesis, although I may later find myself limited by my ability to achieve such complicated tasks in development.


Manipulating Direction of Play


This section involves some paper prototyping I have undertaken. I have put down onto paper ideas I have for how the player will use objects in the game to change the direction of play and work their way through obstacles and puzzles in order to reach the end point.

Platform Control

Here, the player has the ability to move platforms 'with their mind'. Having this technique may allow the player to travel to another point deemed previously unreachable, or block a lethal object that poses a threat.

Pushable Blocks

In the above picture, I have depicted a projectile being fired from the right. In this scenario, it is assumed that this projectile will be continuously shot by a spawner and so you must push a moveable block in the path of these projectiles in order to continue in the direction specified.

Stompable Blocks

This is a concept I have stumbled across because it is included in some of the packs I have snuck a peak at on Stencylworks. In the pack, it features only as an animation, though I suspect I will use it to allow the player to smash through objects in order to progress or change the path of play. This very much plays into the sort of mechanics I am working towards for my game.

Jumping Obstacles

To add further to my idea of tackling obstacles, it may be a nice change of pace to include a 'spring pad' type actor that allows the player to gain more height than usual. I do feel, however, that if I do include this then I need probably not include the double jump feature.

Related Concepts

I've felt that the best way to come up with ideas for gameplay and artwork is to pull ideas from existing games that work well. Starting with gameplay, I already know that I'd like to make a 2D platformer, though I know very little about I am going to develop from that idea. May game needs to have a more fundamental concept, or game mechanic.


Referring to tried and testing games that I have enjoyed in recent years, the following was brought to mind..




Super Meat Boy:

I played this game after it was bought for me by a friend and came to find it very addictive. The game challenges you to navigate through obstacles in order to reach an end point and progress to the next level. A key aspect of the game is trial and error. You are pretty much expected to fail at every first attempt of navigating through a new level. This does not stunt your attitude, however, as you respawn very quickly after death without even reloading the level. It almost feels like rapid prototyping obstacle approaches! I like this approach as you are not penalised for having multiple attempts at passing a level. The emphasis is not on how skilled you are at making it through the game, but more about how you adapt and learn to smooth out your control of 'meat boy'.


A second point I favour in this game is that you are the only living, moving character throughout. The 'mobs' that pose a risk to you are static or patrolling non-living entities. I feel I may go either way with this one and have just one and not the other.




Infectonator! World Dominator:

This is one of the 10 games I reviewed, as previously mentioned. It was brought to the front of my mind when I started to consider how my game may look. Something I am keen on doing from the start of my game is to design original textures, tiles and sprites. Keeping that in mind, I would like to go with a simplistic theme that's both easy to draw and easy to hide mistakes with. This game has a 90's feel aesthetic look as the designer has chosen to go with a pixel drawing; where each pixel is drawn with a solid block of colour.




Psi-Ops

Although this game is not a 2D game by any means, I would like to employ it's core concept as a possible game mechanic for my game. The basis of this game is the ability to be able to control people and objects with your mind. I would like to have my game use some sort mind-control element with which to manipulate objects on the screen in order to pass the level.

Brainstorming Ideas

It's early days and about time to start developing ideas for a game concept. I've played and reviewed 10 games hosted on Kongregate in order to get an understanding of what works and what is popular to date. It's been quite a while since I have played flash games and I have come to notice that they have come a long way. Whilst playing reviewing these games, I have been taking the time to note what game mechanics work and how games look these days. 

After playing and reviewing recent games, I was ready to start brainstorming my own ideas. With a lot of ideas buzzing around in my head and no real direction as to where I might start; I employed the use of a few basic mind map and word association programs to get me started.

Word Association

Here is a capture of a word association map produced by Wordle:

This really is a very basic form of brainstorming, but is a nice way to kick off with some research. I copied in a few collections of text from various sites that tell you, in their own words, what a game actually is. From that, the site using a script to pull out the most relevant key words and then displays them back graphically with the bigger words holding more emphasis. Some of the words that crop up are unnecessarily obvious, yet there are already concepts emerging from terminology in there that I would not have immediately associated with 'Games'.

Mind Mapping

The next logical step was to map out some ideas about the sorts of games I could make, before even considering any limitations I might have with my knowledge of design and experience with relevant software. I decided to employ the use of a program I have used in the past to visualise ideas into a smartly laid out and annotated map.

Here is a Concept mind map made with MindGenius that merely depicts the game types I could go forward with when making a 2D flash game:

In the picture, coloured child labels are game mechanics that came up more than once for assorted game types.

What I achieved from producing this is seeing how open I am to producing an original idea should I choose to run with any of these game types. I noticed that choosing to make a 2D Platform game  would leave me open to a whole array of interesting game mechanics, as it appeared to be the least limited in what you can produce. As I am new to game making, and the design process for it, I felt it most appropriate to make my game a 2D Platform jumper - and then produce something original from that.