Too Hot to Handle: Dream Date

Too Hot to Handle: Dream Date was a mobile game prototype based on the Netflix reality show, made at Liithos for Netflix. The player arrives at the villa as a new contestant, plays Truth or Dare with the cast, and makes choices that decide who they kiss and how the night goes, while Lana, the show's AI host, watches.

I owned the generative AI production. That meant the character models, the pipeline that turned 3D previs into finished frames, and the board where every shot was tracked and reviewed before it went into the app. Every frame had to work as a vertical 9:16 image on a phone, show the same six contestants and the same villa from shot to shot, and pass review before it went in.

The pipeline

Each shot went through the same steps:

1. Pre-production. The script and specs fixed the cast, costumes, sets, lighting, and file conventions before anything was generated.
2. Previs. A 3D blockout set the camera, staging, and set for the shot.
3. Background. The previs background was rendered, then given an AI pass. Reusable backgrounds kept the villa the same set across shots.
4. Base image. FLUX.1 [dev] generated the frame, held to the previs by ControlNet and given each contestant's likeness by their character LoRA.
5. Fixes. Inpainting repaired hands, faces, and wardrobe, and a face swap pass corrected likeness where it drifted.
6. Finish. Upscaling and a final pass in Photoshop.
7. Review. The frame went onto the shot board with a review mark, next to the shot's video prompt.
8. Video. Approved frames were animated with Kling 2.1 Master, with idle loops for the choice points and lip sync tests for dialogue.

Pre-production

Nothing was generated until the specs existed. The creative specs covered the character roster with names, roles, and personalities; a costume bible with outfits, colors, and variations; an environment palette with reference boards for each location; lighting moods for each time of day; and art-style references for how photographic the look should be. The output specs covered file naming, the folder and Figma structure, and the formats and resolutions for delivery.

Every shot got an ID by scene, 2000 for Truth or Dare and 3000 for the living room, and every ID carried an image prompt and a video prompt. Every prompt named the character by their LoRA trigger, such as jessie01, and described the framing, pose, expression, setting, and light in full, so the same character read the same way in any scene.

From previs to final

In a traditional pipeline previs is a rough draft. Here it was the foundation, so I set rules for what a good previs render looked like. Clear silhouettes give ControlNet something to hold and stop shapes bleeding into each other. Strong contrast between the characters and the background keeps the model from merging planes. Soft shadows keep depth without hard edges the model could read as object boundaries. A calibrated 3D character model keeps proportions and wardrobe the same in every shot, which makes the LoRA's job easier.

The base model was FLUX.1 [dev], with T5-XXL and CLIP-L as text encoders, sampled with Euler over 20 to 32 steps at a Flux guidance of 3.5. Depth Anything V2 and DWPose turned each previs render into a depth map and a pose skeleton, and Flux ControlNet Union Pro 2.0 fed both into the generation.

The ControlNet setting mattered most. Running it at full strength reproduces the render, game-engine skin and all. The workflows mostly ran it at about 0.27 strength and only for the first 27 percent of the sampling steps. That fixes the composition, pose, and camera early, then lets the model render skin, fabric, and light on its own, so the frame keeps the previs staging without the CG look.

Keeping the cast consistent

Six contestants and Lana had to look like themselves in every shot, across scenes, outfits, and light. Each contestant had a character LoRA trained on a dedicated photoshoot, and the photoshoot guide set the rules for those datasets:

• Decide the purpose first. A fixed outfit and a flexible wardrobe need different datasets, so the shoot plan followed from that choice.
• Shoot for quality. At least 1024 pixels, ideally 4K, in RAW or PNG and never JPEG, with sharp focus and no motion blur.
• Match the lighting to the scenes. A character who appears in sunlit scenes needs direct sunlight in the dataset. A single lighting setup across the whole shoot overfits.
• Cover the framing. Extreme close-ups through full body, from high, low, front, profile, and back, with relaxed, dynamic, and expressive poses.
• Keep it clean. No logos or busy patterns, no stray people or reflections, no heavy grading, and accessories only when they belong to the character.
• Caption everything. Each image was annotated with outfit, pose, expression, environment, lighting, composition, and lens.

The guide's rule of thumb was that the input is 80 percent of the output: a good LoRA depends more on the dataset than on the training.

Each character had candidate LoRAs, and they were tested before one was approved. Epoch tests rendered the same prompt at successive training checkpoints, and strength sweeps rendered a character at LoRA weights from 0.5 to 2.0, in steps of 0.1, on one labelled sheet. The approved version of each character went into a single folder that the production workflows loaded from. Two characters, Taz and Poppy, went through a second version. In the saved workflows the character LoRAs ran at a model strength between 1.0 and 1.35.

Wardrobe had three routes. If the photoshoot included the costume, the character LoRA learned the outfit along with the likeness. In-context try-on applied a reference outfit to the character through image-guided inpainting. For a costume that had to stay exact, a small clothing LoRA trained on just that garment could be blended with the character LoRA or applied through inpainting.

Fixing and finishing

Most frames needed some repair. Inpainting worked on a crop around the masked area, scaled to a fixed vertical working size, then stitched the result back into the full frame. The mask was grown and feathered, differential diffusion blended the edges, and the denoise ran between about 0.5 and 0.9 depending on how much had to change. That handled hands, faces, and wardrobe details.

Where a face lost its likeness, especially in shots with two characters, a face swap pass with ReActor, using the inswapper model and CodeFormer restoration, put the right likeness back before the frame was retouched. Finals were upscaled with the Flux ControlNet upscaler or Magnific and finished in Photoshop.

Reviewing at volume

The shot list lived on one Figma board. Each shot ID carried its image prompt, video prompt, previs, and finished frames, plus an artist tag and a review mark. Before a base image went up for review it had to pass a checklist: four fingers and a thumb on every hand, five toes on every foot, normal ears and eyes, clothes that make physical sense, no jewelry, no malformed chairs, tables, plants, or lights in the background, and the correct resolution. By the end the board held 274 review marks: 136 green, 39 yellow, and 99 red.

Bringing it to video

The app played video, not stills. Its narrative script cued a named clip at every beat, such as jesse_01 or taz_03, so approved frames had to become shots. I animated them with Kling 2.1 Master, using each finished frame as the start image and the shot's video prompt from the board, and kept the clips vertical for the phone.

Choices needed their own kind of clip. While the player decides, the character can't freeze, so each choice point had an idle loop, made as an extend in Kling that starts on the last frame of the clip before it so the cut back in doesn't show. That was the hardest part to keep clean. The extends tended to stretch the frame slightly and shift the color warmer, which shows as a jump at the loop point, and at the time of the QA pass that logged it the fix was still open. Key moments got their own generations, such as a separate kiss for the "lean in" choice instead of the small peck.

The dialogue was voiced, so lip sync became a stage of its own, and I tested two routes. Kling's lip sync animates the mouth on an existing clip to match the audio. Runway Act-One takes a driver video of a real performance and transfers its expression and timing onto the character. QA flagged lines where the lips drifted from the voice-over, which is the gap those tests were trying to close.

Where it started

The project began in 2024 with R&D on the date mechanic, before the final cast and pipeline existed. This early test shows the idea: the player picks a line, and the score out of 100 rises or falls with each choice.