Hey all, apologies for missing the past two weeks! I’ve been feeling a bit under the weather lately, but I’m all good now.
There’s not too much to speak of progress wise, but we do have some comments from Doddler which may help to explain why Sakura Sakura is taking so long…
Newton and the Apple Tree:
Physical copies of Strongest Gamer and Battle Divas finished printing, available on Amazon now!
Hello everyone, Doddler here. I was brought on several months back to assist on the Sakura Sakura project in making the higher res assets for the English release. If you recall, Sol Press announced during the Kickstarter that they would be releasing the game in higher res than the original. I told them they were crazy to do it, but sanity is not a common trait in this industry.
You might be wondering, why would you bring on a programmer to do an image job? Well, I’m here to tell you! Sakura Sakura is a game developed by Hiqo Soft, the ‘hiqo’ short for ‘High Quality’. True to the name, the game contains an almost crazy amount of art assets, as well as simple animations including blinking sprites and mouth movement. Just among character sprites, there are over 5000 images. That’s not the full story though, because all the frames of animation for a specific eye or mouth pose are placed on a single image or sprite sheet for each set. Each character has about 5-6 poses, 3-6 outfits, 4-6 eye and mouth variations for each one (with several frames of animation each), with three different kinds of lighting. There’s a lot of images, is what I’m saying.
We were given psd files with high resolution assets, but there’s no particular easy path to get that into cut up sprites. In addition, each set of sprites has an associated file that tells the game how to compose those sprites and where to display each of the pieces. It isn’t enough to just make bigger sprites, but we need to make sure the different parts get placed in the right locations, and update all those sprite files with updated values.
There’s really no easy way to get the thousands of images out of these dozens of psd files without an equivalent thousands of hours of terrible manual work, so the answer is easy: automation. I needed a way to take the psd file, specify what layers represent what images, find the new dimensions and coordinates of each sprite based on the original sprite definition files, and then spit out new images and sprite files.
In the end, the workflow I created worked like this:
1. You make a script, where you specify the base layers and what is on those layers (for different clothing and such). Then you define animations, which are sequences of layers that display on top of the base layer. You can add modifiers, such as clipping masks, or add additional layers to each group.
2. Your script is parsed using a custom tool and creates a photoshop .jsx file. The jsx file scripts photoshop to enable/disable layers and saves every possible combination of layers that is used to a temporary folder.
3. Another tool reads the script again and the original sprite definition files, and takes the images output in the previous step. It then crops and masks the images to the proper size, and then builds the sprite sheets and updated definition file for each animation.
And that’s it! It’s certainly not an easy process, is it? Even automating the conversion, naming layers, building the scripts is all a rather manual process, so it’s taken longer than was originally forecast. So if you’re wondering why things have taken longer than expected, this is one of those reasons.