Forums » Code » Impact++ library [75+ additions]

@vassildador we're all asking for it ;)

https://twitter.com/stalkjimmy/status/366579091580796932

@vassildador yeah, I'd call it in the buildLevel method of the game, because that is where the level gets built. The loadLevel method is now for lazy loading levels. Near the end of the buildLevel method the camera tries to follow the player, so just before that would make the most sense.

@collinhover @TigerJ: I had it working with recalculating the size every frame, I'll move it to the buildLevel method tonight or tomorrow, throw it in a branch and do a pull request to add this :)

The only downside is that it uses the collision layer, if in some exotic case you'd use a collision layer that's smaller (or larger) than how far your camera can move it'll probably not work as intended.

@collinhover @vassildador The top-down stuff seems to be working pretty well by just dropping it into my code. Thanks for the effort guys. I am running into a problem, though, trying to switch player animation based on the desired movement direction (I have unique animations for each direction the player is facing or moving). I've explicitly set the following in the user config:

ig.CONFIG_USER = {
    TOP_DOWN: true,
    ENTITY: {
        CAN_FLIP_X: false,
        CAN_FLIP_Y: false
    }
};

In my player&039;s #updateChanges() method, I'm handling button presses and using #animOverride('walk' + Facing) (where Facing = Up, Down, RIght, or Left). However, that is delaying the walking animation until I release the input. How would you suggest I do this?

Oops, please forgive the formatting errors in the previous post.

@vassildador I think we can safely ignore the fringe case for now. Using anything other than a level's collision layer is game specific I think. Thanks for the help!

@mpenner the issue is that every frame you&039;re checking if a button is pressed, and if so, overriding the current animation to play a walk animation, i.e. you're likely forcing it to restart the animation every frame. You shouldn't need to do that, as general movement animation is already handled by ig.Character's #updateCurrentAnim method. If a character is moving, it plays the move animation and appends the direction based on facing.x/y and canFlipX/Y. So instead of calling your animation walkLeft/Right/Up/Down, name it moveLeft/Right/Up/Down.

However, if the case is that your character can both walk and run, then you&039;ll need to override the #updateCurrentAnim method and modify it to play either walk or run, instead of move, based on some property or threshold. Also, the benefit of using this method, instead of the updateChanges method, is that it only updates the animation when the character is visible in the screen.

@collinhover That&039;s fantastic. I figured it had something to do with the named move animations and #updateCurrentAnim, but I somehow didn't put 2 and 2 together. Thanks.

@collinhover Of course the moment I want to send you a pull request github gets DDoSed, great timing! :D

Currently keeping the camera inside the level is working fine for me. Two minor things to keep into account:

- When making the camera shake, you can still see black borders. Disabling the shaking in one direction made it look worse than seeing a bit of black. As long as you don't put any ridiculous numbers in as intensity it'll look fine :)

- When the level is smaller than the camera, the camera will automatically turn keepInsideLevel off for the dimensions it's smaller in.

@vassildador very nice. I'll merge it in once I'm back home. Thanks for making the call on the shake being allowed outside the level, I'd rather it look good even if it isn't totally correct.

Hi, I have a question about scaling. I am trying to make the canvas a fixed size and the game remain at a fixed scale. I have been able to restrict the game window to a fixed size via the canvas css. However, when I resize the browser window, the game scales up/down still.

Below is the code that I've been fiddling with inside of main.js. Even when I comment out the ig.system.resize() method, the game still scales up/down its contents depending on the browser window size.

How can I fix it so that the canvas size and game contents are fixed, no matter what size the browser window is dragged to? Thank you.

        // now lets boot up impact with
        // our game and config settings
		// we've modified Impact++'s 'config-user.js' file
		// to override some of the default settings
        ig.main(
            '#canvas',
            game,
            60,
            640,
            480,
            3,
            ig.LoaderExtended
        );
		
		/*
        // and resize to make sure everything looks fine
        ig.system.resize(
            ig.global.innerWidth * _c.CANVAS_WIDTH_PCT * ( 1 / _c.SCALE ),
            ig.global.innerHeight * _c.CANVAS_HEIGHT_PCT * ( 1 / _c.SCALE ),
            _c.SCALE
        );
		*/	

@kurisukun if you just started with Impact++, I'd recommend using the dev branch instead of r4 release. I say this because r5 is about to be released and has a lot of fixes/enhancements. On to the question.

In r4, you'll need to override the game's resize method, copy the code that is in the resize method and remove one line: https://github.com/collinhover/impactplusplus/blob/master/lib/plusplus/core/game.js#L1981

In r5 this issue is fixed, you'd just set the config values "GAME_WIDTH" and "GAME_HEIGHT" to whatever fixed size you want your canvas to be, and optionally the "SCALE" as well.

@collin Thank you very much! I will give the r5 branch a try first and see how that goes. Thank you for these great additions to impact :)

Is there a simple way to create a UIButton that responds to the user holding their mouse / finger over the button. I want to create a simple button class that changes the current animation based on if the user is hovering over the button. I want to then activate a callback if the user releases input while still on top of the button.

I looked into UIElement and UIInteractive for a way to set call backs for input.pressed and input.released but to no avail. Note that I am very much a noob to Javascript.

I came up with a solution but it seems pretty hacky. It seemed like the UIElements were only set up to receive events about quick taps. I added an onReleaseOver and onHeldDown event to entity.

@vorce67 you're correct, UI elements have been setup to only respond to click/tap at the moment. That isn't to say they couldn't be setup for more, as the input already handles clicks, holds, and swipes, but I haven't had the time to do it yet, sorry!

