私はこの質問について少し知っていますが、このテーマについて非常に多くの多様な意見があることに気づきましたか？
プレーヤーの観点からは、ほとんどの場合、オプションの数が多いほど良いことを知っています。しかし、その一方で、マルチプレーヤーの場合、開発者とプレーヤーの両方にとって、より複雑（メタゲーム）になります。
開発の複雑さと時間の制約は常に関係しています。もう1つは、リソースとプラットフォームの制約です。後で延期することの経済的影響の可能性も、理由になることがあります。
では、上記のほかに、ここで経験する人々から、いつ機能をカットしたり、後でリリースする必要があるのでしょうか？
回答:
それは私たちにとって2つのステップのプロセスだと思います。
これら2つのポイントが一致する場合、機能リストは十分に長くなります。そう：
1.目標を設定する -プレーヤー/レビュー担当者/誰に対してもゲームで実行してほしいすべてのことを理解し、それを適切に述べます。たとえば、最新の（ここでalpha test vidを参照）では、次のようにしたいとします。
2.これらの目標を達成するのに役立つ機能を決定します -これらは、ほぼ自然に上記に該当しません。したがって、上記の例に対応する機能は次のようになります。
このプロセスを実行すると、次のことを判断するのに役立ちます。
私たちはこれらのルールに怠惰に固執しないことは注目に値します！たいていの場合、プロジェクトのプロトタイピングと一般的な混乱の結果として、驚くほど興味深いことが起こります。特に私たちのような小さなゲームのために。
複雑さはゲームを楽しくしません。
ゲームプレイ要素の適切な組み合わせとバランスが重要です。プレイヤーは自分のスキルレベルの範囲まで押し込まれ、挑戦を征服することで熟練の感覚を得なければなりません。
現在のゲームプレイが面白くないと感じるたびに、機能リストを変更する必要があります。これらの変更は、予算/時間の制約内で行う必要があります。ゲームに付加価値を加える変更があることを確認してください。
また、早い段階でプロトタイプを作成し、膨大な機能リストを作成するだけでなく、まとめるとすべてが楽しいものになると思い込んでください。
それらを含めるのに必要な時間と労力が、ゲームに追加する価値よりも大きい場合。
たとえば、プレーヤーが自分のスキルを披露する可能性が高いスポーツゲームなどを作成している場合、マルチプレーヤーは必須です。ギターヒーローはそれなしでは同じではないでしょう。ただし、自分で最初から最後まで行き、ストーリーやプロットをたどるだけの個別のゲームでは、マルチプレーヤーは必要ありません。Grand Theft Auto San Andreasの見事なマルチプレーヤーシステムは、その証拠です（その会社がマルチプレーヤーをそれほど難しく見つけていなかったとしても）。
また、ゲームのストーリーに実際には合わない機能もあるのです。それがゲームプレイに完全に不可欠ではない場合、時間が問題となる場合、それを後のリリースにプッシュできることはおそらく良い兆候です。
問題は、追加機能はゲームの本質的な要素ではないということです。楽しいゲームプレイと組み合わされたエキサイティングなストーリー展開です。
機能の多様性が素晴らしい程度があります（GTAっぽいゲームでたくさんのランダムなことを行うことができる、RPGやCall of Dutyっぽいゲームで武器やアクセサリーにたくさんの多様性があるなど）、いくつかのコア機能にしっかりと焦点を当てた最小限のゲームプレイは非常に効果的だと思います。
ポータルを見ると、それは1つのコアメカニックを使用し、余分な混乱を必要とせずに、その周りに本当に効果的にパズルを構築しました。
機能リストを可能な限り最小限に抑え、いくつかのコア機能を実際に具体化することについて厳格であると、より実現可能なプロジェクトと多くの場合より楽しい体験が可能になります（PortalがRPG要素と駆動シーケンスとスローモおよびその他の「クールな機能」を追加した場合） "、それはそれで良かったのでしょうか？コアのメカニズムは洗練されていたでしょうか？）
さて、インディーズの開発者としては確かに偏見がありますが、通常は機能が「少ない方が多い」と思います。それでも、現時点でクールで人気があるとしても、全体的なエクスペリエンスが著しく改善されない場合はカットする必要があります。
私の個人的な経験から、新しい予定外の機能をできるだけ早く追加しないことが最善であることがわかりました。
設計の観点から見ると、「機能xがあればいいのではないでしょうか」という瞬間に追加された機能は、開発時間を長くし、コードとうまく統合されない可能性があります。残りのデザインと完全に一致します。
最悪の場合、これらの瞬間が多かったプロジェクトは、機能の組み合わせが乱雑にハッキングされたように感じる可能性があり、実際には、設計フェーズで多くの時間を費やして、結果として専門家らしく見えないはずです。
一般的なガイドラインとして、私は次のルールに従うようにしています。
プロジェクトの早い段階で新機能が登場した場合は、時間をかけて設計フェーズに戻り、この機能が製品でどのように機能し、他の設計との整合性を保つことができるかを実際に確認してください。
プロジェクトがリリースに近づいている場合は、新しいバージョンに追加する機能のリストを作成することを検討してください。
これは明らかに他のプロジェクトよりも適しているプロジェクトもありますが、実際にプロジェクトの後半に登場する機能がある場合は、少なくとも新しいバージョンで作業を開始するまで、機能がなくても問題ないでしょう。
機能リストを作成しないでください。作成する場合は、数週間の開発に値する非常に短いものを作成してください。
アジャイルスタイルで開発-機能するものと機能しないものに基づいて、いくつかの最も重要な機能から始めて、テストし、さらに機能を追加する価値があるかどうかを検討します（そうすれば、機能をはるかに適切に判断できます）基本的なゲームプレイの経験はすでにあります）。
それ以外は、「それらを含めるために必要な時間と労力が、ゲームに追加する価値よりも大きい場合」というbennybdbc基準に同意します。
つまり、「外部」の世界も考慮する必要があります。
あなたが単に楽しみのためにゲームを開発しているのでない限り、そのような単純な現実の問題も考慮する必要があります。