Impact

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

1 decade ago by collinhover

@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 :-)

1 decade ago by Graham

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).

1 decade ago by collinhover

@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&039;s #getDirectionalAnimName and account for when facing x and y together. You may also need to override ig.EntityExtended&039;s #lookAt method also, as it currently sets facing to x OR y, not both.

As far as controls, check out ig.GameExtended&039;s #inputStart method, and override it with whatever inputs you need. You&039;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&039;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.

1 decade ago by collinhover

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

1 decade ago by Graham

@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.

1 decade ago by kurisukun

@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!

1 decade ago by collinhover

@kurisukun edit: I realized what you&039;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?

1 decade ago by Tharuin

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?

1 decade ago by collinhover

@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.

1 decade ago by Tharuin

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

1 decade ago by Tharuin

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

1 decade ago by Joncom

@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.

1 decade ago by collinhover

@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.

1 decade ago by Tharuin

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

1 decade ago by Tharuin

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?)

1 decade ago by collinhover

@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.

1 decade ago by Tharuin

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!

1 decade ago by collinhover

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.

1 decade ago by vassildador

@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.

1 decade ago by collinhover

@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?

1 decade ago by vassildador

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

1 decade ago by Tharuin

@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.

1 decade ago by collinhover

@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.

1 decade ago by collinhover

@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
}

1 decade ago by Tharuin

@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&039;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?

/><br />
<br />
Shouldn't it reach for the "lowest" waypoint and not the one on the same height of the target at first?			</div>
		</div>
			<div class=

1 decade ago by collinhover

@Tharuin thanks for testing it! That is incorrect behavior. In fact, it used to reach for the lowest, but it was changed some time ago (for whatever reason I don't remember anymore). I've changed it to perform better and handle more cases. Give the latest dev a try and let me know how it goes.

1 decade ago by Tharuin

@collinhover It works just perfectly now in my case. Thank you! They are perfectly always chosing the best waypoint.

The only thing that is bothering me a bit is the fact that the creatures don't walk constantly when using the simple pathfinding method since they are always stopping when they reached a waypoint, which looks like they are lagging every second. But I guess that this is one of the downsides of the "simple" method.

1 decade ago by collinhover

@tharuin that is caused by the pathfinding update delay, which is used to keep pathfinding requests low for better performance. For simple pathfinding, the property is pathfindingSimpleDelay. I'd recommend that the faster the entity, the closer to zero this number should be. You can set it to 0 and they should have a constant walk, but that usually is not necessary.

1 decade ago by collinhover

Impact++ is now at release 5 and everything appears to be stable: https://github.com/collinhover/impactplusplus/releases

1 decade ago by collinhover

Added some critical bug fixes and miscellaneous enhancements to creatures and abilities to r5 release. Good news everybody, this includes entities sticking to slopes instead of falling repeatedly, hurrah! (yes, that particular enhancement was delayed entirely too long)