• 本文
• トップ
• 編集
• 差分
• 添付
• 名前変更

Game A Week

Game A Week とは

Game A Weekとは、一週間で1つゲームを作って、ゲーム開発者の経験値を上げる方法として、オランダのインディー系デベロッパー「Vlambeer」のRami Ismail氏が提唱したもの。

• Gamasutra: Rami Ismail's Blog - Game A Week: Getting Experienced At Failure

Rami Ismail氏は「Vlambeer」の共同設立者であるJan Willem氏が圧倒的なゲーム開発・ゲームデザインをする力を持っており、それは「数百ものプロトタイプを作り、失敗を繰り返しながら経験を積んだ」ということに気がついた。そして、それを実践するための一般的なルールとして「Game A Week」を提唱した。

定義

振り返りについて

振り返りで検討すべき事項

Game A Weekを行う意義と方針

• 意義
  • ゲーム開発は、ゲームを作ることでしか学ぶことはできない
    • 失敗することで経験を積む
  • 思いついたアイデアが、長い期間をかけて開発する価値があるかどうかを判断するためにも、短い時間でゲームを完結させてみる
• 方針
  • ゲームのコンセプトを見失うことがあるかもしれないが、それでも前に進み続けること

大切なのは「ゲームを作り続ける」ということ

参考リンク

• The guidelines for making a game a week, every week (Game A Weekでゲームを作るときのガイドライン) GDCでGame A Weekの講演を行った、Wallick氏が提唱するガイドラインのまとめ

  1. WEEKLY DEADLINE (1週間で強制的に開発を終わらせる)
  2. REMEMBER THE PUBLIC (遊んでくれる人を意識する)
  3. A NEW IDEA EVERY WEEK (毎週新しいアイデアに挑戦する)
  4. REFLECT ON WORK FOR THE WEEK (完成したら振り返りをする)

  Constraint(制約)が主なテーマ。制約なしでゲームを作っても「自由による麻痺」という罠にかかりやすいとのこと

• 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さんが得た、ゲームを面白くする方法

    ・斬新さを少しずつ削る
    ・無理やり発想を広げるワンキーゲーム
    ・誘爆は友達
    ・重力も友達
    ・レトロゲームからつまみ食う
    ・人でなくマシンにレベルデザインさせる
    ・納得できる終わりをもたらす難度曲線
    ・リスク駆動開発

• 『Downwell』の作者もっぴん氏の成長が著しすぎる件
  • 海外でも高い評価を受けている「Downwell」の作者であるもっぴんさんのGame A Weekの過程
  • Downwellは Game A Week から生まれたので、Game A Week での成功例の1つと言える

Game A Week を続けていて分かったこと

Game A Week を続けていて分かった個人的なメモ

Game A Weekで得られるもの・得られないもの

「1週間に1つ、ゲームを作り続ける」という定義でGame A Weekを実行した結果、得られるものと得られないものをまとめ。

「売れるゲームを1週間で作る」という目標を立てれば、売れるゲームの作り方は身につくかもしれない

Game A Week は面白いゲームを作るためのものではなく、経験を積むためのもの

面白いゲームを作れるかどうかは、作ってみないと分からない。面白いゲームが作れるかどうかはわりと運だのみ。ただし、Game A Weekで経験を積むことでやれることが増えるし、思いついたアイデアがどのようにゲームとして動作するかを「ある程度」脳内シミュレートできるようになるなど、ゲームデザインの視野が広がる

Game A Week はミニゲームの作り方の経験を得るためのもの

どちらかというと一発ネタのゲームを作る技術が身につくだけ。やはり1週間で作るので、期間的な制約上、中～大規模なゲームは作れない。そのため、プレイヤーにゲームを長く楽しませるための技術（コレクション要素、やり込み要素、実績など）は身につかない。

長く楽しませるゲームを作るには多くの開発期間が必要で、複合的な(各ゲームシステムが相互に作用する)コアメカニクスを作る力が必要となる

アイデアの引き出しが増える

様々なアイデアにチャレンジすることで、うまくいくアイデア、うまくいかないアイデアの引き出しが増える。それにより作ることのできるゲームの幅が広がる

クソゲーになることを恐れずにゲームを作ることができる

「失敗できない(クソゲーになる)」という恐怖は人を追い詰め、本来の能力を削いで、発想力を小さく収めてしまう。

しかし、Game A Weekはそれを気にする必要がない。新しいアイデアが面白いゲームになるかどうか、という心配をして先に進めないことがなくなる。

無理に「良いゲーム」を作らなくてもよい

失敗を恐れて、無難な「良いゲーム」を作ろうとすると、心に負担がかかる。他人に楽しんでもらうために「良いゲーム」を作ろうとすると、プレッシャーで作業が進まなくなる。

「面白いゲーム」を作ろうとする心構えは大切だけれども、それがつらくなったら「クソゲーでいいじゃん」くらいのお気楽な気持ちで作ると良い。継続することが大切

