game-prototype

AlterLab GameForge -- 仮説駆動型プロトタイピング

プロトタイプはデモではなく、実験です。すべてのプロトタイプは、ただ一つの問いに答えるために存在します。「これは作る価値があるか？」プロトタイプを磨き始めた時点で、プロトタイピングは終わり、開発を始めています。そして、間違ったものを作っている可能性があります。Undertale の初期デモは粗削りで見栄えも悪いものでしたが、たった一つのことを証明しました。弾幕シューティングと RPG を融合させたメカニクスには、フルゲームを作る価値があるということです。Hollow Knight は、雰囲気のある 2D 世界での緊張感ある戦闘を検証した、ゲームジャムのプロトタイプから始まりました。Celeste は PICO-8 のプロトタイプとして始まり、一つのアイデアを実証しました。8x8 ピクセルの解像度で、精密な空中ダッシュを使ったプラットフォームアクションは、驚くほど気持ちよいということです。このワークフローでは、同じ規律を徹底します。仮説を立て、必要最小限のテストを作り、実際のプレイヤーを観察し、証拠に基づいて採用か破棄かを二者択一で判断します。

目的と開始条件

このワークフローを使う場面：

• チームメンバーが新しいメカニクスを提案し、「リリースしよう」ではなく「実証しよう」と返すべき場合
• デザインドキュメントに、実際のプレイヤーで一度もテストされていない前提が含まれている場合
• どちらがよりよい感触かを見極めるため、競合する 2 つのメカニクス案を直接比較する必要がある場合
• 書面上では魅力的に思える機能について、チームが楽しいかどうかを直感的に判断できない場合
• エンジニアリングリソースを投入する前に、プリプロダクションでコアとなるループを検証する必要がある場合
• ピボットを検討しており、新しい方向性の実現可能性を迅速に確認する必要がある場合

このワークフローを使わない場面：

• メカニクスが十分に理解されており、類似ゲームですでに検証されている場合（そのまま適切に開発してください）
• ステークホルダー向けのプレゼンテーション用に垂直スライスが必要な場合（それはデモであり、プロトタイプではありません）
• 問いがメカニクスではなくコンテンツに関する場合（コンテンツの問いには、プロトタイピングではなくプレイテストが必要です）

重要なルール

1. プロトタイプごとに仮説は一つ。 2 つのことをテストするなら、プロトタイプは 2 つ必要です。仮説を組み合わせると結果が混乱します。失敗したとき、どちらが原因だったのかわからなくなります。
2. 時間を区切り、守れなければ中止。 すべてのプロトタイプには、厳格な時間制限を設けます。最長で 1〜3 日です。その期間内に仮説をテストできないなら、スコープが大きすぎます。さらに細分化してください。
3. プロトタイプのコードは危険物です。 プロダクションに移行させてはいけません。絶対にです。仮説が検証されたら、適切なアーキテクチャで本番実装を一から始めます。プロトタイプのコードをプロダクションに流用すると、技術的負債が生まれます。Celeste の PICO-8 プロトタイプは完成版とコードを一切共有していません。感触を実証した後、本番の開発はクリーンな状態から始まりました。
4. 見た目が粗いのは正解です。 キャラクターには色付きの四角形、サウンドは仮のもの、アートはプログラマーアート、ラベルには Comic Sans を使います。プロトタイプのビジュアル品質について誰かがコメントしたら、その目的を理解していません。Hollow Knight のゲームジャム版プロトタイプでは、シンプルなシルエットが使われていました。雰囲気は後から生まれ、まず感触を確かめたのです。
5. 意見ではなく行動を観察する。 プレイヤーは、あなたが聞きたいと思っていることを話します。彼らが実際に何をするかを見てください。「まあ、よかったよ」と言いながら、身を乗り出して 20 分間続けてプレイしたプレイヤーは、その言葉から想像するのとは異なるデータを示しています。
6. ためらわずに破棄する。 仮説が誤りだと証拠が示しているなら、プロトタイプは破棄します。アイデアがどれほど巧妙だったか、自分がどれほど気に入っているか、作るのにどれだけ時間をかけたかは関係ありません。Supergiant は絶えずプロトタイプを破棄しています。同社の GDC 講演では、テスト段階を通過せずに消えていった数多くのメカニクスが明かされています。チームは愛着よりも証拠を信頼しているのです。
7. プレイヤー体験に関する仮説を立てるときは、共通の理論的枠組み（MDA、フロー理論、SDT）を参照するため、必ず docs/game-design-theory.md を確認してください。

