GameLoop 0.03 – Introduced modulation, unit and integration testing

December 16th, 2019 10:48 am |  by David.Reid  |  Posted in GameLoop development log

Last week, I restructured GameLoop into classes and released version 0.02. In my previous development log I mentioned that wrapping up the code in classes took the JavaScript 2D game engine a step closer to modulation.

This week, I’ve moved GameLoop to a modular based architecture – I use the word architecture loosely – and added some basic integration and unit tests for our main GameLoop class.

What follows is a brief overview of this weeks progress.

Modulation is now a GameLoop thing

As mentioned in the introduction I have modulated GameLoop. For anyone who has worked on JavaScript web applications before, you’ll be aware the Modules and Requires only work on serve side JavaScript applications. And, our game engine is of course web based. To overcome this minor inconvenience I’ve done the following.

First off, I’ve had to reintroduce an Index.js file that contains the following code.

let GameLoop = require('./app/GameLoop');

window.onload = function() {

    // The window.game declaration is important.
    window.game = new GameLoop.GameLoop({ 
        Fullscreen: true,
        Resources: [
            { id: "player", var: window.playerPic = document.createElement('img'), file: 'player.png'},
        ],
        MoveEverything: CustomMoveEverything,
        DrawEverything: CustomDrawEverything,
        GameReady: CustomGameReady,
        GameEnded: CustomGameEnded,
    });
    window.game.Start();
}

function CustomMoveEverything() { }
function CustomDrawEverything() {
    window.game.settings.Fx.DrawImage(window.game.GetResource("player").var, 100, 100);
}
function CustomGameReady() { }
function CustomGameEnded() { }

This file now contains the code that configures and initiates our GameLoop engine.

Secondly, I had to update the Index.html file as follows.

<!DOCTYPE html>
<html lang="en">
    
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <meta http-equiv="X-UA-Compatible" content="ie=edge">
        
        <script type="module" src='./gameloop-bundle.js'></script>
        
        <title>Game Loop</title>
    </head>

    <body onresize="window.game.ResizeCanvas();">
        <canvas id="canvas" width="600", height="600"></canvas>
    </body>
</html>

The config and initiation code has been removed from this file – as it now lives in Index.js – and we’ve replaced our script references with the following.

<script type="module" src='./gameloop-bundle.js'></script>

The file – gameloop-bundle.js – is a file generated by browserify which basically finds all the code relevant to our application and bundles it up into one file. In our case that file is gameloop-bundle.js.

We create this file by running the following command inĀ  a terminal.

browserify Index.js -o gameloop-bundle.js

This minor restructuring of our code and the magic of browserify has taken GameLoop from a collection of files into a small, very small, modulated product.

High fives all round.

We have introduced unit and integration testing for GameLoop

With the introduction of JavaScript modules, I decided that now was the right time to introduce integration and unit testing for the GameLoop.

I’m using Jasmine for testing. And in this iteration, its mostly unit tests to evaluate how the GameLoop class handles configuration data. I’ve also setup integration tests that ensure our supporting modules are wired up correctly. The latter is fairly simple at the moment as there is only one supporting module which is the Graphics class. However, that will start to change as we progress.

So at this juncture, the tests are fairly thin on the ground. However, I intend to approach future development by writing tests first, followed by implementation and finally refactoring. With the aforementioned in mind, I would expect the test cases for GameLoop to grow rapidly.

GameLoop has dependencies

So, now that we are working with JavaScript modules our product has dependencies. Personally, I’d like to keep dependencies to a minimum because I hate having a node_modules directory full of hipster named modules I’ve never heard of. However, if we want to improve the usability of GameLoop then dependencies are inevitable.

With the aforementioned in mind, what follows is a list of our main dependencies.

#1 GameLoop requires browserify

As I mentioned earlier, browserify – spot the ridiculous hipster name – bundles up all your modules into one file which is then referenced from your web page. Despite its stupid name, browserify is extremely useful and is a dependency worth having.

The only down side is we push bundling down to the developer because the game specific code has to be bundled too. This means developers have to write their specific code and then bundle the project before running/testing their game.

I guess in the future I can create some build/deployment script that does this for you but for now, bundling from the command line is a thing.

#2 GameLoop requires http/https protocol

Up to this point, we’ve been able to develop using the file:// protocol. However, the introduction of modules has changed that. GameLoop requires the developer to use the http(s):// protocol which in turn requires some sort of web server.

Although this is not a coding dependency it is a software dependency which adds to the list of things a developer must do before they start building games with GameLoop. However, like modulation, moving development to a web server is an unavoidable step. And in the long run, it allows us to produce a better game engine.

And that is pretty much it for this week. I haven’t published the latest release yet but I would expect that to happen in the next few days.

Happy coding fellow programmers.