高校の卒業制作でゲーム作った

Last updated at 2024-01-25Posted at 2024-01-25

はじめに

今回、高校の卒業制作として、初音ミクが主人公の「GOT SIMULATOR」なるゲームを作成しました！

ゲーム開発を知識0の状態から始めて、約1年間の開発で得た経験や考えを共有できればと思います！

本記事の内容は、名古屋市並びに名古屋市立工業高等学校に非公式で公開しているものです。
本記事に関する問い合わせをこれらの機関へ行う行為は絶対にしないようお願いいたします。

自己紹介

こんにちは。どきみきと申します。名市工¹に所属する3年生の18歳、つよつよプログラマーになることを夢見てプログラムを学んでいるひよこプログラマーです。

合成音声(特にVOCALOID!!)が大好きなので、ボカロ、ボイロ、ボイボとか好きな人と仲良くしたいです。

どんなゲーム?

ここからDLできます

初音ミクが建物を壊したり、敵を倒したり、人にネギを刺したりするアクションオープンワールド(?)なゲームです。

ゲーム制作を始めた動機

ゲームが作りたかったからです。

名市工には3年次に、課題研究という、卒業制作のような自由にモノを作る授業があります。
課題研究には毎年、成果物を後輩に向けて発表する時間があります。
私は、発表で先輩方の作ったゲームを見て、自分もゲームが作りたいと思うようになりました。

どうせならすごいもの作りたいと考え、高クオリティで楽しいゲームを作るとこが目標になりました。
また、初音ミクはかわいいので、初音ミクを追加したいとも考えていました。

そこで、アクションオープンワールド系のゲーム、GOT SIMULATORの作成を決意しました。

開発チーム

このゲームは、私をリーダーとして出来た5人チームで開発していました。

デザイン・UI作成・マップ作成・スクリプト作成に分かれ、作業を分担して行いました。
私はUI作成とスクリプト作成、その他の管理を行いました。

最初は全員ゲーム開発初心者で、プログラム自体も慣れていないメンバーもいました。

使った技術・ソフト等

Unity: ゲームエンジンの一つで、日本語のドキュメントや情報が豊富です。

Feel: Unityのアセットの一つで、コーディングをするうえで便利なツールや、簡単にエフェクトを追加できるようになるツールが使えます。

Figma: デザインを作るためのツールで、複数人での同時編集ができるのが特徴です。

VSCode: 起動が早く、機能面でも申し分ないコードエディターです。拡張機能で化けます

Git/Github: コードのバージョン管理を可能にするツールです。コードの共有もできるので、家で作業するためには必須のツールです。

Github Copilot: コードを自動補完してくれる優秀なAIです。コメントさえしっかりかければ実装を任せることもできます。

Github Actions: Githubでの作業をコーディングで自動化できるツールです。

GameCI: Github Actions上でUnityのビルド・テストができるツールです。

Discord: チャットコミュニケーションが取れるSNSです。GithubのWebhook設定をすればGithubの活動を通知することもできます。

作成スケジュール

ひどく偏ったコミットグラフ

最初期 3～4月 (設計や案出し)

開発の中で1番楽しく、夢を語れるのが最初期段階です。

この時は、チーム内で方向性を合わせるために、上のように紙に書いてたくさん案を出したり、イメージに近いゲームを遊んだりしていました。

また、これまでの開発経験から、とりあえず設計は大事ということは分かっていたので、いろいろなサイトを見て設計方法を学び、とりあえずの設計を作りました。

あとから振り返り、方向性合わせをしたのは後の開発にも良い影響を与えたと思います。
方向性が決まっていることで、ある程度の統一感が生まれますし、新たな機能案が出た際に、追加すべきかどうかの判断基準としても役に立ちます。

設計は失敗でした。なぜなら、自分含め誰も設計を使うことがなかったからです。

これが作った設計なのですが、一番の問題は「何からどう始めたらいいの?」となってしまう点です。
そもそもなぜ設計が必要なのかと言えば

実装の進捗度を確かめる
残っているタスクを管理する
次何をすべきかをはっきりさせる

ことが目的だと思います。

そのため設計書を作る際は、

チームの誰が見ても分かり、実行出来るタスクを書く
全タスクを同じぐらいの時間(今回の開発では2, 3日が良いと思った)で終わるように書く
それぞれのタスクの依存関係をはっきりさせる

ことが大切なのですが、自分の作った設計はタスク分割が足りなく、正しいことを言っているのにも関わらず使われることはありませんでした。

開発経験のない分野の設計をする際は、

新たに見つかったタスクやその依存関係を随時追加
1タスクに時間がかかりすぎる/なにから始めれば良いか分からない場合に、タスクをもっと細かくする

