This forum is read only and just serves as an archive. If you have any questions, please post them on

7 years ago by collinhover

Just finished documenting and tweaking a library I've been working on called Impact++. Currently it has over 100 modules, including things like dynamic lighting, characters, creatures, AI, pathfinding, player, multi-touch, gestures, abilities, layers, improved collisions, camera, spawners, and a ton more that I can't think of at the moment.

Impact++ supports both side scrolling and top down style games, and includes docs, demos, and examples to help you get started. Impact++ is currently at r6:

Feel free to ask questions here or via github issues!

7 years ago by mimik

cool stuff and lots of stuff!
Will try it out later when i have a day or two.

7 years ago by Joncom

In the "Getting Started" code, you call ig.system.resize() immediately after starting the game. What is the point of making that call when the game size has not changed?

7 years ago by paulh

in case of orientation change? (Just a guess)

7 years ago by collinhover

Its actually to make sure the loader is fit correctly to the screen. When ig.GameExtended is init, it automatically calls a resize, but it is not init until all the initial assets are loaded. I felt it was necessary that the loader be fit to the screen so that the user knows what is going on. It does also prevent a visible snap resize after assets are loaded, which might make your game look just a touch more professional =)

7 years ago by ChrisC

I can't get it to work - can anyone help? (I'm somewhat of a newbie at impactjs)

I am trying to integrate my exsiting main.js into Collin's example code at

I had to remove the code that calls the debug mode because it was not finding files in impact++'s codebase - it couldn't find debug.js in /lib/debug/ - I found it in /physics/ and changed plusplus.debug.debug to plusplus.physics.debug and it got by that. Then it couldn't find another js file in /core/ which I couldn't find anywhere, so maybe your eg code needs updating?

So I just removed that code, and I'm getting this error:

Uncaught TypeError: Attempting to add to a layer that doesn't exist: undefined game.js:1081

Here is my main.js:

// starting with Impact++ is simple!
// setup a main game file, such as 'game/main.js'
// that you load right after ImpactJS
// and inside this file...
// setup the main module
    // now require the appropriate files
        // don't forget to load your levels

    // define the main module
    .defines(function () {
        "use strict";

        var _c = ig.CONFIG;


        function start() {

            // have your game class extend Impact++'s game class

            var game = ig.GameExtended.extend({

				gravity: 500, // All entities are affected by this

				// Load a font
				font: new ig.Font( 'media/04b03.font.png' ),
				clearColor: '#1b2026',	

				musicPlaying: false,

                // override the game init function
                init: function () {
					// Initialize your game here; bind keys etc. 'media/music/levelMusic1.*' ); 'media/music/levelMusic2.*' ); 'media/music/levelMusic3.*' ); = 0.7; = false; = true; = '#000';
					// arrow keys for movement
					ig.input.bind( ig.KEY.LEFT_ARROW, 'left' );
					ig.input.bind( ig.KEY.RIGHT_ARROW, 'right' );
					ig.input.bind( ig.KEY.UP_ARROW, 'jump' );
					// or wasd for movement
					ig.input.bind( ig.KEY.A, 'left' );
					ig.input.bind( ig.KEY.D, 'right' );
					ig.input.bind( ig.KEY.W, 'jump' );
					// attack ENTER or C
					ig.input.bind( ig.KEY.C, 'attack' );
					ig.input.bind( ig.KEY.ENTER, 'attack' );

					ig.input.bind( ig.KEY.SPACE, 'jump' );
					ig.input.bind( ig.KEY.SHIFT, 'run' );

					ig.input.bind( ig.KEY.M, 'music' );

					var as = new ig.AnimationSheet( 'media/environment.png', 24, 24 );
					this.backgroundAnims = {
					    'media/environment.png': {
					        10: new ig.Animation( as, 0.3, [10,11,12,13,14])


                    // so we can load the first level
                    // which of course you didn't forget to require above

					musicPlaying = true;


				loadLevel: function( data ) {
					this.parent( data );
					for( var i = 0; i < this.backgroundMaps.length; i++ ) {
						this.backgroundMaps[i].preRender = true;
				update: function() {["media/environment.png"]["10"].flip.x = true;

					// Update all entities and BackgroundMaps

					// Add your own, additional update code here
					if (ig.input.pressed('music')) {
						if (musicPlaying == false) {;
							musicPlaying = true;
						} else {;
							musicPlaying = false;

					// screen follows the player
					var player = this.getEntitiesByType( EntityPlayer )[0];
					if( player ) {
						this.screen.x = player.pos.x - ig.system.width/2;
						this.screen.y = player.pos.y - ig.system.height/2;


				draw: function() {
					// Draw all entities and BackgroundMaps

					// Add your own drawing code here
					var player = this.getEntitiesByType( EntityPlayer )[0];
					this.font.draw( 'Movement: arrow keys or WASD, space = jump, attack = enter or C, M = music on/off\nHEALTH: ' +, 2, 2 );


            // now lets boot up impact with
            // our game and config settings

            // and resize to make sure everything looks fine

       * _c.CANVAS_WIDTH_PCT * ( 1 / _c.SCALE ),
       * _c.CANVAS_HEIGHT_PCT * ( 1 / _c.SCALE ),



7 years ago by collinhover

Hi ChrisC!

Thanks for catching the issue with the debug. It is present in my branches locally, but it seems I had mistakenly placed the wrong .gitignore in Impact++ and this was causing git to completely ignore the whole debug folder... I've fixed that. The issue with the missing file from the physics debug is also fixed.

As for your TypeError about the layer, Impact++ uses a heavily expanded version of Amadeus' layers plugin, so all entities need to have a "layerName" property. However, before you go adding that to each of your entities, you should probably instead have your entities extend: (in the blue tip it suggests that all entities need to extend ig.EntityExtended to work with Impact++ properly).

Also, looking through your code above, you should probably look through the Impact++ source code for ig.GameExtended. You might find that Impact++ already does all of the basic setup you're adding into the getting started code. For example, bindings are done via (source: Impact++ is huge so reading through it all can take time, no doubt, but it is huge because I want it to save you 3-5 months dev time. (edit: I also realize now that the getting started section of the docs isn't enough, so I'm adding to that right now).

Hope that fixes your issue!

7 years ago by ChrisC

Great! thanks for replying and the help. I will give it a try again, and follow up on all the suggestions you made as well.

7 years ago by collinhover

Noticed another thing in the code you posted: you're setting all the background maps to prerender in the "loadLevel" method, but again you don't need to do this as Impact++ already prerenders all background/foreground maps.

Also, to enhance transitioning between levels, Impact++ has changed the level loading process into:

1. "loadLevelDeferred" > this is only necessary when changing levels, not for first level. This is also the only method you need to call for changing levels.
2. "loadLevel" > this parses level names into files and figures out if level is valid
3. "buildLevel" > this does what ImpactJS's original "loadLevel" did + other things such as unloading the current level via "unloadLevel"

And lastly, you don't need to use the expensive ".getEntitiesByType( EntityPlayer )[0]" to get the player. Use "game.getEntityByName( 'player' )" or "game.namedEntities[ 'player' ]", which will return just the player, assuming you've either extended Impact++'s ig.Player or given your Player entity the "name" property equal to "player".

7 years ago by ChrisC

Thanks for all that. I'm working my way through - I've gone through sections 1. and 2. in your getting started guide, and made those changes in my code.

The game runs with no errors or console messages, however none of the entities are moving. I'm using vel for movement (no box2d), and the animations are running, the player flips with the arrow keys, but the monsters and players do not move.

Interestingly its only the entities that have vel that are running their animations. I have an entity for a wall torch, which just runs an animation (has no movement normally) and it is not running its animation. Thats probably a clue.

Any ideas?

7 years ago by ChrisC

I'm just realizing while reading through your class reference docs that your library is much larger than I thought (assumed) - I was assuming I could drop it in and use select features that I wanted, but it looks like it changes a lot of Impact features where I need to convert my code.

Do you have available to download a sample project that say converts any of Impact's sample's? eg. the jumpnrun? or code to the sample you have running on your site.

Is there a way I can only use one part of your library to start with? I originally was interested in the dynamic lighting.


7 years ago by collinhover

What is the "performance" property of your entities set to?

As is mentioned in the docs for ig.EntityExtended, the whole entity update process is opt-in for performance reasons. If an entity does not need to move, "performance" should be "static" (which is also the default and probably why your entities don't move). If you want an entity to move but not use physics, ex: it will move by tween, "performance" should be "dynamic". And if you want your entities to use physics to move, i.e. velocity and accel and gravity, "performance" should be "kinematic".

7 years ago by collinhover

The main reason why a few of the core classes are necessary is for performance reasons. Impact++ does a few simple checks during update to figure out what has changed. This is especially true for dynamic lighting, which would be ridiculously performance heavy otherwise. As it is, lights only recalculate themselves when something has changed within their bounds.

I've got a few example levels in the "examples/levels" directory of the project, and I'm currently working on a game that I'll be including in impact++ to show everything working together. I'll have the game ready by August, but I'm afraid that doesn't do you much good now.

7 years ago by collinhover


I spent a few min to convert the Jump N' Run demo that comes with ImpactJS to use Impact++, and added a few popular features like player, characters, ability use, projectiles, dynamic lighting, shadows, lava, texturing, and camera atmosphere.

7 years ago by stillen

I just downloaded and set this up. I was hoping it would be able to speed up my development because my game idea is a bit crazy to write myself in a timely manner.

I set it up, turned off debugging and the run n gun example that is included, while looking pretty awesome is only running at 30fps.

Is this because of all the features being used at once, or could I have set something up incorrectly? I basically just added my 1.22 into the game and turned off debug for the run and gun. I haven't tried converting my game, have to look over the documentation.

7 years ago by ChrisC

I'm guessing its due to the use of dynamic lighting and shadows?

7 years ago by reskp

this is cool !

7 years ago by ChrisC

I setup the jumpnrun demo - very impressive. I'm looking forward to trying out the dynamic lighting in my game. I assume and hope that it can be instantiated on multiple entities.. eg wall torches.

I got movement to work in my game again - all I had to do was set the "performance" setting as you suggested, to kinematic: performance: _c.KINEMATIC,

Hopefully that was the right way to do it.

In Chrome the jumpnrun demo is getting 60fps. In Firefox, only 10-15.. not sure why that is? Maybe its because I have Firebug installed. Is that normal?

7 years ago by collinhover

Setting the performance to kinematic is correct for full physics entities that respond to gravity and collide with the collision map. Dynamic is for when they move but don't need gravity or collision map calculations.

I've noticed in the past that firebug caused performance issues on other projects, but I've not used it for some time so I can't comment. I'll look into it to see if that is the case or if it is some of the canvas calls that are causing the issue on Firefox.

7 years ago by Joncom

Quote from collinhover
Setting the performance to kinematic is correct for full physics entities that respond to gravity and collide with the collision map. Dynamic is for when they move but don't need gravity or collision map calculations.

I've noticed in the past that firebug caused performance issues on other projects, but I've not used it for some time so I can't comment. I'll look into it to see if that is the case or if it is some of the canvas calls that are causing the issue on Firefox.

While this may be correct in Impact++, it is not correct in relation to Box2D.

Kinematic bodies do not respond to forces. They can be moved manually by the user, but normally a kinematic body is moved by setting its velocity.
An example of a kinematic body would be an elevator.

A dynamic body is fully simulated. They can be moved manually by the user, but normally they move according to forces.
A example of a dynamic body is a projectile fired from a cannon.

7 years ago by collinhover

While this may be correct in Impact++, it is not correct in relation to Box2D.

Sure but Impact++ doesn't use Box2D. There are some files that use Box2D in Impact++, but they are opt-in and as the README says, I no longer update them as the performance of Box2D on mobile web was not usable. Even so, those files go by the Box2D body types, not Impact++'s, so that things are consistent for Box2D use.

(edit: just thought about it more, and the actual definition of the word 'kinematic' doesn't exactly line up with the way it is used in Impact++... which could be a source of confusion. However, if I change this it could potentially break some projects, because I'd have to replace DYNAMIC with MOVABLE and KINEMATIC with DYNAMIC.)

In Firefox, only 10-15... only running at 30fps.

Just got back from being out of town, tested the current Jump N' Run example on Chrome, Firefox, and both run at 60 fps. I'll make some edits to the example, throw in a few extra features (like wall torches), and reply here with a link to a live version of the example. That way we all are looking at the same thing so I can make sure things are running right.

7 years ago by ChrisC

Do you have Firebug installed? I suspect it might be Firebug as it causes other web apps I build to react slower.

Also for the jumpnrun eg in your code, it seems the C shoot button isn't working.

7 years ago by collinhover

Okay I've added a live demo on the docs site ( ) just hit the demo button at the top and it should load it right into the page. You can control the demo with the original Jump N Run controls and/or use spacebar, wasd, click, click hold, and swipe up. I added two buttons to toggle graphics levels up and down to help test performance.

Ran tests again, Chrome and Firefox both at 60 fps. Some things I noticed:
- Firebug had no noticeable effect on performance.
- Firefox was running anywhere from 1x to 3x slower than Chrome.
- On low graphics, Chrome was executing in 0 - 0.5 ms, while Firefox was executing in 0 - 1.5 ms
- On high graphics, Chrome was executing in 0 - 1 ms, while Firefox was executing in 0 - 2 ms

I don't know that there is a whole lot I can do to cater to Firefox. For r5 of impact++ I'll be working on adding webgl support, which should seriously speed up render times, but beyond that I'd love to hear other ideas.

7 years ago by Joncom

I like the demo you added! That was the first time I saw the dynamic lighting plugin working smoothly.

7 years ago by collinhover

Thanks Joncom!

It might also be helpful to note some of the performance differences in Impact++'s Jump N' Run demo vs the original ImpactJS Jump N' Run demo.

Impact++ demo:
- full screen (usually > 1024 x 768)
- 3-4x scale
- debugging
(and in high graphics mode, which is default)
- dynamic lighting and shadow casting
- dynamic atmosphere

Original demo:
- 320 x 240
- 2x scale

Dynamic lighting by itself is pretty lightweight, as it is basically only radial gradients. Adding dynamic shadows is also not too much worse. At one point during testing, I had 20 - 40 dynamic lights casting shadows all on the screen at 60 fps. But combining that with a dynamic atmosphere, which is creating a full canvas color fill and cutting out all lights, makes the whole bundle probably one of the most performance intensive features you could ask for (edit: you don't need the atmosphere, btw, it is just pretty). Even with a heap of optimizations, you've got to weigh that into your game and make the right trade offs.

7 years ago by Joncom

@collinhover: I noticed however that the environment-shadow-casting effect works well in some areas, but not in others.

Here it's working.
Here it's not working.

7 years ago by collinhover

On a whim, I decided to run a few tests to check how often lights were being recomputed, and I found a small error that was causing all lights to recompute every single frame, increasing the performance hit of lights by a huge amount. Most likely a result of refactoring, but it is fixed (pushed to master/dev branches) and the demo is running super fast now.

@Joncom: the issue you're seeing has to do with the way level edges are handled. As far as shadow casting goes, it doesn't care which way the edge normals face, it casts fine on both. However, you'll notice the platforms are lit up, because they are flagged as hollow. Hollow entities will not block light inside themselves, but they do cast shadows from their edges. In the case of the level edges, there are two, one outer and one inner. Because the inner edges are containing the light, it won't light up the outer walls, because the inner edges completely block the light. In the case of the demo, I've intentionally discarded the outer level edges, so no shadows are cast from them and light is able to go over and outside. I've not found a good solution to this yet... my initial thought is to create a convex hull of the inner edges, and split any edges that are not a part of the hull into their own shapes, but I haven't had time to test this.

7 years ago by Neeko

Awesome library. It's very robust, polished and well documented.

I've started using it for my next game...feels like I'm cheating, there's so much already done for me!

7 years ago by vassildador

This indeed looks like an incredibly powerful and extensive library, I'm impressed!

I have a question for you, though:
I'm currently working on a top-down zelda-esque game (with enough originality to keep it fresh) in Impact and was wondering if this can be done in impact++. It seems that the default behavior of all entities derived from the abstract "character" entity is entirely written for side-scrollers and side-scrollers only, or am I wrong? Is there any quick and easy fix to make them behave in a top-down manner (as in moving up/down works the same way as left/right, no need for gravity for instance), and are there other things that you can think of into which I will probably run when trying to make everything work in such a way :)?

Thanks in advance ^^

7 years ago by collinhover

@vassildador I had a similar question a little while ago. While I do think that Impact++ could use a few changes to make such top-down games a little easier to make, I'm fairly certain you can do it with what is there at the moment. Let me see if I remember my (completely untested) suggestions to make it work:
1. set the "gravity" property of the game to 0, so entities don't fall
2. extend ig.Player and just make a few simple changes:
a. any entity can ignore gravity using the "gravityFactor" property. Set it to 0 if you don't do #1 for whatever reason.
b. Any character can be set to do no jumping using the "canJump" property. Set it to false as you won't need it in top down.
c. Any character can be set to do no climbing using the "canClimb" property. Set it to false as you won't need it in top down.
d. Look at the end of ig.Player's "updateChanges", this is where all the input is processed. When pressing up and down, by default the player will try to climb up or down. You can override "climbUp" and "climbDown" methods to just do the same as the "moveToUp" and "moveToDown" methods.
Page 1 of 6
« first « previous next › last »