ワークフロー

ステップ 1：仮説を定義する

次の正確な形式で仮説を書いてください。「私たちは、[特定の条件]において[メカニクス／システム]が[プレイヤーの行動／感情]を生み出すと考えています。」 次に、反証基準を定めます。つまり、どのような証拠があれば仮説が否定されるのかを明らかにします。ここが最も重要な部分です。失敗がどのような状態か定義できない場合、その仮説は反証不可能であり、検証もできません。

強い仮説の例：

• 「勢いを維持できるグラップリングフックがあれば、プレイヤーが地面に触れずに3回以上スイングを連続させたとき、移動が爽快に感じられるはずです。」
• 「非対称な協力プレイの役割（1人は建築、もう1人は防衛）では、建築役にしか見えない脅威があるとき、自然発生的なコミュニケーションが生まれるはずです。」
• 「回復が目に見えるスタミナシステムでは、プレイヤーが2体の敵に直面し、休まずに両方を倒せない状況で、戦術的な緊張感が生まれるはずです。」

弱い仮説の例（およびその理由）：

• 「戦闘が楽しい」――反証不可能です。楽しいとは何でしょうか。どのような条件で、誰にとって楽しいのでしょうか。
• 「プレイヤーはアートスタイルを気に入る」――これはメカニクスではなく、コンテンツに関する問いです。このためにプロトタイプを作る必要はありません。
• 「マルチプレイヤーにすればゲームが良くなる」――範囲が広すぎます。具体的にどのようなマルチプレイヤーのやり取りでしょうか。「良くなる」とは、どのように測定できるのでしょうか。

仮説を、docs/game-design-theory.md のMDAフレームワークに照らし合わせます。どの美的体験を目指していますか（Sensation、Fantasy、Narrative、Challenge、Fellowship、Discovery、Expression、Submission）？ これにより、仮説を確立された理論に基づいて考えられ、何を成功とするかを定義しやすくなります。

ステップ2：思い切って範囲を絞る

「この仮説を検証するために必要な、絶対最小限の実装は何か？」と問いかけます。その後、さらに半分に削ります。

必要のないもの：

• メニューシステム。テストシナリオからプロトタイプを直接開始します。
• 複数のレベル。1つの部屋、1つの遭遇、1つの状況で十分です。
• セーブ／ロード機能。誰もこれを10分以上プレイしません。
• オーディオ。仮説がオーディオに関するものの場合（例：リズムベースのメカニクスを検証する場合）を除きます。
• プレイヤーが中核となる操作を理解するために必要な範囲を超えるUI。
• アニメーション。状態間を補間します。位置を瞬時に切り替えます。必要ならテレポートさせます。
• エッジケースへの対応。プロトタイプでプレイヤーがバグを見つけたら、おめでとうございます。探索が進んでいます。記録して先に進みましょう。

必要なもの：

• 中核となる入力からフィードバックまでのループが、最大速度で動作すること。メカニクスの「感触」に関する仮説を検証する場合、入力遅延と応答タイミングは実際のものを反映している必要があります。
• 仮説を検証するのに十分なゲーム状態。リソース管理の緊張感を検証する場合、資源の不足を生み出す最低限の経済システムが必要です。
• 素早くリセットできる方法。テスターは複数回プレイします。再開に30秒かかると、テストの速度が落ちてしまいます。

