Global Game Jam 2017に参加してきた話

はじめに

ゲーム開発をおこなうハッカソンとして世界最大の規模を誇る「Global Game Jam 2017」にプランナーとして参加してきました。

「Global Game Jam」への参加は初めてだったので、参加して感じたことと、実際に書いた仕様書などのドキュメントを公開します。

基本的には自分の考えたこと・やったことの振り返りですが、今後ゲームジャムに参加しようと思う方の参考になれば幸いです。

はじめに書いておきますが、糞長いです。

また、関連として、同じチームで一緒にゲームを作ったとりすーぷさんのQiita記事が公開されているので、そちらも合わせて読むとより面白く読めると思います。この記事のなかでも適宜参照しています。

イベントの概要

イベント名 Global Game Jam 2017
日程 2017/1/20(金)18:00 〜 2017/1/22(日)19:00
参加会場 東京 茅場町会場
イベントURL Global Game Jam Japan
お題 WAVE

作成したゲームについて

お題の「WAVE」を衝撃波と解釈し、マッチョがヒップドロップした衝撃波で敵を場外に吹き飛ばすゲームを作成しました。

正直何を言っているかわからないと思うので、サマリーと動画を用意しました。

今回完成したゲームは以下です。

タイトル Muscle Drop
ジャンル 3Dアクション
プレイ人数 2〜4人
お題の解釈 衝撃波
実行ファイル(Winのみ) URL
プレイ動画
Muscle Drop(GGJ2017)

なんとなくどういうゲームか察していただけたかと思います。

最も表現したかったのはヒップドロップで敵をふっ飛ばすときの爽快感です。

モーションが間に合わず女の子っぽい走り方になっていたり(ユニティちゃんSDモデルのデータを借用)、もはやヒップドロップではない点を除けば割りとコンセプトに忠実にできていると思います。

補足

「お題」について、「Global Game Jam」ではイベントごとに毎回異なる「お題」が提示され、ジャムで作成するゲームの内容は必ずその「お題」に基づいて制作する必要があります。

ただし、この「お題」は割りと広い解釈が認められるので、こじつけ的なものもOKなようです。

(というより、是非のジャッジは当事者に委ねられるため、実質なんでもアリっぽいです)


メンバー

  • プログラマ 4名
  • プランナー 2名
  • グラフィッカー 1名

ジャムを終えて振り返ってみると、割りとバランスの良い構成だったように感じました。

主な職種としてはサウンドがいませんでしたが、Asset Storeのパワーでなんとかなりました。Asset Storeは偉大。


担当した箇所

担当した箇所は以下の通りです。抜けや忘れてしまっている箇所があるかもしれません。

共同の記載はもうひとりのプランナーの方と共同で全体をまとめた部分、それ以外は担当した部分です。

  1. ゲーム内容の企画
  2. ギミック案出し(共同)
  3. ギミック仕様作成(共同)
  4. レイアウト仕様作成(バトル、リザルト)
  5. サウンド周り(BGM,SE選定)
  6. パラメータ調整(キャラ挙動)
  7. レベルデザイン(共同)

見ての通り、普段のゲーム開発で行っているような作業を一通り行っていることがわかります。

その意味で、ゲームジャムであってもプランナーに求められる能力は基本的に変わらないようでした。

※スケジュールについてはプログラマーの方にまとめていただきました。ありがたや。


仕様

普段のゲーム開発とは違い、ゲームジャムではどの仕様を詳細化してどの部分をざっくりとしたものにするかの判断が求められるように感じました。

そのため、この項では主にどう考えたか、どうやって判断が行われたかを書きます。

ゲームのメインロジック(キャラの挙動・ふっ飛ばしの部分)

ゲームの核となるメインロジックについては、Unityの物理エンジンを使うことが企画段階で決まっていました。

物理エンジンを採用した理由
  • 細かい部分の挙動まで指定・実装していた場合、時間が足りない
  • 物理エンジンの予想しにくい挙動自体である程度のウケが狙える

そのため、企画発表が終わって制作に移るタイミングでどのようなパラメータを必要とするかの認識をプログラマとすりあわせた後はほとんど指定することはなく、終盤(確か二日目の夜)に実装されたキャラクターを動かしながら調整した程度でした。

ただし、物理エンジンで理想の挙動を表現することが思っていたより難しく、プレイヤーの挙動についてはまだまだブラッシュアップの余地のある出来になってしまいました。

現時点での私のスキルではトレードオフにならざるを得ない部分でしたが、慣れてしまえば48時間でももうちょっとマシな出来になりそうではあります。

ギミック(衝撃波の伝播、即死トゲ)

企画の段階でステージ上にギミックを置きたいよねという話になっていました。

そこで、企画発表終了後、プログラマーの要請に応えて実装したいギミックのリストを書き出しました。

前述のとりすーぷさんの記事でも言及がありましたが、アイディアを後出しで入れることは現実的に不可能であると伝えられていたため、プランナー二人で結構な時間を割いた覚えがあります。

具体的には、以下の手順で実装したいギミックを決めていきました。

手順

1. 二人でバラバラにギミックを思いつく限り付箋に書き出す

A:即死トゲ、プロテインで強大化、回転ハンマー、ダメージで崩壊する床、衝撃波が伝播するオブジェクト、ダンベルでジャンプ力アップ
B:ツルツルの床、バンパー、ベルトコンベア、衝撃波が伝播するオブジェクト、即死トゲ、ヒップドロップでアイテム出現

1. 二人で書き出したギミックを照らし合わせ、似たアイディアをまとめる

衝撃波が伝播するオブジェクト×2、即死トゲ×2など

