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

@Tharuin I agree, it makes me sad too! But only so much I can do by myself. A few nice devs have contributed bug fixes and simple features (@vassildador came in with a huge top down feature), but right now advanced examples are what is needed most.

Good news is I'm working on it. But at the very least, Impact++ will save you the time of writing and bug fixing it all yourself. That takes a lot longer than tinkering with features :-)

Is there an easy solution for adding in support for an 8-directional animations, or even converting the controller scheme over to a twin-stick with the mouse position determining the animation direction and keyboard just controlling the movement?

Not sure if I should be changing the character/entity library files directly to bend the input controls into what I want or if there's an easier way to build upon the existing code. Does Impact++ work best if you're willing to 'play by the rules' of the pre-established modules when it comes to stuff like the base controls/etc?

(New to ImpactJS and ImpactJS++ so apologies if this is a silly question).

@Graham generally, you want to override methods and properties in your own game specific entities. I've tried to build Impact++ so that no modification of the library is needed.

So, for 8-directional animations in Impact++, override ig.EntityExtended's getDirectionalAnimName and account for when facing x and y together. You may also need to override ig.EntityExtended's lookAt method also, as it currently sets facing to x OR y, not both.

As far as controls, check out ig.GameExtended's inputStart method, and override it with whatever inputs you need. You'll probably also want to check the mouse position by overriding ig.Player's updateChanges method and have the player look at the position. Impact++ has moved away from the mouse and instead prefers input points to support mouse and touch in the same setup, but you can still access the mouse the same way as in original ImpactJS.

And the only override of the above that you'll want to call parent() for is the updateChanges method, as you'll only be adding functionality. The rest are complete overrides as you'll be changing the functionality.

Impact++ is now at r5 pre-release:https://github.com/collinhover/impactplusplus/releases

@collinhover Much thanks for the help, not to mention the quick and thorough response! Completely didn't realize I could override methods (my JavaScript-fu when it comes to classes needs some work), and it definitely makes my job a lot easier & more organized.

p.s. Impact++ is incredibly awesome.

@collinhover hi again. I'm having some problems with creative ig.EntityNarrative or ig.EntityConversation programmatically. At least, I don't think I'm doing it correctly.

I've been trying something like this:

var narrative = new ig.EntityNarrative();
narrative.addStep("someText1", "", 0, {});
narrative.autoAdvance = true;
narrative.activate();

This at least gets some text on the screen, but it doesn't disappear on its own. Or if there were multiple addSteps(), then it doesn't autoAdvance to the next step.

The only way to get rid of the narration/conversation if I create it programmatically is if I wrap it in some setTimeout() to call deactivate() after some certain time period. I'm pretty sure this isnt the right way to do it.

Basically, I'd like to be able to create a narrative programmatically, have it either autoAdvance or deactivate itself after some specified time, such as the time per letter. Is this possible?

Thanks!

@kurisukun edit: I realized what you're doing wrong so disregard my previous post. The auto advance is reliant on a timer internal to the narrative or conversation. The only way that timer gets checked is when the narrative gets updated, and the only way it gets updated its either: (a) manually or (b) by the game update loop. Option b is recommended and that is why in the docs I put a warning to use the game's spawnEntity method to create new entities instead of using new EntityClass(...)

Does that fix it?

Could you tell me how you would handle the case when in the same entity animation frames do have different sizes? Like you are having some with walking (e.g. 20x40) and then you have an animation for crawling maybe, beeing 40x20. Is there a way to adjust offsets for special animations? I thought about going for 40x40 in this case for all frames. But do I have to code this myself or is there a solution for that already?

@Tharuin animations sizes are handled the same way as in original ImpactJS: an entity only has one size of animation for all frames. So in your example, all animations should be 40x40. No extra code is needed.

But how do I handle the offset for the collision then? Not each animation will have the same collision box sadly :/

But how do I handle the offset for the collision then? Not each animation will have the same collision box sadly :/

