Thanks for the comments!
@ixMarcel: Believe it or not, the thought did cross my mind while I was working on it :P2 There are plenty of 2D maze generation algorithms I could reuse and the internal structure of the Map.bin file is rather simple, so coding a tool to generate basic random mazes would certainly be possible. However, the keys/locked areas and the decorations would probably complicate things quite a lot. Still, I could release the World.ini code generation tool so other authors can include similar mazes in their levels if they want (although the actual layout would still have to be designed manually).
There's a lot more "shift code" in the .ini file than it needs to be, too. The current tool doesn't do any optimization at all, and just generates all shift metadata for each possible maze cell (1 cell = 4 screens / NSWE) in the grid, regardless of if they're actually present in the map or not. Also, generating a maze larger than the current one would increase the size of the World.ini file dramatically, which would probably slow the level editor to a crawl.
@SilasMann: The attached overlay contains the entire visible level (which is only one "virtual" screen and doesn't match the real level layout), and a CO with a static sprite of Juni is placed at the center on layer 7. Meanwhile, the real player character is made invisible (by using a fully transparent sprite sheet) and placed at the bottom-left in a real screen. As the player moves from side to side, the overlay is scrolled accordingly while the visible Juni CO stays at the center. This means I had to playtest this thing constantly in order to make sure the fake level (overlay) and the real one matched each other, to make sure the level could be navigated from start to finish and to prevent "Juni" from phasing through walls :sick:
Below are several notes on this experiment that may (or may not) contain tips on dealing with long/complex animations in KS.
* Even though indexed PNGs (256 colors or less) don't seem to be supported in KS, grayscale PNGs work correctly and can be used for COs. If your sprite/animation doesn't need color, you can cut the file size to about a third of the original image by converting it to grayscale format instead of using RGB (since this color space only requires 1 byte per pixel, as opposed to 3-4 bytes in the RGB and RGBA formats).
* Using solid colors as much as possible is a good way to take advantage of the lossless compression in PNG, which is why I posterized the animation to B&W (since the original animation already used silhouetted graphics) in order to make it take as less disk space as possible. However, trying to optimize the palette in the resulting PNG file caused KS to stop recognizing it, so I had to work with the full grayscale "palette" even when I only needed two colors.
* Despite the very low file size of the resulting PNG files, trying to fit the entire animation into a single strip always resulted in the processing tool (ImageMagick) freezing and/or slowing the system down to a crawl due to high memory usage (again, probably because of the size of the decompressed data that has to be loaded in memory). The most I could manage without my system going completely haywire was making a 2000 frames long spritesheet, which took my PC a few minutes to build but worked just fine in KS. This might have been due to the low amount of RAM in my system (only 4GB), though, so maybe it's possible to make a single long strip if you have more than 8GB of RAM. Still, doing it that way is probably not a good idea, as this would make editing the resulting strips very slow and cumbersome (or even impossible).
* KS seems to stop loading spritesheets for COs after a certain amount of memory (about ~1.5GB) has been allocated to the stdrt.exe process, resulting in a lot of blank/empty COs after said limit is reached. This is what happened when I was first experimenting with the 30fps version (probably due to the size of the raw uncompressed data for the entire animation), and my options were: A) shorten the duration of the entire sequence to about 1:30 by cutting entire segments; B) lower the resolution of the individual frames; or C) cut down the frame rate from 30 to 15 fps discarding every other frame. I went with the last option, since I didn't want to use an incomplete animation nor resort to a smaller picture size.
* Since I couldn't fit the entire animation into a single strip, multiple COs had to be used. This wouldn't have been much of a problem in KS+ because I could have taken advantage of delayed shifts and the "block user" object to easily implement the entire sequence with only a few screens. However, doing this in vanilla KS was more difficult, since I could only delay screen transitions so much without requiring user intervention. What I did was making Juni loop through the entire screen (except the bottom row, which contains the Shift objects that make this possible) from the top-left to the bottom-right corner. I used a test animation (with an Anim Speed value of 300, which seems to be the rough equivalent of 15fps) that displayed a numeric frame index so I could measure how many frames would be displayed per screen, and then used that value as a reference when splitting the animation into chunks.
* The previously mentioned time could have been greatly extended by enabling the umbrella and giving the player instructions to open it and keeping it that way during the entire sequence. I chose not to go with this approach because I wanted the entire thing to be fully automatic and minimize the risk of the player doing something unexpected that would break the sequence and/or cause audio desynchronization (e.g. closing/re-opening the umbrella
at any point).
* The PNG files generated by ffmpeg and ImageMagick were not using the best possible level of compression, and I was able to further reduce the file size of each PNG strip simply by opening them in GIMP and saving them again with a compression level of 9 (max). This allowed me to cut down the total size of the animation from ~4.2MB to ~3.6MB.
* The last problem I had to deal with in order to get the video to play smoothly was the flickering during screen transitions, which caused the screen to go completely black for a fraction of a second (objects are not rendered in the first render pass in vanilla KS -- only the gradient and the tiles are visible at that point). The workaround for this was to extract the first frame of animation for each of the 16 chunks and convert them to gradients, then set the background in each screen to the appropriate gradient.
* When I first finished implementing the entire thing in KS, I noticed (way too late) that I had screwed up when cropping blank frames at the beginning from the original video, and that the first 60 frames of animation were missing :oops: Since I didn't want to export and optimize the whole sequence again, I resorted to patching in the missing frames in an extra screen and manually adding a few delay cycles at the start.
For this level, were you at all inspired by the aesthetics of Steven Universe? Specifically, there is a very prominent character named Pink Diamond with aesthetics similar to this level, including the little jumpy happy diamond critters.
(https://pm1.narvii.com/7078/56d9b0d1a4d02cbb0cfdb0d2aee9503a7e033bf1r1-1578-867v2_00.jpg)
(https://vignette.wikia.nocookie.net/steven-universe/images/f/f5/That_Will_Be_All_063.png/revision/latest?cb=20170214011528)
(https://i.ytimg.com/vi/Px3x2Fefhe8/maxresdefault.jpg)
No, I'm not familiar with the show at all. I guess it's as they say in disclaimers, merely a coincidence :P2 The backgrounds in those pictures look pretty cool, though. Makes me want to try making a more detailed version of this.