Known Participant

Question

Is my scene too complex? | BIG JS Files

Forum|Forum|7 years ago
December 21, 2018
3 replies
1673 views

Hello,

I recently created an interactive piece with over 500 frames of hand drawn character animation. The animation runs smoothly, but the JS files are huge (7mb) and nearly indecipherable. I was wondering if there was a way to optimize the code, and a best practice for multilayered, frame-by-frame character animation? I understand that what I have created is a bit overboard, and may just be a big file regardless.

I tried merging each layer, converting each frame to a bitmap, exporting spritesheets, and then compressing the spritesheets. I thought this would be more efficient with easier to understand code, but the JS file is about the same size and the animation runs very very slow. I would like to be able to share the code with others if it was requested, but I would never be able to hand over the JS files as is. Is there a way to reduce the bloat of these files on a project like this, or are large JS files inevitable when working with lots of animation?

I guess I am wondering if I somehow hand coded this, what would that code look like? Would it be nearly the same size? Would it use spritesheets?

Here is the site, to get an idea of what is being made: http://www.pmaxwellward.com

And here is an example of the JS files being exported from Animate CC: https://drive.google.com/open?id=1jn8k3LI7-HjDmZXxeoP2wZyrNC8FzEeS

This topic has been closed for replies.

kdmemory

Inspiring

pmwpmw wrote
Hello,
... JS files are huge (7mb) and nearly indecipherable... I was wondering if there was a way to optimize the code ... I understand ... I have created is a bit overboard.

Well pmwpmw, what wrong with overboard. The animation runs smoothly and looks good. Of course it's over the top. If you would produce it as a video it would be much smaller, I'm sure. But it wouldn't be the same, more static than your somewhat dynamic narrative. I'm not skilled enough for this kind of frame-by-frame animation. But organisation/optimization is certainly a way that could help.

In your index.js I see a lot of idleState = Math.floor(Math.random() * 5) followed by if(idleState == 1) {this.gotoAndPlay("idle_headIn"). It looks like you are playing dice and then goto frames to vary the events. If you would use sub-animations (movieclips playing i.e. scratching head, rocking chair, leaning head back, talking and so forth), all with the same size, transformation and center points, then you could do something with Linkage names in the library, addChild/removeChild instead of gotoAndPlay to similar but always newly hand-drawn frames.

And what JoãoCésar mentioned about exporting your document as texture can make a difference.

Klaus

P

pmwpmwAuthor

Known Participant

Very interesting idea! Never used Linkage names. Always looking for more efficient ways to do "dice roll" events, so I will look into this method. Thanks!

Also, I did used the texture option at first, and it ran very slowly. The current option that runs smoothly is all shapes.

kdmemory

Inspiring

Hey p. maxwell ward,

yeah, segmentation might really open up a new avenue. Good luck with that.

I like the guy on your page, some sound would be great though. However - keep us informed about your progress.

Klaus

C

ClayUUID

Legend

pmwpmw wrote
The animation runs smoothly, but the JS files are huge (7mb) and nearly indecipherable.

The JS files aren't supposed to be decipherable. They're supposed to pack everything you've authored into the smallest space possible. Why would you care about deciphering them?

Looking at your live page, I'm guessing the output is so big because you're using an absurd amount of detailed line work, and because you're taking a completely brute-force approach to the animation. Both of these go against best practices for Flash/Animate animation, which is to use simple vector outlines and/or to use tweening instead of redrawing every frame from scratch.

P

pmwpmwAuthor

Known Participant

I suppose it isn't totally necessary to decipher the code that is exported from Animate CC, but I have found myself editing the JS file in small places here and there after publishing, and it would make it easier to work with in that context.

And yes, I concede that the animation is very dense, but it's just an aesthetic choice. Apparently an aesthetic choice that results in large JS files as well.

JoãoCésar17023019

Community Expert

Hi.

It seems that you're exporting your artwork as actual shapes. This can result in slower performance if you use too many vector shapes.

Do you have the 2019 version? What happens if you export your document as texture like shown in the image below?

You'll get a bigger size because animate will generate a lot of spritesheets but the perfomance should be improved.

You can also consider embedding a video of GIFs if this option fails.

Please tell us the result.

Regards,

JC

P

pmwpmwAuthor

Known Participant

I used the texture option at first, and it performed very slowly. The vector shape option seems to be the only thing that runs smoothly.

The GIF option could work well, and would probably be the reduce the size. I may look into that. Is there a way to export your images as GIFs while publishing a canvas, or would I have to code it manually?

Thanks for your response.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded