※この記事はゲームの修羅場14 に投稿した記事を加筆・修正した内容となります。

はじめに

15週間(2016/2/4〜5/13)の間、1週間に1つゲーム作る、ということをやっていました。その中でとても貴重な経験が得られたので、それらを紹介したいと思います

なお、作ったゲームは以下のページにまとめています。

http://haxeflixel.2dgames.jp/index.php?Product

なぜ「1週間に1つゲームを作る」などと考えたのか

なぜ「1週間に1つゲームを作る」などと考えたのかというと、数年前からインディーゲーム開発者の中で、ちょっとした話題になっている「Game A Week」というチャレンジに興味があったからです。それと、海外で高い評価を受けているローグライクアクション「Downwell」が「Game A Week」を通して生まれた、ということも気になっていました。そして、ちょうど仕事が暇になったこともあり、挑戦してみることにしました。

Game A Weekとは

「Game A Week」とは、オランダのインディー系デベロッパー「Vlambeer」のRami Ismail氏が書いた「Game A Week: Getting Experienced At Failure」というブログの記事で提唱されたものです。
これは 1週間に1つゲームを作って、ゲーム開発者としての経験値を上げよう というものです。要は、48時間で1つゲームを作る「Ludum Dare」「Global Game Jam」を長期的に行うようなものです。2ちゃんねるの「おまえら土日までに一本ゲーム作るスレ」も近いといえるかもしれません。
それはさておき、Rami Ismail氏によると、「Game A Week」をするなら以下のルールを守ると効果的だよ、と言っています。

ルール	詳細
1. 毎週ゲームを作る	月曜日の12:00にプロジェクトを開始し、日曜日の23:59までにゲームを作り上げること
2. 毎週ゲームをリリースする	作ったものは例えクソゲーでもWebサイトを通じて配信を行うこと。さらにSNSやブログなどでそれを告知すること
3. 作り終えたゲームは修正しない	ゲーム完成後は手を入れてはダメ。どうしても修正したい場合は Game A Week 終了後に行うこと
4. パターン化を避ける	毎週、異なることにチャレンジすること。例えばデジタルゲームを作る代わりにアナログゲームを作る、アクションゲームではなくパズルゲームを作る、など
5. 振り返りを行う	作って良かったところ、間違っていたところ、興味深かったところ、などをまとめておきます。作ったゲームは何人かにプレイしてもらい感想を聞くこと。そしてその感想をまとめておくこと

5の「振り返り」は以下の項目を検討しておくと良いです。

Idea：アイデア。コンセプト。テーマ。元ネタ
What went right：やってみて良かったこと。うまくいったところ。成功したところ。次回に生かせそうなこと
What went wrong：ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点
What I learned：学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど

ちなみに最初にリンクを貼った、作ったゲームの各ページの下の方には、振り返りや作成にかかった時間などを記載しています（以下はノンフィールドRPG「OneWay RPG」を作った時の振り返り)

Game A Weekで得たもの

ということで「Game A Week」を行った結果、私が得たものです。

ゲームを作りながら技術検証できる
ゲームを完成させたときの達成感を繰り返し得られる
ため込んでいたアイデアをはき出せる

人によって得られるものは異なると思いますが、私はこの3つが大きかったと感じました。それぞれを細かく説明していきます。

1. ゲームを作りながら技術検証できる

ゲームを作るには、開発環境で何ができるのか、何が得意なのかを知る必要があります。UnityやUnreal Engineなどのゲームエンジンを使うにしても、いきなり自分の作りたいゲームが作れることはなく、そのゲームエンジンでゲームを作るための方法を学ぶ必要があります。そういった技術検証は、ゲームを作りながら必要な機能を調べる、というやり方が無駄がなく、作りたいものを作るための知識を比較的効率よく学べると思っています。

私の場合は、ゲーム開発環境として「HaxeFlixel」というゲームライブラリを採用しました。しかし、この開発環境は日本ではとてもマイナーな存在で、日本語情報がほとんどありません。なので、ゲームを作りながら何ができるのかを実験しました。HaxeFlixelは、2D横スクロールのジャンプアクションのサンプルデモが充実していて、そのジャンルが得意そうだったので、まずはそれを作ることにしました。
一番最初に作ったのは、「Basement Shooter」というオーソドックスなジャンプアクションで、ゲームデザインを深く考えずに作ったため、つまらないゲームになりました。

しかし、ライブラリが用意しているタイルマップ描画や、地形との当たり判定が簡単にできることなど、HaxeFlixelの機能を大まかに理解することができました。

