phaser-brainstorm

Phaser 4 ゲームのブレインストーミング

設計書の前のステップです。GDD は ゲームがどう動くか に答えますが、これが答えるのは どのゲームが取り組む価値があり、この人がそれを完成できるか です。

放棄されたゲームプロジェクトのほとんどは、作り方が悪かったわけではありません。スコープの設定が 悪かったのです — アイデアが、使える時間とスキルに対して見積もられることがなく、最初のコードを 書く前に失敗が確定していました。

---

実際に固定されているものから始める

アイデアをひとつ生み出す前に、この4つを問いかけてください。これらは、どれだけアイデア出しを しても排除できない多くの可能性を排除してくれますし、今排除するほうが安く済みます：

質問	なぜ物事を決めるのか
どれだけ時間があるか？ 週末、1か月、1年？	最も強力な制約です。週末のゲームと1年のゲームは、同じものの大きさ違いではなく、別の 種類 のものです。
これは誰のためか？ ジャム、ポートフォリオ、有料の観客、自分自身？	ポートフォリオ作品は、印象的な30秒のために最適化します。商業ゲームは、20時間目のために最適化します。
何を作れる、または手に入れられるか？ アート、オーディオ、両方、どちらも無理？	誰も絵を描けないなら、それが問題にならないゲームにする必要があります — そしてそれは謝るべき制限ではなく、実際の設計上の制約です。
これまでに何を完成させたか？	次に何を完成させるかの最良の予測因子です。最初のゲームと5作目のゲームには、それぞれ異なるアドバイスがふさわしいです。

ユーザーが乗り気に見えるからといって、アイデアに飛びつかないでください。これらなしで 生み出されたアイデアはコイントスであり、間違った大きさのプロジェクトへの熱意こそが、次の6か月を 費やすまさにその方法です。

---

次にフックを見つける

ゲームのコンセプトには、誰かを遊びたくさせられる一文が必要です。ジャンルではありません — ジャンルは棚であって、アイデアではありません。

フックではない	フック
「プラットフォーマー」	「音楽が流れているときしか動けないプラットフォーマー」
「タワーディフェンスゲーム」	「タワーが、あなたが倒した敵であるタワーディフェンスゲーム」
「RPG」	「パーティメンバー全員が、あなたが自分をどう扱ったかを覚えている RPG」

テスト：誰も予想しない動詞を含む一文で、それを説明できますか？ その文がジャンルに形容詞を足しただけなら、さらに考え続けてください。

「もっと考える」よりもうまくいくことの多い、フックの見つけ方：

• 慣習を逆転させる。 このジャンルのすべてのゲームが当然のこととしているのは何でしょう？ プラットフォーマーは、いつジャンプするかを自分が操作するものと想定しています。ステルスゲームは、 見られないことを望むものと想定しています。
• ひとつのメカニクスを別の場所へ持っていく。 レーシングゲームでのデッキ構築。恋愛シミュレーション でのタワー配置。
• 制約から始める。 ボタンひとつ。画面ひとつ。負けなし。テキストなし。
• 感情から始める。 「すべてに少し遅れていること」。「片づけをすること」。そして、それを生み出す メカニクスを見つける。
• 実際に作れるものから始める。 作れるアートがシルエットだけなら、影についてのゲームは妥協では ありません — アートディレクションがすでに解決されたコンセプトです。

---

正直に見積もる

これはゲームをリリースするかどうかを決めるステップです。具体的に、そして嫌われることを恐れずにやりましょう。そうしなければ、半年後に間違っていたことが判明するだけです。

規模	現実的な対象	内容
週末 / ジャム	ひとつのメカニクスを丁寧に作り込む	1種類のシーン、敵1〜2体、3〜5レベルまたはエンドレス
1〜2週間	ひとつのメカニクスと進行要素	メニュー、ゲームプレイ、ゲームオーバー、8〜12レベル、セーブ
1〜2か月	小規模で完成したゲーム	3〜4のメカニクス、20以上のレベルまたはプロシージャル、音声、磨き込み
3〜6か月	商業向けの小規模ゲーム	完全な進行、コンテンツの多様性、チュートリアル、設定、リリース
1年以上	ここから始めてはいけません	—

すべての見積もりを3倍にしてください。冗談ではありません。これはゲーム開発者が見積もる値と実際に計測する値の間でおおむね観察される比率であり、経験レベルを問わず当てはまります。

時間が実際にどこへ消えるのか。 人はコアメカニクスだけを見積もり、それ以外を忘れてしまいます。

作業	プロジェクトに占める割合
コアメカニクス	20%
メニュー、設定、セーブ、ポーズ、トランジション	25%
コンテンツ — レベル、敵、バランス調整	30%
音声、演出、磨き込み	15%
バグ、プラットフォームの問題、リリース	10%

コアメカニクスが完成した「シンプルなプラットフォーマー」は、完成間近どころか20%しか進んでいません。この表は、自分はもう少しで完成すると思っている人に見せる、もっとも役立つ一枚です。

収まるように削る

アイデアが時間に収まらないときは、コンテンツを削り、フックは削らないでください。優れたメカニクスがひとつと4つのレベルがあるゲームは完成しています。5つのメカニクスが半分だけ作られたゲームは、ゲームではありません。

削るもの	残すもの
レベル、敵、武器の数	それを面白くしているたったひとつのもの
マルチプレイヤー	操作感と反応性
ストーリー、カットシーン、ボイス	コアループ
プロシージャル生成	動作するセーブ/ロード
複数のエンディング	ひとつのエンディング