テストプレイをしてもらうことは重要

テストプレイをしてもらうと、自分では微妙と思ったところが面白いと言われることがある。自分以外の視点でプレイされることで、自分では気がつかなかった面白さを発見してもらうことができる。

また、テストプレイを楽しんでやってもらえると、次のゲームを作る原動力になる。テストプレイしてもらう人が、楽しく遊んでもらえるように、考えながらゲームを作れるようになる。

逆に、自分が遊ぶことだけを目的にすると、どうしても視野が狭くなりがち。

Game A Week をすることでゲームデザインの思考力が柔軟に働くようになる

毎日、「ゲームを面白くするには？」という思考を繰り返すことで、柔軟な発想ができるようになる。最初はつらいかもしれないけど、繰り返すことでゲームについて考えることが苦にならなくなる

クソゲーでも無理矢理終わらせることができる

「このゲームは面白くないかも……？」などと不安になりながらも開発を続ける必要がない。クソゲーであろうが1週間経過すれば強制的に次のゲームに移るので、余計なストレスを抱え込む必要がなくなり、精神衛生上とてもよろしい。そしてゲームを完成させたときの充実感を繰り返し味わうことができる

多少のバグは目をつぶる

ゲームが頻繁にクラッシュするものでなければ、基本的に放置する。例えば少しだけ壁に引っかかるとか、スコアが初期化されない、などの些細な不具合。もちろん、簡単に直すことができれば直すべきだけれども

レベルは1つでも良い

レベルデザインは時間のかかる作業なので、少なくしても構わない。ネタが続かないときは3ステージくらいでも良い気がする。

面倒なレベルデザインの過程を省略する、という意味では、ABAさんが言うように、マシンにレベルデザインさせる(プロシージャル・自動生成)方が良い場合もある気がします。

3分間でプレイヤーをゲームから追い出す計算式

https://twitter.com/abagames/status/471998089402646528

[難度] = sqrt([経過フレーム数] * 0.0001) + 1
これで10800フレーム（3分）後に難度が約2.04倍になりプレイヤーはやられる。
生き延びても後は真綿で首をしめるように難度がじりじり上昇

この計算式を使うことで、レベルのプロシージャルが容易になる

エンディングを省略する

エンドレスで遊ぶゲーム(レベルをプロシージャル)にすると、エンディングを作る必要がなくなり、作業を省略できるようになる

実験的な要素をたくさん入れるとクソゲーになりやすい

チャレンジするのは大切だけれども、多すぎるとまとまらずに終わる

他人にテストプレイしてもらうのは重要

作った本人では今ひとつ、と思ってもテストプレイしてもらうと意外なところがウケることがある。そういったポイントは、自分の強みになるので忘れないようにメモに残しておく。

家から脱出すると集中して作業できる

• 家にいると遊んでしまう
  • 作業を妨害する楽しいもの(ネット環境・ゲーム・寝るための布団)が完備されてしまっている
  • 例えば動画を見ながら作業しても集中できないので作業効率が良くない
• 家を出て作業すると、余計なものがないので作業に集中できる
  • 外で作業するとノートパソコンとモバイルルーターが必須になるけれども……
  • スタバとかモスバーガーが作業しやすい
    • しかしお金がかかる
  • 図書館ならタダで作業できる。しかもタダで電源を使える場合も

ノウハウが溜まると制作コストが下がる

Game A Week を始めたあたりはノウハウがなくて、ゲームについて考える時間があまり取れない。しかし、同じジャンルのゲームを作り続けたり、同じツールを使い続けることによって、制作コストが下がる (ただしパターン化せず、チャレンジを続けるようにする)

開発中にメモを残す

開発中に直面した問題や解決策、参考になったURLなどを、その場でメモとして残しておく。理由は、開発完了時には忘れてしまっていることが多いから。メモ書きは、プロジェクトのリポジトリに追加しておくと良い。

制作時間を減らすコツ

• 作ったゲームのノウハウを流用できるようにしておく
  • よく使うプログラムのライブラリ化など
• 作った画像・サウンド素材は、次の作品で(可能であれば)使い回す
• ゲームのコアとならない部分はどんどん流用する
  • 演出やUI、ギミックなど
  • タイトル画面やゲームオーバーUIなどは流用しやすい
• 設計にこだわらない
  • エレガントな設計よりも動くことが重要。ただしフィールド変数をprivateにするなど、バグが起こりにくする配慮は必要
  • ドキュメントは作らない。ただしプログラムに最低限のコメントを入れるくらいはした方が、手を入れやすくなる
• ゲームを公開するページは、簡単に作れるようにひな形となるフォーマットを用意しておく
• 繰り返し発生する作業はツール・スクリプトで自動化する (wav を mp3 と ogg に出力するなど)
  • ただし、ツールの作成に時間がかかると本末転倒なので、できる範囲で少しずつ作る

