クラスにコードを移動するという別の方法を確認します。この方法のメリットは何でしょう。独自のオブジェクトよりも優れた言語機能があります。コードベースと共有できます。クラスを使用している場合、エディターはこのオブジェクトを認識せず、インスペクターにネイティブでは表示できません。この方法では責任の種類ごとにロジックを分割したくなります。実行する唯一のジョブは、物理演算の統合とボールが物体に当たったときのリアクションの処理です。ボールシミュレーションで実際に当たった物に基づいて決定することは意味があるでしょうか。ゲームロジックで処理することのように見えます。最終的には、なんらかの方法でシミュレーションをコントロールするロジック部分がボールにあります。フィードバックされます。処理が深いレイヤ―に埋め込まれていないことに気づきます。残っている責任の明確なエリアは以下の通りです。変更された点があります。位置を更新するロジックを見ると、このコードは位置を送信し、そこから新しい位置が返ることがわかります。ボールシミュレーションではボールの位置を所有していません。提供されるボールの位置に基づいてその瞬間のシミュレーションを実行し、結果を返します。部分、必要とするパーツだけをシミュレーションと共有できます。コードを確認しましょう。クラスは単純なインターフェースを実装します。オブジェクトへの参照を別のクラスに渡すことができるようになります。アスペクトだけを渡します。通知する必要もあります。デリゲートを提供できます。これが、再構成バージョンで最後にマークされた行が実行する内容です。これでよりすっきりした設計になります。あるロジックがたくさんありますが、各クラスは目的が細かく限定されています。これらの原則を使用することで、一人で作業しているプロジェクトの構造を整えることができます。ソフトウェアのアーキテクチャ少し規模の大きいプロジェクトのソフトウェアアーキテクチャソリューションを確認しましょう。コードにさらに特化したクラスの導入を開始すると、階層を構築できます。他のすべての対象を認識する必要があります。すべてのロジックを含むからです。ゲームのシミュレーション部分は必ずしもロジックのしくみを把握する必要はありません。シミュレーションを実行するだけです。ロジックはシミュレーションにシグナルを送り、それに応じてシミュレーションがリアクションすることもあります。入力を処理するのは、分離された、自己完結した場所が便利です。これは入力イベントが生成され、ロジックに渡される場所です。次に起こることは、シミュレーションで決まります。これは入力とシミュレーションでうまく機能します。プレゼンテーションに関連したところで問題が発生する可能性があります。特別なエフェクトをスポーンするロジック、スコアカウンターの更新などがあります。ロジックとプレゼンテーションの分離プレゼンテーションでは他のシステムで発生していることを把握する必要がありますが、それらのシステムに完全にアクセスできる必要はありません。可能な場合は、ロジックとプレゼンテーションの分離を試します。つのモード、つまりロジックのみと、ロジックとプレゼンテーションでコードベースを実行できるように試します。ときには、プレゼンテーションを適切な時点で更新できるようにロジックとプレゼンテーションを接続する必要があります。それでも、正確に表示するために必要なものだけをプレゼンテーションに提供することが目標です。つの部分に自然な境界を設けられます。データのみのクラスとヘルパークラスときには、データに対するロジックと処理すべてを同じクラスに組み込んではいない、データのみを含むクラスも有効です。データを所有せず、渡されたオブジェクトを処理する目的の関数を含むクラスを作成するのも、良い方法です。静的メソッドの優れた点は、グローバル変数にどれもアクセスしないと推定される場合に、メソッドに影響を与える可能性があるもののスコープを、メソッドを呼び出したときに渡される引数の内容で識別できることです。そのメソッドの実装を確認する必要はありません。このアプローチは関数型プログラミングの分野に踏み込みます。このアプローチを試します。従来のオブジェクト指向プログラミングで実行するよりも、バグの数が少なくなる可能性があります。オブジェクトを分割するオブジェクト間にグルーロジックを挿入することで、切り離すこともできます。プレゼンテーションはどのようにして互いに通信するでしょうか。ロジックに問い合せるのか。互いになんらかの方法で通信する必要があります。ロジックが書き込み、プレゼンテーションが読み込む、ストレージエリアの提供だけを目的とするバッファーオブジェクトを作成できます。それらの間に待ち行列を配置して、ロジックシステムが待ち行列にものを入れ、プレゼンテーションが待ち行列から読み込むことができるようにします。ゲームが大きくなるにしたがって、メッセージバスを使うことが、ロジックとプレゼンテーションを切り離すよい方法になります。メッセージングのコアの原理は、送信者と受信者のいずれも相手の情報がなく、メッセージバス/システムを認識していることです。したがって、スコアをプレゼンテーションする部分は、スコアが変わったというイベントをメッセージシステムから知る必要があります。ポイントの変更をプレイヤーに示すイベントをゲームロジックがメッセージシステムにポストします。基に開始すると便利です。独自にコーディングすることもできます。別の目的で分離したバスを使用できます。シーンをアンロードしたいときに、明示的なアンロードを使用します。遅かれ早かれ、シーンの遷移中にいくつかのオブジェクトをライブ状態に維持する必要があります。オブジェクトの寿命の制御ができなくなってしまうためです。使用する必要がなくなります。寿命が長いオブジェクトを寿命が長いシーンに配置すればよいのです。クリーンで制御されたシャットダウン私はこれまでいろいろなゲームを作ってきましたが、どんなゲームを作るときにも役立った習慣は、クリーンで制御されたシャットダウンをサポートすることでした。アプリケーションを終了する前に、実質上すべてのリソースをアプリケーションが解放できるようにします。オブジェクトをシャットダウンする方法に特別な順番があれば、エラーを見つけ、リソースのリークを特定するのが簡単になります。エディターが不安定な状態になりません。ドメインを完全にはリロードしません。クリーンシャットダウンを実行した場合、エディターでゲームを実行した後に、エディターや編集モードのスクリプティングが不安定な動作を起こす可能性が低くなります。バージョン管理システムを使用することによって実行できます。すべてのアセットをテキストとして保存し、オブジェクトをプレハブ化してシーンファイルから切り離します。最後に、シーンファイルを複数の小さなシーンに分割します。これには他にツールが必要になる場合があることに注意してください。人を超えるころには、プロセスの自動化にある程度の労力を割く必要が出てくるでしょう。クリエイティブなプログラマーであれば、ユニークな部分により時間をかけるため、できるだけ多くの繰り返し部分を自動化に回したいと考えるものです。自作のコードのテストを作成することから始めます。移動して、正規のクラスに移す場合、簡単なのは、ロジックとシミュレーション向けユニットテストを構築するためのユニットテストフレームワークを使用することです。すべての場合に有効とは限りませんが、後で他のプログラマーがコードにアクセスできるようになります。プロセスの自動化:コンテンツのテストテストするのは、コードだけではありません。コンテンツもテストが必要です。コンテンツのクリエイターがチームにいる場合、作成したコンテンツを標準化された方法ですぐに検証できるようにしておくと便利です。プレハブの検証やカスタムエディターで入力した一部のデータの検証など、テストロジックはコンテンツクリエイターが簡単に利用できます。エディターでボタンをクリックするだけで、すばやい検証を実行できるようになれば、それにより時間を節約できることの価値がすぐにわかるでしょう。セットアップすることです。セットアップするのが適切な方法です。メール通知をチームメンバーが受け取ります。作成とエラーのロギングが含まれます。エラーを見つけることで、ユーザーが見つけるために費やす時間を節約します。個のゲームクライアントをセットアップし、詳細設定を最小限に抑えて、すべてを実行します。クラッシュしたら、ログを確認します。これらのクライアントのいずれかがクラッシュするたびに、バグを見つけるために自分たちでゲームをプレイするか、あるいは他のユーザーに実行してもらう時間が節約されます。自分たちや他のユーザーが実際にゲームをプレイしてテストするとき、表示の問題がどこにあるのか、ゲームが面白いかなどに注力できます。使用することが可能になりました。それぞれ、プラットフォーム固有の機能と共通の機能を両方提供します。コンテンツを制作するために必要なすべてのものが揃います。詳しい学習リソースも豊富に用意されています。主要な機能について簡単に説明します。ツール、カラーコーディングによるチームの作業効率化などに関するヒントを取り上げます。コミュニティに多くの時間を費やして、多くのユーザーのスクリプティングを改良する手助けをしてきました。クラスの「革新的」な力、そしていつプロジェクトを最適化するべきかについてアドバイスをしていきます。