End of Act 2 - Creating the Template

If you are a current reader of Vast Error, it is no secret to you that the comic is currently in the thralls of "The Pandorapause" — an anticipated 4-6 month long hiatus as the team works behind the scenes to craft a roughly over 7 minute Flash animation to cap off the end of Act 2. But how exactly do we go about preparing for such a large undertaking? What technical limitations and prerequisites do we face before production even begins? Join me, Kohi, as I delve into the technical aspects of developing End of Act 2.

*  *  *

This flash animation, like all before it, starts with a template file that I have specifically crafted for the explicit purpose of streamlining the flash creation process. This template is loaded with useful debugging features that help speed up the process of both developing the animation as well as pinpoint problems in it.

To the left in blue is a timestamp for the animation. To the right in green is a frame counter. In the middle in red is a beats per minute calculator. The last of these debugging tools is the most useful for me personally as it removes the guess work from animation cues — I know exactly which keyframe a beat drops at.

With End of Act 2 being such a long animation (which consequentially means it is also a very large animation), I knew from the start that we would need to do what Homestuck did in [S] Cascade. and divide this animation into segments, all tied together with a root flash animation.

Analyzing a decompiled Flash file of [S] Cascade. provided a good frame of reference for how to go about doing this.

The sequence of events are as follows: 1. The root flash file loads itself, 2. The root flash file sequentially loads each segment of the animation and displays a loader percentage and preloader, 3. When all segments are loaded, the root flash file sequentially plays each segment of the animation.

As you can see here, [S] Cascade. has five distinct segments. End of Act 2 will only have two.

Unfortunately, the process of creating a segmented flash template wasn't as easy as modifying the source files for [S] Cascade. Eight years of time has a way of changing how things work. So additional research was necessary to get this working.

This is how Hussie could load segments for [S] Cascade....

...And this is how I could do it for End of Act 2.

These 10 seemingly simple lines of code are some of the most frustrating that I've ever had to craft in my entire programming career. Flash is being deprecated — and for good reason; it's rife with vulnerabilities, clunky, and littered with bugs. It's almost impossible to find support topics on developing present-day Flash projects in the year 2019.

The code works as follows: 1. A Loader object is created which handles the loading of external resources, 2. A URLRequest object is created with the location of the segment's SWF file, 3. The Loader object then loads from the location of the URLRequest object, 4. The initialized Loader object is then added to the stage and hidden until it is ready to play.

Some additional scripting was needed in order to calculate the preloader percentage to be displayed while the flash loads. In essence, the flash root loader 'pauses' itself while segment1 preloads, all the while the preloader percentage continuously updates to the audience. When the number of segment1's loaded bytes equals the total number of segment1's total byte size, the root loader 'resumes' and does the same process for segment2. Once segment2 has also completed its preloading, the animation has been completely preloaded and the animation can begin!

When each segment is initially loaded, their actual SWF file is added to the animation stage in an object called a container. The container allows the root loader to 'interact', as it were, with the SWF file. When the segments are encapsulated in a container, we can freely call simple methods like play() and stop() or even control the volume of the music in the animation. In short: we can now control the segments directly! Functionally speaking, the root loader can tell segment1 to play when everything is loaded, and then tell segment2 to play when segment1 has finished playing.

With End of Act 2 having almost a roughly 7 minute runtime, I decided that, true to [S] Cascade. fashion, we should implement a Play/Pause/ReturnToStart button so the audience could have further control for their viewing experience. I also took the time to add rewind/fast-forward buttons for development debugging (unsure if this will stay in the live animation as it can cause some interesting bugs if used incorrectly).

The code for the buttons is pretty meaty! (And thankfully, rather simple)

At this point, we now have a rather robust template that we can use for End of Act 2 and any future significantly long flash animations.

*  *  *

I hope you all enjoyed this dev log! This is just the tip of the iceberg of what the End of Act 2 has to offer as we begin to expand the field of vision of what Vast Error can offer to its audience.

- Kohi