HTML5 Game Development with ImpactJS

5 (1 reviews total)
By Davy Cielen , Arno Meysman
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Firing Up Your First Impact Game

About this book

ImpactJS is a JavaScript library specially geared towards building 2-dimensional games. It is intuitive and versatile and allows the game developer to get results in no time while keeping an easy overview when games grow more complex. Games built with ImpactJS can be published on websites and even as an app on both Android and iOS.

With "HTML5 Game Development with ImpactJS", building games for the Web and app markets has never been so easy. Using the ImpactJS JavaScript engine, you only need this book and basic knowledge of JavaScript in order to build and publish your own game.

"HTML5 Game Development with ImpactJS" allows a single person to build a full game. Using only basic knowledge of JavaScript and this book, you will end up publishing a 2D game for the entire world to enjoy. You will learn to set up a working environment and gather all the necessary tools and resources your game needs. Develop both a top-down and a side scroller game, integrate physics such as gravity, and deploy your game as an app or to your website.

Publication date:
March 2013


Chapter 1. Firing Up Your First Impact Game

Now that we have seen in the Preface why the Impact Engine is a good choice for game developers, it's time to get to work. In order to develop a game, you will first need to set up your work environment. Just like a painter who needs his brushes, canvas, and paint, you will need to set up your code editor, server, and browser. By the end of this chapter, you will have equipped yourself with all the tools you need to start your adventure and even run a game on your computer.

In this chapter, we will cover the following topics:

  • Setting up your own local server by using XAMPP

  • Running a premade game on this server

  • A short list of script editors you can choose from

  • Debugging your game using browsers and the ImpactJS debugger scripts

  • Some interesting tools you should consider for helping you create your game


Installing a XAMPP server

When developing anything at all, be it an application, a website, or a game, the creator always has a staging area. A staging area is like a laboratory; it is meant for building and testing everything before showing it to the world. Even after releasing a game, you will first make changes in the laboratory to see if things don't blow up in your face. Blowing up in your own face is fine, but you don't want this to happen to your gamers. Our staging area will be a local server, and during the course of this book we will use XAMPP. The X in XAMPP is an indication that this server is available for different operating systems (cross environmental, hence X).

The other characters (AMPP ) stand for Apache , MySQL , PHP , and Perl . You can install XAMPP on Windows, Linux, or Mac depending on which version you download and install. There are alternatives for XAMPP such as WAMP (for Windows) and LAMP (for Linux). These alternatives are fine too, of course.

Apache is the open source web server software that enables you to run your code. MySQL is an open source database system that enables you to store and query data with the SQL language. PHP is a language that is capable of connecting the SQL commands (which can manipulate a database) to the website or game code (JavaScript). Perl is often called "the Swiss army knife of programming languages" because of its versatility in uses. Installing a XAMPP server is rather straightforward.

You can go to the following website and download the appropriate installer for your system:

After installing the XAMPP server, which is basically going through a standard installation wizard, it is time to check out the XAMPP Control Panel page.

In this panel you can see the different components of the server, which can be switched on and off. You will want to make sure that at least the Apache component is up and running. The others can be on too, but Apache is absolutely necessary for running your game.

Now go to your browser. During the course of this book we will be using the Chrome and Firefox browsers. However, it is recommended to also install the latest Internet Explorer and Safari browsers for testing. In the address bar simply type localhost. Localhost is the default location for a locally installed server. Do you see the following XAMPP splash screen?

Well congratulations, you have successfully set up your own local server!

A known issue is the occupation of your necessary ports by IIS (Internet Information Services). You might have to disable or even remove them in order to free your ports for XAMPP.

For MAMP (M stands for Mac), it is possible that you will need to specify the port 8888 in order for it to work. So type localhost: 8888 instead of just localhost.

Summing up the preceding content, the steps will be as follows:

  1. Download and install XAMMP.

  2. Open the control panel and start Apache.

  3. Open your browser and type localhost in the address bar.


Installing the game engine: ImpactJS

The next thing you will need is the actual ImpactJS game engine, which you can buy from the ImpactJS website at or which comes as a package with AppMobi on the AppMobi website at

Regardless of where you buy the engine, you will be looking for a (zipped) folder filled with JavaScript files. This is essentially what ImpactJS is, a JavaScript library that makes it easier to build 2D games in an HTML environment.

