A simple HTML5 Game tutorial – Part 1

I’ve always wanted to create a game. It seems the older I get the closer I get. This post is the first in a small series which walks you through the steps I followed to create a simple game. Here is a taster of the end result:

A simple game create using HTML's canvas and JavaScript
Screenshot of HTML5 game

Continue reading “A simple HTML5 Game tutorial – Part 1”

Advertisements

JavaScript the hoisting effect

JavaScript is one of the most talked about programming languages of the day. Being the language of the browser any modern programmer, developer or web designer cannot avoid it. It’s even sneaking onto our servers with courtesy of the node.js project. If you’re new to JavaScript there are a few ‘features’ that may trip you up, especially if you have been using a class based language. Take the following example in Java:

	public static void main(String[] args) {
		
		List<String> list = null;
		
		if((list = coloursInImage(img1)) != null) {
			
			int iNoOfColours = 0;
			
			iNoOfColours += list.size();
			System.out.println(iNoOfColours);
			
		}
		
		if((list = coloursInImage(img2)) != null) {
			
			int iNoOfColours = 0;
			
			iNoOfColours += list.size();
			System.out.println(iNoOfColours);
		}
	}

In Java the variable iNoOfColours will hold the size of the list as returned by the method ‘coloursInImage’. So if img1 has 8 colours and img2 two has 256 colours we’d see those numbers printed to the output window.

Let’s look at the JavaScript equivalent:

	var list = null,
		img1, img2;

	if((list = coloursInImage(img1)) !== null) {

		var iNoOfColours = Number();
		
		iNoOfColours += list.length;
		console.log(iNoOfColours);

	}

	if((list = coloursInImage(img2)) !== null) {

		var iNoOfColours;
		
		iNoOfColours +=	list.length;
		console.log(iNoOfColours);
	}

In JavaScript the variable iNoOfColours will hold the size of the array as returned by the method ‘coloursInImage’. So if img1 has 8 colours and img2 two has 256 colours we’d expect to see those numbers printed to the output window. However, we actually get 8 and 264. This is because of the hoisting effect – specifically how JavaScript works when handling declaration statements (var). Regardless of where a variable is declared, its declaration is hoisted to the top. The key here is to understand the declaration and initialization steps are treated separately and only the declaration will be hoisted. In our example, the first declaration also initialises the variable to 0. We then simply increment the variable’s value (zero) by the length of the array; thus, when repeating this within the second if-statement we end up summing the two. This is because the second declaration of the variable has been hoisted. The effect of which is that the expected scope does not mirror that we’d expect in Java. Something to watch out for!

JavaScript Design Pattern – Singleton Pattern

The singleton pattern is a design pattern which restricts the creation of an object to the same instance. In practical terms this means the variable defined below would be looking at the same object instance:

var object1 = new Car(),
object2 = new Car();

object2.colour = 'red';

The example above changes the colour property of object2. With the singleton pattern object1 is the same object, thus, the colour property of object1 also reflects the change. The pattern is useful when there is a need to coordinate the logic across decoupled and thus distinctly separate areas of code while maintaining access to a shared and consistent central object. Let’s look at an implementation of a singleton pattern:

function Game() {
    
    // the cached instance 
    var instance;
    
    // rewrite the constructor
    Game = function Game() {
        return instance;
    };

    // carry over the prototype 
    Game.prototype = this;

    // store the instance 
    instance = new Game();

    // reset constructor pointer 
    instance.constructor = Game;

    // default properties
    instance.lives = 3;
    instance.score = 0;

    return instance;
}

This code above creates an object called “Game”. To make sure the object is a singleton the constructor is rewritten during the object’s first invocation. This rewrite means any subsequent instances of the object simply returns the value of the instance variable. The instance variable within the object is set during the initial creation of the object prior to the new constructor being applied. Two properties are created after the line that rewrites the constructor; to repeat the above for clarity, this property creation will only be performed once for the first object.

Proving the above we can create two instances of the Game object and assert they are equal:


// update prototype and create instance
Game.prototype.player = "Greg";
var g = new Game();

// update prototype and create instance
Game.prototype.difficulty = 'hurt me plenty';

var g2 = new Game();

console.log("New player property works: " + (g.player === g2.player));
console.log("Both instances of Game are equal: " + (g === g2)); // true 
console.log("All prototype properties work: " + 
            (undefined !== 
                 (g.player && g.difficulty && g2.player && g2.difficulty)));
console.log("The initial score property works: " + g.score);
g2.score += 100;
console.log("The properties work after update: " + g.score);
console.log("The constructor points correctly: " + (g.constructor === Game));

The code above creates two instance of the Game object variables: ‘g’ and ‘g2’. The lines which follow then compare the two objects to assert the are truly equal. This will return the following result:

New player property works: true
Both instances of Game are equal: true
All prototype properties work: true
The initial score property works: 0
The properties work after update: 100
The constructor points correctly: true 

