【後編】これまで作ってきたUnity作品を振り返ってみる
Back to Home
【後編】これまで作ってきたUnity作品を振り返ってみる
操作感や敵AI、ゲームバランスに試行錯誤した4作品を振り返り、7本のUnityゲーム制作から得た学びをまとめます。
目次
こんにちは！Darkmochaです。
前編に引き続き、これまでに作ってきたUnity作品を振り返っていきます。
前編では、ハンズオンを通してUnityの基礎を学んだ最初の3作品を紹介しました。後編では、少しずつオリジナルの企画や操作方法に挑戦するようになった、4作品目から7作品目までを振り返ります。
4作品目「アーマーブレイカーズ」
「アーマーブレイカーズ」は、見下ろし視点で戦車を操作して敵と戦う、トップダウン型の戦車バトルゲームです。
このゲームを作った理由はとてもシンプルで、私が「World of Tanks」というゲームを好きだったからです。
戦車が登場するゲームを、一度自分でも作ってみたいと思い制作しました。
この作品で工夫したこと
この作品で特に工夫したのは、次の3点です。
- AIを使った画像生成
- 爆発エフェクトによる手応えの表現
- Raycastを使った敵戦車の行動パターン
AIを使った画像生成
今回も、ゲームのイメージに合うフリーアセットがなかなか見つからなかったため、GeminiのNano Banana Proを使って画像を生成しました。
画像生成を使って作った主なSpriteは、戦車と弾です。
ゲーム全体の世界観をそろえるため、まずAIに画像生成用のプロンプトを書いてもらい、そのプロンプトをもとに全5種類の戦車と弾を作成しました。
戦車は、車体と砲身をそれぞれ別のパーツとして生成し、Unity上で組み合わせています。パーツを分けたことで、車体の進行方向とは別に砲身を回転させられるようになりました。
エフェクトの大切さ
それまでの作品では、エフェクトをあまり本格的に使っていませんでした。
しかし、試しに戦車の破壊時に爆発エフェクトを追加してみると、攻撃が命中したときの手応えが伝わりやすくなり、ゲームの面白さが大きく変わりました。
ゲームのルールやシステムが同じでも、エフェクトが加わるだけで、プレイヤーが受け取る気持ちよさや没入感は変わります。
見た目を豪華にするためだけではなく、プレイヤーにゲームの状態を伝えるためにも、エフェクトは重要なのだと学びました。
Raycastを使った敵戦車の行動パターン
敵戦車の移動や攻撃の自動化には、Raycastを使用しました。
仕組みとしては、1作品目の接地判定で使った
Physics2D.BoxCast と似ています。敵戦車の前方にRayを飛ばし、壁を検知したら進行方向を変えるというものです。簡略化すると、次のような処理です。
RaycastHit2D hit = Physics2D.Raycast(
frontSensor.position,
transform.right,
sensorLength
);
if (hit.collider != null && hit.collider.CompareTag("Wall"))
{
// 壁を検知したら回頭する
transform.Rotate(
0,
0,
avoidTurnSpeed * Time.deltaTime
);
}
else
{
// 前方に壁がなければ前進する
transform.Translate(
Vector3.right * moveSpeed * Time.deltaTime,
Space.Self
);
}上の画像には、敵戦車を中心に2つの円があります。
内側の円が索敵範囲です。プレイヤーがこの範囲に入ると、敵戦車は巡回モードから追跡モードへ移行します。
外側の円は、プレイヤーを見失ったと判定するための範囲です。プレイヤーが外側の円から出た時点で、追跡モードから巡回モードへ戻ります。
索敵を開始する範囲と見失う範囲を分けることで、境界付近で巡回と追跡が何度も切り替わるのを防いでいます。
戦車の前方から伸びている3本のRayは、障害物を避けるためのものです。ほかにも砲身からRayを飛ばし、その先にプレイヤーがいる場合に弾を発射する処理にも使用しました。
接地判定で初めて使ったRaycastを、敵AIの移動や攻撃に応用できたことは、自分の成長を感じられた部分です。
振り返ってみて
見た目や敵の動きにはかなりこだわりましたが、ゲームを繰り返し遊ぶための目標は、もう少し作り込めたと思います。
例えば、倒した敵戦車の数に応じて新しい戦車が解放される仕組みがあれば、戦闘を続ける目的が生まれ、より長く遊べるゲームになったかもしれません。
「戦車を操作して敵を倒す」という基本部分だけでなく、その先にどのような目標を用意するかも考える必要がありました。
5作品目「Can Cracher」
5作品目は「Can Cracher」です。
このゲームは、空から降ってくる空き缶をクリックで打ち上げ、ゴミ箱に入れるゲームです。
我ながら、なかなかユニークなゲームを作れたと感じています。
レベルが上がるにつれて缶を打ち上げられる高さが低くなり、少しずつゴミ箱へ入れるのが難しくなっていきます。
作っている途中は「本当に面白くなるのだろうか」と不安でしたが、完成して実際に遊んでみると、案外面白いゲームに仕上がりました。
クリックする位置で変わる操作感
このゲームの肝は、空き缶をクリックしたときの操作感です。
缶のどこをクリックしても同じ方向へ飛ぶのではなく、クリックした位置によって、缶が飛ぶ方向と回転する向きが変わるようにしました。
void OnMouseDown()
{
Vector2 clickPos =
Camera.main.ScreenToWorldPoint(Input.mousePosition);
// 缶の中心とクリックした位置の差
float xOffset = transform.position.x - clickPos.x;
// クリックした位置と反対方向へ飛ばす
Vector2 direction = new Vector2(
xOffset * sideForceMultiplier,
upForce
);
rb2D.AddForce(direction, ForceMode2D.Impulse);
// クリック位置に応じて回転を加える
rb2D.AddTorque(
xOffset * torqueMultiplier,
ForceMode2D.Impulse
);
}缶の中心より右側をクリックすると、缶は左方向へ飛びます。反対に、左側をクリックすると右方向へ飛びます。
回転方向もクリックした位置によって変わります。
- 缶の右側をクリック：
xOffsetが負になり、時計回りに回転する - 缶の左側をクリック：
xOffsetが正になり、反時計回りに回転する
クリックする位置が少しずれるだけで缶の軌道が変わるため、狙った場所へ飛ばすには微妙な調整が必要になります。
シンプルなクリック操作でも、位置や力の加え方を変えることで、ゲームらしい操作感を作れることを学びました。
WebGLで発生した表示の問題
反省点は、WebGL版を公開した後の表示確認です。
開発中はWindowsを使っていたため気づかなかったのですが、WebGL形式でビルドしたゲームをiframeでサイトに埋め込み、Macのブラウザから確認すると、画面のアスペクト比がずれて左右の端が見切れていました。
このゲームでは、画面端に移動した缶をクリックできないことが致命的です。端が見切れると、そこへ移動した缶を操作できなくなり、ゲームを続けられない状態になってしまいます。
ゲーム本体が正常に動いていても、公開するページやブラウザの表示方法によって、プレイできなくなる可能性があります。
現在はMacも購入したので、今後は複数の環境や画面サイズで表示を確認してから公開することを意識したいです。
6作品目「Meteor Frontier Runner」
残る作品もあと2つ。
6作品目の「Meteor Frontier Runner」は、ロケットを操作して隕石を避けながら進み続ける、無限ランゲームです。
ロケットが進んだ距離に応じて隕石の数が増え、少しずつ難易度が上がっていきます。
この作品は、ゲーム用の素材を探しているときに見つけたKenneyの2Dアセットから着想を得て制作しました。
アセットを眺めているうちにロケットと隕石を使ったゲームのイメージが浮かび、そこから企画を考えました。
企画を決めずに作り始めた結果
このゲームでも、最初に詳細な内容を決めないまま制作を始めてしまいました。
そのため、途中でテーマを変更したり、作ったものを戻したり、別のゲーム案が没になったりしました。それでも、最終的には一つのゲームとして形にできました。
ここまで作品を重ねると、以前と比べて実装面でつまずくことは少なくなってきました。AIを使って実装を補助している影響もありますが、自分自身もUnityの基本的な操作やコードの構成に慣れてきたのだと思います。
一方で、実装できることと、迷わず遊べるゲームを作れることは別でした。
初めて遊ぶ人への説明不足
この作品の反省点は、初めて遊ぶ人に向けた説明が不足していたことです。
チュートリアルがないため、操作方法が分かりにくく、ゲーム開始直後はロケットがどちらへ進んでいるのかも伝わりにくくなっていました。
制作者は操作方法やルールをすべて知っているため、説明がなくても当たり前のように遊べます。しかし、初めて触る人にとっては、進行方向や操作方法が分からないだけでも大きなストレスになります。
長いチュートリアルを作らなくても、最初に操作方法を表示したり、進行方向が分かる演出を加えたりするだけで、遊びやすさは改善できたと思います。
ゲームを完成させるだけでなく、プレイヤーが最初の数秒でルールを理解できるかどうかも確認する必要があると感じました。
7作品目「Monster & Panzer」
7作品目は「Monster & Panzer」です。
このゲームは、戦車を強化してモンスターを倒しながら、1000m地点への到達を目指す2Dクリッカーゲームです。
これまでに作った作品の中では特に規模が大きく、完成までに1か月半ほどかかりました。
ゲームバランスとテストプレイ
この作品で最も苦戦したのは、ゲームバランスの調整とテストプレイです。
過去の作品とは異なり、Monster & Panzerには、戦車の攻撃力や敵の体力、強化に必要な費用など、さまざまなステータスやパラメータがあります。
変数が増えるほど、それぞれの数値がゲーム全体に与える影響も大きくなります。そのため、難易度の調整にはかなり苦戦しました。
さらに、ゲームを最初からクリアするまでに40〜50分ほどかかるため、バランスを少し変えるたびに最後まで確認するのも大変でした。
テストプレイで気づいた単調さ
最初に完成させたゲームを仲間にテストプレイしてもらったところ、大きな問題が見つかりました。
それは、ゲームをクリアするまで、プレイヤーがずっとクリックし続けなければならないことです。
作っている途中は同じ操作を何度も繰り返していたため、自分の感覚が麻痺してしまい、その単調さに気づけていませんでした。
テストプレイでもらった意見をもとに、自動でゲーム内通貨を生み出す装置やセーブ機能など、さまざまな機能を追加しました。
ただ、前編でも書いたように、最初の段階でゲームの内容やバランスを十分に詰め切れていなかったため、後戻りや修正が多くなってしまいました。
機能を追加していくうちに、当初思い描いていたゲームの構想を見失い、そのまま制作を進めてしまった部分もあります。
最後まで残った疑問
このゲームでは、最後まで「単調さ」を解決し切れませんでした。
変化を作るために、ステージの途中へさまざまなチェックポイントや機能を追加しました。しかし、完成したゲームを振り返ると、必要になった要素を後から継ぎ足していったような構成にも感じます。
初めてプレイする人には、楽しく遊んでもらえるかもしれません。
それでも自分の中には、「本当に最後まで楽しくプレイできるゲームになったのか」という疑問が残りました。
最後まで完成させられたことは大きな成果です。しかし、完成したからといって、制作者自身が感じた問題までなくなるわけではありません。
この疑問は、次にゲームを作るときにも忘れずに持っておきたいと思います。
Unity MCPを使ったゲーム制作
この作品では、制作期間の後半からUnity MCPを利用しました。
現在はCodexとClaudeの両方を使いながら、それぞれの違いを比較しています。トークン消費量の関係からCodexを使う機会が多くなっていますが、どちらにも得意な部分があると感じています。
Unity MCPを使うことで、AIからUnity Editorを操作し、GameObjectやComponentの作成、設定の変更などを行えるようになりました。
UIやプレイヤーの細かな配置については、まだ自分で調整したほうがよいと感じる部分もあります。一方で、機能をComponent単位で作る場面では、自分だけで実装するよりも質の高いものを作れることがありました。
AIにすべてを任せればゲームが完成するわけではありませんが、使い方次第では、ゲーム制作を助けてくれる強力な道具になると感じています。
7作品を振り返って
これまでに作ったゲームは、全部で7本です。
「たった7本」とも言えますが、その7本を作る中で多くの失敗を経験し、自分のアウトプットと向き合う時間を重ねてきました。
最初は、ハンズオン動画を見ながらUnityの操作や基本的な実装を覚えるところから始まりました。
そこから、AIを使ったアセット制作、ルールベースAI、Raycastを使った敵の行動、クリック位置によって変化する操作感、ゲームバランスの調整など、少しずつ自分で考えて作る範囲が広がっていきました。
一方で、作品を重ねるたびに、実装できることと面白いゲームを作ることは別なのだと感じるようになりました。
特に大きかった学びは、次の3つです。
- 作り始める前に、ゲームの核と完成範囲を決める
- 自分以外の人に遊んでもらい、客観的な意見を受け取る
- 機能を増やす前に、それが本当に面白さにつながるのかを考える
これからiOS向けのゲームをリリースするにあたっては、ゲームそのものの面白さだけでなく、既存の市場、対象年齢、ゲームデザイン、収益の仕組みなど、考えることがさらに増えていくと思います。
これまでの失敗が、すぐに正解を教えてくれるわけではありません。
それでも、実際に7本のゲームを完成させ、うまくいかなかった部分まで振り返った経験は、次の作品を作るための糧になるはずです。
これからも試行錯誤しながら、自分が本当に面白いと思えるゲームを作っていきたいです。
