[unity1weeks]Unity歴1ヵ月で初制作したゲームのまとめ
11月頃からUnityの勉強を始めてしばらくして、こりゃ独学じゃ無理だわと感じていた頃に「Unityゲーム開発者ギルド」というSlackワークスペースを知り、参加しました。
そこでUnity1週間ゲームジャムという企画を知り、ちょうどチュートリアルに飽きて作り始めていた第一作目が今回のテーマ「あける」にマッチしていたので、せっかくなので参加することにしました。
https://unityroom.com/unity1weeks/18
作ったもの
これを作ろうと思った理由
RPGやアクション、パズルなど、様々なジャンル・規模のゲームを作ってみたいと思っているのですが、特に最初に作りたいと思ったのが、この3Dダンジョン形式のゲームでした。
昔あったWizardryというゲームシリーズがとても好きで、今でも都内の地下鉄などにある天井が低い通路を歩くとワクワクします。
また、画面上に必要なすべての要素をシンプルな四角形と文字だけで実現できるので、デザインや色彩などの調整に時間を取られず、Unityの仕様やオブジェクト操作、内部処理の設計と学習に集中できる題材だと考えました。
デザイン系のアセットを使えばきっと画面の見栄えは良くなるのでしょうが、初学者として、演出の華やかさよりも、堅実な処理と学習を優先しました。
工夫したこと（ゲームの中）
「同じ地形、同じ景色を作らないようにした」
見分けがつかない地形が続くと理不尽さが勝ってストレスを生むと思ったので、部屋や通路の形ができるだけ異なるようにしました。
ただ要所要所に一方通行ドアを設置したり、わざと点対称や線対称の通路を作ってみたりして、"覚えやすい地形"と"迷いやすい地形"のバランスを考えながら地図を作りました。楽しかったです。
「適度にヒントメッセージを表示するようにした」
特に前半に集中させてヒントメッセージを配置しました。
「今どっちを向いているか」「あれ、さっきも通ったぞ」に気づきやすくなるようにメッセージを配置したつもりです。
「歩き回ること自体にストレスを感じないように気を付けた」
とにかく歩き回るゲームなので、さくさく歩ける操作感を大事にしました。
最初は静止画でしたが、より歩いてる感を出すために一歩ずつアニメーションさせるようにしました。アニメーションのコーディングに試行錯誤していたのですが、DOTweenを導入したら一瞬で解決しました。
Before: 静止画での歩行。初期のWizardryを彷彿させる。
After: アニメーションにした
「自由な画面サイズで遊べるようにした」
当たり前のことですが、プレイヤーの方々のモニタサイズが私の開発環境と同じとは限らないので、レスポンシブになるように実装しました。UnityのUI配置や調整は難しいですね……。
極端な縦横比にしない限りは問題なく遊べると思います。
できなかったこと（ゲームの中）
「効果音やBGMを鳴らせなかった」
期間内に音の管理方法まで辿り着けませんでした。ドア音と足音ぐらいは欲しかったですが、素材を探し始めると一瞬で時間が溶けるので後回しにしていて、そのままで公開しました（※現在はドア音のみ鳴るように更新済み）。
このへんの時間配分というかリソース配分はもっと計画が必要でした。
「ミニマップ機能を実装できなかった」
今どこにいるかを表示する機能が作りたかったのですが、時間切れでした。
ちょうどMVPモデルの、Model（プレイヤーの現在地）の更新に対して、2つのView（3Dダンジョンの見た目、ミニマップの見た目）が更新されるというMVPならではの美味しさが味わえる部分なので、引き続き作っていきます。
「鍵イベントを作れなかった」
ゴール前のドアには鍵がかかっていて、どこかにある鍵を見つけてからでないとゴールできない、という仕掛けを作りたかったのですが、これも時間切れでした。
ただ、事前に妻にテストプレイしてもらった際にそのプランを話すと"難しくなりすぎるんじゃない？"と言われました。3分程度でカジュアルに遊べるゲームとしては、未実装なのが結果的には良かったかもしれません。
学習目標と達成度（ゲームの外）
「ゲームを公開しよう」……達成
ゲームって、絵や音楽と同じで、作りこもうと思えばいくらでも作っていられる、終わりがない創作だと思いました。
そういう意味では今回のu1wはとてもよい区切りで、この企画（とフィギュアという餌）がなければおそらくずっと何かしらをいじり続けて、そのうち飽きてお蔵入りになっていたと思います。
公開しなければ何も作っていないのと同じ。これからも心掛けたいです。
「MVPモデルで実装しよう」……それなりに達成
なんせ初ゲーム開発なので、改善の余地はたくさんあるでしょうが、それなりに考えながらMVPモデルで実装してみました。
それにしても、UniRxを使ってModelとViewをPresenterが監視する、という仕組みは面白いですね。
学習コストはやや高いと感じましたが、非常によくできていて、ちゃんと使いこなせば複雑なゲームでもうまく分割しながら、それこそ分業しながら開発していけるんだろうなと思いました。私は一人だけど。
一口にMVPモデルといっても個人や組織の描く"MVP"のイメージはみな異なりますし、Unity界にはUnity界の癖もあり、最初は感覚が掴めずに苦労しました（PresenterはMonoBehaviourを継承するべきかどうか、等）。
ギルドの設計チャンネルでMVPについてあれやこれや様々なご意見をいただきました。
有識者が近くにいて、助言をくれる環境というのが初学者にとってどれだけありがたいかを実感しました。
「Unity向けのDIコンテナを使おう」……達成
もはやDIなしでの開発なんて考えられないので、当然Unity界にもあるじゃろうと思っていたら、やっぱりありました。超有名なやつらしいです。
現状、DIの恩恵を得られるほどしっかりした作りにはなっておらず、入力（UnityEngine.Input）の直接参照を避けることと、後述の自動テストに向けた布石、といった程度です。
これからも使って、もっと使いこなせるようになっていきたいです。
「Unity向けの自動テストを書こう」……未達成
現時点ではそこまでたどり着けていません。XUnitは使えるんだっけ？ とかそんな段階の調査すらできていない。
これからします！
「GitHubActionsで自動ビルドとテストを回そう」……未達成
これも、そこまでたどり着けていません（可能かどうかの調査すらできていない）。勉強頑張ります。
「マップを動的に生成しよう」……達成
今回は、YAMLデータにマス目と壁、ドアなどの情報を持たせて、ゲーム起動時に読み込み、1マス分のPrefabから10マス×10マスのダンジョンを生成しています。壁なども個別にPrefab化して、東西南北の組み合わせで一つのマスになっています。
さすがに10×10のダンジョンをちまちまGUIで配置していくのが筋の悪い設計だってのは容易に想像できたので、これは最初からそういう設計で行くつもりでした。
その処理自体はスムーズに実装できたのですが、肝心のダンジョンデータをYAMLデータとして用意するのが非常にめんどくさくて、専用のエディタか何かを作ろうかと思っています。または、管理方法をSpreadSheetなどに変えるか。これは今後の要勉強課題です。
「現在地から見える範囲だけオブジェクト生成しよう」……未達成
動的にマップを生成しているとはいえ、現在地から見えない範囲もすべて開始時に生成してしまっています。
100×100などの大規模ダンジョンを想定した時に、今のつくりだと超大量のオブジェクトを生成することになるのでさすがに無駄が多すぎます。
これは実装上の課題として現在修正対応中です。
2021/01/15追記: 対応した記事を投稿しました。
全体を通した所感
ゲーム作りって、楽しいけれど、難しいですね。
絵も、音も、曲も、ゲームデザインも、全部ひとりでやってる人が世の中にしばしばいますが、とんでもねぇなと思いました。でも、そうありたいな、とも思いました。がんばろう。
今までたくさんのゲームを遊んできて、「なんだこれクソゲーじゃん」みたいなことを言う時もありましたが、実際に作ってみて考えを改めました。
ゲームを作っている人たち、それを完成させて世に送り出している人たち、本当にすごいと思います。
この記事が気に入ったらサポートをしてみませんか？