参加してきました。
作ったのものはこれです。

togetter 【全部入り】2015年10月11,12日【関西】 UE4 GameJam #KansaiUE4Jam #ue4study

ボク自身は既にGGJを3回(毎回なんだかんだでリーダー)
Unity系のゲームジャムを何回か(ほぼ毎回なんだかんだでリーダー or 企画)
Oculus系のゲームジャムを2回くらい(イルカや金髪を持ち込んだり)
 
で、なんだかんだでトータル10回以上は参加している気がします。

(※リーダー経験がやたら多いですが、別にリーダーや企画の資質があるとかではなく、誰もやりたがらず一向に決まらないのが嫌で申し出ることが多いだけです) 

これだけ参加していれば、 どんなヘタレでもそれなりに知見が貯まるので、
個人的に有効だと思うゲームジャムのコツというか攻略法を記したいと思います。 

【ゲームジャムの個人的コツ】
  1. チームメンバの戦力把握、コミュニケーション
  2. テンションを上げる
  3. 責務を明確にする
  4. バージョン管理を諦める(おそらく最も異論あり)
  5. 超疎結合、誰が死んでも大丈夫なようにする
  6. 神クラス、神レベルの存在を否定する
  7. 早めの統合テスト
 
1~2と3~7がおおむね同じなので、 大きく分けるとふたつです。
順に解説していきます。

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

「○○どのくらいできる?」
っと聞くと殆どのひとは
「全然できません」
っ謙遜しまくって戦力が把握できません。
具体的なゲームジャム参加経験や作ったことがあるもの、使ったことがある機能を聞くと精度が上がります。

2.テンションを上げる

これ、大事です。
経験上、初めての参加者は勝手がわからず借りてきた猫状態になりがちです。
何か好きなゲームや好きなうさぎの種類、好きな筋トレ方法でも聞いて会話を弾ませましょう。
ファーストコンタクトに失敗すると、他所チームが常時爆笑を提供する中、お通夜のように静かになります。

やりたい企画がぶつかり合うくらいで調度いいと思うんですが、経験上中々そこまでのテンションにならず(リーダーのキャラに依る)、一向に作りたいゲームが出なくて時間だけがどんどん減る…っという状態になりがちです。
しっかりテンションを上げていきましょう。
折角コミュニケーションの為に好きなゲームを熱く語ってくれているのに、ゲームジャムの成功で頭がフルになって淡白な反応を返していたら超絶不興を買って後々まで響く…などという失敗を皆さんはしないでください。

3.責務を明確にする 

戦力を把握し、誰が何をするか明確にします。
基本的にヒアリングを元になるべく調査不要で出来る慣れた作業を担当して貰いますが、やりたい作業があるひとが居ればテンションや意欲を優先させます。
後述しますが、なるべく他の作業者との依存度下げて疎結合にします。

4.バージョン管理を諦める
 
恐らく異論のあるひとが多いと思います。
ですが、全員がバージョン管理に精通しているとか、サーバーごと持ち込むようなバージョン管理エキスパートが居るとかじゃない限り、自分は割に合わないので諦めることにしています。
理由は幾つかあります。 
  • メンバに教える時間が勿体ない 
  • 衝突等トラブったときの解決時間が勿体ない
  • ネットは基本的に繋がらない(数十ギガ単位のエンジンやサンプルを落としていたり混雑)
  • そもそも複雑なマージ作業は極力避けるべき
GGJのように3日以上の長丁場ならちょっと悩みますが、1,2日程度ならやりたくないです。
かなりバージョン管理に詳しくて、事前資料を作った方がメンバに居たにも関わらず、予想外のトラブルで半日以上潰れた経験をしたのもあって、個人的にあまり気が進みません。 
やるにしても各人がdropbox上に軽い作業データを入れて、ネットがもし繋がればラッキーくらいでいいと思います。 
USB手渡しが1番確実です。 
後述しますが、そもそも複数人で同じものを編集することは極力避けるべきです。

 5.超疎結合、誰が死んでも大丈夫なようにする

責務を明確にする…の話と重複しますが、誰が死んでも大丈夫な体制にします。
マシンが突然不調になったり、人間が体調不良になったり、参加不可能になって離脱したり、ゲームジャムでは何が起こるかわかりません(ゲームジャム以外でもですが)。

究極的な理想としては、
「各人が作ったパーツを人数分ぶち込めば、それぞれがどの作りかけのバージョンでも問題なく動く、ひとつくらい欠けていても問題なく動く」
…っという状態です。
誰かのパーツと誰かのパーツの相互依存度が高いと、作業の手待ちのムダや合わせたときのトラブル率が跳ね上がります。
必要最低限のインターフェイスで結合しましょう。

例えば、「敵キャラ」は「プレイヤー」が作りかけの箱状態だったとしても、Playerタグを探して追いかける、攻撃する、プレイヤーから敵、アイテムへの作用も同様に互いがどんな作りかけの状態でも動くようにする。
手待ち作業を相互に作らず、必要最低限のインターフェイスと依存度にしておきます。

6.神クラス、神レベルの存在を否定する
 
プレイヤーのクラスが最も重い「神クラス」になりがちです。 
どうしてもゲームロジックが集中しやすいからです。
「プレイヤークラスの責務をどれだけ綺麗に分散できるかで成否が決まる」
と言っても過言ではありません。 
(うちのチームでは取り合えず、ナカシス3Dモデルの見た目やモーション担当と火炎を放射して敵や可燃物を燃やすゲームロジック担当を完全に分離しました)

またレベル(Unityでいえばシーン)には極力ゲームロジックを書かないようにすることも重要です。
(レベルにゲームロジックをガリガリ書いてしまうのを自分は「神レベル」と呼んでいます)
この神レベルを作ってしまうと、ただでさえ時間の食う配置作業を行う人とゲームロジックを書く人が同じになってしまい、作業として重くなリ過ぎてしまいます。
また、作業が重くなるからといって同じレベルを複数人で編集すると、マージ作業のトラブルで地獄を見ます。
仮に何のトラブルも起こらなかったとしても、互いの作業効率が悪くなります。

それにレベル(UE4だとレベルブループリント)にゲームのロジックを書いてしまうと、他の担当パーツと密結合になって依存度が上がり、非常に作業効率が悪くなります。

7.早めの統合テスト

各人が作った仮パーツを早めに合わせて、問題なく連携して動くことを確かめておきます。
箱のままの敵とかプレイヤーとかレベルとかクオリティは問いません。
早めに統合テストをして、データの受け渡しやインポート、マージによる上書き等のトラブルが起こらないか確認し、連携動作ができることを確認したうえで、あとはブラッシュアップ作業にしたいです。
終了直前になって初めて統合作業を行うと、たいてい何らかのトラブルが起きて失敗、発表時にはまともにゲームが動かない…っという事態になりがちです。


次回は、UE4ゲームジャムでの実際について語ります