By now we have seen what the canvas element is, how to use it and seen some effects that can only be created using the canvas. Now it's time to start creating a framework that will allow us to use the canvas element to create a simple game.
Before we jump into the code, first take a look at the demo that will be created through the next few articles. On the surface it looks exactly like the demo from the second article, but rest assured that behind the scenes there is quite a bit of work that has been done to create a base framework that will more easily allow us to create the final game.
The code that will be presented uses JavaScript as an object oriented language. Unless you have done a lot of JavaScript programming this may seem odd at first. I recommend that those not familiar with the object oriented capabilities of JavaScript to read this tutorial, hosted by the Mozilla developer centre. It will get you up to speed on some of the programming techniques that will be used here.
Conceptually the framework will be split into two parts: the classes that deal with the underlying 2D engine (i.e. the code that handles the canvas, render loop, input etc), which will be referred to as Engine classes, and the classes that will create the objects that actually make up the game, referred to as Application classes. Since the Application classes are built on top of the Engine classes, we will focus on creating the Engine classes first.
Main.js
If you have studied the code from the previous examples you will see that a lot of that code exists in the Main file. First some global variables are defined. [code]
And, like before, we set the init function to be run once the page has been loaded. [code]
In the init function we create a new instance of the GameObjectManager class. [code]
You will notice that we call the startupGameObjectManager function on the new GameObjectManager instance. The startupClassName function will be a reoccurring theme in this and upcoming articles. These functions effectively serve as the constructor of the class, and this is done for two reasons.
First is that JavaScript doesn't support function overloading (at least not easily). This is a problem when you want to have more than one constructor. By offloading the construction to another set of functions (e.g. startupClassName1, startupClassName2) it is quite easy to define several different ways to construct a class.
The second reason (and this is more of a personal preference) is that I constantly found myself referencing variables from the constructor that were not already defined. This is more a hang over from my own personal experience with languages like C++, Java and C# where the location in the source code where a class variable was defined had no impact on it's visibility in the constructor function. Take the following example in C#.
class Test
{
public void Test() {this.a = 5;}
public int a;
}
This code is legal and works fine. Now take the same example in JavaScript.
function Test()
{
this.a = 5;
var a;
}
The issue here is that the local variable a does not exist at the point where we try to assign the value 5 to it. It will only exist once the code var a; has been run. While this is a fairly contrived example, it does highlight the problem I ran into. However, by keeping the construction of the class in a function like startupClassName, and defining (but not initialising) the local variables in the constructor, I could be certain that the variables I was referencing in these construction functions did actually exist.