The implementation of the pattern is fairly simple. Although, the pattern does endure a fair amount of criticism. This is because the pattern implements a global space into your code which could be argued as being an anti-pattern. In my opinion used sparingly the pattern can be useful.

JavaScript Design Pattern – The Chaining Pattern

The basic theory of a chaining pattern is to call method after method of a given object without having to split the calls over several lines. Here is an example of calling several methods procedurally:

myObj.method1();

myObj.method2();

myObj.method3();
...
myObj.methodX();

And with a chaining pattern:

method1().method2().method3().methodX();

I can imagine you are asking, “What use is this? And how does it work?”. Well let us first look at a real world example. The JQuery library makes extensive use of this pattern. Take the following example for instant:

$('div').fadeOut(1800).
    fadeIn(1800).
    slideUp(800).
    slideDown(800).
    animate({height:'20px'}, 500).
    animate({width:'20px'}, 500).
    fadeOut(1800);

This implementation allows a user of JQuery to ‘chain’ together animations provided by JQuery. Very powerful! Other libraries such as ExtJS make similar use of the pattern.

To implement the chaining pattern each method must return the instance of the object being called. In other words they return the ‘this’ variable. In JavaScript ‘this’ always refers to the “owner” of the function we’re executing. Thus, this enables the next chained method to execute. A theoretical example of the above JQuery example follows:

var $ = function(selector) { 
    
    this.fadeOut = function(duration) {
        console.log('fadeOut');
        return this;
    }
    
    this.fadeIn = function(duration) {
        console.log('fadeIn');
        return this;
    }
    
    this.slideUp = function(duration) {
        console.log('slideUp');
        return this;
    }
    
    this.slideDown = function(duration) {
        console.log('slideDown');
        return this;
    }
    
    this.animate = function(style, duration) {
        console.log('animate');
        return this;
    }
    
    return this;
}

$('div').fadeOut(1800).
    fadeIn(1800).
    slideUp(800).
    slideDown(800).
    animate({height:'20px'}, 500).

This example simply prints the name of each invoked method to the console; however, it illustrates the pattern quite well.

With anything in life the pattern has advantages and disadvantages. The beauty of the pattern is that it makes the chained method read like a book: almost self documenting syntax! It is also concise and there is less to type for us busy developers. Another advantage of the pattern is that it forces us to split down our methods into smaller reusable chunks.

The disadvantages are it is harder to debug. If any of the methods within the chain fails you will only be informed that the line of code that failed is the one invoking the chain. Meaning the true error is hidden within the chained methods.

JavaScript: A private member variable design pattern

JavaScript does not include some of the common features of a class based language like Java or C++. Simple concepts such as private member variables are not available via in-built syntax. This can result in the global scope becoming littered with variables leading to name conflicts or variable corruption.
Continue reading “JavaScript: A private member variable design pattern”

Eclipse, Java and a Rest API – An introduction

In this post I want to introduce a few real world tools and programming examples to anyone who is fed up with the hundred-and-one ‘Hello World’ examples.  More often than not, tutorials have little substance and leave students feeling that they want more.  My goal is to introduce several hot-industry topics which could help beginners on the path to becoming a software programmer. Continue reading “Eclipse, Java and a Rest API – An introduction”

Puzzle

Software Disconnect

The other day I attended a half-day (three hour) seminar on Practical Project Management. Although the seminar was very good the events of the day surrounding the seminar made me shake my head in disbelief. The disbelief came from my tendency to analyse and pick fault with computer systems: I am a computer programmer after all! Read more

Software bugs – here to stay?

Great Little Computer!Being a software developer I’m pretty ophey with the term ‘bug’. In fact, I do believe the term is used daily within my day job. Historically this term had an entirely different meaning outside of software development. However, in parallel with the app explosion the term has made it into the mainstream. An even more disturbing trend is that consumers now seem to accept that software has bugs. I am not convinced this was always the case! I remember spending hours of my youth bashing away on my Amstrad CPC464 attempting to conquer the latest 2D game. I do not remember these crashing or the need for me to upgrade to version 1.x and beyond. Does this mean that software programmers of yesterday were a smarter animal than today’s crop?

Read more

HTML5’s Canvas – A physics’ Race

Cars in motion HTML5I fancied stepping into the unknown with my next HTML5 and canvas project. I’ve always been fascinated by the laws of physics and the programmatic approach one would take to manage this within a software project. As my knowledge on this subject only extends to my education at school, I decided to attempt to carry out the basics of a car race animation using the basic equation for a particle in motion e.g. x = x0 + (v0 * t) + (1/2 * a * t^2). Continue reading “HTML5’s Canvas – A physics’ Race”

Managing code quality

It’s fair to say that the quality of your code has a direct correlation to the success of your product.   Products crafted to a high quality using proven techniques and industry accepted standards have a better chance of succeeding.  This applies to any field; be it. car production, joinery and  most certainly software development. Read more