前回は個人的に考えているゲームジャムのコツを書きました。
今回は実際のUE4ゲームジャムではどうなったかを書き記します。


がっこうもやし
 
togetter 【全部入り】2015年10月11,12日【関西】 UE4 GameJam #KansaiUE4Jam #ue4study



はじめに

今回はリーダーになるのを避けました。
なんだかんだでやることになってしまう企画も全力で避けました。

別にやりたくないわけではなく、(寧ろどっちかというとやりたいくらいだったんですが)
学生さんがメインということで、学生さんにやるよう猛烈にプッシュしました。
リーダーをやる苦労を思い知ってほs
リーダーは非常に得られる経験値が大きいからです。
この恩恵を毎回毎回私だけが独占するのは申し訳ないからです。

例え、将来的にリーダー的ポジションに立つことがなかったとしても、リーダーをやってみることで、リーダー側の視点でものを見られるようになります。
それはリーダーの下で立ち回る上で圧倒的に有利に働きます。
「会社で致命的な失敗をするより、ゲームジャムのその場限りの人間関係で失敗を経験しておいた方がいいよ! リーダーの器じゃないなら猶更経験しておいた方がいいよ! 勿体ないよ!」
あと、ゲスい話であまり言いたくはなかったのですが、面接の話のネタにも使えます。
必ず何かしらの失敗はするので、その経験と反省は話のネタとしては最高で…


的な話をして、散々リーダーを勧めたのですが、皆さんシャイで結果的には学生さんのリーダーは1人だったと思います3人だったそうです。

CRMTyJ3UAAACKfR
でも、ほぼ全員がリーダー初経験だそうで、悪くないチーム分けになったと思います。
UE4に詳しいメンバーがだいたい均等になるように、主催者のalweiさんの方で分けていただきました。

↑の写真でいうと◎のリーダーがそれほどUE4自体に詳しいわけではなく(開発経験は豊富)、それぞれ2,3番目に書かれたひとがUE4にそれなりに詳しいひととしてサポートする構成になっています。4番目以降は希望やノリで適当に割り振っていきました。

1.チームメンバの戦力把握、コミュニケーション

ゲームジャム経験豊富な自分が7つのコツを大雑把に解説、
リーダーや皆と話し合って全員の経験をヒアリングして割り振り。

2.テンションを上げる

他所チームはよくわかりませんが、我がDチームに限って言えば、リーダーが気さくでいいひとだったので、ほどよく温まりました。
どこのチームもいい感じに温まっているように見えました。
お通夜状態にできるのはこなべだk

ゲームの仕様を決める

暇厨氏「炎で色んなものを燃やしたい」
こなべ「ナカシス姉妹で火を噴く側と消火する側で対戦ゲームはどうか」
こなべ「対戦ゲームだとAI作る必要ないし、傍目にも盛り上がってテンション上がる」

…なんやかんやで対戦案はなしに(うろ覚え)
…っていうか今回こそは企画はやらないと決めていたので、他のメンバの意見を優先

誰か「ひとを燃やすと問題だからゾンビにしよう」
誰か「舞台はじゃあ学校にしよう」
誰か「タイトルはどうしようか…早目に決めとかないと」
こなべ「がっこうもやし」
皆「それだ!!!!!」

たぶんこんな感じで比較的すぐ決まった気がします(違うかも)。
少なくとも昼食前には決まっていた筈。

大雑把に決まった仕様
  • ナカシス姉が学校で火を噴いて(火炎放射器?)ゾンビを倒す
  • 最初は真っ暗。火を噴くことで明かり代わりに
  • 火を噴くと有利だけど噴きすぎると火事によって自分も死ぬジレンマ(結局未実装)
  • ゴールとなる車(新築マンション風光で場所を明示)まで到達するとゲームクリア
  • 余裕があれば、車でゾンビを轢いて回りたい(結局未実装)

3.責務を明確にする 