マルチプレイヤーには独自の警告が必要です。それは機能をひとつ追加するのではなく、プロジェクト全体を倍増させます。ネットコード、同期、ロビー、そしてあらゆるバグが2倍のバグになります。マルチプレイヤーがフックそのものでない限り、削ってください。

---

着手する前に圧力をかけて検証する

6つの質問です。ここでの弱い答えは、今なら安く発見でき、3か月目なら高くつきます。

1. プレイヤーは一瞬一瞬、何をしているのか? 答えに段落が必要なら、ループはまだ明確ではありません。「床が崩れる中でプラットフォームの間をジャンプする」は明確です。
2. なぜ2分目は1分目より面白いのか? 答えがなければ進行がなく、そのゲームはおもちゃです — ジャムならそれでよく、それより長いものには致命的です。
3. プレイヤーは何を間違え、どうやって学ぶのか? 失敗状態のないゲームには緊張感がなく、教えられない失敗があるゲームはただ不公平なだけです。
4. アイデアが機能することを証明する最小のバージョンは何か? それがプロトタイプであり、数週間ではなく数日で作るべきものです。
5. これを殺しうるものは何か? 技術的なリスクを今、挙げてください。「物理の操作感を正しく作れるかわからない」は、6週目に発見するものではなく、最初にプロトタイプすべきものです。
6. あなた自身はこれを遊ぶか? 「売れるか」ではありません。正直な答えが「いいえ」なら、それに6か月を費やすのは、聞こえるよりもつらいものになります。

---

Phaser 4 は適しているか？

Phaser は 2D WebGL エンジンです。いくつかのことにおいては優れていますが、そうでないことには誤った選択です。そして、この段階でそう言ってあげるほうが親切です。

非常に適している: プラットフォーマー、トップダウンアクション、パズル、タワーディフェンス、シューティング、カードゲームやボードゲーム、ローグライク、エンドレスランナー、ビジュアルノベル、タイルベースのあらゆるもの、そしてブラウザで動作することを意図したあらゆる 2D ゲーム。

努力次第で実現可能: 物理演算を多用するサンドボックス（Matter は有能ですが要求も高いです）、大規模なオープンワールド（チャンク化とカリングが必要です）、リズムゲーム（本当の問題はブラウザのオーディオレイテンシーであり、Phaser ではありません）、リアルタイムマルチプレイヤー（Phaser はクライアント専用であり、サーバーは別プロジェクトです）。

誤ったツール: 3D。Phaser 4 のレンダラーは 2D です — 本格的な 3D は計画されていますが、まだありません。Three.js や Babylon を使用してください。また、テキストのみのゲームも同様で、こちらは Web フレームワークのほうがシンプルです。

Phaser 4 が特にもたらすもの: Beam レンダラーは v3 よりもはるかに多くのオブジェクトを画面上で処理できます。フィルターはあらゆるオブジェクトに適用できます。SpriteGPULayer により弾幕の物量が現実的に扱えます。コーンライトによりステルスの視界コーンを低コストで実現できます。アイデアがライティング、エフェクト、あるいは純粋なスプライト数に依存するなら、v4 は実現可能なコストを変えました — skills/phaser-fx/ を参照してください。

---

何を生み出すか

選択肢のリストではなく、ユーザーが行動に移せるもので締めくくってください:

1. コンセプトを、フックが見えるように一文で。
2. スコープの判断を、時間の予算と、収めるために何を削ったかとともに。
3. プロトタイプを具体的に記述します: 何を含み、何を証明し、どのくらいかかるべきか。日数単位で。
4. 名前を付けたリスク — 最も失敗させそうな一つのことと、プロトタイプがそれをどう検証するか。
5. 次のステップ: 設計書を書くなら /phaser-gdd、すぐにスキャフォールドしてプロトタイプを作るなら /phaser-new。

ユーザーが複数のアイデアを持ち込んだ場合は、一つを推薦し、その理由を述べてください。ランク付けされたリストは決断を避ける方法であり、決断こそがユーザーが求めているものです。

---

設計の前にプロトタイプ

ゲームジャムより長いものについては、GDD を書く前にプロトタイプを作ってください。まだ誰も体感していないメカニクスの設計書はフィクションです — 実際には感じが悪いと判明するジャンプについて、あなたは 3 ページ書くことになります。

プロトタイプは一つの問いに答えます: コアメカニクスは気持ちいいか？ 色の付いた矩形で十分です。メニューも、アートも、オーディオも、セーブも不要です。

/phaser-new              # scaffold
# build the one mechanic
/phaser-playtest         # verify it actually runs

そしてプレイしてください。矩形の状態で楽しくないなら、アートはそれを救いません — そしてそれを 3 か月ではなく 3 日で見つけられることが、このステップ全体が生み出す単一で最も価値の高いものです。

---

追加リソース

参照ファイル

• references/ideation-prompts.md — ユーザーが行き詰まったときのための構造化された生成ツール: 制約プロンプト、メカニクスの反転、ジャンルのマッシュアップ、そして漠然とした感覚を具体的なメカニクスに引き出す質問。
• references/scope-calibration.md — 実際のゲームの形に対する具体的なスコープの内訳、システム別の時間見積もり、プロジェクトが長引いたときの削減リストの順序。

関連

• skills/phaser-gdd/ — 次のステップ: 合意されたコンセプトを設計書に変える
• skills/phaser-init/references/template-archetypes.md — 9 つの既成アーキタイプ。出発点としても、各ジャンルが実際に何を含むかの感覚をつかむのにも役立ちます
• skills/phaser-architect/ — 設計が存在した後の技術アーキテクチャ