ハッカソンで大失敗した話を晒す
2月下旬に某所で開かれた某ハッカソンに参加したのですが、そこでハッカソンで考えられる全ての失敗を犯したと思うので、今後の自分の戒めとして記録に残しておこうと思います。
開発しようと思ったコンテンツ
VRゲームってプレイヤーだけしか楽しめないじゃないか...
そんな思いからこんなコンテンツを考えつきました。
センサを装備したプレイヤーが何かしらのジェスチャーをすることでVR空間内にジェスチャーに対応する変化が現れる...みたいな。例えば三人のプレイヤーがいるとすると...
- プレイヤー1の前にゴブリンがあらわれた!
- ゴブリンの色が赤(炎属性)だ!
- プレイヤー1には炎属性のゴブリンに対応する武器が必要だ!
- プレイヤー1がプレイヤー2とプレイヤー3に武器(水の剣)を要請
- センサを持ったプレイヤー2とプレイヤー3はそれぞれ剣を生成するジェスチャ、水属性を付与するジェスチャを実行
- プレイヤー1の上空から水属性が付与された剣が降ってくる
- プレイヤー1が剣を手にとってゴブリンを倒す!
というような流れを実装したいと考えていました。
チームメンバー
私は敵周りおよびUnityとマイコンのパイプ部分を担当しました。
技術的仕様
具体的なコンテンツ仕様
- 武器は剣、魔法の杖、銃の3種類(1回きりの使い捨て)
- 敵はスライム、オーク(白板ではゴブリン)、鳥系の3種類
- 属性は炎、草、水の3種類(●ケモンとは関係ありません...多分)
- スライムなら魔法の杖、オークなら剣、鳥系なら銃が対象の武器となる
- 武器はプレイヤーの座標の上空に降ってくる
- 敵はそれぞれ特有の移動をする
- 弱点属性だと一撃で倒せるが、弱点属性でない属性がついた武器ではあまりダメージが入らない
- プレイヤーはワープでの移動が可能
ということを実装するつもりでした。(雲行きが怪しい...)
結果
大失敗!
今回のこの企画は私が考えたものでしたので、自動的に私がディレクターとして開発を進めることになっていたのですが、私の失敗のためにチームに多大な迷惑をかけることになってしまいました。結果、ハードウェアの部分は完成してUnityに任意のデータを送るまではできたのですが、コンテンツ部分が完成せず、デモができないという結果なってしまいました。ハッカソン終了後に一人反省会をしまして、何がいけなかったのかをしっかり考えてみたのですが、様々なミスを犯していたことに気づきました。
うまくいかなかった原因
コンテンツ設計
チームオペレーション
問題点や進捗の共有をうまく行えていなかった
一応進捗報告はチームのSlackチャンネルで確認を取っていたのですが、作業をしているうちにその進捗内容が他のメッセージの中に埋もれてしまって出来上がったモデルやアニメーションなどに気が付かなかったなどということがあったりしました。また、メンバーの誰がどんな作業をしているのかが分からなかったということもありました。
他にも、もう一人のUnityプログラマーが、Unityの最新バージョンにてViveコントローラーの入力の取得方法が今までのバージョンと違い苦労しているということに早く気付くことができず、1日目の深夜(1:00)頃にようやくそのことに気付いてバージョンを下げたなんてこともありました。
これについてはTrello等でカンバン管理をして進捗の状況把握や問題点の把握をすると良かったのかなという感じです。
開発
まともに使ったこともないのにクラスの継承を意識したクラス設計をしてしまい、後半で詰まってしまった
クラス設計をおろそかにしてしまい、後半においてゲーム進行のロジック作成時に詰まってしまった
当初は敵の動きの実装を以下のような感じで実装してみようと考えていました。
Slime, Bird, OrcはEnemyBaseを継承しているという形です。
これで敵単体の動作はできたのですが、問題は属性に関わる部分でした。本来ならば自身の属性を表す変数なりプロパティなりをEnemyBase抽象クラスが持っておくべきだったのですが、それの必要性を後半まで気付くことができませんでした。結果、敵を生成する際のロジック、攻撃された武器の属性判定からのダメージ計算ロジックの設計に戸惑ってしまいました。他にも、
GetCompont<EnemyBase>()でちゃんと派生クラスのデータを持ってこれるのかなども分かっていませんでした。このため、敵の生成ロジック記述時に時間を食ってしまいました。作れもしないのに時間ギリギリまで作業をしてしまって結果的にプレゼンに割く時間を完全に無くしてしまった
個人的ハッカソンでやってはいけないことワースト1位。終了10分前くらいで既に完成は無理だろうと断言できるような状態だったのですが、結局開発終了までディスプレイとにらめっこしていました。そのため制作物プレゼンテーションで使うスライドの制作がまともにできませんでした。幸いチームメンバーの一人が作ってくれてはいたのですが、その人は他のハッカソンにも参加しており、そちらが忙しくなってしまったので最終的に中途半端なスライドのままプレゼンをすることになり、コンテンツの企画内容や苦労した点、工夫した点などについて十分に伝えることができませんでした。
土台を作ることよりも小さいところに気を払いすぎてコアの部分となるゲーム進行ロジックをまともに作れなかった
個人的ハッカソンでやってはいけないこと同率ワースト1位。優先順位が狂っていたということですね。1日目の後半で敵の動きの実装をしてる最中にQuaternionで詰まってしまってそこでかなり時間を費やしてしまい、代償としてコアとなるロジックの実装にかける時間を溶かしてしまいました。冷静に考えてみれば、敵の動きの実装なんかよりもゲームマネージャーの実装の方がはるかに重要度は高いことは言うまでもないですよね。
早い段階で妥協点を模索して遊べる段階まで持っていくことが最優先であったはずなのに、最初の仕様に最後までこだわってしまった
これに関しては、最初の段階で実装でかかる時間や重要度の見積もりをしたり、実装する必要があるものを列挙したりするべきだったと思います。そうすればどの作業を優先的に行えばいいか分かり、あまり重要ではない部分で悩んで時間を取られることはなかったと思われます。他にも、早い段階でコンテンツの複雑さを理解でき、仕様変更することを考えることができたのではないかと思います。
まとめ
審査員の一人がハッカソンの講評でこんなことを述べていました。「ハッカソンでのコツは最初にプレゼン用の資料を作り、チームでどんなコンテンツを作るかを最初に共有して、土台を作ることを最優先でやることだ」と。本当にその通りだと実感しました。細々としたところもそれはそれで重要であるとは思いますが、結局一番大事なのは動くものを見せることなんですよね。今回のハッカソンではそのことを痛感しました。
また、ハッカソンで今までやったことがない新要素を取り入れることはいいことだと考えているのですが、それをするなら仕様は単純の方がいいです(特に今回のような短い期間のハッカソンではなおさら)。切羽詰まって開発することもなくなりますし、デモをする時間も多く取れるようになりますからね。何より、心のゆとりが生まれてハッカソンを楽しむことができるようになります。
この失敗を次の機会に大いに生かしていこうと思います。
