用Grok和Unity Hub开发2D回合制RPG的实践：从失败到成功的工作流

前言

前几天，我参加了在熊本市内举办的创意动手工作坊，获得了学习利用Unity和AI进行游戏制作（提示词编程）的宝贵机会。

我被“通过自然语言对话让游戏逐渐成型”的开发体验所感动，回家后立刻着手自己制作游戏。……然而，就在此时，那个总想尝试“没教过的多余东西”的老毛病又犯了。

本文将总结从因模糊提示而失败的案例出发，向AI提供需求定义、状态设计和资产命名规范，从而成功构建出符合预期的2D回合制RPG的实践过程。

1. 初次失败：“勇者斗恶龙风格”无法传达给AI

起初，我只是出于“更换模型是否能提升视觉质量？”这种肤浅的想法，便尝试使用Codex，并将其与Unity Hub连接后，气势汹汹地抛出了以下提示。

「我想制作一款类似《勇者斗恶龙》风格的RPG」

结果，生成的却是不知为何变成了“没有横向卷轴风格世界地图的RPG”。
提到《勇者斗恶龙》，大家想到的是俯视视角（top-down）的网格移动与指令战斗，但对AI来说，仅凭“类似《勇者斗恶龙》风格”这一表述，理解偏差实在太大了。

此外，这次我还想加入一些略带锋芒的设定（包含稍显敏感的服装破损差分或耽美BL元素），于是灵机一动：“Grok或许能接受一定程度的敏感暗示吧？”便着手搭建环境，决定卷土重来。

2. 卷土重来：提交需求规格说明书级别的提示词

吸取上次的教训后，我回归了“如果要让AI来制作，就必须将人类侧的世界观和系统规范语言化并交付”这一vibe coding的基本原则。

以下是实际发送给Grok / Unity Hub关联功能的初始提示词。

Unity Hubに接続して、ドラクエ風の2Dターン制RPGを作成してください。

【ゲーム概要】
ネオトーキョーで人気の3人組男性バンドのボーカル・優（19歳）が、ステージ上から忽然と消える。
バンドメンバーであり恋人の御堂と楊は絶望に陥る。
優はボス・ファントムの元から逃げ出し、ネオトーキョーへ戻ろうとするが、
優を自分のものにしたいファントムに妨害されるBLRPG。

【開始フロー】
1. オープニング動画再生：opening.mp4
2. 動画終了後、ゲーム画面へ遷移
3. 優がファントムの拠点から脱出した状態でスタート

【マップ構成】
ワールドマップ＋各エリアのローカルマップで構成。
- 砂漠の国（ファントムの拠点あり・スタートエリア）
- 珈琲国（安藤がいる）
- 氷結国（催眠が得意な龍がいる）
- ネオトーキョー
- 絶望の島

【主要キャラクター（立ち絵あり）】
- 優：you.png（ベース衣装。ボスの趣味で着せられたもの）
- 御堂：mido_anger.png
- 楊：yang_anger.png
- ファントム：boss.png（顔は見えない）
- 龍：dragon.png
- 安藤：ando.png
- 服を狙う敵：Enemy.png
- 防具屋：armor.png
- 服が気になる街の人：mob.png

立ち絵があるキャラクター・敵は専用会話UIで表示。
それ以外の人物は簡易NPC（テキストのみ）で対応。

【コアシステム】
- 探索中・戦闘中に「服を狙う敵」が出現する。
- 優の服装はダメージを受けるごとに変化する（cloth0〜cloth3の4段階）。
  - cloth0：無傷
  - cloth1：軽度
  - cloth2：中度
  - cloth3：重度
- 修復方法：
  1. 宿屋で休む（全回復）
  2. 防具屋で裁縫道具を購入し、メニューから「縫う」を選択（1段階修復）
- 敵に敗北すると、ファントムの元（砂漠の国の拠点付近）に強制送還される。
- ファントムのセリフは「服の破損段階（cloth0-3）」と「帰還回数」によって変化させる。

【ファイル命名規則（優の立ち絵）】
You_cloth[0-3]_ret[帰還回数].png
例：You_cloth1_ret0.png、Yu_cloth2_ret3.png

まずは以下の最小構成でプロトタイプを作成してください：
1. ワールドマップから砂漠の国へ移動できる
2. 砂漠の国に簡易な街（宿屋・防具屋）とフィールドがある
3. 服ダメージ段階の変数と、簡易的な「縫う」コマンド
4. 敗北時にファントムの元へ送還される処理
5. 立ち絵を表示する基本的な会話システム