Game A Weekで作ったゲームを本制作(1週間以上の期間をかけて作り込む)する場合

なるべくソースコードを流用しないで、1から作り直す方が良い。理由は、Game A Weekで作ったゲームのコードは、最後の追い込みで無茶なコードを書いてしまうため、それを流用すると、長期間の開発に耐えられない作りになってしまうため

ネタ切れ対策 (アイデア発想法)

Game A Weekを続けると、だんだんネタ切れになってくる。対策としては以下のことが考えられる

1. 他のゲームを参考にする

既存のゲームをベースに「不満点を改善したもの」「自分だったこう作る」という発想で自分のゲームを作る。なるべく安く買えて、時間のかからないゲームが良い

• スマートフォンのゲーム
  • ガッツリ遊べるソーシャルゲームは避ける
• Steamのゲームを色々遊んでみる
• Ludum Dare に投稿された作品を遊んでみる
  • Ludum Dare #34
• ミニゲーム集で遊んでみる
  • バイトヘル2000 : カルト的な人気を誇るミニゲーム集。ただしミニゲームを全種類集めるのは大変かも……
  • G.G シリーズコレクション+ : DSiウェアとして配信したゲームを集めたもの。これもミニゲームを全種類出現させるのは大変
  • ナゾのミニゲーム ちょいがえ
  • メイドインワリオシリーズ
• レトロゲームコレクションを参考にする
  • ナムコミュージアム
  • カプコン クラシックス コレクション
  • コナミ アーケード コレクション
  • バーチャルコンソール
  • ゲームアーカイブス

2. ジャンルから発想する

ゲームジャンルからアイデアを考える。

• アクション＋タワーディフェンス
• リズムゲーム＋マッチ3ゲーム
• 落ちゲー＋テキストアドベンチャー
• シューティング＋ドットイートゲーム
• ローグライク＋FPS
• クッキークリッカー＋STG

などなど。

Wikipedia - コンピュータゲームのジャンルなどを参考にすると良いかも

3. 技術的なチャレンジをする

新しい技術を導入すると、できることが増える。そしてマンネリ化を打破することができる。しかし技術的な調査に時間がかかって、ゲーム性を考える余裕がなくなるというデメリットもあるので、ほどほどに

• 作ったことないゲームジャンルに挑戦する
• 物理エンジンを導入する
• アニメーションツールを導入する
• スクリプトエンジンやデータベースを組み込んでみる
• ネットワークゲームにする
• ゲームエンジンを使ってみる

4. コンセプト・テーマを決める

難易度は上がるけれども、コンセプト・テーマを決めてそれに沿ったゲームを作る。テーマの考え方のアイデアは以下のとおり

• 国語辞典をランダムに開いて、目に入った単語をテーマにする
  • 四文字熟語やことわざなんかが使いやすいかも
• 映画や小説などのタイトルから借用する
• 流行語をテーマにする
• Ludum Dareの過去のテーマに挑戦してみる

5. ルールから組み立てる

面白いと感じたゲームのルールを抽出し、それを再構築してでゲームを作る方法。1の「他のゲームを参考にする」に近いけれども、「ルール」を抽象化して分解を行い、抽象化した概念を組み立てる、という過程が異なる。

ルールを組み立ててゲームを作る考え方としては、この本がおすすめです。

• 組み立て×分解! ゲームデザイン ――ゲームが変わる「ルール」のパワー

使いやすそうなルールの例

6. アルゴリズムから発想する

プログラムのアルゴリズムからゲームを発想する。AIの分野が使いやすい？

• 再帰処理
• 逆ポーランド記法
• ハノイの塔
• セルオートマトン
• 群集シミュレーション
• 遺伝的アルゴリズム

Wikipedia - アルゴリズムの「代表的なアルゴリズム」の項が参考になるかもしれないし、そうでもないかもしれない

7. 他のゲームの一部を切り出す

他のゲームの一部分を切り出して考える方法です。 具体的な例は以下のゲームです

これらのように、既存のゲームの一部分に「着目」して、それをうまく「抽出」し、「それをコアとするシステム」に仕上げる、という手法も有効なのかもしれません。

8. オズボーンのチェックリストを使う

アイデア発想のためのヒント集

9. 手段目的構造フレームワーク

「●●を□□して(手段)、××を△△する(目的)のゲーム」

• ●●を□□して
• ××を△△する

の部分をランダムに言葉を当てはめる、という発想法

• どうやってもゲームのアイデアになるEMS Frameworkの紹介

■例

• [罠]を[仕掛けて]、[動物]を[捕まえる]ゲーム
• [水]を[撒いて] 、[火事]を[消火する]ゲーム
• [種]を[蒔いて]、[植物]を[育てる]ゲーム
• [商品]を[売って]、[お金]を[稼ぐ]ゲーム
• [銃]を[撃って]、[敵]を[倒す]ゲーム
• [ビル]を[登って]、[屋上]を[目指す]ゲーム