次に作った「Basement Shooter2」はシューティング要素強めのジャンプアクションです。

敵のAIをStrategyパターンで実装してみたりと技術的な挑戦もあったのですが、ジャンプ要素がないシューティング的な文法でデザインしたため失敗作となりました。この手のゲームを作るのであれば、魂斗羅やガンスターヒーローズを参考にするべきだった、と反省しています。あとAIはプログラムに直接書くよりもスクリプトでデータ化するべきだったように思います。

とまあ、最初の2つのゲームが気合いを入れて作ったのにも関わらずクソゲーだったので、次はできるだけシンプルに作ろうと思い、脱出アクションの「Room666」、キャラクター切り替えパズルアクション「TwinFlip」を作りました。

前の2つが「面白いゲームを作ってやろう」と意気込んで作ったのに対し、これらは肩の力を抜いて作れたので、そこそこ面白いゲームとなりました。

ここから得られたものとして、 技術が積み重なると、ゲームデザインに余裕が生まれ、面白いゲームが作りやすくなる ということを強く実感しました。ここで言う技術とは、プログラムの技術もありますし、ゲームデザインに対する理解も含みます。2Dジャンプアクションを4つ作ったことで、それに対する理解が深まったように感じています。私のゲーム制作のスタイルとして、念入りに脳内でゲームデザインを検証したりするタイプではなく、とりあえず作って試す、といった脳筋スタイルのため、Game A Week は相性が良かったように思います。

そしてその後も、「Hell Ball」というビリヤードゲームを作って物理エンジンの使い方を学びました。また「Flappy Shooter」というシューティングゲームでは、自作のスクリプト言語を、初めて敵のAIに使用して、問題なく動くことが確認できました。
　

また「One Way RPG」というノンフィールドRPGを作ったときには、静的データベースであるCastleDBを導入して、このツールの使い方とアプリケーションでの読み込み方法を調査し、簡単に使うためのモジュールの作成を行いました。また、RPGはユーザーインターフェイスを効率よく作ることが重要なので、HaxeFlixelが持つGUIライブラリを使って、XMLで記述したGUIのレイアウトデータを読み込んで配置できるようにしました。

その他にもステルス系ゲームを作った際には、プレイヤーが敵の視界内に存在するかどうかのアルゴリズムを実装したり、レーザーを撃つゲームを作った際には線分と矩形の交差判定を実装して、自作のライブラリへ組み込み、汎用的に使えるようにしました。

これにより、今後似たようなゲームを作る場合には、かなり楽に実装できるようになったと思います。ノウハウが溜まっていくのも、自分の成長を実感できて楽しいですね。
私の場合は、プログラムを得意としているので、開発効率を上げるツールやライブラリの調査を重点的に行いましたが、絵が描ける人であればアート的な挑戦をしてみたり、作曲ができる人であればサウンド的な挑戦をしてみるのも、良いかもしれません。

2. ゲームを完成させたときの達成感を繰り返し得られる

個人ゲーム開発は基本的に締め切りがないので、延々と作り続けることが可能です。
そして、その結果、完成のメドが立たず開発中止することもあります。私自身も、何ヶ月も作り続けたゲームが全然面白くならなったので、お蔵入りさせたことが何度もあります
ですが、「Game A Week」は期限が1週間と決められているので、例えクソゲーでも1週間の作業が無駄になるだけです。クソゲーであっても完成させれば、完成したという達成感が得られます。
極端なことを言うと、 クソゲーであっても1週間経過すれば次のゲームの開発に移行することができます 。面白くなるかどうかわからないゲームの開発をズルズルと続けてしまうリスクを回避することができるわけです。

私の場合、作ったゲームは会社で毎週発表しました。そうしたら、毎回なんらかの反応を返してくれる人もいて、それが楽しみでゲームを作り続けることができました。そういう意味では、作ったゲームを公に発表できる場があり、ダイレクトに反応が返ってくる環境があったのは、恵まれていたような気がします。

3. ため込んでいたアイデアをはき出せる

私の場合、日頃から作りたいゲームのアイデアをたくさん抱えているのですが、あまり実現はできていませんでした。「なぜ作れなかったのか？」と考えた結果、2つの制約が邪魔をしていることがわかりました。

時間の制約 ：ゲームを作るにはとても時間がかかる。そのため、実際に作ることができるのは、それらのアイデアの中でも「これは面白い！」と思える厳選したアイデアになってしまう
技術的な制約 ：作るのが難しそうなものは最初からあきらめてしまう。自分が作れそうな、実現可能なアイデアを選びがちになる