使用する画像は指定のファイル名でAssetsに配置する前提で進めてください。

3. 实现中的技巧与设计要点

① 将文件命名规则与“状态变量”一对一匹配

为了根据服装破损和败北回归次数动态切换立绘，我们对资产名称进行了明确的规则化。

You_cloth0_ret0.png   // 無傷・初帰還
You_cloth0_ret1.png

You_cloth1_ret0.png   // 軽度・初帰還
You_cloth1_ret2.png

You_cloth2_ret0.png   // 中度・初帰還
You_cloth2_ret1.png
You_cloth2_ret3.png

You_cloth3_ret0.png   // 重度・初帰還
You_cloth3_ret2.png
You_cloth3_ret5.png

通过提前告知这一命名规则，C#脚本侧只需使用字符串插值即可生成直接加载资源的代码，例如 $"You_cloth{cloth}_ret{returnCount}"。

② 战斗系统与服装破损状态的联动

在接下来添加战斗功能时，我们按如下方式叠加了提示词。

「请添加简单的回合制战斗。以瞄准服装的敌人（Enemy.png）为中心，敌人在战斗中受到伤害时，优的cloth阶段会上升。失败时将被送回法姆处。」

由此，除了常规的HP伤害计算外，服装耐久度减少并切换立绘的处理（ClothSystem）被清晰地分离并实现。

// 実際に生成・整理された服ダメージと敗北帰還のロジック例
public static class ClothSystem
{
    public static bool ApplyEnemyClothHit(GameState state)
    {
        if (state.Cloth >= GameBalance.MaxCloth)
            return false;
        state.Cloth++;
        return true;
    }

    public static string ApplyDefeat(GameState state)
    {
        state.ReturnCount++;
        state.Hp = state.MaxHp; // 生かされて連れ戻されるためHPは回復
        state.Screen = ScreenId.DesertTown;
        // 服の破れ段階と累計帰還回数に応じたボスのセリフを返す
        return PhantomLines.Line(state.Cloth, state.ReturnCount);
    }
}

\n③ 修复机制（“旅馆”与“道具店+缝补命令”）

因为想要制作出服装破损会导致无法进行的事件或NPC的特殊反应，所以也准备了两种修复手段。

• \n旅馆：付费住宿可完全恢复HP + 服装完全修复
• \n道具店的缝纫工具：在道具店购买“缝纫工具”后，菜单画面中会追加“缝补”命令，可在野外逐步进行应急处理

我们不仅按照指示制作，还通过与AI反复推敲，加入了更精细的逻辑，例如“根据服装状态显示不同的菜单选项”以及“在催眠状态下针尖可能会打滑导致失败”。

4. 集成到画面中与“人类最后的润色”

这是将生成的脚本附加到Unity场景中，并配置立绘和瓦片地图后的样子。

在完成所有代码后，最后由人工进行的部分如下：

1. 调整对话的人性化程度
   AI最初编写的台词略显说明口吻，残留着“AI感”，因此根据角色的语气和紧迫感进行了重写。
2. 调整每个事件中立绘差异的插入时机
   对“在哪个时机展示哪种表情/破损度的立绘”这一演出层面的间隔进行调整。

「骨架与逻辑交给AI高速搭建，细节和演出调味由人类负责”这一工作流程运作得极为顺畅。

总结：通过Vibe Coding学到的东西

1. 仅用“XX风格”一句话下达指令是事故之源
   如果仅凭类型名称或知名标题名来下达指令，AI的解读可能导致作品在横版卷轴与俯视视角之间摇摆不定。必须具体指定构成游戏性的核心要素，例如“2D回合制”、“俯视网格”、“命令选择式”等。
2. 尽早确立资产命名规则
   在将程序与插图（立绘）联动时，如果先从提示词侧提出如名前_ステートA_ステートB.png之类的命名规则，脚本的加载处理会变得极其简单。
3. 从最小可行产品（MVP）开始，逐步通过对话进行完善
   不要试图一开始就一次性做出成品，而是通过“移动与对话”→“衣物破损与回归”→“战斗与修复”这样的阶段逐步进行对话，从而以最短距离构建出运转无误的游戏。

对于原本对Unity游戏开发犹豫不决的人，如果是基于与AI的对话方式，也能以惊人的速度将想法转化为现实。感兴趣的朋友请务必尝试一下！

使用工具
Grok build,unity HUB