DEV Community: 尚毅段

A same-word game that runs in the browser: state, scoring, and the tie problem

尚毅段 — Sat, 14 Nov 2026 01:32:53 +0000

Two players join a room, get the seed word "moon", and type a word each in secret. If both write "night", they score. If one writes "night" and the other writes "star", the round ends with nothing, even though both answers are perfectly good associations.

That gap is the whole game. I built SameWord, a word-association game for two to four players that runs in a browser tab with no account and no install. The interesting part was never comparing two strings. It was deciding what a round is, how a round is won, and what happens when the room does not agree.

Here are the three parts that took the most thought.

A round has one state, and everyone shares it

A game is five rounds. Each round has the same shape: the server picks a seed word, every player submits exactly one word, then everything is revealed at once.

The reveal is the only moment anything is shared. Before that, the room shows a counter like "2 of 3" and nothing else. Nobody can see which words are in, so nobody can copy an answer. When the last player submits, or the clock hits zero, the words appear together with the name attached to each.

Two timers have to agree for that to work: the round clock (30 or 60 seconds, chosen when the room is created) and the reveal. The round clock is the authoritative one. If it hits zero with someone still typing, the round is scored on the words that arrived; an empty slot is skipped rather than filled with a placeholder. That rule matters in practice, because a four-player room with a 60-second clock will almost never have everyone submit early.

The host presses Start on each round, which creates an obvious failure mode: a distracted host freezes the room. The reveal advances on its own 20 seconds after it appears, so the game keeps moving even if nobody clicks.

Two ways to win, and no partial credit

A round scores when one of two things is true.

A match: every submitted word is the same word. The comparison trims spaces and ignores capital letters, so "MOON" and " moon " are the same. Plurals are not. "rabbit" and "rabbits" are different answers, and so are "ocean" and "sea", because the game cannot score a synonym as a match on its own.

The second path is the same-meaning confirm. The words differ, but every online player taps a button saying they treat the words as one answer. Then the round counts.

That button exists because word matching fails exactly where language is interesting. Plural forms, synonyms, and typos are all things a room can agree on and a string comparison cannot. But a confirm that any one player could trigger would be a free point, so it needs unanimity.

There is no partial credit. A round is a win or it is not, and the result screen counts wins out of five. Players who want a finer signal have asked for per-round closeness scores; I left them out because "you were sort of close" turns a five-round game into a spreadsheet.

The tie problem is the default, not the edge case

The seed for round two comes from round one. After a win, the next seed is the word the room agreed on. After a no-match round, the next seed is the word that appeared most often.

That rule has a hole, and the hole is the normal path whenever two people play.

In a two-player room with no match, the two words appear once each. The frequency is 1 to 1 every single time, so "most frequent" never picks a winner. Three players can produce a three-way tie; four players tie two and two quite often. A tie-breaker is not a rare branch in this game, it is the road most rounds take.

The rule I settled on: when words are tied on frequency, the word that was submitted first becomes the seed. It is deterministic, it needs no extra round, and every client can compute it from the same reveal data.

The cost is real. Submission order is a function of typing speed and network latency, so in a two-player game the next seed is often decided by who was faster rather than by anything about the words. A player who types immediately after the seed appears gets to steer the following round. I considered three alternatives. A random pick from the tied words is fairer but makes the game feel arbitrary. Replaying the round punishes everyone for a tie. Carrying the previous seed forward breaks the chain that gives round two its context.

None of those were clearly better, so the fast-finger rule stays. If I were starting over, I would show the tie resolution on screen instead of resolving it silently. Players already suspect the seed is not random; telling them the rule is cheaper than letting them guess.

Unanimity breaks before anything else does

The same-meaning confirm asks every online player. With two people that is two taps and a small cost. With four it is the most fragile part of the game, because one player who does not tap turns a round everyone else agreed on into a no-match.

"Online player" is doing quiet work in that sentence. Someone who closed the tab cannot confirm, so they cannot block a round either. Someone who is still connected but walking away can. The rules put no timer on the confirm, so a four-player room can stall on a decision that three people already made.

I have not solved that one. A majority rule would make the four-player mode feel fairer, but it would also let two players outvote the third, and the entire game is built on the idea that the room is the unit, not the individual.

What a browser-only room actually costs

