All blog posts
3 months ago (Jul 16th, 2018) by tbac

Sol Press Weekly Round Up 07/16/2018

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…

 

Progress:

Visual Novels:

Newton and the Apple Tree:

  • Doing a second QA pass while we wait for Steam approval.
  • Launching as soon as we get through Steam approval
  • First stretch goal translated and edited. Will be launching a few months after the main game.
  • Backerkit locked down.

Yotsunoha:

  • Translation & Editing Wrapping up
  • QA Starting
  • Launch window changed to Q3 2018
  • Demo available¬†HERE

Sakura Sakura:

  • Up-scaling and programming in progress
  • Releasing ASAP, with Kickstarter Exclusive Beta prior

Light Novels:

Physical copies of Strongest Gamer and Battle Divas finished printing, available on Amazon now!

Strongest Gamer is available Here.

Battle Divas is available Here.

 

Tales From Sakura Sakura:

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.

Lots and lots of this

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.

You might not be aware that photoshop actually has a javascript like scripting engine that can be used to script actions. It’s slow, poorly documented, and provides little feedback for errors and debugging… but it is doable. I initially attempted to use various libraries to load photoshop files externally, but the psd files use complex blending modes that didn’t reproduce properly… the only solution was to do it all in photoshop. To automate it, the plan was to make a simple custom scripting language that can be used to define what parts from the psd need to be grouped together.

A sample of the scripts used to identify what parts are displayed together.

The script references the layer names in photoshop directly.

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.