HOUSE DUCK · AUTOMATIC TRANSLATION
プロンプトでゲームキャラクターをデザインする | House Duck バイブコーディング
人工知能にゲームのキャラクターを作ってほしいと頼むと
それらしい絵が一枚はかなり早く出来上がる。
問題はその次だった。
同じ人物をもう一度描いてほしいと頼んだのに顔が変わり、
表情を変えると服まで変わり、
ゲーム画面に縮小して入れると目と口が一つのかたまりになった。
一枚だけ見ると気に入るのに
何枚か並べて置くと同じゲームのように見えないことも多かった。
可愛い画像を出力することと
ゲームのキャラクターを作ることは違うことだった。
プロンプト一回でお気に入りの絵が出ても
その絵がゲームの中で生き残るのかは別の問題だった。
Project K、Quirky Ball、
そしてまだゲーム名も決まっていない
次作を作りながら学んだ。
一枚うまく描けた絵が一番危険だった。
Project Kの初期の人物画は
今見ると生成型画像の痕跡が非常に鮮明だ。
絵一枚だけを見ればキャラクターが存在感のあるように見えた。
しかし世界観の特徴を早く見せたくて
似た外見の条件を繰り返し入力した結果
指導者候補が全員似たような年齢と体型で集まった。
表情は増えたものの
名前を隠すと誰が誰なのかすぐに区別しにくかった。
そのため人物の数を増やす代わりに
顔の型、体型、髪型と服装のシルエットを
まず広げる方向に変えた。
自動検査もたくさんパスし
画像サイズとファイル規格も合っていた。
ところが実際のモバイル画面に入れてみると
髪の毛や服のしわ、光沢のような細かい描写が残り
ゲームのドット絵と浮いているような感じがした。
ファイルが正常だからといって絵まで良いわけではなかった。
結局Project Kはドットフィルターをさらに強くかける方向も捨てて
一人の3Dの元データをまずきっちり作った後に
その元データから似顔絵、プロフィールとカード画像を抽出する方向へ改めた。
上記の絵も最終的なゲームアセットではない。
現在承認された人物方向板に近く
実際のゲームに入れる3Dの元データはまだ製作中である。
気に入る方向を見つけたからといって
完成したかのように言わないこともかなり重要だった。
プロンプトを鑑賞文ではなく製作指示書のように変えた。
最初は素敵な、高級な、映画のような感じの
形容詞をたくさん入れれば良くなると思っていた。
今は逆に書いている。
このキャラクターがどんな役割なのか、
画面でどのサイズで見えるのか、
何が変わってはいけないのかを先に記述する。
役割： モバイル画面ですぐ認識できる指導者
区分： 顔型・体型・髪・長いコートのシルエット
固定： 同一人物の正面・側面・背面、同じ服装と代表色
明暗： 基本色と影中心の2から3階調のセル明暗
禁止： 実在の人物の似顔絵、肌のノイズ、微細なシワ、文字とウォーターマーク
検収： 実際のゲームサイズに縮小しても目・鼻・口と役割が判読できること
これは当時使用していたプロンプトの原文ではない。
何度も失敗した後に残った製作条件を
プロンプトの形式で再び整理したものである。
そして一度に数十人を作らない。
代表キャラクター数名だけをまず出力し
実際のUIやゲーム画面に入れてみた後に次の束へ移行する。
生成回数を増やすことよりも差し戻しの基準を先に作ることが早かった。
Quirky Ballはむしろあまり描かないことでキャラクターになった。
Quirky Ballも最初から現在の顔だったわけではない。
一時は一般の玉にも顔を付けようとしたり
赤い六角形のクッキーは大きな歯を見せて笑っていた。
画面の中のすべてがキャラクターのように見えると
肝心の主人公が誰なのかがぼやけてしまった。
そのため一般の玉の顔は取り払い
クッキーだけ三白眼と太い眉毛、
片方が上がった口角を持つキャラクターとして残した。
表情を直すだけでは終わらなかった。
名前を知らせ、なぜ研究所に閉じ込められたのかを話し、
プレイ状況に応じてまばたきし、笑い、心配し、挑発してこそ
ようやく赤い図形がキャラクターとして読み取られ始めた。
カットシーンも似たような過程を経た。
初期には科学者と機械を単純な図形で描いた。
その後、生成型画像で科学者と装備の草案を得たが
その結果物をそのままゲームに入れたりはしなかった。
色を五つに減らし、白い背景を消し、
サイズとピクセル倍率を固定して一枚のアトラスに再びまとめた。
同じ規格で切り抜いておいてこそ
場面が変わっても科学者の顔と機械の大きさがブレなかった。
優れたプロンプトよりも後処理のルールの方が長く生き残った。
ゲーム名未定の次期作では最終キャラクターをあえて作らなかった。
次期作の初期プロトタイプは
キャラクターすらいないタイミングゲームに近かった。
リブートしながらアヒル、ガチョウ、ハトを入れたが
今見えている鳥たちはコードで作ったローポリのグレーボックスだ。
最終的なキャラクターデザインではない。
代わりに先に決めたのは役割だった。
アヒルは指揮とバランス、
ガチョウは防御と重さ、
ハトは経路を作るキャラクターに分けた。
モデルが美しくなくても
ドラッグ、衝突、掩蔽と報酬が正しく読み取れるかから見る。
まだ外部プレイヤーの面白さの検証も通過していない。
そのため最終的なセル 3D キャラクターをまず大量に作らず
アヒル一種類の原画だけを検証した後に拡張する計画で止めておいた。
面白くないゲームに綺麗なキャラクターを十人さらに増やしたところで
面白いゲームになるわけではないからだ。
アセットが気に入っているからといってゲームが完成したわけではない。
キャラクターの画像がうまく出ると
プロジェクトが急にたくさん完成したかのように感じられる。
私も新しい絵を画面に入れるたびに
ゲームがかなりそれっぽくなったと勘違いした。
しかしプレイヤーがもう一度実行したくなるほど 面白いのか、
セーブとログイン、決済が壊れないほど ソフトウェアが完成しているのか、
初めて見る人でも理解できるほど UIが明確なのか、
ボタンを押したときに即座に反応するほど インタラクションが機敏なのか、
そしてゲームの存在を知らせる マーケティングへとつながるのかは
キャラクターの原画一枚で解決されるものではない。
むしろアセットが良くなるほど
プレイヤーがゲームに期待する基準も一緒に上がる。
アセットはスタートラインを見栄えよく作ってくれる。
しかし結局ゲームを動かすのは
面白さと完成度だ。
プロンプトがうまく機能して気に入ったキャラクターが出たら
喜んでもいい。
ただその日一日プロジェクトがうまくいったということであり
ゲームが成功したわけではない。
翌日には再びプレイし、修正し、
ボタン一つの反応と最初の 10 分の面白さを確認しなければならない。
一喜一憂するには、ゲームを完成させる仕事がまだあまりにも多く残っている。