1.
GameJamCanvas
2014年2月10日
国立情報学研究所 GRACEセンター/先端ICTセンター
長久勝
mailto : nagaku@nii.ac.jp
Twitter : @mnagaku
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

2.
2
Jam慣れした人がいない場合、
ガチ仕様GameJamの初動で観察される事象
 リードできる人がいない
 年長者やプロでも、Jamチームのリードは未体験
 声の大きい人にチームでついて行こうとする
 日本人特有の変な義務感に流されていないか？
 各自が何をどこまで出来るのかが不明
 「Unity出来ます」どのレベルで？
 重み付けなしの公約数で技術を採用するのは最適ではない
 合意が徹底されない
 「え？それやるの？」
 「あ、そっちの意味？」
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

3.
3
解決せねば
 リードできる人がいない
 個人の資質に過度に依存せず回すためのワークフローが
あれば良いのでは？
 各自が何をどこまで出来るのかが不明
 自己紹介のテンプレがあれば良いのでは？
 スキルを明示し、チームの「道具箱」に何が入っているか
「見える化」すれば良いのでは？
 合意が徹底されない
 合意形成が織り込まれたワークフローが必要では？
 ゲーム開発の視点でゲームを捉える枠組みが必要では？
 「互いに別のレイヤの話をぶつけて空中戦」をなくしたい
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

4.
4
解決方法
 「ワークフロー」、「テンプレ」、「見える化」
 「キャンバス」
 「枠組み」
 「MDAフレームワーク」
 「キャンバス」＋「MDAフレームワーク」
＝「GameJamCanvas」
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

5.
5
GameJamCanvas
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

6.
6
GameJamCanvas
①③
①③④
③④⑤
①
③④⑤
②③④⑤
④⑤
⑤
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

7.
7
GameJamCanvas①
 「Thema（テーマ）」、「Diversifiers（実績）」、
「Members（チームメンバー）」を書く
 これらは、予め決まっているので、書き込む
 非ガチ仕様で、チームメンバーを、話し合いなどで、別途手
段を用いて決めていく場合、その決め方は、
GameJamCanvasではスコープ外とする
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

8.
8
GameJamCanvas②
 「SkillSet（チームの道具箱）」を書く
 自己紹介も兼ねて、各自、何が出来るのか書いていく
 ×「プログラミング」〇「Unity」
 ポートフォリオ（過去作品）を開示して、誰が何をどのくらい
出来るのか、チーム内で共有
 スキルは属人なので、どのメンバーとどのスキルが紐付い
ているのか視覚化しておいた方が良い
 電子的なツールを使っているなら、線で結ぶ
 模造紙やホワイトボードなどアナログなツールを使っている
なら、各項目を付箋紙に書くと思うので、付箋紙の色を同じに
するなどの工夫（パーソナルカラーを決める、パーソナルマー
クを決める）
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

9.
9
MDAフレームワーク
 MDAフレームワーク
 Aesthetics（面白さ）＝「要求」
 死にそうになっても、なかなか死なないで、綱渡り的なスリル
が味わえる
 Dynamics（起こって欲しい出来事）＝「振る舞い」
 ダメージの有無を、HPの逆数に比例した確率で制御する。死
にそうになるとダメージをもらわなくなる
 Mechanics（システム）＝「構造」
 プレイヤーキャラはHPを持つ。攻撃を受けるとHPが減る
 AがDによって表現されるためにMが必要
 新規性が高いものを扱いにくく、粒度にも留意が必要
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

10.
10
GameJamCanvas③
 「Aesthetics（面白さ）」、
「Dynamics（起こって欲しい出来事）」を書く
 「Thema（テーマ）」、「Diversifiers（実績）」との関連、整合性
に留意する
 「SkillSet（チームの道具箱）」で実現可能性を少しは気にす
る
 AとDは紐付いた関係なので、追跡可能性に留意
 仕様変更時の評価に必要となるため
 AとDの洗い出しでは、可能性を並列で挙げておき、後で
集約すると良い
 ゴール木を書いて、後で枝刈りする
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

11.
11
GameJamCanvas③
 「Aesthetics（面白さ）」
 テーマとメンバーの想い
 各自が独立して自由に書き出していき、後で集約
 抽象的な表現よりは、何がどうなって楽しい/気持ち良い、
と具体的なストーリーで書いた方が良い
 想定しているゲームのジャンル、プラットフォーム、操作系を
、可能な範囲で、メンバーでイメージ共有出来る程度
 表現に凝っても仕方がないので、いくつかの要素は箇条書き
で、口頭で補足説明でも良い
 実現可能性に問題があるものは、注釈付きにするか、候補
から外す
 起こって欲しい出来事とセットで出てくることを許容する
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

12.
12
GameJamCanvas③
 「Dynamics（起こって欲しい出来事）」
 Aのために必要な振る舞い
 さまざまなAに対して、独立にアイデアを出していく
 Dが膨らまないAを切り捨てたり、衝突するDを調整したり、
実現可能性に問題があるものは外すなど、整合性やバラ
ンスを調整していく
 調整は、ゲームデザインのリーダーを決めて、リーダー主導
で行うと良い
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

13.
13
GameJamCanvas③
 この作業が終わると、どんなおもしろさを持った、どんな
ゲームを作るのかが、大枠で決まる
 イメージボード
 アートワークの人に、ラフでいいからレイアウトを描いても
らって意識合わせ
 実現可能性
 プログラマの判断
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

14.
14
GameJamCanvas④
 「Mechanics（システム）」を書く
 仕様化の作業
 DとMは多対多で紐付く関係なので追跡可能性に留意
 A、Dとの関連、整合性に留意する
 Mで取れる実績が存在するケースを少しは気にする
 全てのMが、チームの道具箱に照らして、実現可能か確認
 問題が見つかったら、関連するD、Aに遡って検討
 必要であればD、Aを修正する
 データに関する仕様も決める
 作成するゲームの量的側面にも考慮
 面数、マップの広さ、絵素材の点数など
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

15.
15
GameJamCanvas⑤
 「Tasks（作業）」を書く
 具体的な作業を洗い出す
 Mと作業は1対多で紐付く関係なので追跡可能性に留意
 作業はどのスキルで（誰によって）賄われるか
 作業負荷に留意
 エフェクトについて、素材ではなくプログラムで対応するなど
 問題が見つかったら、関連するM、D、Aに遡って検討
 必要であればM、D、Aを修正する
 作成するゲームの量的側面にも考慮
 面数、マップの広さ、絵素材の点数など
 作業の依存関係も考慮し優先順位を付ける
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

16.
16
GameJamCanvasそのあとで
 「Tasks（作業）」を実行する
 具体的な作業をこなしていく
 作業を優先順位に合わせてアサインもしくは自分で取る
 スキルに合わせて作業分解してるので、レーン付カンバン
に移して進捗管理するなど可能
 問題が生じたら、M、D、Aと紐付きを追跡しながら影響範囲
を把握し、必要に応じて変更を行う
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

17.
17
効果
 「仕様のムリ」を解決
 実現可能性を考慮しつつ仕様化
 「時間のムダ」を解決
 無駄のない自己紹介
 MDA導入による空中戦の回避
 「分担のムラ」を解決
 メンバーの構成とスキルを考慮して作業化
Copyright (C) 2014 National Institute of Informatics, All rights reserved.

18.
18
おしまい
Copyright (C) 2014 National Institute of Informatics, All rights reserved.