Video no. But sure, I'll give you a quick break down of some of the processes involved in making an update.
First up is text capture. I need all the dialogue form the Unity game. I used to get this by typing it all by hand (fucking yuck), then some OCR, which transcribed a lot of mistakes. Those had a lot of issues, not the least of which is typos. Now, I just modify a bit of game code (using dnSpy to open the fungus DLL, and slip some custom code into the SayDialogue function) to output text as it displays on screen, and completely hide the text box (for clean image captures).
(I also do some search and replace reformorting, such as adding speaker names for text, or replacing character names with variables, stuff like that).
Once I have the script, I have to pull out all the images (and videos (windows+G)). I use two tools for getting images. One is a mod from this site called Texture Replacer, which lets me dump all the images out of a scene (great for getting backgrounds and texture files (used for character puppets and animations). The second is a simplistic bit of python I wrote to click and capture images out of the game. I used to get images via image extraction, but Ferdafs has started using file optimization via Atlasing which makes most image unusable (example below).
View attachment 3328008
Once I have the images, the next step is sorting the images into folders so they all match, then slicing, or cutting away the parts of the images that don't change. For the new content from 3.9, before image slicing the file size of all the images is roughly around 190MB. After slicing the file size is 36MB (and after compression it will be 5~8mb).
So how does slicing work? It's simple to understand, slightly tedious to do.
I built an automated script that (mostly) gets the job done, but sometimes gives me fun outputs like this one:
View attachment 3328022
All slicing is, is a difference between a background and foreground layer. I cut out only what is changing (creating a "slice" of the base image) and this lets me remove the parts of the image that are the same, and only include a file that has what is different. There are several ways I can implement it in game, but they all boil down to a layeredimage that I can simply change which "overlay" displays on top of the background.
So, for example, here is a background, the second image with a new mouth, then a difference layer (in clip studio) between the two, and the final sliced image:
View attachment 3328028
View attachment 3328107
View attachment 3328045
View attachment 3328031
The sliced image is transparent, except the part that is changing, making the file size tiny. This lets me put out an uncompressed image set that isn't 10GBs. I'll often have to go in and clean up sliced images by hand, my script is imperfect and sometimes causes extra noise. Or, sometimes more than one thing is changing, so I'll make that it's own overlay element for more image control.
The main goal is to both make it small, and easy for me to work with. This is all just prep work and varries in how much time it takes me. If slicing is smooth, than it's fast. If I have to "fix" every image, then it can take days.
Implemntaiton (putting all the assets into the game) mostly invovles me launching the Unity game on one screen, and my IDE on another, and matching up what images go where (and making adjustments as needed). I built another tool to help me with this, the
Layered Image Poser (which I uploaded to this site for others to use). It lets me re-combine images and copy/paste code directly.
(Also video capture and editing (to make them loop), nothing special here, but usually has to be done).
Once all the content is in, I'll sometimes add exrtas or alterations (in addition to anything I changed during implmentation) then playing it over and over and over and over looking for mistskes.
When I'm happy with the scene (or can't stand to look at it anymore), I send a BETA build (unfinished game files, that may have bugs or placeholder elements) off to
aaronminus for dailogue editing and review (and aaron can talk about that side of the workflow if desired). Then I get revised file(s) back, implment the reivisions via text difference, and depending on time, possibly send it out for additional passes.
Then more testing... and when I can't find anything else (or again, can't stand to look at it anymore), I make the final builds and upload them, then do one last check on the final files (looking for crashes, not typos), and if everything is good, release it.
I hope that explains it well enough?