列がちょうど3つのスコープチェックリストを作成します： | 必須（仮説を検証） | あるとよい（テストを明確にする） | 対象外（本番開発に回す） |

「必須」列の項目が5つを超える場合、範囲を十分に絞れていません。戻って分解しましょう。

ステップ3：粗く作る

キャリアの中で、悪いコードが正解となるのはこのときだけです。

• すべてをハードコードします。マジックナンバーをふんだんに使います。設定ファイルも、データ駆動の仕組みも不要です。
• 可能ならスクリプトファイル1つにまとめます。アーキテクチャも、関心の分離も、デザインパターンも不要です。
• 抽象化する代わりにコピー＆ペーストします。72時間後には削除されるコードを書くのです。
• 使えるベストプラクティスをすべて無視することになっても、プレイ可能にするための最速の方法を使います。
• エンジンにビジュアルスクリプティングシステム（Blueprints、Bolt、VisualScript）があれば、それを使います。使い捨てのロジックをより速く反復できます。
• メインリポジトリには何もコミットしません。プロトタイプのコードは、使い捨てブランチか、判断後に削除する別フォルダーに置きます。

ビルドフェーズに費やす時間は、全体の60％以内にしてください。3日間のうち2日をビルドに費やすと、テストに0.5日、分析に0.5日しか残りません。それでは足りません。40／30／30の配分を目指します。ビルドに40％、テストに30％、分析に30％です。

ステップ4：構造化された評価 単独でテストしないでください。自分のプロトタイプを自分で評価して得られるデータは、収集できるデータの中で最も価値が低いものです。

最低限のテスト：開発チームに所属していない3～5人にプロトタイプをプレイしてもらい、あなたは黙って観察します。

観察プロトコル：

• **黙って観察するだけにしてください。**説明したり、助けたり、ヒントを出したり、反応したりしないでください。プレイヤーが戸惑ったら、何に、なぜ戸惑ったのかを記録してください。行き詰まったら、その箇所を記録し、案内をする前に少なくとも60秒は試行錯誤させてください（介入が必要になったこと自体も、発見事項として記録してください）。
• **すべてを記録してください。**最低限、画面を録画します。可能であれば、顔もカメラで撮影します。プレイヤーが抵抗を感じない場合は、発話思考法のプロトコルも実施します。
• **タイムスタンプ付きの出来事を記録します：**目に見える苛立ち、目に見える喜び、戸惑い、プレイヤーが考えるために立ち止まる瞬間（戦略的な没入）、プレイヤーが興味を失う瞬間（スマートフォンを確認する、視線をそらす）。
• セッション後の質問（最大3～5問に絞ります）：
  1. 「何をしようとしていましたか？」（中心となるメカニクスの理解度をテストします）
  2. 「とても気持ちよく感じた瞬間はありましたか？」（喜びのピークを特定します）
  3. 「苛立ちを感じた瞬間はありましたか？」（摩擦点を特定します）
  4. 「もう一度プレイしたいですか？」（率直な継続率の指標です。答えるときのボディーランゲージのほうが、言葉より重要です）

docs/game-design-theory.mdのフロー理論の観点を適用します：プレイヤーはフロー状態に入ったように見えましたか？難易度とスキルのバランスは適切な範囲にありましたか？不安（難易度が高すぎる）や退屈（難易度が低すぎる）を感じていましたか？

Step 5: 中止か昇格かの判断

これは二者択一の判断です。「たぶん」も「プロトタイプを反復しよう」もありません。仮説が検証されたか、されなかったかのどちらかです。

中止の基準（いずれか1つを満たせば十分です）：