(edit: if you really need complex UI, I'd recommend using the DOM and maybe some libraries such as jQuery/Dojo/Sencha/etc. Impact++ UI elements are really meant to be simple and ready to go for when you also want to port your game through Ejecta/CocoonJS/etc and there is not a DOM available )

Hi, I have a question on doors. I'm still trying to wrap my mind around doors. two problems I'm having:

1) Having the door become passable only after the "openX" animation is finished. Right now, I can walk through the door while the door is still animating the openX sequence.

2) Having the door stay open once I open it once. Right now, I walk up to the door and then it does the animation and I can walk through it, but if I walk back to the door, it just repeats the openX sequence over again.

Is there any sample code to show how to properly use doors? Thank you and sorry for the simple question!

@kurisukun there isn't any sample door code at the moment, sorry.

1) doors descend from ig.EntitySwitch, which handles the open/close. If you want your door to become passable only after the animation completes, you'd want to override the open/close methods in your custom door class and NOT call parent. Here is an example of how you'd do that for open (and you can probably figure out close):

open: function () {
   this.animOverride( this.getDirectionalAnimName( "open" ), {
      lock: true,
      // below is the only new bit
      // after open animation finishes
      // call makePassable in this context
      callback: this.makePassable,
      context: this
   } );
   // this doesn't include the autoBreak code
   // which you may or may not care about
}
makePassable: function () {
   // normally door calls this in open method
   // but we want to wait until the open animation finishes
   this.collides = ig.Entity.COLLIDES.NEVER;
}

2) you should be able to set the "autoToggle" property on your door to false, and it should not automatically close after you've finished walking through.

Thanks, that worked beautifully. :)

I am nearly finished with one level, but I am running into an issue where I am using the regenEnergy functionality. In my player.js class, I have these lines:

    ig.EntityPlayer = ig.global.EntityPlayer = ig.Player.extend({
		
		size: _c.TOP_DOWN ? {x:8, y: 8} : {x: 8, y:14},
		offset: _c.TOP_DOWN ? {x:4, y: 4} : {x: 4, y: 2},
		
		health: 50,
		regenEnergy: true,
		regen: true,
		regenRateEnergy: 0.02,
		regenDelay: 0.1,

And this works just fine. I have coded it so that when I shoot the grenade, some energy is depleted, but with the regenEnergy, it fills back up. However, I noticed that when I die and respawn at a Checkpoint, my player no longer recharges his energy. Is there something else that I need to do to make the player to continue to regenerate energy even after respawning? I noticed the same behavior when changing levels via ig.game.loadLevelDeferred(). As in, if I deplete my energy halfway, then step onto some trigger to change the level, then when I respawn into a new level, my energy bar no longer recharges.

Thank you again :)

I've been seeing the exact same thing.

@kurisukun @mpenner that sounds like a bug, not at all the correct behavior. Would you mind submitting an issue report on github please? I should be able to fix it in no time :)

On a side note, in my door example above, the code should be COLLIDES.NEVER and not COLLIDES.NONE, sorry.

Thank you! I just posted a new issue on your github. I hope it's ok :)

Regarding the door example code, thanks for the correction. I got it working previously, but it's good to note! :D

Okay, pushed some fixes (which includes a fix for the regen issue). The problem was when a character is added to the game, the max energy is set based on the energy, assuming that energy is at 100%. This is fine for the first time, but in the case of the player, he/she was removed from the game at a sub-100% energy sometimes. So to keep it stable, stats are reverted to their original state before max stats are set.

(edit: I broke collisions entirely with a small refactor in this change, but it is fixed also)

@collinhover Thanks a lot for this. I haven't had a chance to test properly yet, but will let you know if I find anything out of the ordinary.

@collinhover I've been testing this and all is good! Thank you so much for this :)

I have a separate question regarding the toggleGfxMax.activate() function, if I may. Right now in the sample code, this toggleGfxMax.activate() is set in the initUI() function. However, if I load a new level in the game, the environment is not using toggleGfxMax settings, it seems.

Is it possible to get rid of the UI buttons entirely and just have it set to toggleGfxMax each time a level is loaded? I tried pasting the code of toggleGfxMax.activate() within my main.js within loadLevel(), but it didnt quite have the effect I wanted...

@collinhover sorry, maybe I spoke too soon. I am testing the game without adding my EntityPlayer into the level without weltmeister. Rather, I am programmatically spawning my EntityPlayer via ig.game.spawnEntity(EntityPlayer, x, y) in each level. When I do this programmatically, it doesnt seem to regenerate energy. I will do more testing on this.

@kuriskun that is a strange issue, but I also don't normally spawn the player programmatically. I'll look into it!

As for the toggleGfxMax, that was a UI element specific to the demo ui. I wouldn't recommend you use it as I hacked it together very quickly for the demo only. The method ".activate()" is a general method for activating an entity (all entities have it), and in the demo I overrode it to toggle the lights and atmosphere on or off.

@collinhover I agree that it's a strange way of doing things. I resorted to spawning the player programmatically because I wanted the player to spawn at specific "entrances" on a level, depending on where he had left. For example, I may have a "levelA" with two LevelChange entities on the left and right side of the map and he exits through the left levelchange entity to another level. When the player comes back to levelA, I'd like to have him spawn at the left "entrace" so to speak, to provide for some continuity of where the player was coming from. I couldnt get this to work with my player set in weltmeister -- he just kept spawning at the weltmeister-set position.

If theres a better way to accomplish what I'm trying to do, then I'm all for it :)

@kurisukun there is :-) take a look at the levelchange's "playerSpawnerName" property.

Impact++ updated to be stable with ImpactJS v1.23.

The whole project is just awesome. But I do feel very sad when I see all these nice sounding entities and additions but can't find a way to use them becuase there are not examples in the doc.

The example game does not cover very much in my opinion :(

And it takes a lot of time to read all the code myself and get behind it.