ゲームジャムゆるふわ勢のゲーム作りたいマンがGGJ2015で死んだ話
Global Game Jam 2015
世界各地で一斉にゲームを作り始め、2日後には完成させなければいけないというデスマーチなイベントが開催されました。それがGlobal Gam Jamです。
僕が参加したのは石川県のJAIST会場、一般参加でした。
ちなみに記事を書くまで期間が空いてしまったので内容は曖昧です。
チームAlive-march
チーム分けはハイライト法で行われました。
そして結成されたチーム「Alive-march」！
「なんとかしてデスマーチを回避する」というヘッドラインアイデアの元に結成。
メンバーは5人全員プログラマ(学生)で他のことに挑戦したいorちょっとだけ出来る人が少しと言った感じでした。
僕はゴリゴリとコードを書いてました。ちょっとだけマネジメントもしました。
開発の話(環境編)
JAIST会場では事前にUnityインストールしておいてね、とアナウンスもあったので初めからみんなUnityで開発する気マンマンのようでした。
集まったメンバーではUnityの他にUE4なんかも候補に上がってました。
最終的に僕達のチームが採用していたツールはこんな感じ
- 開発：Unity4.6
- プロジェクト共有：Slack
- ゲームパラメータ作成：Excel
- 3Dモデル作成：(忘れた)
開発にUnityを使うのはいいのですが、プロジェクト共有にSlack使ったのは失敗でした。
というのは、統合したプロジェクトのunitypackageを受け取る側は毎回、Assetフォルダの関係のあるファイルを削除していたからです。
各々の成果物をSlackでunitypackageとして上げて1人が責任を持って統合するスタイルだったのですが、統合されたファイルをいまいち反映出来ない現象(よく考えれば自然)があったので上の対処法を取りました。
今思えばなかなかクレイジーでした。
また、ゲームのデータを予めいくつか用意してそれを読み込む方式となったのでその辺だけExcel使いました。
神クラス（笑）
最初の会議でゲームの内容、クリア条件、ゲームオーバー条件などを話し合って必要となるコンポーネントを整理しました。
全員プログラマだったのでここはスムーズでした。
関連ある機能で作業を分担し、僕は主にゲームの進行に関連している機能を書きました。
ゲーム管理体と言えばシーン遷移、あとはデザイナーがゲーム全体のバランスを調整するパラメータなんかを調整できるように持つものだと考えています。
オブジェクト指向的にはシーン遷移は切り分けて設計するものかもしれません。
とにかく、当初はシーン遷移を行い、いくつかのパラメータを保持するだけのはずでした。
しかし最終的にはいわゆる神クラスとなってしまいました。
やっていることを書き出してみます。
- シーン遷移
- メインシーンの進行
- UI管理体に仕事を割り振り
- ゴミ処理(シーンに要らないオブジェクトを破棄)
多すぎィ！
なぜこうなってしまったのか
なぜこんなことになったのかは明らかで、
- ゲーム全体を管理する人と、メインシーンを管理する人を混同した
- 終盤、「もう全部あいつ一人でいいんじゃないかな」になった
からです。
1.に関してですが、製作を始めてまず取りかかったのはメインシーンの流れを作ることです。
これは当然です、アルファ版発表もありますし。
メインシーンの流れは誰が作るか、ゲーム管理体(GameManager)だろうと考えてゴリゴリと書きました。
このシーンが完成してくると次に他のシーンを作るか、となります。
そして他のシーンをメンバーにぶつ切りで作ってもらい、統合する人(僕)が受け取り、繋ぎ合わせるわけです。
じゃあシーンを繋ぐ人は誰だろう、そりゃGameManagerだろうとなりGameManagerにはシーンを繋ぐ責務が追加されました。
こうして、本来切り分けられるはずの責務を1人で全うする存在が出来たことにより、GameManagerはその便利さから、あらゆるオブジェクトと繋がりました。
最初の設計を振り返ると分かるのですが、最初にゴリゴリと書いたメインシーンの管理はもともとGameManagerの仕事では無かったんですね。
神クラス作り始めたから多分これはデスマーチだな！ #ggj_jaist
— くりあ (@clear10_foo) 2015, 1月 242.に関して。メインシーンの管理と一言で言えば簡単ですが実際は当然とても処理が多いのです。
さらに保持するデータもたくさんあります。
そうすると、メンバーの間で
「この値って誰に聞けば分かるの？」「GameManager」
「指示されたら仕事するようにしたけど誰が指示してくれるの？」「GameManager」
の会話が広げられ、
となったわけです。
全知全能の神クラスをつくって、創造主に仕事をポイするチームAlive-march #ggj_jaist
— きんぱく＠卒研瀕死マン (@gold_leaf_9541) 2015, 1月 25GGJで神クラス作ってたマンだけど、GUIに必要な情報をパッケージにして渡したりゲーム管理情報を意地でもpublicにしなかったのは良かったと言える。ただ他のオブジェクトが神が指示しないと仕事しないし低級オブジェクトを直接殺すまでしてたのはまさに神クラス(笑)だった。
— くりあ (@clear10_foo) 2015, 1月 26結果、終盤はチームメンバーからメソッド追加とメソッド呼び出しの申請で度重なるアップデートに追われました。
さらに統合作業&バグフィックスもあったので、死ぬほど忙しかったです。
どうすればよかったのか
対策はいくらでも考えられると思います。
例えば、コンポーネントA→GameManager→コンポーネントBとなっている部分をコンポーネントA→コンポーネントB(末端のことは末端間で解決)としたり、別のオブジェクトの仕事をGameManagerが呼び出すのではなく、仕事をしていいかGameManegerに聞いて自分で仕事をするようにしたりだとか。
結局言えるのは、
- 切り分けられることは切り分ける
- 能動的に仕事をさせる
ということでしょう。よく言われることですが今回、痛いほど実感しました。
そうは言ってもやはり
しかしゲームジャムです。
製作期間が極端に短いのでそんなに丁寧に設計している余裕もないでしょう。
妥協点を決めてある程度妥協してでもゲームをより良くするのが大切です。
今回のことはもちろん反省していますが、これもゲームジャムならではの経験だと思います（神クラスはさすがに妥協しすぎ）。
昔誰かが言っていたのですが、
「コードは綺麗に書け、最後に汚してもいいように」
が今回の教訓となりました。
まとめ
ゲームジャムは超短期間でチーム開発が経験することが出来るめったにない機会だと考えます。
良い経験になるし、なんだかんだ楽しいので一度は参加してみると思います。
ただし進捗によっては高確率でデスマーチが発生します。回避したい人は夜間開放されない会場で参加するのがいいでしょう。
ちなみに今回作ったゲームはGGJのサイトにもありますが、
で遊ぶことが出来ます。バグだらけですが、お楽しみください。
他のチームの作品も2日間とは思えない作品なので遊んでみるといいかもしれません。
チームメンバーも今回のレポート記事を書いているようなので、そちらもぜひ。
Global Game Jam @JAISTに行ってきました - nyaruratoものづくり記録
【速報版】Global Game Jam 石川サテライトへ行ってきた - akira-kashiの日記
