SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsai-gameplay-pack

ai-gameplay-pack

Design & creation

View repository

Updated 10-15 22:38

About this skill

AI Game Real-Gameplay Video Prompt Pack Factory

Give one reference image or a character description → a complete production pack of "image prompt + video prompt + sequence timeline + voiceover script" that can be copied directly.

🚨 Highest-priority red lines

  1. Do not copy the specific examples in the main tutorial document: In the main tutorial document, "cyberpunk dual-character confrontation," "rainy-night city rooftop," "protagonist Victor," and "seven years and he is still waiting for that answer" are all teaching examples, not reusable material. The subject, scene, dialogue, and character names for each instantiation must be 100% original.
  2. The variable dictionaries are only reference skeletons: The era texture dictionary, HUD dictionary, perspective dictionary, and emotion dictionary only tell you "what granularity to write to and which dimensions to cover." Do not stuff them into the output as-is. Reorganize the wording according to the current character and game genre.
  3. Do not write the original dialogue lines in the video prompt: Seedance is very weak at Chinese lip-sync. Dialogue can only be carried by subtitle bars (image-side HUD) + post-production TTS voiceover. The video prompt only describes "mouth opens and closes naturally N times + emotion + micro-expressions."
  4. Do not add any explanatory content unrelated to the prompt before the character design image prompt: For character design image prompts such as the Character No. 0 four-view and the 0.5A UI overview image, just output the prompt itself. Do not add meta-explanatory text before it, such as image-generation step introductions, usage explanations, reference image description paragraphs, or annotation setup. Under the section title, leave one blank line and then place the prompt directly, without writing any preceding explanation.

Violating any one of these means redoing the entire thing.

First step after triggering: identify the input mode + ask all parameters at once

Input mode determination

  • A. Reference image mode: The user attached an image → first look at the image and extract the subject features (gender / age / clothing / hair color / signature prop / stylistic tone), and write the features into the "protagonist description" slot in all subsequent prompts.
  • B. Keyword mode: The user only provided text (character name / IP name / description) → the first output must be a "Character Reference Sheet Prompt (No. 0)," so the user can first use GPT Image 2 to produce a character three-view as the subsequent anchor.
  • C. Mixed mode: The user provided both an image and keywords (e.g., "based on this image, but make it a cyberpunk version") → use the image as the base + use the keywords to override the differing dimensions.

One-time merged form (do not ask over multiple rounds)

If the user's input does not cover the following parameters,list all missing parameters at once, and have the user answer them all in one go. Parameters that can already be inferred from context should be defaulted directly; do not ask again.

请确认以下 5 项（已默认的可以略过，要改的告诉我）：

1. 叙事模式：演示向（默认）/ 剧情向（带对白字幕）/ 混合向（前 gameplay 后 cutscene）
2. 镜头数量：默认 6 个 / 可选 8 / 10 / 12
3. 游戏类型：默认 [基于角色推断]，可改 [开放世界 / 动作 RPG / Roguelike / 潜行 / 生存 / 模拟经营 / 对战格斗 / 横版动作 / 视觉小说 / 解谜]
4. 年代风格：默认 [基于角色推断]，可改 [街机 / PS1 / PS2 / PSP / PS3-360 / PS5 现世代 / Switch 卡通 / 假未来主机]
5. 视角：默认 [基于游戏类型推断]，可改 [第三人称越肩 / 第一人称 / 俯视 2.5D / 等距 / 横版 2D / 固定 / 过场电影机位]

Default inference rules(so the user answers less):

  • If it is chibi / cartoon / childhood IP (My Little Pony, Roco Kingdom, Pokémon, Little Red Riding Hood fairy tale) → default to Switch cartoon rendering + action RPG / fighting battle + third-person over-the-shoulder
  • If it is a realistic / dark / urban character → default to PS5 current generation + open world + third-person over-the-shoulder
  • If cyberpunk / sci-fi → default PS5 current-gen + first-person FPS or third-person over-the-shoulder
  • If side-scrolling style character → default side-scrolling 2D + side-scrolling action + lateral tracking camera
  • If the user explicitly says "narrative-driven", the narrative mode automatically switches to narrative-driven, and the shot count rises to 8

Output structure (hard constraints)

File persistence