• テスター5人中2人未満しか、目標とする行動や感情を示さなかった
• 正しく機能している場合でさえ、中心となるインタラクションが意図した感情を生み出さない
• メカニクスを理解するのに詳しい説明が必要（自然に使い始めてもらえないことを示しています）
• 「楽しさ」がテスト対象のインタラクションではなく、二次的なインタラクションから生じていた（何が魅力的なのかについての仮説が誤っていました）
• プレイヤーが、意図したインタラクションを不要にする、攻略の余地が大きすぎる戦略を見つけた

昇格の基準（すべてを満たす必要があります）：

• テスター5人中少なくとも3人が、促されることなく目標とする行動や感情を示した
• 中心となるインタラクションが、時折ではなく安定して意図した感情を生み出す
• 少なくとも1人のテスターが、促されることなく「もう一度プレイしてもいいですか？」に相当することを言った
• 中心となる課題を無意味にするような、攻略の余地が大きすぎる戦略が見つからなかった
• メカニクスが少なくとも1つのデザインの柱に沿っている（プロジェクトのビジョン文書と照合してください）

プロトタイプを中止する場合：

• 学んだことを記録します。実験の失敗にも価値があります。可能性を1つ排除できたからです。
• 発見事項をチームと共有します。失敗したプロトタイプがあれば、後のチームが同じ行き止まりをテストせずに済みます。
• プロトタイプのコードを削除します。保管ではなく、削除してください。役割は終わっています。

プロトタイプを昇格させる場合：

• 本番実装向けのデザイン概要を作成します。プロトタイプで実証できたことと、まだ設計が必要なことを明記してください。
• 本番実装はゼロから始めます。プロトタイプのコードを引き継いではいけません。
• プロトタイプで答えられなかった未解決の質問を特定し（必ずいくつかあります）、それらに対処するためのプレイテストを計画します。

出力形式

## Prototype Report: [Prototype Name]
## Date: [YYYY-MM-DD]
## Time Budget: [X days allocated, Y days used]

### Hypothesis
[Full hypothesis statement in the required format]

### Falsification Criteria
[What evidence would disprove this hypothesis]

### MDA Alignment
- Target Aesthetic: [which MDA aesthetic this tests]
- Relevant Design Pillar(s): [which project pillars this serves]

### What Was Built
[2-3 sentence description of the prototype]
[Screenshots or video links]

### Scope Decisions
| Must Have | Nice to Have | Out of Scope |
|-----------|-------------|--------------|
| [items]   | [items]     | [items]      |

### Observation Notes
| Tester | Key Observations | Delight Moments | Friction Points | Flow State? |
|--------|-----------------|-----------------|-----------------|-------------|
| P1     | [notes]         | [moments]       | [points]        | [Y/N/Partial] |
| P2     | [notes]         | [moments]       | [points]        | [Y/N/Partial] |
| ...    |                 |                 |                 |             |

### Evidence Assessment
**For the hypothesis:**
- [Observation supporting the hypothesis]
- [Observation supporting the hypothesis]

**Against the hypothesis:**
- [Observation contradicting the hypothesis]
- [Observation contradicting the hypothesis]

### Decision: [KILL / PROMOTE]
**Reasoning:** [2-3 sentences explaining the decision based on evidence]

### Lessons Learned
- [Insight 1 -- applicable beyond this prototype]
- [Insight 2]
- [Insight 3]

### Next Steps
- If KILL: [What alternative approaches might work, or what to test next]
- If PROMOTE: [Design brief summary for production implementation, open questions remaining]

品質基準