ですが、「Game A Week」は「失敗してクソゲーになっても良い」ので、面白くなるかどうかわからなくても、実験的なアイデアをどんどん試すことができます。
ゲームはある程度、脳内でシミュレートして面白さを検証することができます。しかし本当に面白いかどうかは、やはり作ってみないとわかりません。私の場合、以前からパズルRPGを作ってみたいと思っていましたが、なかなか時間が取れずに悶々としていました。そしてそのアイデアも面白いかどうか分からなかったので、そのゲームを作る時間はないなぁ……、などと思っていました。ですが、「Game A Week」を続けていたときに、そのアイデアを思い出してパズルRPGを作りました。それがターン制のパズルRPG「Super Puzzle RPG」です。

パネルを消すと、その消したパネルの数に応じて敵にダメージを与えることができる、パズドラのようなゲームです。
作った結果、このゲームが面白いものになったのかというと……、正直、いまひとつでした。まあ作る前にすごく面白くなるという確信がなかったので、当たり前といえば、当たり前かもしれません。ですが、「面白くなるかどうかわからない」アイデアを脳内に残したままにしておくよりは、遊べるゲームという形にして頭の中から追い出すと、とてもスッキリします。また「遊べるゲーム」にしたことで、似たようなアイデアを思いついた際、その検証がやりやすくなるのではないかと思います。

Game A Weekの欠点　その1

とまあ、「Game A Week」の良いところばかりを書いてきましたが、欠点があります。一番大きいのは、やはり 1週間で1本ゲームを作らなければならない ということです。
このノルマはとてもハードで、「Game A Week」を始めるとそれを中心した生活にならざるを得ません。

今週はゲームを作る時間はどうやって確保しようか……？」
「うーん、次回のゲームは何を作ろうか……？」
「来週は時間がないから、Flappy Birdでも作るか……」

などと、毎日、夕ごはんのメニューに悩む奥様のごとく、ゲーム開発を常に考えるようになってしまい、日々の生活にプレッシャーがかかります。
この問題への対策は、究極的には「頑張れ！」という根性論しかないのですが、「再利用しやすいように作る」という時間短縮の工夫をしていくのも大切です。

タイトル画面やエンディングは毎回同じでよい
ゲーム開始演出やゲームオーバーのリトライ処理は使い回すようにする
BGM / SE は毎回同じものでよい
画像も毎回同じでよい

これは私の勝手な解釈ですが、「新しいゲームのアイデアを試すことができれば、素材は全く同じでも良い」と考えています。
そして「再利用しやすい技術」の検証ができるゲームを早めに作っておくのも良いかもしれません。敵のパラメータを設定するのにExcelのような表形式のデータを読み込める仕組みを作っておけば、その後に作るゲームで使い回ししやすいと思います。
私の場合は、自作スクリプトでシューティングの敵のAI (敵の行動・弾幕パターンが定義できる) を実装してからは、シューティングを作るときは、そのスクリプトを使い回して制作時間を短縮できるようになりました。
それと、時間がないときのために「簡単に作れるゲームアイデアをストックしておく」のも有効かもしれません。例えば、ワンタップで遊べるゲーム (Flappy Birdみたいなもの) は時間の確保が難しい忙しい週に作るようにします。逆に（個人的には）時間のかかる、ターンベースのRPGのような非リアルタイムかつシステム寄りのゲームは、時間が取れそうなときに作るようにしました。

Game A Weekの欠点　その2

「Game A Week」のもう1つの欠点があります。それは、クリアするのに何時間もかかるようなやり込み要素のあるゲームや、複合的なゲームメカニクスを持つゲームを作るのは、期間的に難しいということです。「Game A Week」が向いているのは、ミニゲームであったり、アイデア勝負の一発ネタのゲーム、というような単一のゲームメカニクスを持ったゲームを作ることです。
作りたいゲームが明確に存在していて、技術的な検証も特に不要、と考えているのであれば、「Game A Week」はあまり役に立たないかもしれません。
ただ、

新しい環境や技術を試してみたい
（面白くなるかわからないけど）新しいアイデアを試してみたい
作りながら面白いゲームのアイデアを考えたい

というように、手を動かしながら色々な実験をしてみたいという方には向いている気がします

参考

今回の記事を書くにあたって、参考にしたWebページです。

もし、「Game A Week」についてより詳しく知りたいのであれば、これらの記事をたどってみてもよいかもしれません。