prototype-fast

プロトタイプを素早く作る

プレイヤーにメカニクスをすぐに体験してもらい、作る価値があるかを確かめます。プロトタイプの成果は製品ではなく、判断（継続／中止／再設計）です。学習の速さを優先し、コードを使い捨てにするのか、今後も使うのかを最初に決めます。

使う場面

• 1つのメカニクスや「もしこうだったら」を検証するとき、垂直スライス／MVPを作るとき、レベルやインタラクションをグレーボックスで作るとき、本格的に時間をかける前にアイデアのリスクを減らすときに使います。
• 「とにかくプレイできるものを作って」「これは楽しい？」「ざっくり作って」とユーザーが言ったときに使います。

使わない場面： 期限と提出物のある時間制限付きコンテスト（game-jam を使います）；実際のリリースを公開または更新するとき（steam-publish／itch-publish を使います）；検証済み機能の製品版を作るとき（エンジン／ジャンルのスキルを直接使います）。

基本的なワークフロー

1. 検証する問いを1つ書きます。 プロトタイプで答えるべきことを1つだけ示します。例： 「落下中のグラップリングは、操作していて気持ちよいか？」 問いが2つあるなら、プロトタイプも2つ作ります。すべてを検証するプロトタイプは、何も検証できません。
2. コードを書く前に、使い捨てにするか継続利用するか決めます。 使い捨て（スパイク）：ハードコードし、アーキテクチャは作らず、終わったら削除します。継続利用：まだ粗くても、後から拡張できるフォルダー名や命名にします。ほとんどのプロトタイプは使い捨てにするべきです。そうしないと、プロトタイプが腐って製品版のコードベースに入り込んでしまいます。
3. 時間制限を設けます（メカニクスなら30～90分、スライスなら一度の作業時間）そして、見える場所にタイマーを置きます。制約を設けることが重要です。細部ではなく、核となるアイデアを検証せざるを得なくなります。
4. 必須でないものはすべてグレーボックスにします。 アートにはプリミティブ（ボックス、円、カプセル）、組み込みフォント、デバッグ用のサウンドを1つ（またはなし）を使います。検証する問いに関係のないものには、1分も使いません。
5. 問いに合わせて計測できるようにします。 判断対象（速度、距離、タイミングの猶予など）を示すデバッグ用テキストやギズモを画面に追加します。飾るのではなく、計測します。
6. すぐに、率直にプレイテストします。 まず自分でプレイし、その後、操作方法を説明せずに他の人に渡します。どこで苦労するかを観察します。
7. 中止基準（以下を参照）に照らして判断します。 継続 → 本制作を予定し、スパイクを昇格させずに書き直します。中止 → 得られた知見を記録して次に進みます。再設計 → 問いを絞り、再びスパイクを作ります。

パターン

1. プロトタイプの概要（コーディング前に記入）

QUESTION:     The one thing this must prove (binary if possible).
CORE VERB:    The single action the player repeats.
THROWAWAY?:   yes -> hard-code freely, delete after.  no -> minimal structure to grow.
TIMEBOX:      e.g. 60 min. Stop when it rings, even if unfinished.
KEEP IF:      observable signal that means "fun / worth building" (see kill criteria).
KILL IF:      observable signal that means "stop".

2. 中核となるループをグレーボックスにし、それ以外はすべて仮のものにする（エンジンに依存しない疑似コード）

# Only the CORE VERB is real. Visuals are primitives; systems are stubs.
on update(dt):
    read_input()
    apply_core_mechanic(dt)        # the ONLY thing you're testing — make this feel right
    draw_primitive(player)         # a box. not a sprite. not animated.
    draw_debug_hud(speed, timing)  # show the numbers you're judging
    # enemies, menus, save, audio, art -> stubbed or absent until the verb proves out

3. 中止基準 — 継続／中止の判断を感情ではなく、観察可能なものにする

KEEP when, with placeholder art:
  - a fresh player does the core verb on purpose within ~30s, unprompted, and
  - you (or they) repeat the loop "one more time" without being asked.
KILL when:
  - the verb only feels good after you explain it, or
  - making it fun needs systems far beyond the prototype's scope, or
  - you're adding art/levels to avoid admitting the verb is flat.
REFACTOR when one variable is clearly off (too slow, window too tight) -> retune, retest.

4. 隔離：スパイクを製品版のコードベースに入れない

prototypes/<idea-name>/      # separate folder or project, never imported by main game
  - hard-coded values, single file ok, magic numbers welcome
  - committed on a throwaway branch (or not at all)
Rule: a "keep" decision authorizes a REWRITE in the real project, not a copy-paste of the
spike. Prototype code carries prototype assumptions; shipping it ships the assumptions.

落とし穴

• 早すぎる仕上げ。 アート、メニュー、音声を加えると、平坦なメカニクスが完成品のように見え、判断が遅れます。動詞としての体験が証明されるまで、グレーボックスのままにします。
• 中止基準がない。 「この場合は中止する」という基準を書いておかないと、どのプロトタイプにも「可能性がある」となり、何も削られません。コードに愛着が湧く前に、判断材料となる指標を決めます。
• メカニクスではなくシステムを作る。 インベントリ、セーブ／ロード、設定は検証する問いではありません。スタブにします。
• スパイクが製品になる。 使い捨てコードを本番環境に昇格させるのは、楽しい起源を持つ技術的負債です。継続する場合は書き直します。
• 実際のコードベースでプロトタイピングする。 実験が製品版のシステムと絡み合い、スパイクを削除するコストが高くなります。別のフォルダー／プロジェクトを使います。
• 自分だけでテストする。 自分は操作方法も意図も知っています。説明を受けていないプレイヤーに試してもらえば、自分で1時間プレイするより、2分で多くのことが分かります。

参考資料

• 厳しい外部締め切りのもとで作業し、提出する場合は、game-jam スキルを参照してください。
• グレーボックスで作るエンジン固有の中核ループについては、そのエンジンのスキル（godot-gdscript、phaser-core、love2d-core、unity-csharp-scripting、…）を参照してください。

関連スキル

• game-jam — 提出物のある時間制限付きコンテストに、同じスコープ管理を適用します。
• エンジンのコアスキルとジャンルのスキル — 「継続」と判断したものを適切に作り直す際に使います。