House Duck
← すべての記事

HOUSE DUCK · AUTOMATIC TRANSLATION

バイブコーディングでゲームデザインをする、デザイン科出身なのにアセットを一つも自分で作らなかった理由 | Quirky Ball

結論から言うと、

私は工業デザインを専攻したが

Quirky Ballのゲームアセットを直接作らなかった。

 

イラストを一枚ずつ描き、

ボタンをフォトショップで書き出し、

アイコンを直接整える方法で

作らなかったという意味だ。

 

それでもゲームの雰囲気はだんだん一つにまとまっている。

 

最初は私もこれが少し変だった。

 

デザイン科を出たのに肝心の自分のゲームの絵を自分で描かないなんて。

 

しかしゲームを最後まで作るには、

むしろこの方法が正しかった。

 

デザイン科を出たからといって全ての絵を自分で描かなければならないわけではない。

工業デザインを勉強すると

絵が上手な人に見える時が多い。

 

しかし私が学んだデザインは

きれいな絵を作ることより

問題を整理することに近かった。

 

誰がこの画面を見るのか、

何を一番先に知るべきなのか、

どのような行動を自然に誘導するのかを

決めることだ。

 

Quirky Ballでも私の担当した仕事は同じだった。

 

玉を直接描く代わりに

どんな形であれば一目で区別できるか決めた。

 

科学者を直接ピクセルで打つ代わりに

このキャラクターがゲームのとぼけた実験室の雰囲気を

どれほどうまく伝えるか判断した。

 

絵を描かなかったからといってデザインをしなかったわけではなかった。

 

科学者と玉の実験で始まるQuirky Ballのオープニング。

アセットから作り始めるとゲームが終わらない。

1人開発で一番怖いのは作れないことではない。

 

作るものは増え続けるのに

ゲームは相変わらず実行されない状態だ。

 

ホーム画面を一つ作るにしても

背景、ロゴ、ボタン、アイコン、

バッジ、ポップアップ、キャラクターが必要だ。

 

これを全部手で完成させた後に

開発を始めようとしたら

私はまだ最初の画面で

色を選んでいただろう。

 

だから順番を変えた。

 

まずプレイができる画面を作り、

実際のゲームの中で不自然な部分を直した。

 

必要な視覚要素はAIとコードですばやく取り出し、

生き残ったものだけデザインルールにまとめた。

 

完成したアセットを待たないから

画面をはるかに早く比較できた。

 

Quirky Ballの大部分は画像よりルールで描かれる。

プロジェクトを紐解いてみると意外にも

画像ファイルよりコードで描く画面がはるかに多い。

 

玉の顔とハイライト、

カードの枠線と影、

ボタンの押し心地、小さなバッジとアイコンまで

ゲームの中で組み合わされる。

 

この方式の長所は

一つを直すと複数の画面が一緒に良くなるという点だ。

 

角の丸みの大きさ、

影の方向、

ポイントの色をルールにしておけば

ショップのカードごとに新しい画像を作る必要がない。

 

パッケージ、財貨、チケット、コスメティックのように

内容が違っても

同じゲームの画面のように見えるようになる。

 

同じルールで整理したパッケージ、財貨、チケット、コスメティックカード。

最初からこのように整理されていたわけではない。

 

ボタンごとに色が違っていたし、

アイコンの表現方式も混ざっていたし、

カードごとに情報の順番が違っていた。

 

一つずつ綺麗に直す代わりに

共通のルールを先直すと

画面全体がすばやく整理され始めた。

 

私がしたデザインは選択して捨てることだった。

バイブコーディングをすると成果物がとても早く出る。

 

問題は良い結果だけが早く出るわけではないという点だ。

 

それらしそうだがゲームと合わない画面、

自分だけ浮き立つアイコン、

読みにくい色の組み合わせも一緒にあふれ出る。

 

だから私が最も多く行った作業は

新しく作ることではなく

比較して捨てることだった。

 

実行画面をキャプチャし、

何が先に見えるかを確認し、

一文で問題を書き留めた。

 

修正された画面をもう一度見て、

まだぎこちなければさらに捨てた。

 

ランキング画面も同じ過程を経た。

 

順位の数字だけを並べる代わりに

表彰台、自分の順位、シーズン情報、

複数のランキングへの入り口を

一つの画面で読み取れるように整理した。

 

表彰台と複数のランキングへの入り口を一つの画面に整理したランキングの場面。

ここでデザインは装飾ではなく情報の順番を決めることだった。

 

きれいなボタンよりも誤って押されないボタンが先だった。

ゲーム画面をきれいに作るだけでは

完成度は上がらない。

 

プレイヤーの指が実際にどう動くのかも

デザインしなければならない。

 

Quirky Ballにはレベルが上がると

二つの成長方向のうち一つを

選ぶ画面が出てくる。

 

ところが直前の動作で

画面を素早くタップしていた指がそのまま残っていると、

ポップアップが出現した瞬間に

望まない選択をタップしてしまう恐れがある。

 

そのため選択ボタンは最初 1.5 秒間

ディム状態で表示され、入力も受け付けない。

 

時間が経つと色とコントラストが戻りながら

ボタンが有効化される。

 

選択ボタンは 1.5 秒間ディム処理された後、色とコントラストが戻って有効化される。

暗い状態と鮮明な状態がはっきりと違ってこそ

プレイヤーも今押せるかどうかを

すぐに理解できる。

 

こうした要素はスクリーンショットを一枚

きれいに作る作業では見落としやすい。

 

しかし実際のゲームを続けながら実行して作れば

結局発見することになる。

 

私の考えるゲームデザインの完成度は

こうした小さな安全装置から生まれる。

 

AIが作ったからといってデザインが自動的に完成するわけではない。

AIは画面を素早く作ることができる。

 

しかし、どのような画面が Quirky Ballらしいのかは分からない。

 

どのボタンをより大きく見せるべきか、

どの冗談を残し、どの装飾を捨てるべきか、

モバイル画面で文字が実際に読めるかどうかは

結局のところ人間が決定しなければならない。

 

私が行ったことは

AIに一度素敵に作ってほしいと頼んで

終わらせる作業ではなかった。

 

ゲームを実行し、

キャプチャし、

問題を具体的に伝え、

再び比較する作業を繰り返した。

 

結局バイブコーディングにおいて

デザインのセンスが求められる瞬間は

作る瞬間よりも選ぶ瞬間だった。

 

もう一度作るなら同じようにするだろうか？

おそらく同じようにするだろう。

 

最初から完璧なアセットの束を作るのではなく、

プレイ可能な画面から作るはずだ。

 

そして繰り返し使われる形や色が

見え始めた時に

デザインルールとしてまとめるだろう。

 

直接描かない代わりに

より多く見て、

より正確に伝え、

より冷徹に捨てるだろう。

 

デザイン科を出た私が

アセットを一つも自分で作らなかった理由は

絵を描くことを諦めたからではない。

 

一人でもゲームを最後まで完成させることができる

デザイン手法を選んだからだ。