• 仮説の明確さ：初めて読む人が仮説を読んで、何を検証しているのか正確に理解できますか？前提知識や専門用語が必要なら、明確さが足りません。
• スコープの規律：プロトタイプの作成を時間予算の60％未満で終え、テストと分析に十分な時間を残せましたか？
• 証拠の質：観察内容は行動（プレイヤーがしたこと）に基づいていますか、それとも感想（プレイヤーが言ったこと）に基づいていますか？行動に基づく証拠は、感想に基づく証拠の5倍の価値があります。
• 判断の健全性：終了／継続の判断は、証拠から論理的に導かれていますか？観察データだけを使って、懐疑的な相手にもその判断を説明できますか？
• 学びの抽出：レポートには、この特定のプロトタイプ以外にも応用できる知見が少なくとも1つ含まれていますか？実験を通じて、自分のゲーム、プレイヤー、またはゲームデザインそのものについて何かを学べる必要があります。
• アンチパターンの回避：プロセス中にアンチパターン（スコープの拡大、磨き込みへの誘惑、プロトタイプから製品への流出）が発生した場合は、レポートに明記してください。

仮説とMDAの対応付けリファレンス

仮説がMDAフレームワーク（docs/game-design-theory.md）の特定のプレイヤー体験に焦点を当てていることを、このクイックリファレンスで確認してください。明確に定義された体験に対応しない仮説は、たいてい漠然としすぎているか、デザイン上の問いではなく技術的な問いを検証しています。

MDAの体験	プロトタイプで検証する内容	仮説の兆候の例
感覚	刻々と変化する感触――爽快感、ゲームの手応え、フィードバックの応答性	プレイヤーが前のめりになる、自発的に何かの「感触」について話す
ファンタジー	役割への没入――プレイヤーはキャラクターになりきったと感じるか	プレイヤーが「自分」を主語にした表現を使う：「あれをしたとき、力強さを感じた」
物語	物語の理解と没入度	プレイヤーが次に何が起こるか尋ねる、物語の筋道に基づいて判断する
挑戦	難易度の調整、公平な失敗	プレイヤーが苛立たずにすぐ再挑戦する、「あと少しだった」と言う
仲間意識	マルチプレイヤーにおける交流の質	プレイヤーが自然に会話する、笑いや交渉が起こる
発見	探索への動機と報酬	プレイヤーが自発的に重要な経路から離れる
自己表現	プレイヤーの創造性とパーソナライズ	プレイヤーが最適化だけでなく、自分らしさを反映した選択をする
没入	放置状態での関与、気軽な反復	プレイヤーが静かでリズミカルな状態になり、体の動きがリラックスする

仮説が複数の体験に対応する場合、問いを組み合わせています。仮説を分けてください。

注意すべきアンチパターン

「プロトタイプを少しだけ整えましょう。」 いいえ。整えているのではありません。使い捨てコードに思い入れを持ち始めているのです。やめましょう。仮説が検証されたら、一から適切に作り直します。検証されなければ、いずれ捨てるものを磨くのに時間を費やしただけです。

「プロトタイプが動くので、そのままリリースしましょう。」 いいえ。プロトタイプのアーキテクチャではスケールしません。プロトタイプのコードには、エラー処理も、例外的なケースへの対応も、アクセシビリティも、ローカライズ用の仕組みも、セーブシステムも、テレメトリーもありません。プロトタイプをリリースすると、技術的には動くものの、コンテンツの追加やバグ修正に着手した途端に破綻するゲームができあがります。

「プロトタイプに機能をもう一つ追加しましょう。」 いいえ。スコープが膨らんでいます。仮説はステップ 1 で定義しました。その仮説を検証するのに想定していなかった機能が必要なら、仮説のスコープ設定が不適切だったか、最初に設定したものとは別の問いを検証しているかのどちらかです。ステップ 1 に戻りましょう。

「データがもっと必要です。20 人でテストしましょう。」 いいえ。プロトタイプの段階では不要です。二者択一の判断材料を得るには、テスター 3～5 人で十分です。5 人がプレイしても結果が曖昧なら、おそらく答えは「中止」です。強力なメカニクスなら、少人数のサンプルでも明確にわかります。

「うまくいかなかったけれど、もっと時間をかければ……」 サンクコストの誤謬は、ゲーム開発で最も高くつくバイアスです。3 日かけても仮説を検証できなかったのなら、さらに時間をかけても解決しません。仮説が間違っているか、スコープが大きすぎるかのどちらかです。内容を練り直し、焦点を絞ってもう一度試しましょう。

