Forums » Help » Multiple Layered Entity Animations

I am building a player entity who's animation will sometimes be augmented by items he picks up and can wear, or carry around. This presents an interesting challenge that I would think would be pretty common.

Say my character picks up a watch, and wears it. It would be easy enough for me to duplicate, for example, the running sequence in the same sprite sheet with the watch added to my player's arm. But if I was doing a LOT of this type of thing with many different items that can be added to my player entity, the animation sheet would quickly become very bloated.

So I have been thinking about a way to layer up animations for a single entity. I'm pretty new to Impact, but I can think of a way this could be done. What I'm really looking for is the best way to do this. Has something similar been done?

It appears that an entity can only have one animation sheet, so it seems like I would need to build an entity out of multiple entities (probably two at most, because my player can only pick up one item at a time) that have their positions linked together in some way.

Any ideas, issues anyone can think of?

The easiest way I can think of would be to augment the entity's draw routine, calling this.parent() to call the regular draw and then to add another manual draw to just draw the bits you want to draw.

It's complex but should be achievable.

Does this work with transparency? So, if I draw a transparent pixel form the overlaid sheet, will it overwrite an opaque pixel in the base sheet?

No, it'll be transparent. All draw operations effectively stack, meaning that whatever you draw last will be on top - and if that last draw op has transparent pixels in it, they'll be transparent on top of whatever was there before.

I need a similar function in the RPG i'm building, but in my case the single character is a 300kb png, and the combination of weapons, armor, etc leaves billions of possible combinations. I also want to use this same base character image for the hundreds of other characters in my game, just "dress" them different.

The solution I've decided to go with is to create a separate sprite sheet for every weapon, item of clothing etc. Then in my player entity code I will create an empty canvas the same size as my sprite sheets, load and each image sequentially onto the canvas, and use the final composited image data as my animation sheet. While this is a little more coding work, the upside is the image data only has to be constructed once instead of on every draw().

I guess it really depends how often it's likely to change, since the composition stage is probably not going to be that cheap, as it were.

I would create multiple entities separately like head/arms/legs etc and put them together then based on the pickup change either one of them to the next animation. So lets say you have a spritesheet with anims for legs that are bare, few frames later you have them wearing shoes. So once you pick up shoes you change animation on your legs entity to the one that has shoes. all you need to do to achieve it is to set up the zindexes on the elements that will combined create your playerEntity.

The only problem with that is the fact that not only do you then have the extra draws per frame, but you also have the extra updates per frame to contend with too, and if you're doing that with a lot of things at once (e.g. player + multiple bad guys) you're not just moving around half a dozen entities but potentially dozens at once if you're not careful.

This is as extremely common task in game dev. Seems like there should be support for it. Anything in the works, or is it something that will just always have too many performance issues to it?

For something that is "an extremely common task", I have actually yet to see one Impact game doing it - compared to all the others that don't. The same is true for most Flash games too, for that matter.

It's always going to be performance sensitive, however you implement it because it's all logic and drawing that has to be done per frame and the more complex you want to make it, the more performance effort will be required.

The thing is, if you make this part of the core, it screws it up for everyone else who doesn't need it, which seems to be the majority.

As difficult as it is to accomplish, you should not be expecting to see many people doing it in Impact. I make Flash games, and this is something that is quite common. You simply turn on or off visibility of parts that are nested within the main clip.

I'll be adding this feature to my game soon - I will post the code when I do.

That would be great. Thank you.

The thing is, Flash is a very different beast to Canvas/Impact. Canvas has no concept of visibility of parts, it's either drawn or it's not.

The other thing is that even the most complex stuff I've done so far in Impact still runs better on my PC than any Flash game I've seen to date, Flash is just so inefficient (and consumes one full core of my PC apparently not doing anything, something Impact doesn't generally do for me)

After playing with impactjs for awhile, I am impressed by its speed. So I decided to throw caution to the wind and I've implemented a bone-head stupid approach to adding items to my player's animation.

Instead of modifying the player's animation, I create additional entities.

For example, if I want to add a shield I create a shield entity. Using photoshop, I paint that shield panel so that when it overlays my player it looks right.

Then I give the shield a zIndex so that the shield is above the player.

In the shield entity I stub out update. Give it never collide, and type none.

I update the shield's position in the player's update method (after the pos.x and pos.y have settled down)

So far this method has been working just fine. I admit it is pretty much brute force, but it is letting me test the animations and move forward. I don't have too many entities and the player is the only one that gets the "extras". So, I don't believe the impact on the engine is that bad.

Later, I will surely need to do something more elegant.

I was thinking about doing that initially. I'm not taking shots at how Impact is built. I'm just a n00b, and I'm trying to explore and find the best way to do this, because I may be doing much more Impact development in the future.

I tried just slamming every possible combination into one sprite sheet, but the sheet ended up being massive. It may be slowing things down. I think I'm going try this by layering up entities. I can't imaging this would slow down performance more than having a sprite sheet that is 1000x3000 px.

I just posted a plugin which allows you to add layers on top of animation sheets - hope it helps:

http://impactjs.com/forums/code/layered-animation-sheet

That's pretty intense. Have you tried to compare the performance difference between this and layering up entities? Seems like your solution would be better, but might be nice to see some real benchmarks. I could do some testing down the road, but I'm not currently at a point where I can experiment.

I'll try the layered animation sheet right away though. Thanks for posting.

Quote from Bradley
Have you tried to compare the performance difference between this and layering up entities? Seems like your solution would be better, but might be nice to see some real benchmarks.

I haven't, but this is guaranteed to be faster because instead of the extra draw() calls involved with layering entities, this still uses just the single draw() from the AnimationSheet class - there is going to be a bit of overhead initially when all your layers have to be composited, but it's a one-time operation and shouldn't cause any sort of noticeable lag.

Awesome possum. Thanks again.

Yep, I looked at the code, it looks awesome. I will definitely take advantage of it. :)