@Tharuin: If you shorten your entity.size.y you will need to compensate your entity.offset.y. You will likely have to fine tune this by hand. So immediately following the execution of your selectAnimation function (I'm assuming you have one), you should run another function which updates the offset based on animation and entity size.

@Tharuin what @joncom suggests is correct (thanks!), and Impact++ has a selectAnimation method built into the character abstract, but it is called updateCurrentAnim. Override that method and set your new size and offset after calling parent.

Thank you all! Overriding updateCurrentAnim is exactly was I was looking for!

I'm sorry for asking so many questions, but I'm really excited about impactplusplus (and impactjs too ofc), but I'm not able to use all the nice features because I'm missing examples and also "best practices". Does anybody have an example where he makes use of the impactpp AI methods and also pathfinding? (Maybe even in a platfformer game?)

@Tharuin I don't mind answering questions. The "examples/jumpnrun" demo uses basic AI and pathfinding in the ghost entity. I'm also working on a bigger demo now that will include different examples of AI and pathfinding, which should be ready in a week.

Thank you very much @collinhover! This is just really awesome.

Is there still anybody who has open source games made using impactpp? I'm looking forward to see the bigger demo!

There are a couple games that I know of, one is http://www.thesilvergymnasium.com/ which uses an older version of Impact++, but I don't know of any open source ones at the moment.

@collinhover Are there any plans for integrating gamepad support? I've found out there are several existing plugins for this but I was wondering if it makes sense to integrate it into the impact++ library. I think it'd be a worthy addition IF it can work cross-browser. I'm afraid that's a big if though, as currently different browsers have different implementations :(

Either way, it's something I definitely want in my game. The API is still in early stages though, so I'm thinking even if it's implemented it'll need a big "experimental" tag :D

PS: I'll be sending you a pull-request for the asynchronous loading either tonight or tomorrow (friday) evening. Sorry for the delay :) I wanted to make sure to document everything and not miss any bugs.

@vassildador I have not planned to integrate gamepad support. Dominic was talking about it recently, and mentions that in some cases support isn't even at the experimental stage. That's not to say I wouldn't have it in the library, but someone else would need to build it and I would worry about bugs (as with any experimental feature). Perhaps there is a cross-browser controller support library, not ImpactJS specific, that could be made into an impact module in the interim?

@collinhover I'll look into it the coming weekend :) gamepadjs looks promising.

@collinhover

Thank you very much for this supercollider demo. This is just great.

Edit: I do wonder why

moveToPreySettings: {
			simple: true,
			avoidEntities: false,
			searchDistance: 2500000
		}

this works great (performance-wise) but does not let the entities move over simple slopes and stop in front of them?

When I set simple to false they do use the slope but performance does get worse.

@Tharuin simple pathfinding only looks 1 tile ahead in the direction of the target, so it will naturally be much faster performance wise than A*. I believe simple pathfinding will not work on slopes in some situations, such as when the target is on the other side of a hill, because simple pathfinding will try to walk into the hill instead of over it, causing the path walking code to register that as an unwalkable tile and stop. I may have a solution for this, I will try tomorrow and let you know.

@Tharuin I decided to do it tonight, not sure why! You can either check out the game.entities.villain-friendly-unsafe in the SUPER COLLIDER! or you can just use the following settings (using the latest dev branch):

moveToPreySettings: {
	// keep it simple and only look 1 tile ahead
	simple: true,
	// don't care if tiles are walkable
	// or if path will take us over the edge into death
	// or if path is too high to get to
	// the upside is we can move up and down slopes
	// at a much cheaper cost than complex pathfinding
	unsafe: true
	// and no need for:
	// search distance (not used in simple pathfinding)
	// avoiding entities (not used in simple unsafe pathfinding)
	// etc
}

@collinhover Thank you very much for your help! I really appreciate it!

It looks like the creature is now attempting to walk over the slope, but it seems to be stuck because it can't reach it's own next waypoint. I've added an image with my semi transparent collision layer. My entitiy is 23x32 in size. The tilesize for collision layer is 16x16. I've used the latest dev build on github and the moveToPreySetting you provided.

He can't touch this point, that is why it is moving left and right constantly now. But it is atleast trying to climb the slope, instead of idling in front of it :)

Do I have to change my collision-layer? Is it a bad combination of my entities size and the tilesize?

1 decade ago by collinhover