Output persisted to:~/Downloads/调研报告/{项目名}-实机视频Pack/, with only one MD file in the directory:prompt主包.md. Project name format:YYYYMMDD-角色简称-游戏类型(e.g.:20260427-洛克王国小红帽-对战RPG）。

At the same timethe complete content must also be pasted in the conversationfor the user to see; do not just say "persisted".

MD content skeleton

# {角色名} {游戏类型} 实机视频 Prompt Pack

> 生成时间：YYYY-MM-DD
> 输入模式：参考图 / 关键词 / 混合
> 参数：叙事模式 / 镜头数 / 游戏类型 / 年代 / 视角
> 角色锚点描述：[一段 30 到 50 字的角色特征摘要，作为所有 prompt 的一致性锚点]

---

## 0｜角色四视图设定 Prompt（先用这条出锚点，后续所有镜头沿用这个形象）

[一段中文段落 prompt，纯文本，无代码块，无负面词。生成"左侧一张大尺寸正面特写头像（从头部到锁骨清晰展示面部 + 发型 + 头饰 + 领口装束）+ 右侧依次正面全身、侧面 90 度全身、背面全身三视图（完整展示从头到脚的造型与装备细节）"，四个独立角度水平并排在纯白背景上，柔和均匀的正面光照，无任何环境元素，画风匹配本项目目标年代质感（Switch 卡通 / PS5 写实 / PS2 复古等），干净抗锯齿描边，比例 16:9，作为后续所有镜头的角色形象锚点参考。**这张图是给 Seedance 做角色一致性参考用的，必须极度克制：纯白底、无配饰之外的环境元素、无戏剧化光影、无表情变体、无装备拆解小图、无色板色块**。]

---

## 镜头组（图片 prompt + 视频 prompt 配对）

### 镜头 1｜{镜头主题}

**图片 Prompt**（喂 GPT Image 2，用 ```plaintext {wrap} 代码块包起方便一键复制 + 保证 `{{{图N}}}` 三层花括号不被 MD 渲染破坏。本镜头需要挂哪几张参考图，由 prompt 内文里出现的 `{{{图N}}}` 集合直接确定，不另写挂图清单）：

```plaintext {wrap}
[首段：参考图说明段。例："本次跑图输入的参考图共 N 张：第 1 张是主角四视图设定稿（角色锚点）{{{图1}}}、第 2 张是项目 UI Style Guide 总览图（HUD 样式基准）{{{图2}}}、第 3 张是镜头 X 成品截图（HUD 实战基准）{{{图3}}}。本镜头生成时角色形象沿用第 1 张参考图、HUD 整套样式与位置沿用第 3 张参考图。"]

[第二段：场景与主角描述（中文段落，覆盖风格定锚 / 视角 / 主角动作 / 场景 / 画面质感）]

[第三段：HUD 描述段。直接在内文用"沿用第 N 张参考图（{{{图N}}}，即镜头 X HUD 实战基准）的样式与位置"句式 + 描述本镜头变化点]

[末段：比例 X:Y。]

Video Prompt(fed to Seedance 2.0, code block):

@图片1 作为首帧。延续画面的视觉调性、HUD 排布与角色造型不变。
镜头：{镜头运动 + 节奏词}。
[演示向：主角动作 + 环境动效] / [剧情向：嘴部开合 + 情绪 + 微表情 + 字幕条稳定]
时长 {N} 秒。
约束：避免肢体扭曲、身份漂移、HUD 文字突变。

Shot 2｜...

(repeat N shot groups according to the count)

0.7｜HUD reference image inheritance map (which image to attach to each shot during production)

[JSON form recording what each shot produces / which preceding anchors it consumes / which temporary HUD elements it introduces + natural language operation steps]

Shot sequence timeline

Segment Duration Shot theme Camera movement [Narrative-driven] Subtitles / voiceover

(total duration written below the table)

[Narrative-driven only] Subtitle script

Shot Speaking character Original dialogue Suggested duration Emotion

[Narrative-driven only] TTS voiceover script

Specify a suggested voice for each line of dialogue (Doubao / ElevenLabs / Volcano Engine speech synthesis voice name + speech rate + emotion parameters).

Post-production suggestions

  • Editing tools: Jianying / CapCut / Final Cut
  • Sound effect libraries: freesound / Zapsplat / Soundsnap
  • BGM style references: [recommend 2 to 3 reference music styles based on the game genre; do not copy specific tracks]
  • Watermark suggestion: "Captured on {target console}"

## 图片 Prompt 写作要求

### 演示向图片 prompt 结构（中文段落，用 ```plaintext {wrap} 代码块包起）

**重要**：本 skill 的图片 prompt 因为内文有 `{{{图N}}}` 引用变量（三层花括号在 MD 渲染时容易被解析破坏），**必须用 ```plaintext {wrap} 代码块包起**保证花括号原样保留方便用户一键复制。这条规则**覆盖** Irene 的全局偏好"图片 prompt 用纯文本段落无代码块"，只在 ai-gameplay-pack skill 内生效。视频 prompt 也照常用 plaintext wrap 代码块。

每个镜头的图片 prompt 是**一整段连贯中文文字**（在代码块内），覆盖以下维度但不要用 1/2/3 列点：

1. 风格定锚：开头一句"生成一张《{风格参考}》风格的游戏实机截图"或"……过场动画截屏"
2. 视角 + 主角 + 动作：第三人称越肩 / 第一人称 / 等距 + 主角具体描述（基于角色锚点）+ 正在做什么
3. 场景：地点 + 时间 + 天气 + 3 到 5 个环境元素
4. 画面质感：年代质感词 + 光照氛围 + 后处理（动态模糊 / 反射 / 泛光 / 颗粒）
5. HUD 描述：分位置写（左上 / 右下 / 顶部中央 / 底部中央），每个位置具体到元素 + 字体
6. 收尾约束：比例 16:9（剧情过场可写 21:9 letterbox）、看起来像真实 {目标主机} 实机画面

### 剧情向图片 prompt 额外要求

- HUD 简化为剧情演出模式：其他 UI 淡出，只保留底部字幕条
- 字幕条规格：半透明黑色，高度约画面 1/8，左侧白色描边角色名"{角色名}"，中间对白原文"{对白}"，字体现代无衬线白字描黑边
- 比例可以用 21:9 电影画幅
- 主角动作描述要带情绪和微表情（眉头微皱 / 嘴角抽动 / 抿嘴 / 眼神涣散）

### 字数控制

每条图片 prompt 200 到 350 字之间。少于 200 字颗粒度不够，超过 350 字模型容易抓不住重点。

### 比例和分辨率（每条都必须带，0 号到 N 号无一例外）

每条图片 prompt 的**末尾必须显式带上**：「比例 X:Y」。比例选择规则：

- **演示向 / 游戏内截图 / 0 号四视图**：`比例 16:9`（默认横屏游戏画面）
- **剧情向过场动画 cutscene**：`比例 21:9`（电影 letterbox 画幅）
- **竖屏短视频专用版本**：`比例 9:16`（小红书 / 抖音 / 视频号）
- **方形 IP 卡 / 装备图标**：`比例 1:1`

如果项目同时要横屏剪辑版 + 竖屏短视频版，0 号锚点四视图和镜头组都用 16:9 出主版本，竖屏发布时再单独用 9:16 复跑一份。

**违反即重做**：自检清单里会校验每条 prompt 是否带比例。

## 视频 Prompt 写作要求

### 演示向视频 prompt 结构（```plaintext {wrap} 代码块）

```plaintext {wrap}
@图片1 作为首帧。延续画面的视觉调性、HUD 排布与角色造型不变。
镜头：{slow push-in / gradual pull-out / smooth lateral pan / tracking shot follow / gentle orbit / stable aerial drone / subtle handheld / locked-off fixed 八选一}。
主角动作：{一个或一组具体动词，幅度要拉满，让人一眼看出在玩游戏，举例：跑动 5 到 8 步步幅大金发被气流明显吹起 / 法杖从腰侧抬至头顶杖头爆出强光 / 一记完整大幅度挥砍武器尾迹拖出弧光}。
互动反馈（关键）：{至少一个 HUD 元素或场景元素的动态变化，让画面有"在玩游戏"的反馈感，举例：技能图标从亮变灰冷却环形进度条顺时针填充 / 蓝条快速从满槽下降到三分之一 / 任务标记从屏幕外滑入定位并弹一下 / 经验数字滚动跳动 / 物品弹窗从屏幕边缘滑入到位 / 操作提示按键图标做按下脉冲一次 / 战斗提示框从画面边缘滑入}。
环境动效：{1 到 2 个持续性环境动效作为底子}。
音效（点睛笔，1 到 2 个最关键的拟声音效就够，不要堆叠）：{挑本镜头最具辨识度的 1 到 2 个声音，例如"任务标记滑入'叮'一声"、"按键按下'咔'+ 远处鸟鸣"。绝不写整段音效清单堆叠或抽象描述如"激烈的战斗音"}。
光照与 HUD 元素位置稳定不漂移（位置不变 ≠ 状态不变，状态可变样式不可变）。
时长 {5 到 10} 秒。
画面比例：{16:9 / 9:16 / 21:9}。
约束：避免肢体扭曲、身份漂移、HUD 样式漂移。

Notes on sound effects: Sound effects are just the finishing touch, not the main course. Write only 1 to 2 of the most critical Foley sound effects per video segment,absolutely do not stack an entire sound effect list. Irene's hard constraint: "Sound effects should be just a little, absolutely do not overdo it." Principles: ① Capture the single most recognizable sound of this shot (the "ding" of a mission marker sliding in / the "thud" of a stamp landing / the low-frequency "thud" of a closing workshop drum), and leave everything else silent to let the visuals breathe; ② Use concrete onomatopoeia (ding / thud / click / rustle / crackle) rather than abstractions ("intense battle sounds"); ③ The model grasping the rhythm + post-production editing alignment both rely on these 1 to 2 key points.

Narrative-driven video prompt structure

@图片1 作为首帧（@图片2 作为可选末帧用于情绪递进）。延续画面的视觉调性、HUD 字幕条与角色造型不变。
镜头：{镜头运动 + 节奏词}。
角色表演：{角色名} 面向{方向}，嘴部自然开合 {2 到 3} 次表示说话状态，眉眼传达{情绪词}，{次要动作如握紧拳头/低头/转身/后退半步}。
环境氛围：{雨水/风/烟雾/灯光闪烁等持续性动效}。
音效（点睛笔，1 到 2 个最关键的情绪音效就够，不要堆叠）：{挑能强化本镜头情绪的 1 到 2 个最具点睛感的音，例如"轻轻一声叹息 + 远处雨声"、"角色握拳骨节响 + 静默瞬间"。}
HUD 字幕条位置、文字内容、字体保持稳定不变。
时长 {5 到 8} 秒。
画面比例：{16:9 / 21:9 / 9:16}。
约束：避免身份漂移、字幕文字突变、嘴型夸张错位、肢体扭曲。

The aspect ratio of the video prompt must match the aspect ratio of the corresponding image prompt, otherwise Seedance will do strange cropping or stretching.

Character orientation + 180-degree confrontation axis (hard constraint, must be explicitly stated in all image prompts)

AI image generation models by default make all important characters "face the camera in a heroic pose", so when two characters stand in the same frame it becomes "each doing their own thing", with no real sense of confrontation / dialogue / interaction.Each image prompt must explicitly state each character's orientation, and multi-person shots must establish a clear confrontation axis.

Orientation must be explicitly declared

  • Single-person exploration / traversal: The protagonist's facing direction = direction of travel, not facing the camera. Phrasing: "the protagonist is in a three-quarter back-side orientation facing the direction of travel into the depth of the frame" or "the protagonist is in a side-on pose running toward the right side of the frame"
  • Two-person standoff / combat: The two parties face opposite directions, forming an inward-facing axis. Phrasing: "the protagonist is in a three-quarter side orientation facing the right side of the frame + the enemy is in a three-quarter side orientation facing the left side of the frame, forming a confrontation axis with the protagonist, and their lines of sight converge at the center of the frame"
  • Two-person dialogue: Same as above, the two parties face each other rather than facing the camera
  • Summon / coordination: The summoner and the summoned spirit face the same direction (jointly facing the enemy). Phrasing: "the protagonist casts toward the right side of the frame + the spirit lunges toward the right side of the frame in the direction of the enemy"
  • Falling / knockback: The direction of falling should match the direction of knockback (if hit from the left, fall to the right; if hit from the right, fall to the left)

Exceptions where facing the camera is allowed (only these scenes)

  • Title screen / Character No. 0 four-view / character key art (ceremonial reveal)
  • First-person perspective (the player is the camera)
  • Story-driven character monologue close-up "speaking to the camera"
  • UI overview image

Standard confrontation phrasing template

画面左侧主角呈四分之三侧身姿势朝向画面右方{动作描述}，{发型 / 服装}被{方向相反}的气流吹动；画面右侧敌人呈四分之三侧身姿势朝向画面左方与主角形成对抗轴线，{敌人状态描述}，{敌人头部 / 武器}指向主角方向。两个角色之间形成清晰的内向对抗轴线视线在画面中央{交汇 / 对峙}。

Violation means redo: Add one item to the self-check list: "Does the two-person shot explicitly state both parties' orientations and form a confrontation axis?"

Progress bar logic consistency (cross-shot continuity, hard constraint)

Each project, while producing UI Style Guide No. 0.5,must also produce a "progress bar state chain table" (numbered 0.6), recording the per-shot state of all progress bars appearing in all shots (health bar / mana bar / experience bar / skill cooldown ring / enemy health bar / quest progress).Produce it in dual form: a JSON array + natural-language paragraphs; markdown tables are strictly forbidden(tables cannot be copied as a whole block and fed to a model or LLM for proofreading).

JSON array form：

{
  "progress_chain": [
    {
      "shot": 1,
      "shot_name": "<镜头主题>",
      "hp": "<状态描述，如 hidden / full / 60% / full_with_red_pulse>",
      "mp_or_stamina": "<状态描述>",
      "level_exp": "<状态描述，如 LV 14 60% / LV 14 60%→76%>",
      "ammo_or_count": "<状态描述>",
      "skill_cooldown": "<状态描述>",
      "enemy_hp": "<状态描述，如 not_present / full / 100%→25% / fade_out>",
      "extra": "<其他变化补充>"
    }
  ]
}

Natural-language paragraph form(one sentence per shot, strung into a cross-shot closed-loop narrative, so readers can see the logical cause and effect at a glance):

"Shot 1 title screen all HUD hidden; Shot 2 close-up protagonist HUD shows initial full gauge LV 14 experience 60%; Shot 3 running the map stamina drains from full gauge to 45%; Shot 4 charging stamina to 25% enemy health bar slides in at full gauge; Shot 5 release stamina drops to 15% ammo 12→11 enemy health bar full→25%; Shot 6 settlement enemy fades out + experience 60%→76% (no level up)."

Logic self-consistency rules(must be followed when writing states):

  • Mana bar: Decreases only when releasing skills that consume mana; basic-attack wind-up does not consume it, and running the map does not consume it. The amount of decrease must match the skill level (small skills deduct 10% to 20%, ultimate skills deduct 60% to 90%)
  • Health bar: Deducted only when taking a hit; it must not decrease for no reason; at the moment of entering combat, an "edge red-light pulse" prompt may be used but health does not drop
  • Enemy health bar: From 0 to N there should be a complete closed loop of "enter at full gauge → deduct on hit → zero out and fade out on kill"; it cannot suddenly disappear or suddenly appear
  • Experience bar: Any increase must have a source (killing monsters / quests); after the increase, if not full, advance to the new progress; if full, golden light bursts + level jumps + experience bar resets to 0%
  • Skill cooldown: After release, switch from "fully lit and available" to "gray + ring progress bar filling from 0%". If the next shot referencing that skill is not yet filled, it must show "gray + current fill progress"; once filled, return to "fully lit and available"
  • Quest bar / quest marker: Appears only after being triggered, does not disappear while incomplete, and after completion plays a checkmark animation before fading out
  • Item / equipment count: Increases once per pickup; it must not be obtained in shot 5 and then vanish into thin air in shot 6

Wording: In the "interaction feedback" section of each shot's video prompt, you must explicitly state the entry state and exit state of that shot's progress bar, for example "the blue bar drops sharply from full to about 1/10" (explicitly state from where to where); do not just write "the blue bar is consumed" (vague).

Shot pacing words vs. protagonist action amplitude (key concept; only by distinguishing them clearly will you avoid writing duds)

Shot pacing words(constrain the camera's movement): slow / smooth / stable / gradual / gentle. These words govern how thecameramoves, not how the protagonist moves.

Protagonist action amplitude(do not restrain it; perform it): large running amplitude, one complete sword-swinging motion, jumping into the air with a wind-up before takeoff, a sense of burst when casting a skill, recoiling when hit, the boss falling and rolling on the ground, raising a hand when collecting an item → these must use specific verbs + large-amplitude modifiers, so that at a glance people can tell this is playing a game.Strictly forbiddento use "slight / small-amplitude / faint / slowly" to compress the amplitude of the protagonist's actions; that would turn the image into a cinemagraph, not gameplay.

Classic combinations：

  • Camera slow push-in + protagonist violently swinging a sword → maximum sense of burst
  • Camera stable tracking shot follow + protagonist running intensely → parkour feel
  • Camera gentle orbit + protagonist raising the staff widely to cast a spell → highlight shot
  • Camera subtle handheld + protagonist fiercely fighting the enemy → combat tension
  • Camera locked-off fixed + UI popup sliding in from off-screen + numbers ticking → settlement feedback

Interaction feedback is the soul of fake real-time gameplay (write at least one in every video prompt; for key shots, write two or more)

The reason a game image looks like a game is not because the characters are moving, but becausethe image has a visible visual response to the player's "button operation". Interaction feedback falls into four categories, andclick/keypress feedback is the most easily overlooked but most important category—it is the key difference that separates "passively playing a video" from "playing a game".

Click / keypress feedback category (the visual response at the instant of the player's operation; must be present)

This is the key to the audience subconsciously recognizing "this is gameplay, not a cutscene". Every shot with active player operation must explicitly write the visual feedback of "the frame when pressed". Optional ways to write it:

  • Key icon press depression animation: The X key icon in the bottom skill bar shrinks for one frame at the instant it is pressed at second X (about 0.1 seconds), then rebounds to full brightness
  • Circular ripple spreading outward from the key center: At the instant the A key icon is pressed, a ring of white or golden circular ripple spreads outward from the icon center and fades out
  • Key edge highlight flashing: The icon's outer ring briefly has a golden or colored outline glow once
  • A key prompt label appears on screen: A small "X" label appears in the bottom right corner, indicating the player just pressed that key, and it disappears after one rhythmic pulse
  • Number damage pop-up: At the moment the attack hits, an orange or red number "-128" pops out from the target's position and floats upward + fades out
  • Crosshair / lock-on marker scaling: At the moment of aiming, the crosshair in the center of the screen shrinks from large to small in a lock-on animation
  • Menu option selected: At the moment the option bar is selected, the entire bar highlights and enlarges, and an arrow slides in on the left side
  • Skill charge progress bar: When holding down a skill, the progress bar along the edge of the icon fills clockwise from 0% to 100%
  • Secondary confirmation prompt: For dangerous operations, a circular hold prompt appears saying "Hold R to confirm"

HUD status feedback category (feedback for system state changes)

  • Skill icon goes from bright → gray after release + golden ring cooldown countdown fills clockwise
  • Health bar deduction: at the moment of being hit, the health bar value flashes red, then drops to the new value
  • Mana bar consumption: at the moment of casting, the mana bar quickly drops from full to one third
  • Experience number rolling and jumping: flips from 0 to 240
  • Control hint key icon does a "pressed" color pulse once
  • Quest marker flies in from off-screen + settles + bounces once to confirm
  • Quest bar slides in from the top + text displays character by character
  • Combat prompt box slides in from the edge of the screen + highlights + stays
  • Popup slides in from off-screen into place + level-up golden light bursts out

Scene feedback category：

  • Enemy knocked back and sent flying when hit + dust flies up from the knockback
  • Enemy falls to the ground and slowly dissipates into light particles
  • At the moment of collecting an item, the screen flashes white + the item icon flies from the world scene into the inventory bar
  • A speech bubble or exclamation mark appears above the head of an interactive NPC
  • At the moment a skill is released, a magic circle blooms on the ground + particles rise upward
  • At the moment of a hit, the screen shakes slightly + red edge vignette (when hit) or golden edge vignette (when hitting)

Camera feedback category：

  • The camera shakes slightly once when an ultimate is released
  • The screen briefly flashes white at the moment the BOSS is killed
  • 0.3 seconds of slow motion at key story moments (story-oriented only)

Writing styles strictly forbidden

  • ❌ "The protagonist takes two to three slight steps," "small range of motion," "the right arm sways slightly with the steps" → this is a cinemagraph, not gameplay
  • ❌ fast / cinematic / epic (the model does not understand these words, butthis does not mean the protagonist cannot make big movements, use specific verbs)
  • ❌ Multiple camera movements combined (use only one main camera move per segment, do not write "slow push-in then orbit")
  • ❌ Writing the original dialogue lines in the video prompt
  • ❌ MJ-style --ar / --stylize / --sref / --no parameters
  • ❌ Long strings of negative words (finish it in 1 to 2 sentences of constraints)
  • ❌ Repeating the subject description already present in the image (the video prompt only writes "changes" and "motion")
  • ❌ A dash appearing anywhere

Camera sequence design logic

Demo-oriented 6-shot template (default)

镜头 1｜标题画面 / Logo 浮现 → locked-off fixed (4s)
镜头 2｜世界远景 + 任务标记 → gradual pull-out (6s)
镜头 3｜主角越肩行走 → tracking shot follow (6s)
镜头 4｜战斗起手特写 → slow push-in (5s)
镜头 5｜技能释放 / 关键动作 → gentle orbit (6s)
镜头 6｜结算页 / Victory / 经验弹窗 → slow push-in (5s)
合计 32 秒

Demo-oriented 10-shot expansion

On top of the 6 shots, add:

  • Equipment menu (locked-off fixed)
  • Cutscene dialogue (locked-off fixed)
  • BOSS appearance (gentle orbit)
  • Death / Respawn (subtle handheld)

Story-driven 8-shot template (default)

镜头 1｜场景远景 + 主角剪影 → gradual pull-out (6s) + 旁白
镜头 2｜主角越肩特写 → slow push-in (7s) + 主角独白
镜头 3｜环境推进 / 走向冲突 → tracking shot follow (6s)
镜头 4｜关键人物登场 → locked-off fixed (6s) + 对方开场白
镜头 5｜对峙中景 → subtle handheld (8s) + 主角回应
镜头 6｜情绪转折特写 → slow push-in (7s) + 关键台词
镜头 7｜动作 / 高潮 → gentle orbit (6s) + 环境音
镜头 8｜结尾拉远 + 字幕 → stable aerial drone (6s) + 旁白收尾
合计 52 秒

Shot count and duration reference

Shot count Suggested total duration Per-segment duration
6 30 to 40s 5 to 7s
8 45 to 55s 6 to 8s
10 60 to 75s 6 to 8s
12 80 to 95s 6 to 8s

Character anchor description (core of consistency)

At the top of the MD, write a 30 to 50 character "character anchor description" that extracts the character's most core visual features:

角色锚点：{年龄段 + 体型}，{标志性服装}，{标志性色彩}，{标志性道具/武器}，{发型/头饰}，{表情基调}。

When describing the protagonist in the image prompts of all shots, you must reuse the core elements of this anchor, ensuring the character is consistent across 6 to 10 images. After each output, self-check: extract the "protagonist" section from all shots and see whether the core features are all the same.

No. 0.5 UI Style Guide (mandatory output, the shared UI consistency anchor for all shots)

Why it is needed: all screenshots of the same game must share the same HUD visual language (health bar color and shape, font, icon style, minimap style, subtitle bar style). If the health bar color differs in every image, the font differs, and the minimap border differs, the audience will see at a glance that it is AI-assembled. No. 0 handles character consistency, No. 0.5 handles UI consistency,both are indispensable。

No. 0.5 output format: one "UI overview image" prompt + one "UI specification dictionary"

No. 0.5A Overview Image Prompt(image side): place all HUD elements into a blank game scene (for example, the menu background just after entering the game), and have GPT Image 2 draw the unified style of all UI elements in one pass, to serve as the @image visual anchor when feeding Seedance for each subsequent shot.

Template:

生成一张本项目专用的 UI 风格总览截图，画面是一个用作 UI 展示的简洁{游戏类型}菜单背景（{背景描述：纯色/简洁场景/渐变背景}）。在这个画面上完整展示项目的所有 HUD 元素以便后续每个游戏内截图都沿用相同的视觉规范：左上角{血条样式描述}，左上血条下方{蓝条样式描述}，血条左侧{角色头像框样式}；右下角{迷你地图样式}附{指南针描述}；顶部中央{任务条样式}显示示例文字"{示例任务名}"；底部中央{操作提示样式}显示示例按键{按键风格}+示例文字；右上方{额外辅助 UI 描述，如经验条/等级/金币};{战斗 UI 与剧情字幕条的统一样式描述}。所有元素的字体为{字体描述}，配色为{主色 + 辅色 + 强调色}，图标风格为{图标风格}，描边为{描边规范}，圆角为{圆角规范}。整体匹配{年代质感词}，比例 16:9，作为后续所有游戏内镜头的 UI 视觉锚点参考图。

No. 0.5B UI Specification Dictionary: use JSON code block + natural language summary dual formto output,markdown tables are strictly forbidden(tables cannot be copied as a whole to feed GPT Image 2 / LLM; after rendering, line breaks during copying will lose fields). Fix one copy per project; when describing the HUD in all shot prompts, the unified wording from the dictionary must be used.

JSON form(for programs, LLMs, copy-paste use):

{
  "ui_style_guide": {
    "color": { "primary": "<主色>", "secondary": "<辅色>", "accent": "<强调色>" },
    "fonts": {
      "title": "<标题/Logo 字体描述>",
      "body": "<正文/数字字体描述>",
      "subtitle": "<剧情向字幕条字体描述，演示向可填 null>"
    },
    "hp_bar": "<HP 条形态/位置/颜色/描边/附属元素>",
    "mp_or_stamina_bar": "<蓝条或体力条形态>",
    "level_badge": "<等级显示形态>",
    "minimap_or_radar": "<迷你地图/雷达形态>",
    "quest_bar": "<任务条形态>",
    "control_hint": "<操作提示样式 + 按键图标风格>",
    "enemy_hp_bar": "<战斗中敌方血条形态>",
    "skill_icon_bar": "<技能栏形态 + 冷却环样式>",
    "popup": "<拾取/奖励弹窗形态>",
    "level_up_fx": "<升级特效形态>",
    "victory_screen": "<胜利结算样式>",
    "subtitle_bar": "<剧情向字幕条规范，演示向可填 null>",
    "quest_marker_icon": "<任务标记图标形态>",
    "corner_radius": "<圆角规范>",
    "stroke": "<描边规范>"
  }
}

Natural language summary form(a 30 to 80 character paragraph, for readers to quickly scan + to be directly referenced by shot prompts):

"Overall HUD specification: primary color X, secondary color Y, accent color Z. HP bar ...; quest bar ...; control hints ...; combat health bar .... When describing the HUD in all shot prompts, reuse the above wording; states may vary but styles must not."

How shot prompts reference the UI Style Guide

When describing the HUD in each shot's image prompt,you must explicitly reference the field wording from the dictionaryrather than starting from scratch. Both ways of writing are acceptable:

Writing A (short reference, suitable for medium granularity)：

...The HUD follows the unified style defined by this project's UI Style Guide: top-left blue health bar + character portrait frame, bottom-right circular minimap with a golden feather quest marker, top quest bar displaying "{current shot quest text}", bottom control hint "{current shot key hint}"...

Writing Style B (full reuse, suitable for complex granularity)：

...Interface HUD elements: in the upper-left corner, a rounded-rectangle health bar with orange-red fill and black outline, accompanied by a circular character portrait frame with gold outline (consistent with UI Guide No. 0.5), and directly below the health bar, an equal-length sky-blue mana bar; in the lower-right corner, a circular minimap with a semi-transparent dark green background and thin gold outline, containing an N compass and a gold feather quest marker icon (consistent with UI Guide No. 0.5); at the top center, a semi-transparent black quest bar with rounded white text outlined in black displaying "{current quest name}"...

Key constraint: for the same HUD element appearing in all shots, the text description must use the same set of keywords. If Dictionary No. 0.5 says "orange-red health bar + gold portrait frame," then in the 6 shot prompts,absolutely must nothave some writing "red health bar, silver portrait frame" and others writing "orange life bar, circular portrait." Variation may only appear in "state" (full bar / half bar / empty bar), not in "style."

No. 0.7 HUD reference syntax + reference image inheritance graph (mandatory output)

Why it is needed: in actual image generation, the overall HUD style is globally consistent (fixed by the 0.5A UI overview image + 0.5B dictionary), but for each shot, whether it "fully follows the previous one," "follows the HUD + replaces the scene," or "follows the HUD + adds temporary elements" varies greatly. If the prompt main package does not tell the user, for each shot during image generation, "use {{{图N}}} to reference which image as the HUD baseline," the user would have to rewrite the HUD description every time, which is inefficient and prone to drift.No. 0.7's two responsibilities: ① within each image prompt, directly use {{{图N}}} to specify which preceding image the HUD should reference (core); ② in the main package's unified section, provide an "image number mapping table + inheritance graph" so the user can understand the entire chain at a glance.

Core mechanism:{{{图N}}} reference syntax + self-contained reference image description paragraph

Key design principle: when the user feeds the prompt to models such as Codex / GPT Image 2 / Nano Banana Pro during image generation, the model receives the prompt + multiple reference images at once.The prompt text must be self-contained with the role definition of each reference image, so that the model can identify on its own, without consulting any external mapping table, "which image is the HUD baseline, which is the character anchor, and which is the time-period continuation anchor."{{{图N}}} is the image number code for the user to read, and the self-contained description paragraph is the role definition for the model to read. The two must appear together.

1. The beginning of each shot image prompt must have a "reference image description paragraph"

Position: the very first paragraph at the beginning of the image prompt (before "generate a ... style in-game screenshot").

Template：

"The reference images input for this image generation total N, in order as follows: the 1st is the protagonist character four-view setting sheet (used as the character appearance consistency anchor), the 2nd is this project's 0.5A UI Style Guide overview image (used as the HUD style / position / font / color scheme baseline anchor), the 3rd is the finished screenshot generated for shot X (used as the HUD practical baseline), the Nth is ... (continue listing each image's role and purpose). Please generate this shot's image according to the prompt description below; when the description mentions 'follow the HUD baseline image,' it refers to the Nth reference image."

Practical example (shot 3):

"The reference images input for this image generation total 3: the 1st is the protagonist four-view setting sheet (character appearance anchor){{{图1}}}, the 2nd is the project's 0.5A UI Style Guide overview image (HUD style baseline){{{图2}}}, the 3rd one is the finished screenshot of Shot 2 (HUD combat benchmark){{{图3}}}. When generating this shot, the character appearance follows the 1st reference image, the entire HUD style and positions follow the 3rd reference image, and the UI color scheme / fonts / icon style continue the specifications of the 2nd reference image."

Hard constraints (abbreviation is absolutely not allowed): The reference image description paragraph is the sole source for the user to determine "which image to attach" (the image attachment checklist has been canceled); writing it wrong or omitting it will directly cause the wrong image to be attached when running the image generation. Each reference image must be a separate sentence containing three elements:

  1. Image number：{{{图N}}} Three-layer curly brace code + natural language ordinal ("the Nth one")
  2. File nature: what this image is (main character four-view setting sheet / 0.5A UI Style Guide overview image / finished screenshot of Shot X / nighttime period continuation anchor point, etc.)
  3. Role assumed: what this image is responsible for in this shot (character appearance anchor / HUD style benchmark / HUD combat benchmark / period continuation anchor / UI color scheme benchmark, etc.)

Abbreviated forms that are absolutely not allowed:

  • ❌ "Input 2 images: Image 1 main character + Image 2 HUD" (missing file nature, role assumed compressed into two words)
  • ❌ "For this input {{{图1}}} {{{图2}}} {{{图3}}} three reference images" (only image numbers, no nature or role)
  • ❌ "Reference images: character four-view, UI overview, Shot 2 finished product" (missing image number codes, the model cannot map them to slots)

Each reference image must be a separate sentence like the "actual example (Shot 3)" above, with all three elements present.

2. {{{图N}}} Variable reference syntax

  1. Variable name format: must be {{{图N}}}(three-layer curly braces wrapping "image" + number, e.g.:{{{图1}}} {{{图2}}} {{{图5}}}), where N is the number in the image number mapping table
  2. Reference scope: reference only the HUD part (position / style / font / color scheme / icons), do not reference the main character / scene / lighting / period
  3. References must be paired with natural language: writing only {{{图3}}} will not be recognized by the model; it must be written as "continue using the 3rd reference image ({{{图3}}}, i.e. the Shot 2 HUD combat benchmark)", a dual form of "natural language description + variable code"
  4. Three levels of reference strength：
    • fully continue using the entire set：HUD 整套沿用第 3 张参考图（{{{图3}}}，即镜头 2 HUD 实战基准）的样式、位置、字体、配色不变，仅状态有变化：{描述状态变化}
    • continue using the main body + add temporary elements：HUD 主体沿用第 3 张参考图（{{{图3}}}）的样式与位置（HP / 体力条 / 迷你地图 / 任务条 / 三键操作全部位置与配色不变），本镜头新增临时元素：{描述新增}
    • continue using the main body + partial changes：HUD 主体沿用第 3 张参考图（{{{图3}}}），本镜头变更：任务条文字从"X"变更为"Y" / 状态从满槽变到 N%
  5. Major premise: overall HUD style global consistency is solidified jointly by the 0.5A UI Style Guide overview image + the 0.5B dictionary, so the reference semantics are "the HUD part is anchored to this image" rather than "cloning the entire image"; the model will not mistakenly think the scene should also be copied over

Image number mapping table (required for every project, placed at the beginning of Section 0.7)

When the user actually runs image generation, the reference image slots are arranged in the order "Image 1 / Image 2 / Image 3". The MD main package must provide animage number mapping tableso the user knows which {{{图N}}} corresponds to which actual file. The format is as follows:

图号映射表（跑图时按此顺序挂参考图槽）：
- 图1 = 0 号主角四视图（`0号-主角四视图.png`）
- 图2 = 0.5A UI Style Guide 总览图（`0.5A-UI总览图.png`）
- 图3 = 镜头 2 成品截图（`镜头2-成品截图.png`，是后续镜头 HUD 引用的实战基准）
- 图4 = 镜头 4 成品截图（夜间场景延续锚点，仅镜头 5 / 6 参考）
- 图N = ……

Numbering suggestion: place "permanent anchors" (No. 0 main character / 0.5A UI overview) in the Image 1 / Image 2 positions (small numbers), and place "dynamic anchors" (finished products of previous shots) in high-number positions. In this way, references in each shot prompt are clear at a glance.

Standard writing method for the HUD paragraph in each shot prompt

Rewrite the original "The HUD elements on the interface follow the unified style of this project's UI Style Guide: cinnabar-red curling-cloud pattern outline in the upper-left corner... (a long paragraph rewritten)" as:

"The entire HUD set follows {{{图3}}} 's style and positions (HP / stamina bar / minimap / top quest bar / bottom three buttons / upper-right copper-coin reputation), with only state changes: the stamina bar is consumed from full to about 55%, and after the sprint key is released it turns gray with a golden ring-shaped cooldown progress filling clockwise to 60%; the cinnabar triangle player marker on the minimap moves from the north to the northwest position. This shot adds a temporary element: in the lower-right foreground, a small "grape" commodity bubble icon pops up above the head of the Sogdian merchant's stall."

The benefits of writing it this way:

  • When the user runs the map, it mounts {{{图3}}} 's actual file, and the model automatically learns the complete HUD style
  • The prompt word count is greatly compressed, highlighting "this shot's changes"
  • The same HUD element has zero drift across shot descriptions (because it is not rewritten at all)

Inheritance graph JSON (placed after the image-number mapping table)

{
  "hud_reference_chain": [
    {"shot": 0, "name": "主角四视图设定稿", "produces": "图1（0号-主角四视图.png）", "hud_reference": "无 HUD"},
    {"shot": "0.5A", "name": "UI Style Guide 总览图", "produces": "图2（0.5A-UI总览图.png）", "hud_reference": "本身定义基准 HUD"},
    {"shot": 1, "name": "<镜头1主题>", "produces": "无（HUD 全隐藏视镜头类型而定）", "hud_reference": "<不引用 / 引用 {{{图2}}}>"},
    {"shot": 2, "name": "<镜头2主题>", "produces": "图3（镜头2-成品截图.png，成为后续 HUD 实战基准）", "hud_reference": "{{{图2}}}（首次按 0.5A 落地）"},
    {"shot": 3, "name": "<镜头3主题>", "produces": "<可选产出>", "hud_reference": "{{{图3}}} 整套沿用，状态变化"},
    {"shot": 4, "name": "<镜头4主题>", "produces": "图4（如时段切换需要为后续提供延续锚点）", "hud_reference": "{{{图3}}} 主体沿用 + 新增临时 HUD"},
    {"shot": 5, "name": "<镜头5主题>", "produces": "<可选产出>", "hud_reference": "{{{图3}}} 主体沿用 + {{{图4}}} 时段延续"},
    {"shot": 6, "name": "<镜头6主题>", "produces": "<可选产出>", "hud_reference": "{{{图3}}} 主体沿用 + 新增结算页元素"}
  ]
}

Do not write a separate mounted-image list under the shot title (to prevent drift in the set of image numbers)

In practice, it has been found that the "mounted-image list" block and the {{{图N}}} references in the prompt body drift very easily: the mounted-image list says image 3 but the prompt body only references image 1, or conversely the prompt suddenly has an extra {{{图5}}} and the mounted-image list omits it.Therefore, the mounted-image list is canceled entirely as an independent block, and which images this shot should mount is instead determined jointly by the following three authoritative sources, and they must be strictly consistent:

  1. The "reference image explanation paragraph" in the prompt body(first paragraph): self-contained explanation of how many images are input this time and what role each plays (protagonist anchor / HUD style baseline / HUD in-action baseline / time-period continuation anchor, etc.)
  2. The {{{图N}}} reference set in the prompt body: the image numbers actually to be mounted for this shot = all {{{图N}}} sets that appear in the prompt body (automatically derived; the model does not need to write them again separately)
  3. The hud_reference field of the inheritance graph JSON in section 0.7: the image numbers listed in this shot's one-line hud_reference field = the set from 2 above

Change pointsThe information is merged into the end of the third paragraph of the prompt body, the "HUD description paragraph" (the one-sentence "This shot adds a temporary element: ..."), and is no longer an independent block.

If any of the three authoritative sources is inconsistent, the output is considered defective and the entire thing must be redone.

The core rules of section 0.7 (must be followed when writing the graph)

  1. Image numbering is permanently stable: image 1 / image 2 permanently refer throughout the entire project to protagonist 0 / the 0.5A UI overview image; do not give the same number different meanings in different shots
  2. Global consistency of the overall HUD style is the major premise: the HUD style, positions, fonts, and color scheme of all shots are fixed by the 0.5A overview image + 0.5B dictionary, and the{{{图N}}} reference merely concretizes this fixed result onto a particular in-action image
  3. {{{图N}}} reference ≠ cloning the entire image: only the HUD part is referenced; the scene / protagonist pose / lighting / time period are described separately by this shot's prompt
  4. Temporary HUD elements(settlement-page scroll / countdown / quest progress bar / level-up effects / combat health bar, and other elements that appear only in specific shots) do not go into the 0.5A overview image, are not written into the 0.5B dictionary, and are not written into the reference syntax; they are described only in text in this shot's prompt
  5. Seedance 2.0 video generation: In the video prompt, you can likewise use @图片N or {{{图N}}} to reference the first frame, keeping the syntax consistent with the image prompt
  6. Do not force rewriting every shot: If a certain shot's HUD changes too much (e.g., the settlement page almost covers the entire frame), then abandon the reference method and return to a full description; the reference method is a tool, not a dogma

Multi-character projects: each main character gets an independent four-view sheet (important)

If the project contains multiple main characters (heroes + villains, a duo team, a trio squad, an ensemble cast),produce a separate four-view character design sheet for each character, numbered 0a / 0b / 0c…, and never put multiple characters in one image. When AI draws multiple characters in one image at the same time, problems such as mixed-up costumes, crossed props, imbalanced proportions, and degraded recognizability are extremely likely to occur. After each character has an independent four-view sheet, when using Seedance multi-image reference, reference them separately with @image.

Prop quantity rule:Each character keeps 1 signature prop (weapon or magical implement), and at most 1 additional auxiliary accessory (pendant/badge/strap). If props pile up beyond 2 items, AI will almost certainly mix up their positions across the four views (short bow moves to the right shoulder, first-aid kit becomes a waist pack, gloves become cuffs). Less is more.

The "pure white background" of the No. 0 four-view sheet must be placed in the first sentence at the highest-weight position (key experience)

AI image generation models give the highest weight to keywords at the beginning of the prompt, with weight decaying progressively toward the middle and end."Pure white background" must be the first sentence of the prompt, rather than buried in the second or third clause.

Incorrect wording ("pure white background" buried in the middle, the model will ignore it):

"Generate an original beautiful fantasy AAA game character official four-view character design sheet, on a pure white background four independent angles arranged horizontally side by side…"

Correct wording ("pure white background" occupies the highest-weight position in the first sentence):

"Pure white background character four-view character design sheet, the background is a pure 100% white #FFFFFF flat surface with no environmental elements whatsoever, no scene details whatsoever, no halos whatsoever, no particles whatsoever, no color gradients whatsoever, the entire image contains only four independent character views arranged horizontally side by side on a pure white background…"

At the end, specific background elements must be hard-prohibited a second time

Just saying "no environmental elements whatsoever" is too abstract, and the model will still imagine forests, light beams, and mist.At the end, an explicit prohibition list must be listed：

"Emphasize the constraint again: the background must be a pure white #FFFFFF flat surface with absolutely no elements whatsoever,strictly prohibited from drawing forests, ancient trees, moss, mist, light beams, Tyndall light, light spots, magic particles, decorative patterns, ground, shadow projections, color gradients……"

The prohibition list must includeall environmental elements that the current project might evoke, for example:

  • Beautiful fantasy projects: forests, ancient trees, moss, mist, light beams, Tyndall light, light spots, magic particles, vine decorations, petals
  • Post-apocalyptic realistic projects: ruins, smoke and dust, smoke, vines, rust, ground, distant building silhouettes
  • Fairy-tale cartoon projects: stars, rainbows, clouds, candy, decorative patterns, color gradients
  • Cyberpunk projects: neon lights, circuit patterns, scan lines, data streams, city silhouettes

The character's own glow/effects must be limited to "not spilling outward into the background"

If the character has built-in glowing elements (any form of fluorescence, magical radiance, energy eyes, smoke form, drifting particles), the prompt must explicitly state that these light effectsappear only at localized positions on the character's body and do not project or spread into the background. The phrasing is a placeholder template:

"{glow/effect element} appears only at {specific localized position on the character's body} and does not {spread / project / diffuse / spill / radiate} into the background"

If you don't write this sentence, the model will expand the glowing elements into a full-screen halo, colored haze, and particle background, and the white background will be ruined.Right after the character description, immediately add a "constraint" sentence, don't wait until the end of the prompt to add it.

The style positioning must explicitly state "character reference sheet" rather than "game screenshot"

Finally, you also need to add one more sentence:

"The style of the entire image is an official character reference sheet, not an in-game scene screenshot and not a cutscene screenshot."

This is because if the same character description does not specify "character reference sheet", the model will prioritize interpreting it as a "game screenshot" and automatically add a scene.

The standard layout for character No. 0's four-view sheet (important)

Reference style:1 front close-up headshot on the left (occupying about 30% of the left side of the image, from the head to the collarbone) + 3 full-body views on the right (front / side 90 degrees / back, arranged horizontally at equal distances, each occupying about 23%). This is the standard character reference sheet format in the reference-to-video field, and it provides the strongest consistency when fed to Seedance as a reference. The prompt must clearly specify this layout:

  • Emphasize "four independent angles arranged horizontally side by side"
  • Emphasize "pure white background"
  • Emphasize "soft and even frontal lighting, no dramatic lighting or shadows"
  • Do notadd expression variation grids, equipment breakdown thumbnails, color palette swatches, or text labels (these will pollute Seedance's reference weights)

If the user later wants a "complete setting collection" (including expressions + equipment + color palette), that is a different deliverable and should not be placed in No. 0.

Subtitle script writing (for story-driven use)

The subtitle script is for voice acting, not for the video model. Requirements:

  • Keep each sentence within 8 to 18 characters: too long and it can't be read in 5 seconds, too short and it lacks information
  • Avoid "complete complex sentences with subject, predicate, and object": game cutscene dialogue tends to be short and forceful; "I will come back" is better than "When the snow melts, I will definitely return to this place"
  • There must be differences in tone between characters: the protagonist vs the villain vs the narrator, the wording of all three should be distinguishable at first listen
  • Absolutely do not copy lines from existing games(do not write original lines that appeared in The Last of Us, GTA, or The Witcher)

TTS voice-over script writing (for story-driven use)

Recommend voice timbre + speaking rate + emotion for each subtitle:

Tool Example recommended voice timbre Suitable scenario
Doubao Voice Synthesis Steady male voice / lively female voice / weathered elderly voice Chinese game tone
ElevenLabs Adam / Bella / Rachel Western game tone
Volcano Engine Voice Narrator male voice / dramatic female voice Narration / story

When outputting, label each subtitle with:音色：XX / 语速：0.9 / 情感：低沉。

Self-check list (mandatory before output)

  • The four-view character design prompt for Character 0 has been generated (mandatory in keyword mode; in reference-image mode you may omit the note "the uploaded image has been used as the anchor")
  • UI Style Guide for No. 0.5 has been produced(including the 0.5A overview image prompt + 0.5B UI specification dictionary), and every shot prompt uses the unified wording from the dictionary when describing the HUD
  • HUD reference syntax for No. 0.7 + inheritance graph have been produced: at the top of the project there is an "image number mapping table" (Image 1 = No. 0 protagonist four-view / Image 2 = 0.5A UI overview image / Image 3 = finished screenshot of Shot 2 as the HUD practical benchmark / Image N = continuation anchor for the preceding shot's time segment) + the inheritance graph JSON with one line per shot
  • No longer write a separate "reference image attachment list" block: go directly into the prompt under the shot title, do not write 🔗 参考图挂图清单 block. The attached image set is reverse-derived from the {{{图N}}} in the prompt body
  • At the start of every shot's image prompt there is a "reference image description paragraph": a self-contained description of how many images are input this time and what role each one plays (protagonist anchor / HUD style benchmark / HUD practical benchmark / time-segment continuation anchor, etc.), so that Codex / GPT Image 2 / Nano Banana Pro, upon receiving the prompt + multiple images, can identify each image's purpose on their own without needing an external mapping table
  • The HUD reference paragraph uses a dual form of "natural language + variable code": write "follow the style and position of the 3rd reference image ({{{图3}}}, i.e. the HUD practical benchmark of Shot 2)" rather than writing only {{{图3}}} or only a descriptive reference
  • Every shot has a "image prompt + video prompt" pair
  • All video prompts use ```plaintext {wrap} code block wrapping
  • Image prompts also use ```plaintext {wrap} code block wrapping (a special rule of this skill, overriding Irene's global preference); the body uses Chinese paragraphs with no 1/2/3 bullet points
  • The body of every image prompt must contain {{{图N}}} an explicit code(not merely written in the attached image list), and must adopt the dual form of "natural language description + {{{图N}}} variable", for example "follow the style and position of the 3rd reference image ({{{图3}}}, i.e. the HUD practical benchmark of Shot 2)"
  • The image number set is self-consistent (a hard anti-drift constraint, verified once for every shot): the {{{图N}}} set appearing in this shot's image prompt body ≡ the image number set referenced by the hud_reference field in this shot's Section 0.7 inheritance graph JSON ≡ these image numbers are all defined in the Section 0.7 "image number mapping table". If any one of the three is inconsistent, redo the entire document
  • In the reference image description paragraph, each image is its own sentence + all three elements are present: image number code ({{{图N}}}) + file nature (protagonist four-view design sheet / UI overview image / finished screenshot of Shot X, etc.) + role played (character anchor / HUD style benchmark / HUD practical benchmark, etc.). Compressed shorthand like "Image 1 protagonist + Image 2 HUD" is absolutely not allowed; if any one element is missing, redo
  • Every video prompt must explicitly carry the shot duration(e.g. 时长 6 秒。); if the duration is missing, redo. The same applies to story-driven / demonstration-driven / mixed-driven
  • The "Duration" column of every row in the shot sequence timeline table must be filled in and non-empty, if a row is missing, rewrite
  • Every image prompt ends with "ratio X:Y", every video prompt includes "aspect ratio: X:Y", and paired images and videos have matching ratios
  • No em dashes at all
  • No abstract words like fast / cinematic / epic
  • No MJ --xx suffix parameters
  • No long lists of negative words
  • The protagonist's description is highly consistent across 6 to 10 images (the core 3 to 5 features stay unchanged)
  • HUD element positions stay consistent across all shots (health bar always top-left / minimap always bottom-right)
  • Story-driven: subtitle bar style is consistent throughout + subtitles are original and not copied from existing games + TTS voice is specified
  • No copying examples from the tutorial document such as "cyberpunk dual-character standoff", "rainy night rooftop", "Vido", etc.
  • Already saved to ~/Downloads/调研报告/{项目名}-实机视频Pack/prompt主包.md
  • Full content has been shown in the conversation

Common input examples

用户："做一个《洛克王国》小红帽的实机演示"
→ 关键词模式 / 默认 Switch 卡通渲染 / 动作 RPG / 第三人称越肩 / 6 镜头 / 演示向
→ 必出 0 号角色参考表 + 6 镜头 + 时间轴

用户："基于这张图（贴图）做一个赛博朋克剧情向"
→ 参考图模式 / 默认 PS5 现世代 / 第三人称越肩 / 8 镜头 / 剧情向
→ 跳过 0 号 + 8 镜头 + 时间轴 + 字幕脚本 + 配音脚本

用户："给我家猫做个 GTA 风的"
→ 关键词模式 / 默认 PS5 现世代 / 开放世界 / 第三人称越肩 / 6 镜头 / 演示向
→ 必出 0 号宠物风格化 + 6 镜头 + 时间轴

Things not to do

  • Do not ask again about parameters that can already be inferred from context
  • Do not present a long "here is what I plan to do" list for approval before starting; just deliver
  • Do not paste the entire tutorial document back as preamble
  • Do not add plot narration and transition text between each shot (the output is a prompt pack, not a planning document)
  • Do not add emoji decorations to prompts
  • Do not write pleasantries like "here is the content you requested"