Game A Week の変更点
* Game A Week とは [#g5896600]
Game A Weekとは、一週間で1つゲームを作って、ゲーム開発者の経験値を上げる方法として、オランダのインディー系デベロッパー「Vlambeer」のRami Ismail氏が提唱したもの。
- [[Gamasutra: Rami Ismail's Blog - Game A Week: Getting Experienced At Failure>http://www.gamasutra.com/blogs/RamiIsmail/20140226/211807/Game_A_Week_Getting_Experienced_At_Failure.php]]
Rami Ismail氏は「Vlambeer」の共同設立者であるJan Willem氏が圧倒的なゲーム開発・ゲームデザインをする力を持っており、それは「数百ものプロトタイプを作り、失敗を繰り返しながら経験を積んだ」ということに気がついた。そして、それを実践するための一般的なルールとして「Game A Week」を提唱した。
** 定義 [#y0584613]
,''毎週ゲームを作る'',月曜日の12:00にプロジェクトを開始し、日曜日の23:59までにゲームを作り上げること
,''毎週ゲームをリリースする'',作ったものは例えクソゲーでもWebサイトを通じて配信を行うこと。さらにSNSやブログなどでそれを告知すること
,''作り終えたゲームは修正しない'',ゲーム完成後は手を入れてはダメ。どうしても修正したい場合は Game A Week 終了後に行うこと
,''パターン化を避ける'',毎週、異なることにチャレンジすること。例えばデジタルゲームを作る代わりにアナログゲームを作る、アクションゲームではなくパズルゲームを作る、など
,''振り返りを行う'',作って良かったところ、間違っていたところ、興味深かったところ、などをまとめておきます。作ったゲームは何人かにプレイしてもらい感想を聞くこと。そしてその感想をまとめておくこと
*** 振り返りについて [#q47edd58]
振り返りで検討すべき事項
|''検討事項''|''例''|h
|Idea|アイデア。コンセプト。テーマ。元ネタ|
|What went right|やってみて良かったこと。うまくいったところ。成功したところ。次回に生かせそうなこと|
|What went wrong|ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点|
|What I learned|学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど|
** Game A Weekを行う意義と方針 [#o01d5fab]
- 意義
-- ゲーム開発は、ゲームを作ることでしか学ぶことはできない
--- 失敗することで経験を積む
-- 思いついたアイデアが、長い期間をかけて開発する価値があるかどうかを判断するためにも、短い時間でゲームを完結させてみる
- 方針
-- ゲームのコンセプトを見失うことがあるかもしれないが、それでも前に進み続けること
大切なのは「ゲームを作り続ける」ということ
** 参考リンク [#kc3edcd0]
- [[The guidelines for making a game a week, every week>http://www.polygon.com/2014/8/11/5990261/Adriel-wallick-gdc-europe-2014-game-a-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>http://indiegames.com/2014/02/what_one_dev_learned_while_doi.html]] (Game A Weekに挑戦して学んだこと)
初めてゲームを作ったときの目標は、ゼルダの伝説のクローンゲームを作ることだった。
しかし2週間後にできたのは、緑色のキャラクターが何もない空間を動き回るだけの、つまらないゲームで、
とてもそれを完成させる気にはならなかった。
しかし、Game A Weekを実践することで、ゲームを完成させ、その過程を楽しむことができ、
多くのことを学ぶことができた。
1. とにかく小さなことから始めましょう
2. 適切なフレームワークを選びましょう
3. グラフィックとサウンドは素材サイトやBfxrなどを活用して簡単に作りましょう
4. アニメーションやエフェクトでゲームを楽しそうに見せましょう
5. 友達や家族にテストプレイしてもらいましょう
- [[一週間に一つミニゲームを作り続けるのに役立つひどいゲームをかろうじてましなゲームにする力>http://aba.hatenablog.com/entry/20140308/p1]]
-- Game A Weekを実行して、2ヶ月で9本のゲームを作ったABAさんが得たもの
・ルールが複雑で分かりにくいゲームになってしまったら、
ルールを単純化・分割するとうまくいくことがある
・Game A Week は期限が決まっているので、つまらないゲームでも
ラストスパートで悪あがきして面白くしようとする力が身につく
- [[今年50のゲームを作って分かった面白いゲームを作る方法>http://aba.hatenablog.com/entry/20141223/p1]]
-- Game A Weekを実行して、1年間で50本のゲームを作ったABAさんが得た、ゲームを面白くする方法
・斬新さを少しずつ削る
・無理やり発想を広げるワンキーゲーム
・誘爆は友達
・重力も友達
・レトロゲームからつまみ食う
・人でなくマシンにレベルデザインさせる
・納得できる終わりをもたらす難度曲線
・リスク駆動開発
- [[『Downwell』の作者もっぴん氏の成長が著しすぎる件>http://togetter.com/li/794308]]
-- [[海外でも高い評価を受けている>http://www.gamespark.jp/article/2015/10/23/61195.html]]「Downwell」の作者であるもっぴんさんのGame A Weekの過程
-- Downwellは Game A Week から生まれたので、Game A Week での成功例の1つと言える
----
----
----
*Game A Week を続けていて分かったこと [#je052b25]
Game A Week を続けていて分かった個人的なメモ
** Game A Weekで得られるもの・得られないもの [#jfcd192a]
「1週間に1つ、ゲームを作り続ける」という定義でGame A Weekを実行した結果、得られるものと得られないものをまとめ。
|''得られるもの''|''得られないもの''|h
|・ゲーム開発者としての経験&br();・ミニゲームの作り方(単一のゲームメカニクス)&br();・ゲームデザインに対する柔軟な思考力&br();・アイデアの引き出しが増える&br();・ゲーム開発の技術的なノウハウ&br();・ゲームを完成させた達成感|・面白いゲームの作り方&br();・売れるゲームの作り方&br();・中～大規模なゲームの作り方(複合的なゲームメカニクス)&br();・チーム開発する力(たいてい一人で作るため)|
「売れるゲームを1週間で作る」という目標を立てれば、売れるゲームの作り方は身につくかもしれない
** Game A Week は面白いゲームを作るためのものではなく、経験を積むためのもの [#x7741449]
面白いゲームを作れるかどうかは、作ってみないと分からない。面白いゲームが作れるかどうかはわりと運だのみ。ただし、Game A Weekで経験を積むことでやれることが増えるし、思いついたアイデアがどのようにゲームとして動作するかを「ある程度」脳内シミュレートできるようになるなど、ゲームデザインの視野が広がる
** Game A Week はミニゲームの作り方の経験を得るためのもの [#m058e73d]
どちらかというと一発ネタのゲームを作る技術が身につくだけ。やはり1週間で作るので、期間的な制約上、中～大規模なゲームは作れない。そのため、プレイヤーにゲームを長く楽しませるための技術（コレクション要素、やり込み要素、実績など）は身につかない。
長く楽しませるゲームを作るには多くの開発期間が必要で、複合的な(各ゲームシステムが相互に作用する)コアメカニクスを作る力が必要となる
** アイデアの引き出しが増える [#na8287f7]
様々なアイデアにチャレンジすることで、うまくいくアイデア、うまくいかないアイデアの引き出しが増える。それにより作ることのできるゲームの幅が広がる
** クソゲーになることを恐れずにゲームを作ることができる [#v489f01c]
「失敗できない(クソゲーになる)」という恐怖は人を追い詰め、本来の能力を削いで、発想力を小さく収めてしまう。
しかし、Game A Weekはそれを気にする必要がない。新しいアイデアが面白いゲームになるかどうか、という心配をして先に進めないことがなくなる。
** 無理に「良いゲーム」を作らなくてもよい [#pe7279eb]
失敗を恐れて、無難な「良いゲーム」を作ろうとすると、心に負担がかかる。他人に楽しんでもらうために「良いゲーム」を作ろうとすると、プレッシャーで作業が進まなくなる。
「面白いゲーム」を作ろうとする心構えは大切だけれども、それがつらくなったら「クソゲーでいいじゃん」くらいのお気楽な気持ちで作ると良い。継続することが大切
** テストプレイをしてもらうことは重要 [#v526d7e0]
テストプレイをしてもらうと、自分では微妙と思ったところが面白いと言われることがある。自分以外の視点でプレイされることで、自分では気がつかなかった面白さを発見してもらうことができる。
また、テストプレイを楽しんでやってもらえると、次のゲームを作る原動力になる。テストプレイしてもらう人が、楽しく遊んでもらえるように、考えながらゲームを作れるようになる。自分が遊ぶことだけを目的にすると、視野が狭くなる。
また、テストプレイを楽しんでやってもらえると、次のゲームを作る原動力になる。テストプレイしてもらう人が、楽しく遊んでもらえるように、考えながらゲームを作れるようになる。
逆に、自分が遊ぶことだけを目的にすると、どうしても視野が狭くなりがち。
** Game A Week をすることでゲームデザインの思考力が柔軟に働くようになる [#kc83662c]
毎日、「ゲームを面白くするには？」という思考を繰り返すことで、柔軟な発想ができるようになる。最初はつらいかもしれないけど、繰り返すことでゲームについて考えることが苦にならなくなる
** クソゲーでも無理矢理終わらせることができる [#af476322]
「このゲームは面白くないかも……？」などと不安になりながらも開発を続ける必要がない。クソゲーであろうが1週間経過すれば強制的に次のゲームに移るので、余計なストレスを抱え込む必要がなくなり、精神衛生上とてもよろしい。そしてゲームを完成させたときの充実感を繰り返し味わうことができる
** 多少のバグは目をつぶる [#z6d598b4]
ゲームが頻繁にクラッシュするものでなければ、基本的に放置する。例えば少しだけ壁に引っかかるとか、スコアが初期化されない、などの些細な不具合。もちろん、簡単に直すことができれば直すべきだけれども
** レベルは1つでも良い [#j63278b0]
レベルデザインは時間のかかる作業なので、少なくしても構わない。ネタが続かないときは3ステージくらいでも良い気がする。
面倒なレベルデザインの過程を省略する、という意味では、ABAさんが言うように、マシンにレベルデザインさせる(プロシージャル・自動生成)方が良い場合もある気がします。
***3分間でプレイヤーをゲームから追い出す計算式 [#od1a916f]
#ref(aba3min.png,nolink);
https://twitter.com/abagames/status/471998089402646528
[難度] = sqrt([経過フレーム数] * 0.0001) + 1
これで10800フレーム（3分）後に難度が約2.04倍になりプレイヤーはやられる。
生き延びても後は真綿で首をしめるように難度がじりじり上昇
この計算式を使うことで、レベルのプロシージャルが容易になる
** エンディングを省略する [#x0105dd8]
エンドレスで遊ぶゲーム(レベルをプロシージャル)にすると、エンディングを作る必要がなくなり、作業を省略できるようになる
** 実験的な要素をたくさん入れるとクソゲーになりやすい [#e4c5008d]
チャレンジするのは大切だけれども、多すぎるとまとまらずに終わる
** 他人にテストプレイしてもらうのは重要 [#f5abbe47]
作った本人では今ひとつ、と思ってもテストプレイしてもらうと意外なところがウケることがある。そういったポイントは、自分の強みになるので忘れないようにメモに残しておく。
** 家から脱出すると集中して作業できる [#f941f4e6]
- 家にいると遊んでしまう
-- 作業を妨害する楽しいもの(ネット環境・ゲーム・寝るための布団)が完備されてしまっている
-- 例えば動画を見ながら作業しても集中できないので作業効率が良くない
- 家を出て作業すると、余計なものがないので作業に集中できる
-- 外で作業するとノートパソコンとモバイルルーターが必須になるけれども……
-- スタバとかモスバーガーが作業しやすい
--- しかしお金がかかる
-- 図書館ならタダで作業できる。しかもタダで電源を使える場合も
** ノウハウが溜まると制作コストが下がる [#wed966a4]
Game A Week を始めたあたりはノウハウがなくて、ゲームについて考える時間があまり取れない。しかし、同じジャンルのゲームを作り続けたり、同じツールを使い続けることによって、制作コストが下がる (ただしパターン化せず、チャレンジを続けるようにする)
** 開発中にメモを残す [#baa8e19a]
開発中に直面した問題や解決策、参考になったURLなどを、その場でメモとして残しておく。理由は、開発完了時には忘れてしまっていることが多いから。メモ書きは、プロジェクトのリポジトリに追加しておくと良い。
** 制作時間を減らすコツ [#h26144c3]
- 作ったゲームのノウハウを流用できるようにしておく
-- よく使うプログラムのライブラリ化など
- 作った画像・サウンド素材は、次の作品で(可能であれば)使い回す
- ゲームのコアとならない部分はどんどん流用する
-- 演出やUI、ギミックなど
-- タイトル画面やゲームオーバーUIなどは流用しやすい
- 設計にこだわらない
-- エレガントな設計よりも動くことが重要。ただしフィールド変数をprivateにするなど、バグが起こりにくする配慮は必要
-- ドキュメントは作らない。ただしプログラムに最低限のコメントを入れるくらいはした方が、手を入れやすくなる
- ゲームを公開するページは、簡単に作れるようにひな形となるフォーマットを用意しておく
- 繰り返し発生する作業はツール・スクリプトで自動化する (wav を mp3 と ogg に出力するなど)
-- ただし、ツールの作成に時間がかかると本末転倒なので、できる範囲で少しずつ作る
** Game A Weekで作ったゲームを本制作(1週間以上の期間をかけて作り込む)する場合 [#o85db143]
なるべくソースコードを流用しないで、1から作り直す方が良い。理由は、Game A Weekで作ったゲームのコードは、最後の追い込みで無茶なコードを書いてしまうため、それを流用すると、長期間の開発に耐えられない作りになってしまうため
** ネタ切れ対策 (アイデア発想法) [#p90368e4]
Game A Weekを続けると、だんだんネタ切れになってくる。対策としては以下のことが考えられる
|''対策''|''分類''|h
|1. 他のゲームを参考にする|模倣・改造|
|2. ジャンルから発想する|抽象化からの再構築|
|3. 技術的なチャレンジをする|技術的アプローチ|
|4. コンセプト・テーマを決める|抽象化からの再構築|
|5. ルールから組み立てる|抽象化からの再構築|
|6. アルゴリズムから発想する|技術的アプローチ|
|7. 他のゲームの一部を切り出す|抽象化からの再構築|
|8. オズボーンのチェックリストを使う|抽象化からの再構築|
|9. 手段目的構造フレームワーク|???|
*** 1. 他のゲームを参考にする [#t81f5e85]
既存のゲームをベースに「不満点を改善したもの」「自分だったこう作る」という発想で自分のゲームを作る。なるべく安く買えて、時間のかからないゲームが良い
- スマートフォンのゲーム
-- ガッツリ遊べるソーシャルゲームは避ける
- Steamのゲームを色々遊んでみる
- Ludum Dare に投稿された作品を遊んでみる
-- [[Ludum Dare #34>http://ludumdare.com/compo/ludum-dare-34/?action=top]]
- ミニゲーム集で遊んでみる
-- [[バイトヘル2000>http://www.jp.playstation.com/software/title/jp9000npjg00055_000000000000000000.html]] : カルト的な人気を誇るミニゲーム集。ただしミニゲームを全種類集めるのは大変かも……
-- [[G.G シリーズコレクション+>http://www.amazon.co.jp/dp/B003A2IZZ2]] : DSiウェアとして配信したゲームを集めたもの。これもミニゲームを全種類出現させるのは大変
-- [[ナゾのミニゲーム ちょいがえ>http://www.mechanicarms.com/software/nazomini3ds.html]]
-- メイドインワリオシリーズ
- レトロゲームコレクションを参考にする
-- ナムコミュージアム
-- カプコン クラシックス コレクション
-- コナミ アーケード コレクション
-- バーチャルコンソール
-- ゲームアーカイブス
*** 2. ジャンルから発想する [#ubc9ba9b]
ゲームジャンルからアイデアを考える。
- アクション＋タワーディフェンス
- リズムゲーム＋マッチ3ゲーム
- 落ちゲー＋テキストアドベンチャー
- シューティング＋ドットイートゲーム
- ローグライク＋FPS
- クッキークリッカー＋STG
などなど。
[[Wikipedia - コンピュータゲームのジャンル>https://ja.wikipedia.org/wiki/コンピュータゲームのジャンル]]などを参考にすると良いかも
*** 3. 技術的なチャレンジをする [#od24faaa]
新しい技術を導入すると、できることが増える。そしてマンネリ化を打破することができる。しかし技術的な調査に時間がかかって、ゲーム性を考える余裕がなくなるというデメリットもあるので、ほどほどに
- 作ったことないゲームジャンルに挑戦する
- 物理エンジンを導入する
- アニメーションツールを導入する
- スクリプトエンジンやデータベースを組み込んでみる
- ネットワークゲームにする
- ゲームエンジンを使ってみる
*** 4. コンセプト・テーマを決める [#v2670ad7]
難易度は上がるけれども、コンセプト・テーマを決めてそれに沿ったゲームを作る。テーマの考え方のアイデアは以下のとおり
- 国語辞典をランダムに開いて、目に入った単語をテーマにする
-- 四文字熟語やことわざなんかが使いやすいかも
- 映画や小説などのタイトルから借用する
- 流行語をテーマにする
- [[Ludum Dareの過去のテーマ>Ludum Dare#nadaaea0]]に挑戦してみる
*** 5. ルールから組み立てる [#m2ab189d]
#ref(rule_power.jpg,right,around,nolink)
面白いと感じたゲームのルールを抽出し、それを再構築してでゲームを作る方法。1の「他のゲームを参考にする」に近いけれども、「ルール」を抽象化して分解を行い、抽象化した概念を組み立てる、という過程が異なる。
ルールを組み立ててゲームを作る考え方としては、この本がおすすめです。
-[[組み立て×分解! ゲームデザイン ――ゲームが変わる「ルール」のパワー>http://www.amazon.co.jp/dp/4774179442]]
#clear
使いやすそうなルールの例
|''ルール''|''例''|''効果・補足''|h
|ゲームオーバー|自機の死亡。制限時間が「0」になった。ライフの残りが「0」になった|とりあえず入れておけば最低限ゲームとして成立する|
|連鎖|敵をはじき飛ばしてぶつけると、ぶつけた敵もはじき飛ばされる|敵が複数存在しないと成立しない。誘爆との違いは他のオブジェクトを巻き込まない|
|誘爆|爆発に敵が巻き込まれて死亡する|誘爆を有効に機能させるには、発火するオブジェクトを大量に配置・出現させる必要がある|
|コンボ|一定時間内に連続で敵を倒すとボーナス。スコア倍率上昇|コンボによりパワーアップが発生するゲームもある。ハック＆スラッシュ系ゲームと相性が良い|
|アクションの回数制限|弾薬の制限。1回のショットで敵を倒す||
|クールダウン(時間による制限)|弾薬数が一定時間で回復|クールダウン中にやれることがないと退屈なので、複数のアクションを用意して効率よくローテーションするゲーム性にすると良いかも|
|地形の変化|地形が崩れる、足場を動的に作れる、時間で変化する。QIX / ディグダグⅡ / テトリスなどの落ちものパズル||
|強制スクロール|ラン&ジャンプ系ゲーム|プレイヤーを強制的に前に進ませる。ランダムなレベル生成による難易度のばらつきをある程度均一化する効果もある|
|時間制限|残り時間「0」でゲームオーバー。時間経過により敵が強くなる|プレイヤーを強制的に前に進ませる。敵の減少により簡単になっても緊張感が出る|
|探索|レベル内のアイテムをすべて見つけるとクリア。ゴールを探す||
|撃つ＋避ける|シューティングゲームの基本要素|撃つだけのゲーム、避けるだけのゲームにするとカジュアルなゲームになる|
|パワーアップ|ショットの連射速度の上昇|アイテム獲得で上昇することが多い。ゲームに大きな緩急をもたらす。パワーダウン条件も取り入れるとインフレしにくい|
|無敵|敵の攻撃が当たらない。体当たりで敵を倒せる|パワーアップの一種。たいていは時間制限がある。パックマンのように無敵状態でしか敵を倒せないというルールにするとゲームの緩急をつけやすい|
|成長|長期的なパワーアップ。一般的なRPGにおける経験値の獲得によるステータスの上昇||
|慣性|重力。引力。加速度。スーパーマリオなどのアクションゲーム|精密な操作が難しくなるので慣性を強くしすぎると大味なゲーム性になりやすいが、操作に慣れるための習熟過程をゲーム性にしやすい。また物理法則に従っていればプレイヤーが理解しやすい|
|ターン制|1ターンにつき限られたアクション(移動・攻撃など)しかできない|たいていは制限時間がないので、思考を重視するパズルゲームに向いている|
*** 6. アルゴリズムから発想する [#jcfa46b6]
プログラムのアルゴリズムからゲームを発想する。AIの分野が使いやすい？
- 再帰処理
- 逆ポーランド記法
- ハノイの塔
- セルオートマトン
- 群集シミュレーション
- 遺伝的アルゴリズム
[[Wikipedia - アルゴリズム>http://bit.ly/217T2uJ]]の「代表的なアルゴリズム」の項が参考になるかもしれないし、そうでもないかもしれない
*** 7. 他のゲームの一部を切り出す [#k0172475]
他のゲームの一部分を切り出して考える方法です。
具体的な例は以下のゲームです
,Braid,時間巻き戻しの仕組みは「プリンス・オブ・ペルシャの時間を戻すシステムを無限にできるようになったら面白いでは？」という着想
,Downwell,Spelunkyのスーパープレイの爽快感にヒントを得た
,バーンアウト,敵の車に衝突して加速するシステムは、斑鳩の「敵弾に接触することでメリットを得られる」というルールからヒントを得た
これらのように、既存のゲームの一部分に「着目」して、それをうまく「抽出」し、「それをコアとするシステム」に仕上げる、という手法も有効なのかもしれません。
*** 8. オズボーンのチェックリストを使う [#g6dd7bf2]
アイデア発想のためのヒント集
|No|分類|質問|例|h
|1|転用|他に使い道はないか？|既存のものの新しい使い方や、改善、改良をする|
|2|応用|他からアイデアが借りられないか？|似たようなものを探す|
|3|変更|変えてみたらどうか？||
|4|拡大|大きくしてみたらどうか？|「Braid」は「プリンス・オブ・ペルシャ」の時間巻き戻しを無限に使用できるように拡大した|
|5|縮小|小さくしてみたらどうか？|単純化するなど。例えばRTSの防衛の面白さを単純化したのがタワーディフェンス|
|6|代用|ほかのもので代用できないか？||
|7|置換|入れ替えてみたらどうか？||
|8|逆転|逆にしてみたらどうか？|立場を逆転する。例えば「勇者のくせになまいきだ。」のように魔王を主人公にする|
|9|結合|組み合わせてみたらどうか？|ジャンルを混ぜる。例えば「Crypt of the Necro Dancer」はリズムゲーム＋ローグライク|
*** 9. 手段目的構造フレームワーク [#x2861850]
「●●を□□して(手段)、××を△△する(目的)のゲーム」
- ●●を□□して
- ××を△△する
の部分をランダムに言葉を当てはめる、という発想法
- [[どうやってもゲームのアイデアになるEMS Frameworkの紹介>http://pdblog.play-app-lab.com/?p=540]]
■例
- [罠]を[仕掛けて]、[動物]を[捕まえる]ゲーム
- [水]を[撒いて] 、[火事]を[消火する]ゲーム
- [種]を[蒔いて]、[植物]を[育てる]ゲーム
- [商品]を[売って]、[お金]を[稼ぐ]ゲーム
- [銃]を[撃って]、[敵]を[倒す]ゲーム
- [ビル]を[登って]、[屋上]を[目指す]ゲーム