Now that you already have your server up and running and you have acquired this ImpactJS engine, all you need to do is put it in the correct place and test whether it works.

In the ImpactJS version (v1.21), at the time of writing this book you get one folder called impact and one license.txt file.

The license file tells you what you can and cannot do with your purchased Impact license, so you would be advised to at least read it.

The impact folder itself consists of more than just the Impact game engine; it also includes the level editor. The folder structure should be able to hold all your future game files.

For now, it is enough to know that you can copy the entire impact folder to the root location of your server.

For XAMPP this should be: "your installation location"\xampp\htdocs.

For WAMP this is: "your installation location"\wamp\www.

Let's also make a copy of this folder and rename it to myfirstawesomegame to make it a little more personal. Now you have the original folder that we will use later in Chapter 3, Let's build a Role Playing Game and Chapter 4, Let's build a Side Scroller Game next to the new folder called myfirstawesomegame.

You should also have the following folder structure in both your XAMPP installation location as \xampp\htdocs\myfirstawesomegame and your WAMP installation location as \wamp\www\myfirstawesomegame.

In the myfirstawesomegame folder there should be the lib, media, and tools subfolders and the index.html and Weltmeister.html files.

Time for a little test! Just go to your browser and in the address bar type localhost/myfirstawesomegame.

The it works! message should now fill your heart with joy! If it doesn't appear on the screen, something went horribly wrong. If you don't get the message, make sure all your files are present and are in the correct location.

ImpactJS comes with a physics engine called Box2D. Check if you have this folder somewhere in your folder structure. If not, you can download a demo game that has the engine included via the personal download link that you got for downloading the Impact engine. This demo is a game called Biolab Disaster and here you should be able to find the box2d folder. If not, Dominic (the creator of ImpactJS) also made a separate folder called physics available. Since Box2D is a plugin for the standard engine, it is best to search the plugins folder in your lib folder as shown in the following screenshot and drop the box2d folder in here.

Summing up the preceding content, the steps are as follows:

  • Buy the ImpactJS license and download its core scripts

  • Put all the necessary files in a newly created folder called myfirstawesomegame in your server directory

  • Open your browser and type localhost/myfirstawesomegame in the address bar

  • Download the Box2D plugin and add it to the plugins folder on your own server


Choosing a script editor

We now have a server up and running with the ImpactJS game engine installed but we don't have a tool yet with which we can actually write the game code. This is where the script editor comes in.

For choosing the right code editor to suit your needs, it is best to make the distinction between a pure editor and an IDE. The IDE or Integrated Development Environment is both a script editor and a compiler. So this means that in one program you can both change and run your game. A script editor on the other hand is just for changing the script. It won't show you the output but will, in most cases, tell you in advance when you are about to make a syntax error. While the editor will show you syntax errors in your JavaScript code, actually executing the code will reveal logical mistakes and give you something (pretty) to look at.

For ImpactJS there is an IDE called AppMobi, which is free but charges for extra services. The alternative to using AppMobi is the XAMPP server you just installed.

Script editors, even very good ones, often come for free. Some nice ones you should check out before choosing the one you like are Eclipse , notepad++, komodo edit , and sublime edit 2 . For Mac specifically there is Textmate , which is an often used editor but it doesn't come for free. And of course Xcode , the official apple developer editor.

All of these script editors will check for mistakes you make in the JavaScript code, however, they don't check for ImpactJS specific code. For this you could make your own script color coding bundle or download one from those who took the time to build one.

Download and install a few of the previously mentioned script editors and pick the one you like best. All of them will do the trick just fine, it's just a matter of preference.


Running the premade game

It's time to get a game up and running on your PC. In order to do this you will need the files that come with the book. These can be downloaded from the following site:

Now you should have everything. Copy the downloadable material for Chapter 1, Firing Up Your First Impact Game. Replace the index.html and main.js scripts that come with the ImpactJS library with the index.html and main.js scripts, which you can download from the Packt Publishing's download page. Also overwrite the media, entities, and levels folders on your PC with the ones provided.