No accounts means the room code is the only shared object: six characters generated when the room is created, copied into whatever chat the group already uses. There is nothing to install and nothing to sign up for, and the host's player list is the only social proof that anyone is there.

The constraint shows up in small places. Words are capped at 24 characters and limited to letters, spaces, hyphens and apostrophes, which keeps the comparison simple and stops the input from becoming a message box. The one-phone mode exists for the same reason: two people, one device, hand it over between turns, words stay hidden until the reveal.

None of this is exotic. A five-round game with a room code and a countdown is about as small as a multiplayer browser game gets. The state machine, the unanimity rule, and the tie-breaker are where the game actually lives, and all three are decisions about what the room is allowed to disagree on.

SameWord is free at playsameword.com, and the rules are written up at playsameword.com/how-to-play.

Book cover sizes that actually break at upload

尚毅段 — Fri, 13 Nov 2026 01:26:29 +0000

A cover that looks finished can still fail at the KDP upload step. When it does, the error is usually not about the artwork. It is a number that came from a different version of the book.

I maintain the sizing calculator at BookCoverGen, and the same handful of mismatches show up in support mail. Here they are in the order they cost people the most time.

The only arithmetic that matters

A print cover is one flat file:

width = panel + panel + spine + 0.25 in
height = trim height + 0.25 in

The 0.25 in is 0.125 in of bleed on each outside edge. The panels come from the trim size. The spine comes from page count times paper thickness.

For 6 x 9 in at 300 pages on black-and-white white paper, KDP's per-page figure is 0.002252 in, so the spine is 0.676 in and the full wrap is 12.93 x 9.25 in. Every case below is that calculation going wrong in a different place.

1. Your page count changed after the cover was built

This one gets caught in the previewer, not at your desk.

Re-paginate a manuscript and the spine moves. 6 x 9 at 250 pages on white paper is 0.563 in. At 300 pages it is 0.676 in. That is 0.113 in, close enough to an eighth of an inch, and it lands exactly where the author name sits on the spine. On a fold, an eighth of an inch is the difference between centered and cut.

Build the cover after the final proof, not after the first draft. If the interior changes, re-run the calculation before the next upload.

2. The paper changed, the cover did not

KDP's spine math is per paper type:

black-and-white white paper: 0.002252 in per page
black-and-white cream paper: 0.002500 in per page
premium color white paper: 0.002347 in per page

At 300 pages the white-paper spine is 0.676 in. The same 300 pages on cream is 0.750 in. The file has to grow by 0.074 in, and the front and back panels shift outward with it. Switch paper at the pricing step and keep the old cover, and the spine type is off the fold.

3. The file has no bleed, or bleed on two edges

A print file is trimmed after it is printed. The artwork has to run past the trim line on the top, bottom and outside edges, which adds 0.25 in to both dimensions.

Two common versions of this:

the file is built at trim size (12 x 9 in for 6 x 9 at 300 pages, not 12.93 x 9.25 in);
the designer adds bleed at the outer edges of the front and back panels but not across the spine wrap.

Both look fine on screen, because the missing strip is white and the background is white. The previewer is the first place the trim sliver shows up, and a background that stops at trim size will show a hairline at the cut.

4. The ebook cover was exported from the print panel

Ebooks have no spine, no bleed and no back cover. KDP asks for a front cover of 1,600 x 2,560 px at a 1.6 aspect ratio, JPEG or TIFF, under 50 MB.

The print panel for 6 x 9 in at 300 DPI is 1,800 x 2,700 px. The ratio is 1.5, not 1.6, so it does not simply scale down. What happens next depends on the store: the image gets cropped, padded, or rendered smaller in the thumbnail grid than a properly sized file. Export the ebook cover at the pixel size, separately from the print export.

5. Spine text on a book that will not print it

KDP prints spine text only above 79 pages. Below that the spine stays blank, so artwork should run through it and type should not be there at all. Type placed on a 40-page file does not appear in print; if the page count later grows past 79, the old file still has type set for a spine width it no longer has.

When there is spine text, it needs 0.0625 in clear on each side of the fold. Thin books have thin margins. Check the template before the title goes on the spine.

6. More than one page, fonts not embedded, images below 300 DPI

These are the boring checks that produce failed preflight:

the wrap is one page: back cover, spine, front cover, never three separate files;
fonts embedded, not linked;
images at 300 DPI at final size;
one flattened layer, no live transparency.