1. ギミックの種類でおおまかなカテゴリを作成し、出てきたアイディアをグルーピング

設置オブジェクト系・・・即死トゲ、回転ハンマー、衝撃波が伝播するオブジェクト、ベルトコンベア、ツルツルの床、バンパー
ヒップドロップで起動する系・・・ヒップドロップでアイテム出現
アイテム系・・・プロテイン、ダンベル

1. カテゴリ毎に各アイディアの面白さを検討し、コスパの良いアイディアの順で優先度を設定

下図参照

1. プログラマと相談

(このあと翌朝までに仕様の実装に耐えうるクラス設計が完成されていました。すごい。)

こうすることで、3.の段階でステージ上にどういうギミックが必要かの大枠が定まり、各アイディアの実装優先度の比較対象がカテゴリ内に限定されたため、時間の削減につながりました。

割りと妥当な決め方であったと思います。

この手順で実際に作成されたアイディアとその実装優先度は以下です。

f:id:zeal404:20170127022326j:plain:w200

かなり関係のないアイディアも並んでいますが、アイテム、HD起動(ヒップドロップ起動・・・)、設置型の3列で上から順に優先度の高い順に並んでいます。

ここで決まった案をもとに、二日目の朝にはもうひとりのプランナーの方が詳細仕様のたたき台を書き上げてくれたので、多少の修正をおこなっただけでほぼギミック詳細案が完成しました。

詳細案は以下です。

f:id:zeal404:20170128153359p:plain:w200

実際にゲームに登場した仕様①です。当初は上からヒップドロップで起動する形で考えられていましたが、わかりづらいのでカットされました。

f:id:zeal404:20170128153410p:plain:w200

実際にゲームに登場した仕様②です。ほぼ仕様どおりの内容になっています。後からバリエーション付けを狙って静止していないバージョンも作成しましたが、どちらも非常によく機能したと思います。

f:id:zeal404:20170128153413p:plain:w200

実現に至らなかった設置物の仕様です。優先度を落とした理由としては、モデルが必要になる、吹き飛ぶくらいの速度で回したら意味不明になるのでは、吹っ飛ぶ要因が衝撃波に集約されない、などでした。(たしか)

f:id:zeal404:20170128153417p:plain:w200

これもやりたかったですが実現に至らなかった仕様です。物理エンジンでカオス的な面白さを表現するにあたり、ステージ上の内容が動的に変化するのはそのままプレイバリューの増加に直結するので、拡張するとすれば是非入れたい要素です。

f:id:zeal404:20170128153420p:plain:w200

アイテムの仕様です。アイテムの実装作業は最終日まで進められていたのですが、難しいというところでステージギミックの作業に集中する変更が行われました。最終的な完成物を見ても、この判断で救われた面が大きかったように感じます。

f:id:zeal404:20170128153424p:plain:w200

f:id:zeal404:20170128153427p:plain:w200

f:id:zeal404:20170128153433p:plain:w200

その他、実装に至らなかった仕様たち


レイアウト

仕様とギミックが決まった後に、必要な画面レイアウトを洗い出しました。

画面数自体少なかったので、洗い出し自体は非常に簡単でした。

あとはシーンをいくつに切るのかをプログラマーと決めた上で各画面の担当を割り振り、ざっくりレイアウト仕様を書いた後にサイドプログラマーと実装のすりあわせを行ってFIXしました。

ここで作成した仕様書は以下です。

f:id:zeal404:20170128153603p:plain:w200

シーンと各画面の結びつきをまとめています。汚くて自分でも嫌になるレベルw

f:id:zeal404:20170128153616p:plain:w200

バトル中のレイアウトです。よくある仕様の集まりなので、特に気をつけることもなかったです。状態異常については実装を見越して書いていましたが、我ながら意味不明ですw

f:id:zeal404:20170128153621p:plain:w200

リザルト画面のレイアウトです。スマブラの丸パクリとも言います。この工数規模のなかでは割りと複雑な挙動を指定しましたが、バッチリ仕様書通りの実装で素晴らしいと感じました。レイアウト仕様などと言いながら、落とした/落とされたの判定という重要な仕様を付け足しているのがキモです。


まとめ

最後に、良かった点と反省して次回に活かしたい点をあげておきます。

良かった点
  • 楽しくゲームを作ることができた点
  • 多くの人に楽しんでもらうことができた、楽しんでいるところを実際に見ることができた点
  • 日常の業務と離れた作業で、自分のスキルに改めて気付けた点(工数感とか全体の洗い出しとか仕様書とか)
  • 今までつながりのなかった人と一緒にゲームを作ったりお酒を飲んだりして刺激になった点
反省点
  • ところどころプランナーの手が余ってしまうタイミングがあった

次に何をすべきか、何が足りていないかをイメージしておかないといけなかったのが、目の前の作業で手一杯になってしまったことで疎かになってしまいました。

それにより、とりあえず作業は終わったけど次は何をすればいいんだろう、という状況が発生してしまいました。

次回以降はざっくりでも全体のスケジュールを区切った上で作業をすすめることで、今何が足りていないかを意識しながら作業することで改善していきたいなと思いました。

  • リソースの指定漏れが多かった

終盤になってからSEの指定が大量に漏れていることが発覚しました。

ギミックやレイアウトの仕様を書いた段階で想定すべきだったので、次回以降はざっくり仕様にサウンドの項目を加えたいと思います。

全体として、今回「Global Game Jam 2017」に参加して本当によかったと感じています。

来年以降もずっと参加し続けていこうと思えるほど充実したイベントでした。