コードにジャンプする前に計画する価値がありますか？

計画はゲームにとって重要だといつも思っていました。しかし、私はどの時点でわからない。計画する代わりにコードを作成するように言っている人もいますが、コードに参加するときに、次に何をすべきかを簡単に知ることができるので、まだ重要だと感じています。私は現在、多くのコンテンツを持つゲームに取り組んでいるので、それらのコンテンツを紹介するデザインドキュメントを開始することを決定し、サイドレベルで、それが可能かどうかを確認するために概念実証を行っています。各概念実証の一部は、その後、実際のゲームで使用できます。

編集：私はこのプロジェクトに一人で取り組んでいます。

だから私の質問は次のとおりです。コードにジャンプする前に計画する価値がありますか？私はまだ他の人がこれについて何を言っているのか知りたいと思っています。原因は、まだ考えずにコーディングする必要があると言っている人がいるからです。

あなたはあなたの質問で2つの賢いことを言った：

1. 「考えるのではなくコード」-これを説明する哲学があります：http : //gettingreal.37signals.com/toc.php
2. 「それが実行可能かどうかを確認するための概念実証」-私は多くのアイデアを見てきましたが、ほとんど完成した時点では不可能または非常に難しいアイデアになりました。プログラミング環境（言語、ライブラリ、ハードウェアパフォーマンス）によって制限されるため、予測できない場合があります。

それが私が言う理由です：

• 設計しますが、コラボレーターや投資家を探していないなら、それがあなたにとって楽しく、プログラミングからの休憩としてとらえられない限り、巨大な設計文書を作成しないでください。
• 達成したいことを常に念頭に置いてください。すべてのモジュールには、設計された入力と出力が必要です。そうすれば、モジュールを簡単にテストでき、霧の中をさまよう気分がありません。
• とにかく、ほとんどの時間を設計することを忘れないでください。コードを入力するのにかかる時間はわずか5％だけです（少なくとも最終コードを入力する）。
• プログラミングは理論的な科学ではありません。何かが紙の上で機能するかどうかをチェックする代わりに、それをコーディングして試すことができます。最終製品の大部分は、ユーザー入力をだましやすくし、GUIを見栄えよくし、特殊なケースに対処することです。アイデアの汚いテストをすぐに行うことができます。
• あなたのアイデアを忘れることを恐れている場合は、todoリストを作成します
• あなたのアイデアについて友人と話してください。彼らはあまり熱心ではなく、フィールドでより多くの経験があるかもしれません。（戦略的ゲームで）ユニットパラメータを秘密にするというアイデアがあったが、友人はこのようなゲームをプレイし、ひどいユーザーエクスペリエンスだったので、悪いアイデアだと教えてくれました。

はい、しかしほんの少し。

ゲームプログラミング、特にゲームプレイプログラミングでは、コードを記述する前に適切なユースケースを用意することが不可欠です。例えば、プレーヤーは何をすべきか、どこに行くべきか、どのように、どのように世界とやり取りするのかなど。はゲームデザインの一部であり、ゲームがどのようにプレイされるかについての大まかな考えさえなしにコーディングを開始するのは愚かなことです。

しかし、ゲームは繰り返し作成する必要があります。ゲームの巨大なスペックを作成することはできず、ゲームが楽しくなることを願っています。何が機能し、何が機能しないかを見つけ、繰り返し続けるために、定期的なプレイテストが必要です。実行可能ファイルが最も速く実行されるほど、ゲームデザインのテストが最も速くなり、最後にゲームが最高になります。そのため、非常に非公式なゲームデザインからできるだけ早くコーディングを開始し、何が出てくるかを確認し、続行し続けることをお勧めします。

一つだけ確かなことは、あなたが単独でコーディングしているので、派手なソフトウェア設計ドキュメントや方法論を必要としないことです。ソースコードは設計です。

考える代わりにコーディングすべきだと言う人もいますか？さて、コードを作成するには、作成するものを知る必要があります。作成するものを知るには、まず、何を持ちたいかを考える必要があります。コーディングする前に考える必要があります;）

真剣に、おそらく最初は詳細な計画は必要ありませんが、アウトラインやマイルストーンは常に有益です。作業。

コーディングと計画の両方が必要です。最初に計画してからコードを作成しますが、すべてを一度に計画しないでください。コアを計画し、コーディングし、必要に応じて計画を更新してから、プレイアビリティ、グラフィックス、サウンド、スプライトなどに追加する機能を計画します。これにより、作成するゲームの外観が良くなり、全体的に気分が良くなります。もちろん、このようなサイクルを複数回実行できます。必要に応じて、アップスケーリングをサポートする意思決定を行うことをお勧めします。

コードを書く前に、どこに向かっているのかを知っておく必要があります。また、書き込み/描画は、達成したいことを実現する良い方法です。私が言うの描画図、スケッチなどを描画することもあなたに大いに役立つ可能性があるため。Wordなどで作成されたすばらしいドキュメントを作成する必要はありません。鉛筆と紙（たくさんの紙ですか？）を用意して、考えられるすべてのものを描いて書いてください。

私にとっては、鉛筆と紙を使用することをお勧めします。これは、アイデアを具体化するのに役立ちます。それは反射を必要とするすべてのために働きます。そして、実際の作業を行う前に物事を書き留めることは多くのドメインで明らかです。

あなたのために働くものは何でもしてください。個人的には、少し計画を立てていますが、コーディングを始める前に、非常に詳細な計画である設計文書はありません。特にあなたが一人で働いているので、あなたにとって最も生産的なことをしてください。

（質問は少なくともゲームデザインではなく、コードデザイン/アーキテクチャの観点から行われますが、少なくともある程度の答えは両方に当てはまります。）

すでに述べたように、両方が必要であり、バランスを取る必要があります。コードフロー/構造の過剰設計と過小設計の両方が問題を引き起こす可能性があります。適切なバランスが何であるかを言うのは難しいですが、一般的には、少なくとも残りのコードが現在プログラミングしているものとどのように結合するかについて、漠然とした考えを持ち、考えられる問題について考える必要があります。そうでなければ、「自分自身を行き止まりにコーディングする」傾向があります-「大丈夫、今、この問題を解決したおかげで、以前のソリューション全体（または最悪の場合はそれ以上）になった新しい問題を作成しました」 ）無駄」。

一般的に、私の意見では、「what if」シナリオを「what if I after（すべてが現在使用しているのと同様のパラダイムで完全に実装されている場合）」のように考えることで、適切なバランスがあるかどうかを大まかに判断できますその部分Aはわずかに異なる動作をする必要があるため、変更に対応する部分Bを完全に作り直さなければならないことを意味しますか？」1つのパーツのアーキテクチャを変更するのに他の1つまたは2つ以上のパーツを変更する必要がなく、変更がカスケードされない場合（つまり、パーツBに接続している次のパーツも、次に接続しているパーツも変更する必要がある場合）それらなど）、コードは比較的良い方法で区分されています。

しかし、実際には、これは経験を積んだ後に感じられるものです。これは、部分的に誰もが最初のゲーム開発者に、既知の簡単なコード（ブレイクアウト/テトリス/スネーク）を最初にコーディングし、すべてのメニュー、サウンド、エフェクト、ゲームを完全に完成させるためにすべてを行うようにアドバイスする理由です小規模なプロジェクトを台無しにして、それを（良い方法でも悪い方法でも）行うことは、さまざまなアーキテクチャの決定の影響がどの程度及ぶかを正確に把握するのに役立ちます。