The barcode area on the back cover has to stay clear. The template marks where it goes.

Before you upload, check these six

Final page count, after the last proof.
The paper type you will actually print on.
Full wrap = panels + spine + 0.25 in.
Bleed 0.125 in on the top, bottom and outside edges.
Spine text only over 79 pages, 0.0625 in clear on each side.
Ebook cover exported at 1,600 x 2,560 px, separate from the print wrap.

KDP publishes the current figures and changes them. The calculator on our site runs the same arithmetic with your page count and exports a layout guide at 1 unit = 1 inch, but the printer's template is the final word. When a file fails at upload, the error text is usually accurate about which of these six it is.

Modeling 33 weapons 9 classes as data (not screenshots)

尚毅段 — Thu, 12 Nov 2026 01:24:40 +0000

Modeling 33 weapons × 9 classes as data (not screenshots)

Most camo trackers are a grid of screenshots. You scroll, you find your weapon, you count boxes with your eyes, and when the game patches something the images are wrong until someone re-uploads them.

I built MW4 Camo Tracker the other way: the whole grind is one JSON dataset, and every screen renders from it. Here is the shape of that data and the parts worth reusing.

The data is a tree with three levels

The top level is class: assault rifles (8), submachine guns (5), shotguns, light machine guns (3), marksman rifles (3), sniper rifles (3), pistols (4), launchers (4), melee. That is 33 weapons.

Each weapon owns an ordered list of camo rows. Order matters, because the game unlocks in a fixed sequence: military camos first, then the 99 special camo challenges, then gold, platinum, harmonic break, divergence, and the mastery set on top. The site exposes 473 checkable rows in total, and every row has a stable id built from weapon + camo, not an array index.

That last decision saves a lot of pain. Array indexes shift the moment a patch adds or removes a camo, and any saved progress then lands on the wrong row. A synthetic key like m4-gold survives reordering.

// rows are generated at build time from the dataset, ids are derived, never positional
const rowId = (weapon, camo) => `${weapon.slug}-${camo.slug}`;

Same reason the dataset keeps the class list as a separate table. Nine classes is small enough to inline, but the sidebar, the filters and the sitemap all read from one array instead of repeating the list three times.

Why not screenshots

Screenshots are easy to produce and cheap to look at once, but they carry cost that grows quietly:

A 1400px webp per weapon is fine for one page and painful when every weapon page needs its own hero image.
You cannot compute anything from an image: no percentage, no "next unfinished row", no sort by challenge type.
Screen readers get nothing. Text rows can be tabbed, labelled and announced.
After a patch, every changed row means an image edit. Text means one JSON diff.

The counterargument is that screenshots show the actual game UI and users trust that. That is fair — but the trust comes from the weapon names and camo names matching the game, not from the image format. A text row that says "Gold — 0/1" carries the same fact.

Progress state lives in the browser

Every tick is stored locally and the page renders from that store. The schema is one object: dataset version plus a map of row id to timestamp.

{
  version: 1,
  dataset: "2026-11",
  rows: { "m4-gold": 1762361000000, "ak74-platinum": 1762361402000 }
}

Two details that matter more than they look:

Dataset version is stored with progress. When the dataset changes, the app can tell whether a missing row was completed or removed. Without it, a patch silently resets partial progress.
Writes are debounced and total count is rendered from the map. No separate counter to get out of sync. The header says 0 / 473 because it counted the map on render, and the map is the only source of truth.

The tradeoff is device-local state: clear your browser data and the grind is gone. That is why the site also offers a Google sign-in to sync, and an export the user can keep. Local-first with an explicit sync opt-in beats an account wall in front of a checklist, and it keeps the first visit fast.

The "next challenge" suggestion is rule-based, on purpose

The site suggests an unlock order. It is generated from the published camo order plus the rows you already ticked. It does not claim to know which challenge is easiest for you, because that depends on how you play. The copy on the page says so.

That distinction is worth writing down in the product, not just in a code comment. A tool that says "easiest" and gets it wrong loses trust on the second weapon.

What I would do differently

I started with a flat array per weapon and had to migrate. The synthetic id should have been there from day one.
I kept the class order in the component. It belongs in the dataset next to the weapons.
I underestimated how much of the UI is just "does this row have a timestamp". A single derived selector would have replaced three separate conditions.

