ゲームの計画とソフトウェア設計？UMLは便利ではないと感じています

私の大学では、彼らは常にUMLのデザインやものについて強調し誇大宣伝していますが、ゲーム構造のデザインではうまく機能しないと感じています。今、私はゲームの設計をどのように始めるべきかについて専門的なアドバイスが欲しいですか？ストーリーは、プログラミングにある程度のスキルがあり、2Dプラットフォーマーをある程度拡張するなど、多くのマイナーゲームを行ってきたということです。私のプログラムについて私が見つけた問題は、質の悪いデザインです。しばらくコーディングした後、計画が不十分なために状況が崩れ始めます（新しい機能を追加すると、プログラム全体を再コーディングしなければならなくなる傾向があります）。ただし、単一の設計上の欠陥なしですべてを計画することは、あまりにも理想的です。したがって、ゲームをどのように計画すればよいかについてのアドバイスはありますか？私と私の友人がデザインを概観できるように、どのようにそれを目に見える写真に入れるべきですか？

私は友人とゲームのコーディングを開始する予定でした。これが私の最初のチームワークになりますので、専門的なアドバイスがあれば嬉しいです。UML以外の代替手段はありますか？

別の質問は、「プロトタイピング」が通常どのように見えるかということです。

ゲームの設計を開始する方法について専門的なアドバイスが必要ですか？

ゲームデザインは、ゲームプレイ、アセット、スコアリングシステムなどの仕様です。これらはソフトウェア固有のものではありません。そのため、UMLはそのタスクに適したツールではありません。

これらのシステムを実装するためのコードの設計に関しては、UMLはタスクに適したツールであり、チームにそれを知らせ、より一般的なダイアグラムタイプに固執します。通常、機能を設計するときに、説明を使用する必要があるか図を使用する必要があるかがわかります。ダイアグラムを使用する必要がある場合、UMLはそれを描画する標準的な方法を提供します。これは良いことです。

しばらくコーディングした後、計画が不十分なために状況が崩れ始めます（新しい機能を追加すると、プログラム全体を再コーディングしなければならなくなる傾向があります）。

これは一般に、計画方法ではなく、プログラム方法の問題です。通常、優れたソフトウェアは簡単に拡張および再利用できます。適切なプログラミングの実践に固執する場合、この問題は減少します。しかし、より良い計画も助けになり、このために複雑な図は必要ありません。機能のリストがあるだけで、1つのことをコーディングするときに、他の機能を念頭に置いて、コーディング中にそれらを考慮することができます。

したがって、ゲームをどのように計画すればよいかについてのアドバイスはありますか？私と私の友人がデザインを概観できるように、どのようにそれを目に見える写真に入れるべきですか？

ここでは、ゲームデザインとコードデザインという2つの問題が混在しているようです。

まず、基本的なゲームデザインを書き、必要な機能、必要なグラフィックとサウンド、ゲームの勝敗を特定することなどを指定することをお勧めします。支援が必要な場合は、「デザインドキュメント」を参照してください。

そこから、コードを作成するために必要な機能のアイデアが得られます。各機能を順番に見て、それらを実装する方法について考えてみてください。ダイアグラムは、ゲーム内のさまざまなクラスとオブジェクト間の関係を示すのに役立ちますが、どのオブジェクトが存在する必要があるかを知るスキルは、練習および/またはさらに読むことで学ぶ必要があるものです。

また、小規模で野心的なプロジェクトに取り組んでみてください。これにより、大規模な計画や書き直しを必要とせずに、適切で実用的なコードを書くことに慣れることができます。

何かを理解していないと、簡単に却下できます。UMLは、構造化された方法でアイデアを伝えるために使用されるエンジニアリングツールです。ゲームは、他のゲームと同様に設計できるシステムです。どちらかといえば、ゲームの複雑さとダイナミズムは、その部分とその相互作用の視覚的表現を非常に貴重にします。

UMLダイアグラムは、議論中のシステムのモデルのさまざまなビューです。プログラムの前に座ってそれを開始する人のユースケースから始めます。ゲームの場合、ユーザーにはデザイナーとプレイヤーの2種類があります。私は彼らがやっているのを見ることができるものごとにユースケースを書きます。次に、CRCカードをいくつか作成して、提供する必要があるサービスを特定します。次に、これらのサービスとその関係を提供するインターフェイスのクラス図を作成します。これはCRCカードに基づいています。次に、計画やオーケストレーションを必要とする初期化などのイベントの動的な図が登場します。次に、インターフェースを実装するクラスを示すより詳細な静的図。

その間ずっと、コードを書いてプロトタイプを作成し、ゲームの要件を満たすためのサービスを提供する方向に進化させています。ユースケースを通じてユーザーをサポートしないものは何も構築されません。役に立たない図の要素をいくつか書きますが、インターフェースのコーディングと図の間に、ほとんど役に立たないコードを書きます。作図は、私が書いているクラスがシステム全体に適合する方法を理解しているという自信を与えてくれます。

私がやろうとしているのは、些細なプログラムを計画なしに書くことができるということですが、ゲームは些細なことではありません。しばらく前、OOPが新しくなったとき、多くの実験があり、いくつかのベストプラクティスが前面に出てきました。ソフトウェア開発コミュニティは、ソフトウェア設計について記述および分析するための言語が必要であることに同意しました。UMLは私たちが開発した言語です。私たちは皆それを知っており、理解しているので、他の人のソリューションをあなたの問題（本、オンラインディスカッション、記事、パターンカタログなど）に使用し、車輪を再発明したくない場合は、標準表記を読むことを学ばなければなりません。ボーナスとして、システムを別の言語で強制的に考えさせると、予期しないことを学びます。