リーダーKoya氏:GUI、BGM作成
栗坂こなべ:学校ステージアセット作成、諸々の配置
ANCK氏:レベルデザイン(アナログノート)、火炎放射機モデル作成
Tonkotsu氏:ゾンビ(アセット購入)モーションとAI、UI実装
Tatsumi氏:プレイヤールック(ナカシス姉の3Dインポート、モーション)
暇厨氏:メインシステム、プレイヤーロジック(火炎放射、可燃物の燃焼)、マージ作業

基本的には互いの作業には不可侵です。
必要最低限のインターフェイスだけを互いに決めます。
同じものを複数人同時に編集して衝突…っという面倒で効率の悪い作業は避けます。

4.バージョン管理を諦める
 
特に異論も出なかったので、各々が作ったBPやmapファイルを「エクスポート」や「移行」でメインシステム制作者の暇厨氏にUSBメモリで渡すことに。

5.超疎結合、誰が死んでも大丈夫なようにする
6.神クラス、神レベルの存在を否定する
 
プレイヤークラスが最も重くなるので、どう分散するか悩みましたが、
今回は、プレイヤールックとプレイヤーロジックで完全に分離しました。
3Dモデルやスケルタルメッシュをまともに扱った経験があるメンバがひとりも居なかったので、
ナカシス姉をインポートするだけでも大仕事になる…っと踏んだのもあります。

私が担当する学校レベルの作成は、ゲームロジックは一切なしです。

level_BP
レベルブループリント(これで全部)

これは作業量の負担というよりも、ゲームロジックがレベル(UE4ならレベルブループリント)に依存してしまうと、密結合になって、非常にメンテナンス性が下がるからです。

極本の242ページにも似た話がありますが、トリガーの類もレベルブループリントではなく、アクター側に付けた方がメンテナンス性が上がります。

BP_car_Goal
ゲームクリアのゴールとなる車のブループリント

BP_player
プレイヤーのBP はTPSテンプレートに元からあるThirdPersonCharacterのメッシュをナカシス姉に変えて、攻撃部分を追加。弾(炎)をスポーンさせるだけ。

BP_Bullet
弾(炎)はEnemyタグを持っている相手とヒットしたらApply Damageを呼び出し

BP_zombi_AI
ゾンビは イベントAny Damageで死亡処理を実行

BP_zombi
ゾンビはAI用にふたつ四角いコリジョンを持ち、それぞれのヒットにより追跡と停止
詳しくはゾンビ担当の【関西】 UE4 GameJam に参加してきました!


以上のように、なるべく各パーツが最低限度の依存度で疎結合になるようにしています。

これで仮に
プレイヤールックが死亡→最悪、火を噴く箱( or グレイマン)が学校で暴れるゲームに
プレイヤーロジックが死亡→最悪、ナカシス姉が学校のゾンビから逃げるだけのゲームに
学校レベルが死亡→最悪、ナカシス姉が謎空間でゾンビを燃やしまくるゲームに
ゾンビが死亡→最悪、ナカシス姉が学校で火を噴くだけのゲームに

っとどの担当パートが死んでも大丈夫な盤石の体制です。

7.早めの統合テスト

早めのテスト…っをやる予定でしたが、予想外に私の学校レベルが遅れました。
最低限歩き回れるだけの学校をでっち上げるのすら難儀したからです。
特に階段回りのパーツ化に難儀しました(後述)。

あと、ゾンビ担当の環境ではちゃんと死ぬ筈のゾンビが、暇厨氏側に持っていくと幾ら燃やしても死なない…っという不具合に苦しみました。

ただ、上記トラブルは十分予想の範囲内であり、寧ろ殆どトラブルらしいトラブルが起こっていない部類です。

全体としては割と余裕があった方で、成功の部類だと思います。



次回、は自分が担当した学校レベル作成において躓いたところ、工夫したところを中心に書く予定です。