None of this is novel architecture. It is the same argument as any catalog app: store facts, render views, keep ids stable, and let the data survive the next patch. The camo grid just makes the argument easy to see, because the whole product is one long checklist.

Cache-read prices are where LLM bills quietly diverge: 50 models compared

尚毅段 — Wed, 11 Nov 2026 04:35:29 +0000

Most LLM price pages lead with input and output cost per million tokens. That number is easy to compare and easy to misread. Cache reads change the bill by a factor of 20 to 50, and the discount is not uniform across vendors, so two models with the same input price can end up far apart once prompts get reused.

We keep a price table of 55 models across OpenAI, Anthropic, Google, DeepSeek, xAI and others, checked on 2026-11-11 against each vendor's pricing page. This post pulls out one column that rarely gets compared: what a cached input token costs relative to a fresh one.

The spread

Fifty of the 55 tracked models publish a cache-read price. The ratio to standard input ranges from 2% to 5%.

Model	Input $/1M	Cached $/1M	Cached share of input
DeepSeek Flash (V4.1)	0.30	0.006	2.0%
Claude Fable 5.2	8.00	0.20	2.5%
Claude Fable 5.1	10.00	0.25	2.5%
DeepSeek V4 Pro	1.32	0.044	3.3%
GPT-6.1 Terra	1.00	0.05	5.0%
GPT-6.1 Sol	2.00	0.10	5.0%
Claude Sonnet 5.5	2.00	0.10	5.0%
Gemini 4 Carbon	2.00	0.10	5.0%
Claude Opus 5.5	4.00	0.20	5.0%

The 2% tier is not the same product as the 5% tier. A 2% cache read means a repeated 100K-token prompt costs 2% of what the first pass cost; at 5% it costs 5%. Over a long agent run that difference is the difference between a workflow that pays for itself and one that does not.

Five models publish no cache price

Mistral Small 4, Codestral 25.08, and the Ministral 3 family (14B, 8B, 3B) list no cache-read rate. That does not mean they are expensive. It means you cannot model a cached workload from the public price page alone, and any comparison that assumes one is guessing.

What this changes in practice

Compare cache ratios before you compare headline prices. A model at $1 input with a 5% cache read can cost more than a $2 model at 2% once the same context is reused a few times.
Watch the long-context surcharge. GPT-6 Astra is $10/$50 per million up to 272K input and $20/$75 beyond it, which moves more than the cache discount saves.
Re-check monthly. This table moved on every check we ran between 2026-11-04 and 2026-11-11.

The full table, with per-model sources and checked dates, is at AI API Cost Calc. If you spot a price that has drifted, the site links every vendor page it was taken from.

How to Play the Same Word Game: Rules for 2–4 Players, Scoring, and the Part the TikToks Skip

尚毅段 — Mon, 09 Nov 2026 10:09:15 +0000

The same word game is the two-player word game that spread through Douyin and TikTok in early November: every player gets one seed word, each player secretly writes a single word they associate with it, then the words are revealed. If two people wrote the same word, they score the round.

Most clips online show the fun part and skip the rules. These are the exact rules we built into a free browser version at playsameword.com, plus the house variants we ended up using.

What you need before you start

2 to 4 players, each with their own phone or laptop. Words are submitted secretly, so one shared screen does not work.
A room code. The host creates a room and gets a 6-character code; everyone else joins with the code or a share link.
30 or 60 seconds per round. 60 seconds is the better setting for kids and for anyone playing in a second language.
A game lasts 5 rounds. That is about 5 to 8 minutes with the reveal pauses.

How one round works

The game shows everyone the same seed word. The built-in list includes words like moon, ocean, fire, rabbit and winter.
Each player types one associated word, 1 to 24 characters. Letters, spaces, hyphens and apostrophes are allowed; anything else is rejected before it reaches the server.
When every player has submitted, or the timer hits zero, all words are revealed at once.
The round is scored as an exact match, a synonym, or nothing.

Players who do not submit in time simply sit the round out. The game does not fill in a word for them.

Scoring, including the part the TikToks skip

Exact match. Both words are normalized (lowercased, spaces trimmed) and compared. Moon and moon count as the same word. This is the main way to score.

Synonym. If the words are different, every online player can click "these mean the same thing." If everyone agrees, the round counts as a success. This exists because two people can hold the same idea and still type ocean and sea. Without the vote, those rounds would be scored as misses, which feels wrong and makes groups stop playing.