ことで、みんなが使えるより良い設計書ができると思います。

初期 5～6月 (プロトタイプの作成)

毎回、作成から歯車が狂っていきます。

初期はとりあえずプロトタイプを作ろうと話し合い、1か月で簡単なゲームを作ることを目標にしました。

しかし、ゲーム開発どころかチーム開発の経験も乏しい人の集まりが1か月頑張ったところで、私たちが思う「ゲーム」が作れるわけありません。

私たちの予想では、Google Playなどで探せば無限にある、ハイパーカジュアルゲームぐらいの品質のゲームが作れると思っていました。
ですが、実際できたのはガラクタにもならないようなものでした。

この段階での成果は、GithubのPull RequestやIssueを作る環境を布教できたことと、Github Action によるコードテスト・Lintの自動化です。

Pull Request時にLintとTestを回し、レビューを依頼するところまでを自動化することで、エラーの出るコードがmainブランチにマージされることを防ぎました。

また、コードレビューをすることで周りから認められた感が出て、とても気持ちよかったのでコードレビューをしたのはよかったです。

中盤 7～9月 (プレイヤー等の実装)

中盤は、モチベ的にも時間的にも厳しいところです。

中盤の時期は進学や就職、文化祭、夏休みなどが重なり、課題研究の時間を取るのが難しい時期でした。

ここでは、初音ミクのツインテールを伸ばしたり、Tポーズのままですが移動もできるようになりました。
Unityがわかり始め、コンポーネントなどの理解が深まってきた段階です。

また、参考になった記事を共有するなどして技術力の向上を狙った時期でもあります。
しかし、記事の共有だけでは初心者組が置いてきぼりにされ、技術力の格差が広がる結果になりました。

終盤 10～1月 (のこり全て)

焦りはじめて毎日コミット大会です。

UI・mob・アイテム・プレイヤー... 全ての実装をしました。冬休みは毎日1コミット以上する生活をしていました。

素早い更新のため、コードレビューを無くしました。
これは、コードの品質を下げるため、苦渋の決断でした。
結果、自動テスト環境のおかげでビルドの通る環境は保てましたが、バグのあるコードや好ましくない記述が増えてしまいました。
ですが、開発速度は上がったので、コードレビューを無くした効果はあったと思います。

また、過去に書いたゴミコードがバグを吐いたり、著しく処理を食っていたので、泣きながら改修を行いました。
特に序盤に書かれたコードは酷く、何が書いてあるのかさえ分からないようなコードばかりで、丸一日かけて改修を行うこともありました。

開発上でこだわったこと

ポストエフェクト

ゲームの楽しい感を演出するために、Unityでポストエフェクトをつけました。
影や光を編集でコントロールすることで、視覚的にも楽しいゲームにすることができました。

ポストエフェクトなしの画像

ポストエフェクトありの画像

影や明るいところを比較すると、違いがよく分かると思います。
特にポストエフェクトを付けたことで、Unity特有の濃い影が消え、発色もきれいに見せることができました。

良いコードを書く

コーディングの際に気を付けたのが、

誰が読んでも処理が分かるコードを書く
誰でも再利用できるコードを書く
処理速度を意識したコードを書く

ことです。

特に今回は複数人開発ということもあり、全員がコードを理解できる状況が善だと考えました。
そこで、

変数名は保持する内容を端的に表す
難しい処理や低レイヤーを使うような処理は関数にまとめる
処理の流れを明確にする
変数のライフサイクルを短くする

ことを意識することで、読みやすいコードになるよう務めました。
また、UnityにはGetComponentや、Findなどの検索を走らせる重い処理がありますが、それらの使用回数を減らしたり、使わないことを心がけました。

サイズの軽量化

画像の解像度を落としたり、オーディオの品質やビットレートを下げることで、ゲームのサイズを落とすことができました。

特に画像の解像度を落とした効果は凄まじく、もともと約700MBあった実行ファイルが300MBほどになりました。

さらにフォントや圧縮方式も見直すことで、最終的に200MB未満までサイズを抑えることができました！

やっておいてよかったこと

情報共有

GithubのIssueと、Discordを使用し、進捗状況やC#・Unityの便利機能などを共有しあいました。

チーム開発をするうえで情報共有は欠かせないものであり、小さなことでも共有していくことで開発速度がぐんと上がります。
また、チームの団結力も高まるので、情報共有は一石二鳥な行為なのです。

上でも述べたのですが、記事の共有後に、初心者へのフォローアップがあればさらに良くなったと思います。

モチベの保ちあい

Discordの「進捗自慢」チャンネルや、Githubのコードレビュー時に相手の作業をほめあうことで、モチベーションアップを狙いました。