Return to your browser and reload the localhost/myfirstawesomegame link. Lo and behold! A fully functioning ImpactJS game! In case you still see the it works! message as shown in the following screenshot, you might have to clear your browser cache or refresh the page a couple of times before the game shows up. In case something else is wrong, we will find out when we learn about debugging.

Summing up the preceding content, the steps are as follows:

  • Download the necessary files from the packtpub download server and put them in the correct location on your own server

  • Open your browser and type localhost/myfirstawesomegame in the address bar


Debugging your game with the browser and ImpactJS

Before you can debug the game, the least you should know is the general structure of ImpactJS code. As you might have noticed, ImpactJS has a main script that is used for actually steering the entire game. The main.js script includes all other necessary scripts and the ImpactJS library. Every script it includes represents a module. Like this, you have a module for every level and entity in the game. They are like Lego blocks, brought together in one big (main.js) castle. Indeed, the main script, as shown in the following code snippet, is a module in itself, requiring all other modules:



Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at If you purchased this book elsewhere, you can visit and register to have the files e-mailed directly to you.

If you take a look inside a level script you will find it to be written in JSON (JavaScript Object Notation), which is a subset of object literal notation . JSON and normal literal differ from each other in the following ways:

  1. The JSON keys are strings encapsulated in double quotes.

  2. JSON is used for data transfer.

  3. You cannot assign a function as a value to a JSON object.

