- slide 1 of 3
In part one we created the GameObjectManager class, which managed rendering to the canvas and allowed GameObject classes to update and draw themselves. Now lets take a look at the GameObject class.
The purpose of the GameObject class (an Engine class) is to define some properties that are common to all objects that will be present in the game. These include the position (x and y), and depth (z). Note that you will not create a GameObject class directly, but instead create a class that extends it.
The x and y positions are quite straightforward - they simply define the position of the GameObject along the x and y axis. The z position defines the depth of the GameObject. This is important because GameObjects with a smaller z value are drawn to the canvas first, and therefore they are drawn underneath GameObjects with a larger z value.
As was explained in part one, all classes initialise themselves in a function called startupClassName, and so the GameObject class has a function called startupGameObject. Its here that the variables are initialised, and the GameObject is added to the list of GameObjects maintained by the GameObjectManager via the addGameObject function. [code]
The shutdown function cleans up the GameObject. Here this means that the GameObject removes itself from the GameObjectManager list via the removeGameObject function. [code]
The ViusalGameObject Engine class extends the GameObject class to define additional properties and functions common to all objetcs that will be drawn to the screen. Viusal objects obviously need something to draw, and so the VisualObject class defines the image property, which will be used as a grpahical source when drawing this object to the back buffer. [code]
Additionally we need to provide some code that will actually draw this object to the back buffer. This is what the draw function is used for. It takes the image and copies it to the back buffer, using the x and y position defined in the GameObject class. [code]
- slide 2 of 3
- slide 3 of 3
The ApplicationManager class is the first of the Application classes, so catagorised because it is used to define how the application is run rather than defining the underlying interaction with the browser. In this case the class is very simple, creating and initialising a new instance of the Bounce class. It may seem pointless to define a class for the sole purpose of creating one object, but in more complicated applications keeping the logic associated with creating and managing the game objects will make more sense.
The Bounce class is the second Application class. It extends the VisualGameObject class because it is a game object that will draw itself to the screen. The Bounce class displays an image that will bounce around the screen, much like we did in this article. This is where the hard work we put into all the pervious classes starts to pay off.
The startupBounce function takes an image, and then initialises the base classes by calling startupVisualGameObject. [code]
The update function (which will be called by the GameObjectManager during the render loop) updates the position of the image, reversing direction when it hits the edge of the canvas. [code]
And that is it. You will notice that there is no code related to drawing the object: that is taken care of by the draw function of the base VisualGameObject class. And because the VisualGameObject class extends the GameObject class, we know that the update and draw functions will be called once per frame. All the code in the Bounce class is related to the logic that we need to define to make the image bounce, which in this case amounts to modifying the x and y variables.
OK, so we have created half a dozen classes to achieve the same effect that we had produced initially with one file. But this foundation will allow us to get on with the task of creating the game without having to worry about all the underlying logic related to drawing to the canvas and managing the game objects.