The next seed word. After a successful round, the winning word becomes the seed for the next round, so the chain drifts toward whatever the group agreed on. After a failed round, the most-submitted word becomes the next seed. With 2 players and a tie, the word submitted first wins.

The result page lists matches out of 5, the words from every round, and the full seed chain. If you want to compare games later, the chain is the interesting part: it shows how far the group travelled from the first word.

Four things that decide whether you score

Round one is harder than it looks because the obvious answer feels too obvious to write.

Write the most obvious word, not the cleverest one. Obvious words are shared words. A clever association is almost always personal.
Pick your first association, not your third. Most players scan the seed, reject the first word as too easy, and land on something only they would say.
Concrete beats abstract. Pizza is a shared word. Hunger is not.
In 3–4 player games, use the synonym vote early. One player writing a slightly different word should not kill a round that everyone can see was the same idea.

House variants worth trying

60-second rounds when the group includes younger players or people playing in a second language.
Theme rounds. Agree before the game that every association has to be food, a city, or a movie title.
Best of three. Five rounds is short; three games takes about 15 minutes.
One-word strictness. Enforce it strictly if you want faster rounds; allowing two-word phrases makes matching much easier.

Where to play

The free version is at playsameword.com. No account, no install, runs in the browser on phones and desktops. There is a Chinese version at playsameword.com/zh/ if your group mixes languages, and the two pages link to each other.

Full disclosure: we built the site. The rules above are free to copy into your own group chat, and the scoring detail is here because most clips leave it out.