プロトタイプの忠実度レベル

すべてのプロトタイプをデジタルにする必要はありません。仮説に最も早く答えを出せる忠実度レベルを選びましょう。

レベル	方法	最適な用途	所要時間	現実度
紙	インデックスカード、サイコロ、テーブル上のトークン	ターン制メカニクス、経済システム、カードゲームのループ、ボードゲーム風の構造	数時間	低い — ただし反復は速い
テーブルトップ・デジタル	スプレッドシートによるシミュレーション、またはサイコロを振るスクリプト	バランス調整、確率分布、進行度の計算	1～2 時間	数値の現実度は中程度、プレイ感はゼロ
使い捨てデジタル	1 つのシーン、ハードコードした値、プログラマーアート	リアルタイムのプレイ感、入力からフィードバックまでのループ、空間的なメカニクス	1～3 日	プレイ感の現実度は高く、コンテンツの現実度は低い
仕上げ済みプロトタイプ	プレースホルダーのアートを使った、整理済みの使い捨てプロトタイプ	ステークホルダーのレビュー、投資家向けデモ、チームの士気の検証	1 週間	高い

判断基準： 仮説を検証できる最低限の忠実度レベルから始めましょう。スタミナシステムの経済性は、スプレッドシートを使えば 30 分で検証できます。グラップリングフックのプレイ感を確かめるには、デジタルプロトタイプが必要です。紙で十分なのにデジタルから始めると、時間の予算の 80％を無駄にします。

競合デザインの比較テストプロトコル

競合するデザインが2つある場合は、順番にテストするのではなく、同時にテストしてください。順次テストでは、時間的な変数（テスターの気分、その分野に対するチームの慣れ、外部の出来事）が混入します。同時にテストすれば、デザインの変数だけを切り分けられます。

準備：

1. 仮説をテストするために必要な最小限の範囲で、両方の実装を作成します。
2. テスターを2つのグループに分けます（各グループ最低3人、合計最低6人）。
3. 各グループがプレイするのは1つのバージョンのみです。同じセッション中に、両方をプレイするテスターはいません。
4. 両グループで、同一の観察プロトコルと振り返りの質問を使用します。
5. 可能であれば、研究者は振り返りの際に、テスターがどちらのバージョンをプレイしたかを知りません（ブラインド評価）。

分析：

• まず行動データを比較します（フロー状態の継続時間、ためらった回数、感情の高まり）。発言データは二次的なものです。
• どちらかのバージョンが明らかに強い行動シグナルを生み出した場合は、チームの好みにかかわらず、そのバージョンを採用します。
• 結果が決め手に欠ける場合（両方のバージョンのスコアが同程度の場合）、仮説の差別化が不十分だったということです。両方のデザインを改良し、再度テストします。
• 負けたバージョンも含め、各バージョンで検証できたことを記録します。勝者よりも敗者から多くの学びが得られることもよくあります。

アンチパターンに注意： テスターの様子を見た後に、どちらのバージョンが優れているかをチームで投票してはいけません。チームの好みには、作者バイアスが混入します。行動データに基づいて判断してください。

ソロ開発者向けの工夫

ソロ開発者には構造的な問題があります。自分で作ったプロトタイプをプレイしている自分自身を、客観的に観察することはできません。次の方法で対処してください。