さまざまな方法論が存在しますが、それらはすべて問題を特定し、体系的な方法で1つのソリューションを説明します。これはエンジニアリングです。UMLは巨大で複雑ですが、すべての構造を使用するモデルはありません。スイスアーミーナイフのようなものです。あなたはそれを知り、あなたのエンジニアリングプロセスをサポートするためにそれを使用する方法を見つけなければなりません。重要なことは、どのプロセスまたは方法論ではなく、あなたが持っていることです。そうでなければ、複雑さにdrれます。

私は友人（2人のチーム）といくつかの独立したゲームプロジェクトにも取り組んでいます。あなたと同じような状況にある人として、私は役に立つと思ういくつかのちょっとしたことを提供できます。

1. アイデアが粗い場合は、超小型プロトタイピングプロジェクトで一度に1つずつ実装してみてください。たとえば、私は現在2Dプラットフォームゲームを作成していますが、プレイヤーのジャンプを正しくすることは私にとって非常に重要です。そこで、a）プレイヤーを画面に描画すること、およびb）入力を検出し、ジャンプを再描画することだけが行われる新しいプロジェクトを作成しました[キャラクターは左右に移動することさえできません]
2. 一部の人々はこのアドバイスに眉をひそめるかもしれませんが、最初にゲームのマニュアルを書くことを考えてください（コンセプト、コントロール、目的を説明するため）。これにより、2つのことができます。非常に必要なドキュメントを生成するだけでなく、ゲームのサブシステムの概要と、プレーヤーに必要な詳細を説明します。プレイヤーが知っておくべきことを前もって知っているなら、あなたは何をする必要があるかを前もって知っています。
3. パスタのプレートから中規模のスパゲッティのすべてを削除しようとしているように感じることなく、ファクタリングされたピースを移動したり、よりよく整理したりできるように、十分に小さい（モジュール化された）チャンクでコードを書きます。

うまくいけば、そこに少なくとも1つの有用な情報が見つかり、幸運を祈ります！

あなたが否定できないUMLからいくつかの貴重な持ち帰りがあると思います。一方、UMLはビジネスプロセス向けに構築されていることを覚えておいてください。多くの人がやり取りし、さまざまな欲求やニーズ、欲求を持つシステムをモデリングしています。UMLは、ユーザーが何も残さず、詳細に圧倒されないようにします。

UMLは「システムのアーキテクチャを視覚化する標準的な方法」です

UMLの説明

• 活動
• 俳優
• ビジネスプロセス
• データベーススキーマ
• （論理）コンポーネント
• プログラミング言語ステートメント
• 再利用可能なソフトウェアコンポーネント

しかし、単純なゲームを作成している場合、これらすべてを本当にモデル化する必要がありますか？

• アクター：プレーヤー。

それはどれほど役立ちますか？

ただし、他のいくつかのモデル化は非常に役立ちます。たとえば、小規模なMMOを作成する場合、適切に設計されたデータベーススキーマが必要です。

そのため、UMLからの抜粋は優れており（実行内容を把握し、要件を書き留め、必要に応じてフローチャートの図をスケッチします）、その要素は非常に有用ですが、完全なUMLプロセスはゲーム用の小さな四角い丸穴。

UMLは1つのものではありません。それは、それらのいくつかがあまり価値のないものの集まりです。古いスタイルのユースケース（少なくとも私たちがユースケースと呼ぶもの）

• 名
• 要件
• 前提条件
• トリガー
• 行動
• 代替アクション
• 例外

非常に便利です。ただし、Web検索を行う場合の「ユースケース」の検索結果（写真）は、一般的なソフトウェアに関するものです。

また、クラス図にいくらかのクレジットを付けます。これは、すべてのオブジェクト間の関係を表示できること、およびアーキテクチャのレイアウトを知っていることを示しています。

結局のところ、モデリングの前に機能セットをすべて計画し、int（need / wantセットアップでリース）をロックし、ダイアグラム作成を開始する必要があります。これらはすべて、ブリーフ/トリートメント/スクリプト（ピッチ、機能ドキュメント、ストーリーとも呼ばれます）にすべて含まれている必要があります。その後、そこからモデルと図を含む技術文書を作成します。

UMLを使用している企業もありますが、これらは通常、個別の設計チームと実装チームを持つ会社です。すべてのドキュメントを作成し、それをコードモンキーのチームに渡してプロトタイプ/アルファを作成する会社。ゲームを正確にモデル化できれば、完全に別のチームにゲームを提供してプログラムしてもらうことができるはずですが、これは単なる夢ではなく正確です。

彼らはあなたの大学でUMLについてあなたに教え、あなたのアイデアを他のチームに伝えるのを助け、あなたに基本的なソフトウェア工学の原則についての実用的な知識がある講師を示します。

言語、ツール、またはデザインに関する議論のように、通常はそれをどのように使用するかによって決まります。仕事に最適なツール/言語/デザインを選択し、強力な根拠で選択をバックアップします。UMLはゲーム制作にはそれほど柔軟ではありませんが、ネットワーク通信やタイミング、並列タスク管理、ユースケースなどのエンジン機能を効果的にモデル化するためにUMLを効果的に使用したと言えます。5人の異なるチームメンバーに同じことを10回も説明することほど悪いことはありません。これがドキュメントです。読んでください。

設計の堅牢性とチームの規律に応じて、まだ開始されていないものを中心に独自の構造をモデル化し、それが原因でどのように動作するかを正確に知ることができれば、非常に生産的ですドキュメンテーション。

これにもかかわらず、おそらくあなたはこれらが生きている文書であると聞いて（そして厳しく気付くでしょう）、それらが定期的に見直され、更新されない限り、それらは時代遅れで効果的に役に立たなくなります。