Game A Weekとは、一週間で1つゲームを作って、ゲーム開発者の経験値を上げる方法として、オランダのインディー系デベロッパー「Vlambeer」のRami Ismail氏が提唱したものです。
Rami Ismail氏は「Vlambeer」の共同設立者であるJan Willem氏が圧倒的なゲーム開発・ゲームデザインをする力を持っており、それは「数百ものプロトタイプを作り、失敗を繰り返しながら経験を積んだ」からだということに気がつきました。そして、それを実践するための方法の1つとして「Game A Week」を提唱しました。
目次
定義
Rami Ismail氏が提唱する「Game A Week」の定義は以下のとおりです。
| ルール | 詳細 |
|---|---|
| 1. 毎週ゲームを作る | 月曜日の12:00にプロジェクトを開始し、日曜日の23:59までにゲームを作り上げること |
| 2. 毎週ゲームをリリースする | 作ったものは例えクソゲーでもWebサイトを通じて配信を行うこと。さらにSNSやブログなどでそれを告知すること |
| 3. 作り終えたゲームは修正しない | ゲーム完成後は手を入れてはダメ。どうしても修正したい場合は Game A Week 終了後に行うこと |
| 4. パターン化を避ける | 毎週、異なることにチャレンジすること。例えばデジタルゲームを作る代わりにアナログゲームを作る、アクションゲームではなくパズルゲームを作る、など |
| 5. 振り返りを行う | 作って良かったところ、間違っていたところ、興味深かったところ、などをまとめておきます。作ったゲームは何人かにプレイしてもらい感想を聞くこと。そしてその感想をまとめておくこと |
これはGame A Weekで最も重要なことです。ゲームを作り続けることが、ゲーム開発者としての経験を積むための唯一の最良の方法であるからです。
作ったゲームを遊んでもらって、面白かった・つまらなかったという反応をもらい、そのフィードバックを次に生かせるようにします。
個人ゲーム制作は基本的に期限がなく、どこまでも作り込むことができます。これはとても自由である反面、開発が永遠に終わらない（エターナる）原因となります。ですので、1週間経過したら、どんなに気に入ったゲームでも(改良すればもっと面白くなると思っても)、それに手を入れてはいけません。どうしても手を入れたいのであれば、Game A Week終了後に行います
同じようなゲームを作り続けないようにします。ゲームが完成したら、そのゲームのことは頭の外に追いやり、次のゲームのアイデアを考えるようにします。
たとえゲームをたくさん作っても、悪い部分は改善し、良い部分は次に生かせるようにならないと、効果が薄くなってしまいます。そうならないように、振り返り（反省文）を書き残しておきます。
Game A Weekで38本のゲームを作り、GDCで講演を行ったWallick氏によると、振り返りで検討した方が良い項目は以下の4つです。
- Idea: アイデア。コンセプト。テーマ。元ネタ
- What went right: やってみて良かったこと。うまくいったところ。成功したところ。次回に活かせそうなこと
- What went wrong: ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点
- What I learned: 学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど
振り返りのアプローチとして、以下の記事では「KPT」を紹介しています。振り返りをする際にはこちらが参考になると思います。
ゲーム開発の振り返りに使える「KPT」の紹介
参考リンク
「Game A Week」を理解するために参考になるリンクです
- Gamasutra: Rami Ismail’s Blog – Game A Week: Getting Experienced At Failure : Game A Week を提唱したRami Ismail氏の記事
- The guidelines for making a game a week, every week : GDCでGame A Weekの講演を行った、Wallick氏が提唱する「Game A Week」のガイドラインのまとめ
1. WEEKLY DEADLINE (1週間で強制的に開発を終わらせる) 2. REMEMBER THE PUBLIC (遊んでくれる人を意識する) 3. A NEW IDEA EVERY WEEK (毎週新しいアイデアに挑戦する) 4. REFLECT ON WORK FOR THE WEEK (完成したら振り返りをする)
- What one dev learned while doing a “one game per week” challenge : Game A Weekに挑戦して学んだこと
初めてゲームを作ったときの目標は、ゼルダの伝説のクローンゲームを作ることだった。 しかし2週間後にできたのは、緑色のキャラクターが何もない空間を動き回るだけの、つまらないゲームで、 とてもそれを完成させる気にはならなかった。 しかし、Game A Weekを実践することで、ゲームを完成させ、その過程を楽しむことができ、 多くのことを学ぶことができた。 1. とにかく小さなことから始めましょう 2. 適切なフレームワークを選びましょう 3. グラフィックとサウンドは素材サイトやBfxrなどを活用して簡単に作りましょう 4. アニメーションやエフェクトでゲームを楽しそうに見せましょう 5. 友達や家族にテストプレイしてもらいましょう
- 一週間に一つミニゲームを作り続けるのに役立つひどいゲームをかろうじてましなゲームにする力 : Game A Weekを実行して、2ヶ月で9本のゲームを作ったABAさんが得たもの
・ルールが複雑で分かりにくいゲームになってしまったら、 ルールを単純化・分割するとうまくいくことがある ・Game A Week は期限が決まっているので、つまらないゲームでも ラストスパートで悪あがきして面白くしようとする力が身につく
- 今年50のゲームを作って分かった面白いゲームを作る方法 : Game A Weekを実行して、1年間で50本のゲームを作ったABAさんが得た、ゲームを面白くする方法
・斬新さを少しずつ削る ・無理やり発想を広げるワンキーゲーム ・誘爆は友達 ・重力も友達 ・レトロゲームからつまみ食う ・人でなくマシンにレベルデザインさせる ・納得できる終わりをもたらす難度曲線 ・リスク駆動開発
ここからは、現在Game A Weekを行っていて気がついた個人的なメモです。
- Game A Weekで得られるもの・得られないもの
- 効率よくゲームを作る方法
- ネタ切れ対策
についてまとめています
Game A Weekで得られるもの・得られないもの
- 得られるもの
- ゲーム開発者としての経験
- ミニゲームの作り方(単一のゲームメカニクス)
- ゲームデザインに対する柔軟な思考力
- ゲーム開発の技術的なノウハウ
- ゲームを完成させた達成感
- 得られないもの
- 面白いゲームの作り方
- 売れるゲームの作り方
- 中～大規模なゲームの作り方(複合的なゲームメカニクス)
- チーム開発する力(たいてい一人で行うため)
面白いゲームを作れるかどうかは、作ってみないと分からない。面白いゲームが作れるかどうかはわりと運だのみ。ただし、Game A Weekで経験を積むことでやれることが増えるし、思いついたアイデアがどのようにゲームとして動作するかを「ある程度」脳内シミュレートできるようになるなど、ゲームデザインの視野が広がる
どちらかというと一発ネタのゲームを作る技術が身につくだけ。やはり1週間で作るので、期間的な制約上、中～大規模なゲームは作れない。そのため、プレイヤーにゲームを長く楽しませるための技術（コレクション要素、やり込み要素、実績など）は身につかない。
長く楽しませるゲームを作るには多くの開発期間が必要で、複合的な(各ゲームシステムが相互に作用する)コアメカニクスを作る力が必要となる
毎日、「ゲームを面白くするには？」という思考を繰り返すことで、柔軟な発想ができるようになる。最初はつらいかもしれないけど、繰り返すことでゲームについて考えることが苦にならなくなる
「このゲームは面白くないかも……？」などと不安になりながらも開発を続ける必要がない。クソゲーであろうが1週間経過すれば強制的に次のゲームに移るので、余計なストレスを抱え込む必要がなくなり、精神衛生上とてもよろしい。そしてゲームを完成させたときの充実感を繰り返し味わうことができる
効率よくゲームを作るには
- ノウハウが溜まると制作コストが下がる
- 多少のバグには目をつぶる
- レベルは1つでも良い
- レベルをプロシージャル(動的に)生成すると楽できる
- エンドレスなゲームにするとエンディング画面が省略できる
- 家から脱出すると集中して作業できる
- 開発中にメモを残す
Game A Week を始めたあたりはノウハウがなくて、ゲームについて考える時間があまり取れない。しかし、同じジャンルのゲームを作り続けたり、同じツールを使い続けることによって、制作コストが下がる (ただしパターン化せず、チャレンジを続けるようにする)
ゲームが頻繁にクラッシュするものでなければ、基本的に放置する。例えば少しだけ壁に引っかかるとか、スコアが初期化されない、などの些細な不具合。もちろん、簡単に直すことができれば直すべきだけれども
レベルデザインは時間のかかる作業なので、少なくしても構わない。ネタが続かないときは3ステージくらいでも良い気がする。
面倒なレベルデザインの過程を省略する、という意味では、ABAさんが提案するように、マシンにレベルデザインさせる(プロシージャル・自動生成)方が良い場合もある気がします。
3分間でプレイヤーをゲームから追い出す計算式
3分間でプレイヤーをゲームから追い出すお気に入りの式 [難度] = sqrt([経過フレーム数] * 0.0001) + 1 これで10800フレーム（3分）後に難度が約2.04倍になりプレイヤーはやられる。生き延びても後は真綿で首をしめるように難度がじりじり上昇
https://twitter.com/abagames/status/471998089402646528
この計算式を使うことで、レベルのプロシージャルが容易になりますエンディングを省略する
エンドレスで遊ぶゲーム(レベルをプロシージャル)にすると、エンディングを作る必要がなくなり、作業を省略できるようになります
- 家にいると遊んでしまう
- 家を出て作業すると、余計なものがないので作業に集中できる
- 外で作業するとノートパソコンとモバイルルーターが必須になるけれども……
- 図書館ならタダで作業できる。しかもタダで電源を使える場合も
- 外で作業するとノートパソコンとモバイルルーターが必須になるけれども……
開発中に直面した問題や解決策、参考になったURLなどを、その場でメモとして残しておく。理由は、開発完了時には忘れてしまっていることが多いから。メモ書きは、プロジェクトのリポジトリに追加しておくと良い。
ネタ切れ対策
Game A Weekを続けると、だんだんネタ切れになってくる。対策としては以下のことが考えられる
- 他のゲームを参考にする
- ジャンルから発想する
- 技術的なチャレンジをする
- コンセプト・テーマを決める
- ルールから組み立てる
- アルゴリズムから発想する
- 他のゲームの一部を切り出す
- オズボーンのチェックリストを使う
1. 他のゲームを参考にする
既存のゲームをベースに「不満点を改善したもの」「自分だったこう作る」という発想で自分のゲームを作る。なるべく安く買えて、時間のかからないゲームが良い
2. ジャンルから発想する
ゲームジャンルからアイデアを考える。ジャンルを組み合わせてオリジナルのジャンルを作ってもいいかも
- アクション＋タワーディフェンス
- リズムゲーム＋マッチ3ゲーム
- 落ちゲー＋テキストアドベンチャー
- シューティング＋ドットイートゲーム
- ローグライク＋FPS
- クッキークリッカー＋STG
などなど。
3. 技術的なチャレンジをする
新しい技術を導入すると、できることが増える。そしてマンネリ化を打破することができる。しかし技術的な調査に時間がかかって、ゲーム性を考える余裕がなくなるというデメリットもあるので、ほどほどに
- 作ったことないゲームジャンルに挑戦する
- 物理エンジンを導入する
- アニメーションツールを導入する
- スクリプトエンジンやデータベースを組み込んでみる
- ネットワークゲームにする
- ゲームエンジンを使ってみる
4. コンセプト・テーマを決める
難易度は上がるけれども、コンセプト・テーマを決めてそれに沿ったゲームを作る。テーマの考え方のアイデアは以下のとおり
- 国語辞典をランダムに開いて、目に入った単語をテーマにする
- 映画や小説などのタイトルから借用する
- 流行語をテーマにする
- Ludum Dareの過去のテーマに挑戦してみる
5. ルールから組み立てる
面白いと感じたゲームのルールを抽出し、それを再構築してでゲームを作る方法。1の「他のゲームを参考にする」に近いけれども、「ルール」を抽象化して分解を行い、抽象化した概念を組み立てる、という過程が異なる。
ルールを組み立ててゲームを作る考え方としては、この本がおすすめです。
この本を参考にまとめてみた使いやすそうなルールの例
| ルール | 例 | 効果・補足 |
|---|---|---|
| ゲームオーバー | 自機の死亡。制限時間が「0」になった。ライフの残りが「0」になった | とりあえず入れておけば最低限ゲームとして成立する |
| 連鎖 | 敵をはじき飛ばしてぶつけると、ぶつけた敵もはじき飛ばされる | 敵が複数存在しないと成立しない。誘爆との違いは他のオブジェクトを巻き込まない |
| 誘爆 | 爆発に敵が巻き込まれて死亡する | 誘爆を有効に機能させるには、発火するオブジェクトを大量に配置・出現させる必要がある |
| コンボ | 一定時間内に連続で敵を倒すとボーナス。スコア倍率上昇 | コンボによりパワーアップが発生するゲームもある。ハック＆スラッシュ系ゲームと相性が良い |
| アクションの回数制限 | 弾薬の制限。1回のショットで敵を倒す | |
| クールダウン(時間による制限) | 弾薬数が一定時間で回復 | クールダウン中にやれることがないと退屈なので、複数のアクションを用意して効率よくローテーションするゲーム性にすると良いかも |
| 地形の変化 | 地形が崩れる、足場を動的に作れる、時間で変化する。QIX / ディグダグⅡ / テトリスなどの落ちものパズル | |
| 強制スクロール | ラン&ジャンプ系ゲーム | プレイヤーを強制的に前に進ませる。ランダムなレベル生成による難易度のばらつきをある程度均一化する効果もある |
| 時間制限 | 残り時間「0」でゲームオーバー。時間経過により敵が強くなる | プレイヤーを強制的に前に進ませる。敵の減少により簡単になっても緊張感が出る |
| 探索 | レベル内のアイテムをすべて見つけるとクリア。ゴールを探す | |
| 撃つ＋避ける | シューティングゲームの基本要素 | 撃つだけのゲーム、避けるだけのゲームにするとカジュアルなゲームになる |
| パワーアップ ショットの連射速度の上昇 | アイテム獲得で上昇することが多い。ゲームに大きな緩急をもたらす。パワーダウン条件も取り入れるとインフレしにくい | |
| 無敵 | 敵の攻撃が当たらない。体当たりで敵を倒せる | パワーアップの一種。たいていは時間制限がある。パックマンのように無敵状態でしか敵を倒せないというルールにするとゲームの緩急をつけやすい |
| 成長 | 長期的なパワーアップ。一般的なRPGにおける経験値の獲得によるステータスの上昇 | |
| 慣性 | 重力。引力。加速度。スーパーマリオなどのアクションゲーム | 精密な操作が難しくなるので慣性を強くしすぎると大味なゲーム性になりやすいが、操作に慣れるための習熟過程をゲーム性にしやすい。また物理法則に従っていればプレイヤーが理解しやすい |
| ターン制 | 1ターンにつき限られたアクション(移動・攻撃など)しかできない | たいていは制限時間がないので、思考を重視するパズルゲームに向いている |
6. アルゴリズムから発想する
プログラムのアルゴリズムからゲームを発想する。AIの分野が使いやすい？
- 再帰処理
- 逆ポーランド記法
- ハノイの塔
- セルオートマトン
- 群集シミュレーション
- 遺伝的アルゴリズム
Wikipedia – アルゴリズムの「代表的なアルゴリズム」の項が参考になるかもしれないし、そうでもないかもしれない
7. 他のゲームの一部を切り出す
他のゲームの一部分を切り出して考える方法です。 具体的な例は以下のゲームです
- Braid: 時間巻き戻しの仕組みは「プリンス・オブ・ペルシャの時間を戻すシステムを無限にできるようになったら面白いでは？」という着想
- Downwell: Spelunkyのスーパープレイの爽快感にヒントを得た
- バーンアウト: 敵の車に衝突して加速するシステムは、斑鳩の「敵弾に接触することでメリットを得られる」というルールからヒントを得た
これらのように、既存のゲームの一部分に「着目」して、それをうまく「抽出」し、「それをコアとするシステム」に仕上げる、という手法も有効なのかもしれません。
8. オズボーンのチェックリストを使う
アイデア発想のためのヒント集
| No | 分類 | 質問 | 例 |
|---|---|---|---|
| 1 | 転用 | 他に使い道はないか？ | 既存のものの新しい使い方や、改善、改良をする |
| 2 | 応用 | 他からアイデアが借りられないか？ | 似たようなものを探す |
| 3 | 変更 | 変えてみたらどうか？ | |
| 4 | 拡大 | 大きくしてみたらどうか？ | 「Braid」は「プリンス・オブ・ペルシャ」の時間巻き戻しを無限に使用できるように拡大した |
| 5 | 縮小 | 小さくしてみたらどうか？ | 単純化するなど。例えばRTSの防衛の面白さを単純化したのがタワーディフェンス |
| 6 | 代用 | ほかのもので代用できないか？ | |
| 7 | 置換 | 入れ替えてみたらどうか？ | |
| 8 | 逆転 | 逆にしてみたらどうか？ | 立場を逆転する。例えば「勇者のくせになまいきだ。」のように魔王を主人公にする |
| 9 | 結合 | 組み合わせてみたらどうか？ | ジャンルを混ぜる。例えば「Crypt of the Necro Dancer」はリズムゲーム＋ローグライク |
ユニ通！-1週間でゲームを作る技術-
unity1weekという「Unityを使って1週間でゲームを作る」イベントがあるのですが、そこに参加するときに知っておいた方が良い知識がまとめられた本です。
こちらの記事の内容を動画にしたものです