進捗をほめあう行為は相手の作業進度の把握にもつながるので、開発が円滑に進みました。

上図のように、モチベーションを保つことができれば作業スパイラルにはまること間違いなしです！

課金

ゲーム開発初心者が作品をよく見せたいなら、課金すべきです。

私たちはマップに使うための建物や敵などをすべて買いました。その際にお世話になったのがUnity Asset Storeです。ここで公開・販売されているものは特別な一部を除きすべて同じライセンスで配布されているので、素材を使う際もライセンスにおびえる必要はありません。

モデルはPOLYPERFECTさんのものが優秀で、初音ミクのかわいい世界観にあっていたので多用しています。

もしこれを読んでいる後輩がいたら、伝えたいことがあります。
良いゲームを作りたいなら、課金しましょう。他の人が作ったものを使いましょう。
全ての素材を一から作って成功できるのは、会社などの大きな組織か、ゲーム制作に精通した天才チームだけです。
ゲーム制作は一人のものではありません。
芸術の輪を広げましょう。
他の人の作品を使うことに誇りを持ち、作者に感謝しながら使いましょう。
mixamoやsketchfab、Unity Asset Storeはきっと役に立つはずです。

AIの導入

コーディングや問題解決のために、ChatGPTやGoogle Bird、Github Copilotを用いました。

特に役に立ったのがGithub Copilotで、非常に優秀なコード補完が可能になります。

例えば、メッシュの形を変更したい時、書き方を知らなければ、Stack OverflowやQiitaを頼って、どんな機能を使うべきかを調べるところから始まりますが、
Github Copilotならとりあえずやりたいことをコメントに書くだけでコードが生成されます。
あとから関数の意味や動作を調べるだけで良いので、圧倒的にプログラムの速度が早くなります。

Githubの導入

かなり初期の方からGit/Githubは導入していました。

もともとgitは使ったことがあったのですが、複数人開発で使うのが初めてだったのと、メンバーにgitを教えなければいけないのに苦労しました。

メンバーに教えるために、今回はDiscordを使用しました。
とりあえずDiscordを見ながらgitをいじれば使える程度の知識を書いておきました。

上のように、Discordで使い方を共有し、コンフリクトなどのイレギュラーが起きたときのみ対応という形で運用しました。

GithubのPRやIssueを使うことで、使い方や運用方法を理解することができました。
ブランチの運用方法であったり、より良いコードレビューの方法も身に付きました。
そのおかげで、OSSへのコントリビュート方法も自然に身に付きました。

Githubを使うことで、学校でも家でも作業ができるようになったのも大きいですが、一番恩恵を受けたのがコミットの巻き戻しです。
Unityを使っていると、設定の変更やシーンの削除など、Ctrl + Zではどうにもならない変更を間違えて行ってしまうことがあります。その変更をGitを使うことで巻き戻せるのは本当に強く、頼りになりました。

人生もGitで管理したいものです。

Github Actionsの使用

Github ActionsもGithubと同時に導入されました。

やったことは、

PR時にビルドが通るかどうかのテスト
PR時にLinterを通す
PRチェック終了時、Discordに通知
ユーザー指示時にビルド
... などなど

いろいろな処理を自動化しました。

Githubでは、途中からレビューをやめたのですが、Github Actionsによるビルドチェックによって最低限の安心感を得ることができました。

また、Lintを通すようにしたので、mainブランチには改行やインデントのきれいなコードで構成されたものだけになるのでよかったです。

これやってればもっと良くなった

初心者教育に力を入れる

プログラム初心者に、つよつよプログラマは付きっきりでプログラムを教えるべきだと思いました。

具体的には、初心者がプログラムをし、つよつよは隣でアドバイスを飛ばす「ペアプログラミング」などをすべきです。

なぜなら、技術格差が大きいままプロジェクトの終盤を迎えると、つよつよは人手が足りずに困り、初心者は周りが頑張っているのにやれることがなく、肯定感が下がることにもつながるからです。

序盤はすべての時間を使う勢いで教育に力をいれてもいいと思います。

Issueの依存関係をはっきりさせる

今、作業を行えるIssueが分かるようにしましょう。

Issueの一部は、前提となるIssueを解決しなければ作業を始めることのできないものがあります。
例えば、プレイヤーの歩行を実装するにはプレイヤーを実装していなければできませんよね。
そのようなIssueの依存関係をはっきりさせれば、どのIssueから手を付ければよいのかが一目瞭然です。
いろいろなIssueから依存されているものを解決できれば、作業に着手できるIssueも増えます。

逆に依存関係がはっきりしていないと、毎回どのIssueを解決すべきか、考えなければならなくなります。