Yesterday I finally decided to stop development and release my game. In a post below I have a summary of what was my image production process for it.  In the bottom you can find links to the sandbox to play the game and a reddit post about the other parts of game development.

It’s a mobile-first hybrid of a visual novel and Match-3, inspired by 2000s anime, with a detective story, comedy and multiple endings. Nothing fancy, a classic dream game of a guy that watched too much anime.

How the visual style was selected

The production style was not chosen from a single prompt or from one lucky image. I spent a long-time comparing generations, keeping the character description stable while changing the style and artist tags. Tools like animadex were not useful enough, as I needed to be sure that I can always get images generated by my unique prompts and multiple characters will look in one style, but will not copy each other or any existing popular character. I ended up creating 2 unique workflows - Anima Style Finder for exploring candidates, and Anima Artist Bake-Off for comparing artist-style tags under the same prompt architecture.

The practical goal was to sort outputs into “this feels right” and “this does not belong to the project” rather than trusting a model name or a single preview.

Some of the first character concepts were made directly with ChatGPT. They were useful for discovering the visual direction, but they exposed a reproducibility problem: ComfyUI could not conveniently reproduce the same results from the conversational descriptions alone. I was forced to convert visual decisions into explicit prompts, negative prompts, artist tags, character metadata, fixed seeds, workflow-level inputs and many-many different trial and error restarts.

The style-selection workflows remain useful as a record of the decision process. The production workflow uses the winning style as a stable input instead of continuing to search during every character generation. I really recommend everyone facing the same task trying to replicate it, as otherwise level of control you have will be very small.

Why getting the style into VNCCS was difficult

Selecting a style was only the first half of the problem. I needed to have multiple different poses of the same characters. That's why I used VNCCS workflow, that I found here on civitai. It is capable of a lot of things and developer is activly supporting it. But VNCCS did not always preserve or expose the full style state in a way that was convenient to reproduce from ComfyUI. I had to keep the known-good VNCCS widget state, make the artist tag and prompt data explicit, and later rebuild the unified workflow around that verified state. This is why I ended up developing a 3rd workflow that containcs VNCCS dedicated Control Center, a Pose Studio, and a production configuration rather than one large free-form prompt.

VNCCS and background-removal problems

The early pipeline had two operational problems that were easy to miss when looking only at the final images. First, green-background removal was not always stable: green spill and edge contamination could survive around hair, hands, or clothing. Second, the process was difficult to observe while it was running. In some runs it was not obvious whether the graph was still generating, waiting on a downstream stage, or already stuck, so we had to wait until the end before seeing a trustworthy result.

The response was to preserve RAW stages, add live preview events, separate white and green branches, and add explicit preflight checks. The current WHITE_RAW_ONLY mode avoids unnecessary green cleanup for the production path, while the older green branch remains useful as a diagnostic and historical comparison.

Character replacement, pose reuse, and outfit experiments

Alongside VNCCS, we tested several adjacent ideas. Character-replacement workflows attempted to keep the same pose, camera, and scene while replacing one identity with another. Outfit-change workflows held the person and framing stable while changing only clothing. Repose-then-replace variants tested the opposite order: first establish a target pose, then transfer the character identity.

These experiments were useful because they separated three questions that are often mixed together: can the pose be preserved, can the identity be preserved, and can the outfit be changed without changing either? The general replacement flows could demonstrate the idea, but they were less predictable for a production character set than the explicit VNCCS pose contract. Outfit-change flows were useful as diagnostics and references, but not as the final source of game-ready character assets. I think i've spent around 2 weeks on it and eventually got back to what was inside of VNCCS, though I found plenty of ready to use workflows on Civitai for real-life people as the boom of AI influencers started and plenty of folks rushed on solving the problem of replacing outfits on different people in both photos and videos, so I decided to stop there.

The original problem

When I started building characters for our visual novel, the task sounded simple: keep one character consistent, give them a few expressions, and add a second pose. In practice, pose handling became the least reliable part of the pipeline.

I had two separate sources of variation: the character description, which defined identity, appearance, clothing, and expression; and the pose description, which defined body position, arms, gaze direction, and framing. When both changed at the same time, the model started to reinvent the character. Proportions drifted, clothing details changed, and the same character occupied a different amount of space in the frame.

The worst issue appeared when we compared the base pose with the alternate pose. The character was technically the same, but the camera scale was not. That made the downstream matte and export stages unreliable: a correct mask could still produce a bad game asset because the character was too close to the edge, cropped, or noticeably smaller than the neighboring frames.

The key change was making pose a contract

ChatGPT helped me split the problem into two explicit layers: Pose A is the base pose and expression set; Pose B is a separate story-driven pose used as a visual accent. The production setup uses Pose A = 10 and Pose B = 1. A dedicated PosePairSelector applies the selection rather than relying on whichever node happens to be connected first.

We also added body-scale normalization and a 24 px safe margin. Pose #1 and Pose #10 now use the same camera zoom, 1.3160189200279584. The pair selector applies body-height normalization as a second safety layer.

For every character, the pipeline produces neutral, smile, serious / concentration, surprised, embarrassed / blush, and one story-specific Pose B frame.

The RAW frames are first written to a separate folder. After the completeness check, they go through matte and export into a structure that can be connected directly to the game:

game_ready/public/assets/characters/
  miku/rig/pose_a/frames/frame-*.png
  miku/poses/pose_b_pointing_sketchbook.png
  onoe/poses/pose_b_evidence_bag.png
  ayuki/poses/pose_b_phone_theory.png
and etc. (almost 160 different images).

Post Scriptum

I'm preparing now the workflows in mention for public use, polishing them and writing documents for other people, myself and coding agents as I already have plans on not only a sequel but 2 other games that can use the same technology but different visual style. With game release I realized, that though the development history is preserved very well in git my ComfyUI workflows and setups are all over the place (both laptop and PC, literally hundreed gigabytes of generated pictures and almost 2TB of different models). As soon As I'm ready with it I will post them here, as this community really helped me a lot.

Here's a link to the game https://playgama.ai/play/lstgi4udvqu6bk

Here's a link to the post on reddit about the development process https://www.reddit.com/r/aigamedev/comments/1xc2o9i/how_i_developed_detective_match3_with_ai_from_old/