More in-depth information about JSON can be found on Literal is used throughout ImpactJS and looks like the following code snippet:

  EntityPlayer = ig.Entity.extend({
    size: {x:20,y:40},
    vel: {x:0,y:0},
    health: 400,

Properties are defined with the colon (:) and separated by a comma (,). In normal JavaScript, this is done differently as follows:

if(ig.input.state('up') || ig.input.pressed('tbUp')){
  this.vel.y = -100;
  this.currentAnim = this.anims.up;

The equal sign (=) is used to assign a value to a property and the semicolon (;) is used to separate different properties and other variables.

Summing up the preceding content, the conclusions are as follows:

  • Three types of JavaScript notations are used by ImpactJS: JSON, literal, and normal notation

  • ImpactJS level scripts are in JSON code

  • ImpactJS makes use of both literal and normal JavaScript notations

Debugging with the browser

While writing code with your freshly installed script editor, you will notice that JavaScript syntax mistakes can be avoided immediately since the editor will tell you what is wrong. However, some mistakes can only be found when actually running the code in the browser. Maybe you didn't want that princess to go up in flames when the hero saves her, but unintended results do happen. This means you should at all times have your browser open so that you can reload your game over and over until everything is to your liking.

However, when your game crashes or doesn't even load completely, it can be a real pain to find the cause. Even when changing small chunks of code at a time, errors can pop up at unexpected places.

For this purpose both Firefox and Chrome have good tools at their disposal.

Firebug – the Firefox debugger

For Firefox you can install the Firebug plugin, a decent JavaScript debugger that will tell you on which lines of code your mistakes are, and has an easy explorer for the DOM (Document Object Model) of your game. The DOM is basically the structure of your HTML document containing all the entities and functions; having a good insight into the DOM is a must.

This DOM explorer is extremely useful for checking values of certain variables such as the health of your hero or the number of enemies on the screen. Mistakes that cause your game to crash will be easy to find with a debugger (both Firefox and Chrome). But in order to discover that you've added two extra zeros at the end of your enemy's health (so those creatures just won't die!), you will need to explore the DOM.

Chrome debugger

For Chrome you don't even have to download a plugin because it comes bundled with its JavaScript console. This console can be found under Options | Extra | JavaScript console and is a dream to work with. You can also bring up the console by right-clicking on your webpage and selecting Inspect element.

The Chrome debugger (also called Chrome developer tools) has eight tabs of which four are particularly useful for debugging Impact games.

The Elements tab allows you to inspect the HTML code of your page and even edit it on the spot. This way you can, for instance, change the canvas size for your game. You have to be aware though that changes are made only to the loaded web page; they are not saved to your HTML or JavaScript files.

In the Resources tab you can look up information about your local storage. Local storage is not necessary for building a game but it is a cool feature used for saving high scores and the like.

The Sources tab is extremely useful because it allows you to inspect and change (again temporarily) your JavaScript code. You can find your DOM in this tab like you would in Firefox. Code can be paused manually or by the use of conditional breakpoints. If, for instance, your character can gain experience, you can pause the game when leveling up to see if all variables take the value you expect them to.

The most important part of the debugger is the Console tab. The console shows where your errors are and even indicates the JavaScript file and line on which they occur. The console is pretty versatile such that it can be called while any other tab is open. This way you can check your code in the Sources tab and if you have errors, call the console by clicking on the X icon in the bottom-right corner. With both the Sources and Console tab opened, debugging becomes a walk in the park.

The other four tabs are the Network , Timeline , Profiles , and Audits tabs. They are useful but you will be spending most of your time with both the Sources and Console components opened.

During the course of this book, Firebug and Chrome debugger can be used interchangeably.

Changing your game and reloading your web browser is often not enough if your caching is enabled. As long as your game is cached, you are not 100 percent sure whether you are evaluating the latest version of your game or a previous one that the browser had locked in the memory. When developing games, it is wise to turn caching off. In Firefox it can be done by downloading and using a plugin that does just this. In Chrome it is simply an option of the Chrome developer tools itself. When the debugger is open, click on the cog-wheel symbol in the bottom-right corner to open the settings. Under the General tab you can disable the cache as shown in the following screenshot:

Debugging can be done in a single browser but it is wise to test whether your game runs smoothly at least on four browsers such as Chrome, Safari, Internet Explorer, and Firefox. With these four you cover at least 95 percent of browser usage.

Testing for certain devices will also be necessary if you want to launch a game for them. This can be done by owning one of the devices on which you want your game to work (for example, an iPad, iPhone, HTC, Galaxy, and so on) and placing your game online with the help of a web hosting company such as Alternatively, you can use AppMobi, which features a device viewer for this purpose.

Another great way to test your game is by using emulators. Emulators are programs that will simulate being an actual smart phone. This is all well and good but let's look at a practical example.

Exercises in debugging with Chrome and Firebug

In the previous sections we got the game up and running. Now let's see what happens if something is actually wrong (provided everything worked fine until now).

We need some flawed code files first. So copy the main.js, player.js, projectile.js, and enemy.js scripts from the debugging tutorial folder and replace the old ones with these scripts. main.js should be located in your game folder, and enemy.js can be found in the entities folder.

Now that your special (read: faulty) scripts are in place, it's time to restart the game. Reload your browser and make sure the cache is empty, otherwise no mistake will be shown.

The game does not load completely as you can see from the following loading bar:

This might happen to you regularly while working on a new game. This will, for instance, always occur if the dependencies of the different JavaScript files are wrong. To see what happened now, open the Chrome debugger.

Go to the Console tab and check out the error message: i is not defined main.js:51. Open the main.js script in your editor at the indicated line number. And sure enough, there is something wrong as shown in the following code:

i.input.bind(ig.KEY.UP_ARROW, 'up');

There is no object called i, this is supposed to be ig like the others.

Now that we fixed this issue, reload the game again. It loads! Great! This does not, by definition, mean everything is without errors. Open the debugger and see if anything else is bugging your game. Not at the moment, so let's get to exploring.

If all goes "well", your game should hang the moment you wanted to walk to the left.

You get the message, Cannot read property 'pos' of undefined. The problem is it's so hard to locate where the error actually occurs because an error seems to show up in almost every script. However, what we do know is that pos is a parameter of an entity and that we have pressed the left button before the error occurred. We should at least check all places where this left button is defined or used.

If you open the player.js script, you will find that the commands for moving left are rather peculiar as shown in the following code:

else if(ig.input.state('left') || ig.input.pressed('tbLeft')){
  this.vel.x = -100;
  this.currentAnim = this.anims.left;

So the entity moves to the left, has its animation set to left, and then kills itself. Throwing around the random kill() functions is not a good thing. In this case, the unexpected spot for the kill() function caused the player to disappear and thus the player has no more position, which created errors further down the update loop of the game. Remove this kill() function and no more game crashes should occur.

So sometimes the console shows an error, but it's still your wits that will lead you to the root cause. The console is only a tool, you are the real mastermind.

We have removed all major bugs because Chrome does not indicate bugs at the current moment. Make sure to check all levels since different levels often have other entities that might be buggy. However, for now, let's get to killing some enemies!

You might have noticed that it's considerably hard to destroy one of those nasty creatures. We don't have any real errors anymore, but maybe something else is not going according to the plan. We can't seem to kill it, so either we don't cause enough damage or it has an enormous amount of health. Let's dive into the two entities that might be involved: projectile and enemy. We should check the projectile entity and not the player entity because even though the player shoots the projectile, it's the projectile that does the damage. Guns don't kill people, bullets do. Open the projectile.js and enemy.js scripts, which are both in the entities folder. Alternatively, you can open the Chrome debugger and select the files under the Scripts tab.

In the projectile.js script, look for the following code:

check: function(other){
  if( == 'enemy'){other.receiveDamage(100,this);}

We will dive into the specifics of this code soon. For now it is enough to know that a bullet does 100 damages upon impact with an enemy.

Now check out the health of the enemy in the enemy.js script. The following code shows the health:


Yes. That's a problem. The enemy is a thousand times stronger than intended. Change the health to 200 and you will be able to kill your enemy with two shots. Alternatively, you can set the damage of the projectile entity to 100,000. Changing the damage property to a large number can be useful in order to appeal to players who prefer to see big numbers over modest ones. (those who ever played World of Warcraft know what I'm talking about).

If you save the code and reload the level, you should have no more problems killing your enemies.

An alternate way of finding out what might be wrong is by taking a look at the individual entity by exploring the DOM. Let's use Firebug for this. If you don't have it installed on your Firefox just yet, Google it and install it.

We shot the enemy twice and found out he has no intention of dying. Instead of checking the code, we can have a look at the spawned entity itself by navigating through the DOM. To find the enemy's health you must open your Firebug by pressing the bug symbol in your browser and then select the DOM tab. Now open the ig, game, and entities folders in that order. You will see a numbered list, the number being the position of a particular entity in the entities array. You can now open some of the numbers until you find the enemy with 19800 as the health value, as shown in the following screenshot:

The enemy is buried in a list of other entities, but by his properties we can see what is going on here. We shot it twice and now it has a health value of 19800. That makes sense because the damage of the projectile is 100.

Mastering the DOM takes a bit of effort but it is very useful to find out if your code works as intended. In addition, you get a better insight on how the core elements of ImpactJS are related to each other. It's recommended to spend some time here to get a feel of the overall structure before proceeding.

So we have seen three different types of errors, which rank from easily solvable to rather difficult to find and fix. In the first scenario, the console tells you that there is an error at one spot and you go and set it right. The second scenario shows the game producing errors on several spots at once with a single root cause. It is up to you and your logical brain to deduct what crashed the game. Finally, we have the unexpected results, which are not really errors. The console doesn't show an error for these because it can't read your mind (maybe in a next version, who knows). These are hardest to find and will take some testing from your side.

Summing up the preceding content, the conclusions are as follows:

  • Both Firefox and Chrome features are very capable debuggers.

  • Firebug is especially recommended for exploring the DOM of a game.

  • Chrome has eight interesting components of which the most useful one is the console, which detects errors.

  • Errors can come in different types: syntax errors, code logic errors, and game logic errors.

  • Most syntax errors can be detected preemptively by a good script editor.

  • A simple syntax error will show up in the debugger console as a single line error. This makes it easy to locate and repair.

  • Code logic errors can be hard to detect since the syntax is often correct at its root but will show errors on other locations.

  • Game logic errors are very subjective errors since they will not make the game crash but result in poor gameplay.

Debugging with ImpactJS

ImpactJS itself comes with a debugger built into the engine. However, it is turned off by default and can be turned on by making a small modification to the main.js script. The main.js script is (as the name suggests) the main script of your game and calls all your other JavaScript files. It is this script that is loaded into the HTML canvas in your browser and is looped through over and over again in order to make your game run. The main.js script can be found in the game folder and should have come together with your Impact license, as shown in the following code snippet:


Everything starts with the ig (Impact Game) object. This object is what you will be looking for in your DOM when you are debugging your game and checking variables and functions. In the main.js script, there is a call to the .module function, which defines game.main to be a module of your game. The module name needs to be the same as its location and filename! So the JavaScript file lib/game/entities/bigmonster.js will be finally defined as game.entities.bigmonster. Adding the debug panel to the game can be done by following these steps:

  1. The .requires() function calls all the scripts it needs to be able to execute the code successfully. Not every module will need this but the main.js script will always at least require the impact library.

  2. It is in this function call that you will want to add the impact.debug.debug script, which (as you guessed) calls the script debug.js in the folder lib/impact/debug.

  3. Save the main.js script and rerun localhost/myfirstawesomegame in Chrome.

  4. If everything goes according to the plan, you should now see a new toolbar at the bottom of your browser called impact.debug.

  5. The debugger has three tabs: Background Maps, Entities, and Performance and four key indicators in the top-right corner.

  6. These indicators from left to right are as follows:

    • The number of milliseconds needed to run one frame of the game.

    • The fps indicator or frames per second of the game.

    • The number of draws that have taken place. This includes characters if you have a conversation going on.

    • On the right-hand side you find the number of entities currently in the game.

While these indicators quickly show you the most important things to take into account, the three tabs as shown in the following screenshot go somewhat more in depth:

If you select Background Maps, you will see all the graphical layers the game has. Let's say you want to run in front of a tree with your epic character; you will expect part of the tree to disappear behind the character and not vice versa. When the character moves behind the tree you will want it to be hidden by it. So you see, you need at least two layers in order to draw a tree like this. One layer comes in front of the player (most likely the treetop), the other behind it (the trunk).

In the part of the debugger, as shown in the following screenshot, you can turn layers on and off. If a layer is set to be prerendered, you will be able to see the chunks of the layer. In the following screenshot, Checks & Collisions is turned on while the other options are turned off:

With the Entities tab you can turn several interesting indicators on and off. If you turn on Show Collision Boxes, you will be able to see a red box around your character and several (invisible) entities that constantly check for collision. These red boxes indicate the borders at which the point collision is triggered. This is important because if the collision box around your hero character is much bigger than the image, he might not fit through doors anymore or get mysteriously hit by enemies who are still far away. You can set the size of these collision boxes yourself when writing your code, allowing for some interesting effects, such as only being able to kill a boss by shooting him in the eyeball.

When you turn on Show velocities, you should walk around with your character. You will now see a line sticking out in front of him, which is an indication of how fast he is currently going.

By showing names and targets you can see all named entities and their targets. It's a fun feature but you are better off with the ImpactJS level editor (Weltmeister) for your purpose.

Finally the Performance tab shows you how much effort goes in the different tasks that the browser needs to perform for running your game, as shown in the following screenshot:

Two horizontal lines are visible on the previous chart: the 33ms and 16ms lines. These lines correspond to an approximate frame rate of 60 fps and 30 fps. Having a game run below 30 fps is inadvisable since it will look as if the game is lagging, and there is no fun in playing such games. If you see that your game lags, check which part is taking all the juice and try to fix that.

In most cases, drawing the game (graphics) takes up most of the resources. This is indicated by Draw in the Performance tab. If this happens, try to work with fewer layers or bigger tiles. Also prerendering can increase performance in this case.

Another part of the resources is taken up by your entities and how they interact. If you have thousands of different entities swarming over your screen because you decided that a flock of seagulls should be represented by a separate entity for each bird, you might get into trouble quickly.

There is a separate indicator for system lag, which is a parameter you have no power over since this shows how well the browser performs. Quite regularly the system lag creates spikes that drop the frame rate. However, in most cases it cannot really be felt because the really huge spikes come and go so quickly.

Summing up the preceding content, the conclusions are as follows:

  • ImpactJS comes with its own debugger but is turned off by default

  • The debugger has several components that allow insight into entity behavior, collision, and game performance

  • ImpactJS debugger is extremely useful for tracking performance issues and should always remain turned on during development


Which helpful tools are out there

If you have a decent script editor, the ImpactJS library, a (local) server, and a browser with debug capabilities, you are set to build an ImpactJS game. However, there are several interesting tools out there that can facilitate your journey quite a bit. There is Ejecta that comes with ImpactJS and is a more efficient way of releasing games for iPhone and iPad. AppMobi is a great tool for preparing your game for the webstores. PhoneGap is an open source framework for creating apps. With lawnchair you can more easily make use of local data storage. There is Scoreoid , a free game cloud service. And finally Playtomic —a game analytics tool. In this chapter, we will take a short peak at each one of these.


Ejecta is a fine piece of ingenuity, which is free to download at the following link:

It totally replaces iOSImpact , which was a way of preparing the game as a native app for the Apple store. Dominic calls Ejecta a "browser without the browser". It has no overhead, only the canvas in which your game features and the audio elements.

Ejecta works well for ImpactJS but it can be used for other apps as well. Like the former iOSImpact, it makes use of OpenGL for the animation and OpenAL for the audio, which drastically increases game performance. If you plan on releasing your game to the iPhone, Ejecta is certainly worth taking a look at.


AppMobi offers an XDK (Cross platform Development Kit), which goes very well with ImpactJS. So well that they actually have a separate development kit for ImpactJS (Impact XDK) apart from their normal one (AppMobi XDK).

Use of the development kit is free but extra services such as their cloud service, live update features, and secure payment are available for an extra fee. You can find everything on

The Impact XDK will only allow you to work on an Impact Game if you have registered your Impact key in your account and included their JavaScript library. When set up properly, the XDK allows you to simulate several devices such as iPad, iPhone, Galaxy, and so on. The XDK only runs in Google Chrome, though that isn't really much of a weak spot. You can open a script editor, but it is in no way as good as the ones we looked at before. You have the option of calling a debugger but it is just the Google Chrome debugger, not one they built themselves.

The Apphub (which is your control center) allows you to build and test apps before sending them to the shops. In order to release a game you will, of course, still need the developer accounts for the platform you want to service.

AppMobi also has what they call direct canvas acceleration , which increases the game's performance by bypassing the canvas element of your games. It is very similar to what Ejecta does but then it is delivered by AppMobi.

The following screenshot is an overview of the different terrains that AppMobi can provide, which will give relief to some developers. While AppMobi is only of limited use while scripting your game, it can provide excellent support during testing and deployment.

There is no possibility of directly connecting to a mobile device. However, you can send a link to anyone who owns one. This way your friends can test your latest creation if they have the AppMobi applab installed.

All in all, AppMobi is easy to get started with and certainly worth considering if you want some help with the entire process of releasing a game, though for development you are almost entirely on your own.


PhoneGap (formerly known as Cordova ) is another XDK for developing mobile-native applications.

PhoneGap can be compared to AppMobi with respect to functionalities but AppMobi is very visual and more newbie-friendly. PhoneGap enables you to build apps that are native to the OS (operating system), integrate PayPal , and use push notifications.

As shown in the following screenshot, PhoneGap provides a way to build your app in order to distribute to the different channels:

Getting started with PhoneGap is a bit more complicated than AppMobi. You will need to install eclipse (which is free), the android development tools, and SDK. Installing Git might be necessary for targeting specific platforms. If you want to release for iPhone or iPad, you will also need xcode .

In all, it's definitely worth taking a look at. Luckily they have very good documentation because it tends to get a bit complicated. More information can be found on


lawnchair offers a free and easy way of using local storage . Local storage is used for storing your data (saving files and high scores) on devices that run your game.

There are many advantages in saving everything on the client side over saving on the server side. For one, you don't need to know SQL. Websites save everything in their databases by the use of SQL, PHP, and JavaScript. If you use local storage, you only need JavaScript. The amount of storage space is not restricted by your server but by your user. So if you have many gamers who each use a small amount of space, you will never get into trouble with local storage while you might get into trouble when solely using server storage. Since it doesn't need to be transmitted to a server at all times, you can play your games offline and still keep your saves.

Those are all pretty good advantages but how does lawnchair work? lawnchair is a JavaScript library just like ImpactJS (but a free one this time). You only need to include it with your other JavaScript files and you can start using the specific commands to save data.

Including the lawnchair functionalities can be done by downloading the library from and including the lawnchair.js script in your index.html file as shown in the following code example:

    <title>my osim app</theitle>
    <script src="lawnchair.js"></script>
    <script src="app.js"></script>

lawnchair uses JSON to save data in the DOM of your game. If you want an example of what this looks like, you can open any ImpactJS level script in the code editor of your choice since these scripts are also coded with JSON.

You will want to take a look at lawnchair if your game is going to require save games, high scores, game progression, or any other option that needs to be kept track of so the player wouldn't need to start all over. More information can be found on


Scoreoid is a gaming cloud service aimed at taking care of some advanced features such as leaderboards , player login , and ingame notifications .

In order to use Scoreoid and its functions, you need to register on their website and implement their code within yours where necessary. There are different codes for different functions. The following code snippet is an example template for storing information about people loading your game:

$.post("API URL",{api_key:"apikey",game_id:"gameid",response:"xml"},
    alert("Data Loaded: "+ data);
    console.log("Data Loaded: "+ data);

You fill out the API URL, your own API key , game ID , and the type of data coding for transferring (XML or JSON) and you're good to go.

An account is free but they have the option of a premium account, which is also free. But that is just because they are currently still working on defining the extra features for a premium account. You can subscribe on their website


Playtomic is the Google analytics of game monitoring.

The basic account is for free but the premium one is currently priced at $15/month or $120/year. You can subscribe on their website

Getting the flow of analytics up and running isn't too difficult. In your index.html file you include a reference to their JavaScript library as shown in the following script:

<script type="text/javascript"src="">

In your main.js script, you can then add a command to send the data to their servers as follows:

Playtomic.Log.View(gameid, "guid", "apikey", document.location);

These two pieces of code are suggested by Playtomic. However, an error might occur if you send the data to their server in plain text. Therefore it is best to replace the script type text by application as shown in the following code snippet:

<script type="application/javascript"src="">
</script> webhost

A webhost is what you will need if you want to place your own game on your own website.

You don't always need your own website since cloud hosts such as Scoreoid also allow you to put your game online. However, sometimes it's nice to have your own little place on the World Wide Web. sells web space and a domain name in one package. The price for this service is pretty ok, especially in comparison with what you need to do to get the same result. You would need to have a PC with XAMPP installed, and it should be up and running at all times. In addition, you would still have to buy a domain name if you are serious, or get a free domain from somewhere and reroute your IP to it. If your IP would remain the same at all times, this would be feasible. However, more often than not, this is a premium service of Internet providers. You can get an account at

If you want to use web hosting, more providers are out there, but downloading and installing FileZilla is recommended in all cases. FileZilla is an efficient file transfer program, which is just what you need to get all your files from your PC to a server somewhere in the desert. FileZilla can be downloaded at the following link:

Summing up the preceding content, the conclusions are as follows:

  • There are a lot of tools out there that will make your life as a game developer much more agreeable

  • Ejecta is an efficient solution for releasing games to iPad and iPhone

  • AppMobi is a free cloud tool, which can help with releasing and developing almost every distribution channel

  • PhoneGap has a lot in common with AppMobi albeit slightly more complicated to work with

  • lawnchair provides a way of addressing local data storage

  • Scoreoid is a free game cloud service, which will host your game and supply features such as leaderboard integration

  • Playtomic is a game analytics tool allowing you to tag certain elements of your game and store the data on their servers



In this first chapter we have made our preparations as a game developer. We have set up a local server, which we can use as a development and initial test environment. In order to write our code we need a script editor, so we briefly went over some of the editors out there. Debugging is one of the main skills of a programmer; for this we can not only use the Chrome and Firefox debuggers but also the ImpactJS debug module. We finished by taking a look at several very helpful tools for ImpactJS game development.

Now we have everything ready to go. We will dive into ImpactJS by messing around with a small premade example game in the next chapter.

About the Authors

  • Davy Cielen

    Davy Cielen is the co-owner of An Ostrich On Mars, a graphic design and marketing agency with a special branch of game design, graphics, and game development. He has a background in analytics, marketing, and mathematics. Davy is seriously in love with game design and web technologies.

    Browse publications by this author
  • Arno Meysman

    Arno Meysman is the co-owner of An Ostrich On Mars, a graphic design and marketing agency with a special branch of game design, graphics, and game development. Arno Meysman is a specialist at customer and web analytics using statistics and has always been very interested in game development, including graphical design. He started using the ImpactJS engine for hobby projects when it was first released in 2010.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Great book to learn ImpactJS. I just love Packt and the great prices
Book Title
Access this book, plus 7,500 other titles for FREE
Access now