1. 時間を置いてテストする。 プロトタイプを作成したら、自分でプレイするまで48時間待ちます。記憶が十分に薄れるため、新規プレイヤーに近い感覚で臨めます。理想的ではありませんが、作成直後にテストするよりは効果的です。
2. 自分のプレイを録画する。 画面録画を開始してからプレイします。翌日に録画を見返し、観察者の冷静な視点で確認します。別の人がプレイしているかのように録画を扱ってください。プレイ中には気づかなかったことが見えてきます。
3. 外部テスターを最低3人確保し、例外を設けない。 ソロ開発者であることは、外部テストを省略する理由になりません。家族、友人、地域のインディー開発者コミュニティから3人に参加してもらうだけでも、セルフテストより確かな手がかりが得られます。自分以外の人にも、いずれゲームをプレイしてもらう必要があります。
4. オンラインテストプラットフォームを利用する。 リモートテストには、OBSとDiscordの画面共有、またはitch.ioの限定公開リンクなどのプラットフォームを使用します。リモートテスターでは顔の映像によるデータが得られませんが、先入観のない自然なプレイ行動を観察できます。
5. ソロ開発者には30％の余裕を見込む。 ソロ開発者のプロトタイプ作成時間には、20％ではなく30％の余裕を見込んでください。デザイン、実装、テスト進行、分析のすべてを担うためです。ソロ開発者にとっての「3日間のプロトタイプ制作」は、集中して作業できる実質2.1日分に相当します。

ビルド前チェックリスト

プロトタイプのコードを1行でも書く前に、以下の条件が満たされていることを確認してください。満たされていない項目があれば、作業を止めて、まず解決してください。

• 仮説が記述されている：必須の形式「[メカニクス]は、[条件]において[行動／感情]を生み出すと考えます。」に従っています。
• 反証基準が定義されている：仮説が誤りであることを示す、観察可能な兆候を少なくとも2つ挙げられます。
• MDAの美学が特定されている：このテストが対象とする8つの美学のうち、どれかを把握しています。
• 期間が設定されている：「完成したと感じたら」ではなく、明確な終了日が決まっています。
• スコープのチェックリストが完成している：「必須」「あるとよい」「対象外」の各列に、具体的な項目が記入されています。
• テスターの予定が決まっている：制作を始める前に、外部のプレイヤー3人以上の氏名とテスト日時が決まっています。
• 録画環境がテストされている：プロトタイプができる前に、テスト録画を行い、画面キャプチャソフトが動作することを確認しています。
• プロトタイプ用ブランチが作成されている：main上で制作していません。これは「プロトタイプのコードを正式な開発に移行させない」という方針を物理的に徹底するためのものです。

このチェックリストがあるのは、プロトタイピングで最も誘惑に駆られるのがビルドの段階だからです。仮説が明確になる前に制作を始めたいという衝動は強く、その場合、ほぼ必ずスコープクリープや曖昧な結果につながります。このチェックリストに20分かければ、無駄な作業を2日分節約できます。

使用例

1. 「プラットフォーマーで巻き戻しメカニクスに爽快感があるかをテストしたいです。プロトタイプの仮説とスコープを設定してください。」
2. 「戦闘システムのデザインを2案で迷っています。アクション要素のあるターン制と、ポーズ可能なリアルタイム制です。両方の比較プロトタイプの設計を手伝ってください。」
3. 「GDDでは、ダンジョン攻略の合間に拠点を建設するループをプレイヤーが楽しむと想定していますが、チームの誰もこの前提をテストしていません。プロトタイピングの進め方を教えてください。」
4. 「グラップリングフックのメカニクスのプロトタイプを作り、4人でテストしました。こちらがメモです。結果の分析と、打ち切るか継続するかの判断を手伝ってください。」
5. 「前回のスプリントでコアとなる戦闘ループを検証しました。次は進行のメタレイヤーをプロトタイプにする必要があります。仮説とスコープの定義を手伝ってください。」
6. 「私は個人開発者です。先週プロトタイプを作り、テスター3人に試してもらいました。2人は退屈そうで、1人は混乱しているようでした。これは打ち切るべきか、条件付きで継続すべきか、判断を手伝ってください。」
7. 「2つの経済システム案を検証する必要があります。固定コストのクラフトシステムと、変動コストの入札システムです。ペーパープロトタイプで比較する方法を教えてください。」