What makes a photo usable for a tattoo stencil (and what doesn't)

尚毅段 — Sat, 24 Oct 2026 03:13:36 +0000

Most "photo to tattoo" attempts fail for a reason that has nothing to do with the model: the photo was never going to survive the conversion.

A tattoo stencil is not a filtered photo. It is a line drawing at a fixed physical size, printed at 300 DPI, that an artist will transfer onto skin and cut into. Every decision before that point either supports the drawing or destroys it.

What a stencil actually needs

Closed, continuous outlines. A stencil is transferred through the outline. Gaps mean the artist improvises.
Simplified interior detail. Shading in the reference becomes either solid black or nothing — a stencil cannot hold a gradient.
Known physical size. 300 DPI at 10 cm is a different drawing from 300 DPI at 20 cm. Line weight has to scale with it.
No background. The photo's room, floor and furniture are not part of the tattoo.

So the pipeline is roughly: remove the background, find the subject's silhouette, simplify interior edges to a consistent line weight, and export at print resolution.

Why fur and foliage break it

Edges that are textured are the hard case. Fur, hair, leaves, lace — each strand is a real edge, and a naive edge detector turns them into thousands of tiny closed shapes. The result looks like static, and no artist will tattoo it.

What works instead: treat the silhouette as the outline, treat interior detail as a handful of shapes, and let the artist decide the rest. A dog portrait stencil is not every hair; it is the ear shape, the eye, the muzzle line and the collar.

The photo checklist

Before uploading anything:

One subject, filling most of the frame
Even light — a hard shadow across the face becomes a hard line in the stencil
Plain-ish background — it gets removed, but busy backgrounds confuse the mask
Sharp focus, especially at the edges you care about (eyes, ears, letters)
No filter. Contrast that looks good on a phone screen turns into a mess of black shapes at print resolution.

What people actually ask for

The three requests that come up constantly:

a pet — usually a memorial piece. Emotional, and the photo is often the only one they have.
a face — portraits are the hardest, because a small error in the eyes reads instantly.
handwriting or a keepsake — the easiest, if the source is a clean scan or a sharp photo.

If you are building something in this space, the useful product decision is not "more styles". It is letting people preview before paying, and being honest about which photos will not work. A free preview that says "this one is too dark, try another" saves both sides a refund.

The print side

A stencil that looks fine on screen and prints at the wrong size is worse than no stencil. Fixed 300 DPI, A4 by default, and the subject scaled to a stated physical size — those three constraints remove most of the support tickets.

That is the whole product at the Tattoo Stencil tool: upload a photo, get clean lines, download a print-ready PDF. Free preview, pay only for the high-resolution file.

The related one, the photo-to-line-art tool, skips the stencil and just produces line art you can take to an artist as a reference.

The general lesson

Every "photo to X" tool is really a constraint problem. For video it is timing and motion. For a stencil it is line weight and DPI. The model is the easy part; knowing what the output must satisfy is the product.

Turning an old photo into a moving clip: the model side nobody explains

尚毅段 — Sat, 24 Oct 2026 03:13:27 +0000

The "sorry I lied" format is not a video trend. It is a confession format that happens to move.

It goes like this: a childhood photo, then a few lines that take the flattering memory apart — I lied, my hair was down. I lied, the dress was not that cute. I lied, that was actually my little brother — and the last slide gives the real photo back. The joke is that the memory was never the version you told.

Why a near-static clip is the right template

Most AI video work is about motion: dance, sport, action. This one is the opposite. The emotional register is slow. A camera push-in, a bit of grain, and the photo holding still is more correct than movement.

So the reference clip is not a dance routine — it is a slow zoom on a single face. That makes it the easiest trend of the three to serve, and the easiest to get wrong:

Too much motion and it reads as a jump-scare, not nostalgia.
A cropped face loses the costume, which is the entire joke.
Sharp modern lighting kills the film look the format depends on.

The audio decision nobody wants to make

Every trend has a sound, and the sound is half the post. Two options:

Ship the clip with music baked in. Feels generous. Gets you: a fixed track that is stale in two weeks, a takedown risk, and posts muted by the platform for reusing audio.

Ship a silent MP4 and tell people to attach the trend sound on TikTok. Feels cheap. Gets you: a clip that rides the current sound, no licensing exposure, and the same workflow every editor already uses.

I picked silent, and made it the answer to the FAQ's first question ("Why is the clip silent?") so it reads as a feature, not a limitation. The clip is a clean canvas; the sound is the user's choice and the platform's distribution mechanism.

If you do ship audio: never ship a track you did not license. A muted post is the best case.

What the model does to an old photo

Two things worth knowing before you promise anything:

It re-renders the scene. Grandma's living room will come back as a plausible living room, not the actual one. This is usually good — the alternative is a blurry crop of the original background — but it is not a restoration.
Low-resolution sources are fine, up to a point. A phone photo of a printed photo works, because the model is generating the detail, not enlarging it. What it cannot fix is a face that is 30 pixels wide.

Practical input rules: single subject, face clearly visible, even light, no glare off the print.

The product bit

For a format this emotional, the failure mode is not "ugly output", it is "output that feels wrong". So the settings are deliberately limited: a length, and that is it. No motion strength slider, no style picker. Fewer choices, fewer ways to make something that misses the mood.

The Tattoo Stencil tool is a different kind of product entirely — same lesson though: the constraint is the product. There, the constraint is 300 DPI and lines that survive being tattooed.

The reference: the old-photo clip tool.

What I learned rebuilding a TikTok dance trend as a one-photo tool

尚毅段 — Sat, 24 Oct 2026 03:08:11 +0000

Dance trends are the worst thing to copy by hand.

You need the counts, the framing, the lighting and someone willing to hold a phone for twenty takes. So the ecosystem solved it the way it always does: templates. The tutorial that goes around for every dance trend is basically identical —

copy the link to the original video
open the creator's profile
pick their template
import your photo
post

That workflow is what a "one photo" tool is actually competing with. Not the model, not the quality — the number of steps.

Why I rebuilt it as a single upload

A template still asks you to: find the trend, find the creator, find the template, install the app, grant permissions, import a photo, wait for the template to load. Seven steps and two apps.

The one-photo version is: upload, pick a length, wait two minutes. Three steps, one tab.

Whether that wins depends entirely on one thing: does the output look close enough to the trend that people believe it. If the model hallucinated a different room, you lost. If it looks like a plausible performance of the same routine, you won.

The reference clip decides everything

For dance specifically, the reference video has to satisfy:

one person, full body, camera static
the whole routine inside the clip
no burned-in captions or app UI
no watermark in the frame

That last one is why most "download a TikTok and use it as a template" attempts fail. The watermark doesn't disappear in the output — it gets re-rendered into your user's video. I learned this the expensive way: my first pass at a dance template produced clips with a phone-screen recording and a creator's handle baked into the middle of them.

The fix is boring: source clean footage, crop to 9:16, and check the frames before you ship. A 30-second review would have saved a full afternoon.

The domain name problem

One of these sites is called talkdirty.ink. That name gets you flagged by:

payment providers (adult-content policy)
ad networks
the occasional user who assumes it is a different kind of product

The fix is not clever copy, it is being explicit on the page: the FAQ's first question is "Is this an adult site?" and the answer is "No. This is a dance-video tool." Content moderation, no explicit uploads, accounts closed if they try.

If you pick a spicy domain for a trend, write that answer before you write anything else.

What actually breaks

Not the model. These:

Queue backlog. Everyone tries the trend in the same 48 hours. A single worker draining jobs is not enough; you need a dead-letter queue and a cron that fails stuck jobs and refunds them.
Refunds. A failed render must return credits automatically, and the refund must be idempotent. Otherwise a retry refunds twice and you are paying users to use your product.
Expectations. The clip takes two to nine minutes depending on the model. Say so before they upload. Users forgive waiting; they do not forgive surprises.

Numbers from real runs

Six-second vertical clip, same photo, four models:

model	time	note
fastest	2m 24s	motion tracks well, face softens on fast turns
mid	4m 20s	sharper, stable edges
pro	8m 48s	best fidelity, too slow for a default
slowest	9m 47s	motion fine, patience gone

The fastest one is the correct default. Quality that nobody waits for is not quality.

Try it

Talk Dirty if you want the dance one. Ozilai for the football variant, I'm Sorry I Lied for the nostalgic one.

The media pipeline I use to turn a clip into a poster + manifest (and to check the frames before shipping) is here: hot-word-site-pipeline.

How to put yourself into a viral trend clip with one photo (no editing)

尚毅段 — Sat, 24 Oct 2026 03:07:49 +0000

Every few weeks a new 20-second clip takes over TikTok, and the comments are always the same: how do I put myself in this?

The honest answer used to be "learn After Effects", or more recently "hunt down a CapCut template and copy a link". Both are friction. This post is about removing it — and about the parts of that product that are not the model.

What actually happens under the hood

Motion transfer models take two inputs:

a reference video (the trend clip)
a source image (your face)

and produce a new video where your identity drives the motion of the original. Timing, camera movement and choreography come from the reference; who you are comes from the photo.

The part people underestimate: the model re-renders the background. That is why the output looks like "you were there" instead of a cut-out pasted on top — and it is also why it will never be a 1:1 copy of the original scene. If you expect the exact stadium, exact lighting and exact crowd, you will be disappointed. If you expect "me, doing that move, in a scene that plausibly belongs to it", it works.

The photo is 80% of the result

People blame the model for bad output. Most of the time it is the input. What works:

one person, facing the camera
even light, no hard shadow across half the face
head and shoulders in frame, not a full-body shot from across the room
no sunglasses, no mask, no beauty filter

What technically renders and looks wrong:

group photos (the model has to pick a face)
mirror selfies (the camera angle fights the reference)
low-light phone shots (the encoder has already destroyed the detail)

A cheap trick: take the selfie in the same lighting you would use for a passport photo, then stop. Fancy lighting makes it worse, because the model has to reconcile your light with the reference scene's light.

The parts that are not the model

The model call is five minutes of work. The rest is what makes it a product:

Credits are a ledger, not a counter. Every movement is a row with an idempotency key derived from the business object — order:<id>, generation:<id>, generation_refund:<id>. Payment webhooks retry. Users double-click. Without the keys you get double-charging and double-refunding, and you find out from an angry email.

A failed render must refund automatically. Not "contact support". The refund is derived from the same generation row, so it is a no-op if it runs twice.

The job is a queue, not a request. Submit to the provider, store the request id, poll, and let a cron reconcile anything stuck past the deadline. A HTTP request that waits for a video will time out long before the video exists.

Content is data. Copy lives in per-locale modules that take the site config as an argument. Change the keyword or the price and every page updates — including the structured data and /llms.txt.

The boring numbers

On a real photo, a 6-second vertical clip:

fast model: ~2.5 minutes
mid model: ~4.5 minutes
slow model: ~9 minutes

Anything above five minutes loses a meaningful share of users before they see a result. That is a product constraint, not a model benchmark.

Try it

Ozilai — the football goal variant
Talk Dirty — the dance variant
I'm Sorry I Lied — an old photo, gently moving

Same engine, different reference clips. One photo in, one vertical MP4 out.

If you are building something similar, the two tools I keep reaching for are in this repo: a media pipeline that turns clips into posters and manifests, and a checker that tells you whether AI crawlers can actually read your site.