はじめに
私はUnityを使ったゲーム開発のプロジェクトに参加しているのですが、開発班としてゲームを創っていく中で見えた課題とその解決方法について紹介したいと思います。
現在開発してるプロジェクト
現在アクションノベルゲームを開発しているのですが、まず開発チームとして参加した経緯を説明します。元々現在のPM(プロジェクトマネージャー)に当たる人がイラストレイターとして活動していて、その人がゲームを作りたがっていたのですがコードは書けないがイラストは描けるという状態でした。私もコードは書けるがイラストは描けないということでPMとお互いのニーズがマッチして開発チームとして私が参加したという経緯があります。
チーム構成
その後私一人でUnityを扱うのは作業量的に難しいと判断し、同じく情報系の学部にいる友人を招待し、PMも同じイラストを書いてる人間を招待したりして以下のようなチームメンバーで開発を行っています。
| 役割 | 人数 |
|---|---|
| PM(イラストシナリオ兼任) | 1人 |
| シナリオライター | 2人 |
| エンジニア | 2人 |
| アニメーター | 1人 |
| UIデザイナー兼イラスト | 1人 |
課題
上記のチーム編成でゲームを開発する関係で間違いなく発生する問題として開発班とイラストレーター・シナリオライターの認識の齟齬でした。PMからはある程度のゲームの概要とシナリオの内容を伝えられましたがコード班に託された裁量は大きく、実装した内容がPMのイメージしてるものに沿っているのかどうかが分からないという問題がありました。そのため、私は以下のような解決策を用いて他班とコード班の認識をすり合わせました。
要件定義書の作成
まず要件定義書を作成しました。「たかがインディーのゲームで要件定義書を作るのは過剰」という意見があるかもしれません。しかし、このドキュメントはゲームを開発していく上でPMとコード班の認識をすり合わせる上でかなりの効果をもたらしたと感じています。
決定事項を残せる
ミーティングなどを通して実装する機能をヒアリングし決定事項を洗い出していくフェーズにおいて議事録だけではどうしても不足情報が出たり定義漏れなどが発生してしまいます。また、議事録だけだと要件を定義していく上で不必要な情報も載ってしまいます。それを解決するのが要件定義書という訳です。
まずPMから要件をヒアリングします。その後、ゲームとして必要な画面と機能を洗い出し、要件定義書に記述していきます。そしたら「この画面を作るならこの画面までどうアクセスするのだろう？」や「このボタンの挙動はどうなるのだろう？」みたいな疑問が次々出てきます。その疑問が出てこなくなるまで煮詰めていきドキュメントに記述していきます。そうすることでPMとコード班の認識のズレをできるだけ小さくし、後から「思っていたものと違う」という理由で大きな手戻りが発生することを防ぎます。
また開発で仕様するAIにコンテキストの共有用資料として添付できるというメリットもあります。
Figmaなどを使用した画面遷移表の作成
上記のようにドキュメントとして実装する内容を残すというのは効果的で重要な作業ですが、これだけでは煮詰まらない要素があります。それは実際のビジュアルデザインやゲームのUIデザインです。これを解消するためにFigmaというデザインツールを導入し、画面遷移図を作成しました。
画面遷移図
ノベルゲームを開発していく上でこの画面遷移図というのは非常に役に立ってくれました。元々ウェブ開発でFigmaを使って画面遷移図を作って開発していたのですが、ノベルゲームも画面遷移図を使った開発と非常に親和性が高く、何度も画面の遷移先やボタンの機能の確認として使わせていただきました。PMと話しながら「このボタンを押せばどこに飛ぶのか」みたいな話をしてすり合わせながら画面の設計をしました。画面のラフを描いてくれたPMには感謝です。
フローチャート
画面遷移図と一緒にFigmaでフローチャートを作成しました。
大学の授業でUMLを使った開発手法を学んでいたので実際に使ってみようとユーザーの進捗によってどうゲームが進行していくかの図も作りました。これはあってもなくてもいいという所感ですが、あるとユーザーがどういった流れでゲームを進行するのかの確認になっていいと思います。
Unityに依存しないツールの導入
スプシ
シナリオ班が執筆したシナリオをどうやってコード班が触ってるUnityに入れようか考えた際にスプレッドシートを使って、csvファイルとして書き出すことでUnityにセリフを挿入できるようにしました。Unity側でcsvファイルのインポートツールを自前で作成しシナリオを入れらるようにしています。素材班⇨Unityの橋渡しとして外部ツールを柔軟に使ってデータの受け渡しをするのは重要な課題だと感じました。
ちなみにUnity側ではノベルゲームを開発するのに特化した便利なライブラリたちがあるみたいですが、大抵は有料なので今回のプロジェクトでは無料のものだけを導入しています。
Notionなどタスク管理ツールを導入
開発メンバーの方がNotionを進捗管理用のツールとして導入してくれました。進捗管理に留まらず画面遷移表や要件定義書などの外部ツールのアクセスの起点として機能しているので、そういった面でも便利だと思いました。今回はたまたまNotionでしたがそういったアクセスの中心となるツールは必要なのかも知れません。
コミュニケーション
PMが決めたルールとして月一でディスコード上に集まってミーティングを行うのですがこれのおかげで各班の進捗状況が共有されて非常に有意義だと思いました。そしてコード班は基本的にGithub上で作業してPRやレビューなどのやり取りをするので如何せん私でも進捗が分かりにくいかなと感じてる節があります。そのため、ミーティングで作業内容をなるべく話す努力をしています。また現状の進捗を共有をするために積極的に開発画面の共有を行っています。
またGithubとDiscordのWebhookを連携させることができるので、GithubのPRやissueの報告をする手間が省けました。
まとめ
エンジニアとしてゲーム開発に携わる際に注意すべきポイントは、コードを実装するだけがゲーム開発ではないというところなのかもしれません。異なる専門性を持つ人たちがゲームを作るとき、どうすれば「同じゲーム」を見ながら開発できるのかを考えることが重要だと感じました。
技術だけではゲームは完成せず、創作だけでもゲームは完成しない。