プロジェクトを開始する前のゲームデザインドキュメントはどのくらい詳細かつ/または完全ですか？

プロジェクトの実装を開始する前に、設計ドキュメントが通常どの程度完成しているのでしょうか。ここでは、ドキュメント全体を完全に具体化したとしても、数十ページしかない可能性がある、非常に小さなチームで中規模から非常に小さなプロジェクトについて話している。

大まかなフレームワークから始めて、実装の開始と同時に詳細を具体化し始めますか？

実装が始まる前に、すべてのセクションを完全に具体化していますか？その場合、実装の開始後にどの程度の変化が見られましたか？

私が概説した2つのシナリオのいずれかを経験したことがある場合、その特定のルートで発生する問題とそれを回避するのに役立ったと感じる障害についての意見をお待ちしています。

ゲームのアイデアが大きく、一部に基づいている場合、異常なゲームプレイのコンセプト、私はそれをプロトタイプすぐにテンプレートとして以前のプロジェクトを使用して、最初から。95％の確率で、これは私が想像したほど面白くないことに気付き、面白くするには、それよりも多くのリソースが必要になります。

その間に別のプロジェクトに取り組んでいる場合は、時間をかけて落書きを作成し、プロトタイプがどのように見えるかを理解します（スケッチアートに気を取られないようにしてください）。次に、それを友人と共有し、一部には入力があるかどうかを確認しますが、ほとんどの場合、すぐに明白ではないことを自分自身で考えさせます（最も単純なアイデアを考えている最も賢い人でも、常にたくさんのことがあります）。このような2時間後、アーキテクチャに含まれる必要のあるいくつかの重要な概念を文字通り〜20語で書き留めます。その後、時間があるときにプロトタイプを作成できます。

現在、私のゲームデザインは開始する前に十分に詳細化されています。

私は重要なクラスのほとんどを具体化し、いくつかのモックアップ（描画は通常恐ろしいです）を描き、ゲームの説明を行います。

これは主に通勤に長い時間がかかり、他に何もできないためです。変更する可能性が最も高いクラスを具体化するのはやり過ぎのように思われるので、私はむしろこれを行う時間を減らし、プログラミングにより多くの時間を費やしたいと思います。

小さなゲームの小さなチーム（小さなカジュアルゲームの1人のチーム）で作業していて、「ヘビーデザイン」から「クイックデザイン」に移行しました。反復的な開発（2週間はコアゲームプレイなどの単一の目標に焦点を当てたもの）がデザインの肉付けに役立ち、プレイする何かを提供します。つまり、設計を変更せず、設計したものの90％を無効にすることはありません。 「紙の上」では見た目は良かったが、ゲーム内では見られなかった。

そうは言っても、私は設計時間のほとんどをコアゲームプレイとメカニズム（メインゲームがどのように機能するか）に費やしており、それがめったに変わることはありません-微調整され、新しいアイデアを取り入れたり、古いアイデアを落としたりすることもあります。しかし、プロトタイプが機能しなければ何も起こりません。

技術面では、コードを現実のものにする前に、少なくとも数分は考えるべきです。ただし、後でいつでもリファクタリングできます。

設計ドキュメントには維持費がかかります。物事が変わったら、戻って既存のドキュメントを読み直して更新する必要があります。そのため、実際にゲームの構築に費やす時間を最大化するため、保守可能なドキュメントの量を最小限に抑えることが、本番の目標になるはずです。

そこから、事前に細部に至るまですべてを設計する必要はありません。半分が変更されることを十分に理解していると、多くの無駄な時間に対処することになります。コアゲームの作成を開始するために必要な最小限の設計を行います。それが終わったら、必要に応じて繰り返し、新しい機能ごとにプロセスを繰り返します。