Tipsオフィシャル記事DEVELOPERプロジェクトが大規模化してもコードを整然とした状態に保つコツDEVELOPER詳細プロジェクトが大規模化してもコードを整然とした状態に保つコツ<このページで学べる内容>規模がどんどん拡大していくプロジェクトのコードを設計する効果的な戦略。整然とスケーリングでき、問題があまり発生しない方法を学びます。プロジェクトの規模が大きくなるにしたがって、設計を繰り返し変更し、クリーンアップする必要があります。変更を実施する前に常に一歩引いて、オブジェクトを整理するために小さな要素に分解し、再びそれらをまとめることが推奨されます。CTO)によるものです。年を超えるゲームの開発とリリースの経験があります。それでもなお、プロジェクトを安全、かつ効率的に拡大できるようなコードの作成方法に大きな関心を持っています。スタイルゲームのコードサンプルを確認しましょう。壁と同様に、パドルに対しても単純なスクリプトがあります。このサンプルはいくつかの重要な原則に基づいています。これらの原則は、このような単純なプロジェクトでは有効ですが、大規模化させる場合は構造の変更が必要です。コードを整理するために使用できる戦略はどのようなものでしょうか。違いについて理解しましょう。コンポーネントで、インスペクターで表示されます。つのパラメーターがあることがわかります。この表示ではパラメーターを使用するコードが何をするのかわかりません。インスタンスで左パドルの入力軸を変更することは意味があるでしょうか。実行すべきでしょうか。両方のプレイヤーで入力軸は異なると推定されます。したがって、おそらくインスタンスで変更する必要があります。Scale(移動速度スケール)」はどうでしょう。インスタンスやプレハブで何か変更する必要があるでしょうか。コンポーネントを表すコードを見ましょう。考えると、このプログラムでは異なる方法で異なるパラメーターが使用されていることがわかります。個別に変更する必要があります。両方のプレイヤーで共有されています。使用するときに指針となる戦略を示します。回だけ使うオブジェクトについては、プレハブを作成し、インスタンスを作ればよいでしょう。インスタンス固有の変更があるオブジェクトを複数回作成するのなら、プレハブを作成し、そのインスタンスを作り、いくつかの設定をオーバーライドしましょう。作成し、そこからソースデータを作成します。コンポーネントの例です。対する参照があります。インスタンス)があります。個別のパドルが指している共有設定のパケットの種類と軸名をまだ変更できます。新しい構造では、異なる設定の背後にある意図をさらに簡単に確認できます。拡大するのがわかると思います。各クラスは単一のオブジェクトを処理しなければならないと規定した、単一責任の原則に基づいて作業することで、それらを分割する方法を確認しましょう。適切に実行すると、「特定のクラスで何を実行するのか」、そして「何を実行しないのか」という問題の解答がすぐに得られます。これによりチームのすべての開発者が、個別のクラスが何を実行するのか簡単に理解できます。あらゆるサイズのコードベースに適用できる原則です。簡単な例を確認しましょう。これはボールのコードです。それほど似ていませんが、よく調べると、初速度ベクトルを設定するためにデザイナーが使用する速度と、ボールのその時点の速度を管理するために自作した物理シミュレーションで使用する速度があることがわかります。異なる目的に同じ変数を再利用しているということです。ボールが動き始めるとすぐ、初速に関する情報は失われます。動きだけではなく、ボールが上下の壁に当たったときのリアクションにも対応します。自体を削除するロジックをトリガーします。大規模のコードベースでは、エンティティがそれ自体を削除することを許可するのは珍しく、多くの場合オーナーがその対象のオブジェクトを削除します。ここを利用して対象を小さな部分に分割できます。ゲームロジック、入力処理、物理シミュレーション、プレゼンテーションなどこれらのクラスには、多くの異なる種類の責任があります。これらの小さなブロックを作成する方法を以下に示します。クラス内に配置できます。内に配置する必要があります。外側にできるだけ多くのコードを追い出すことが重要だと考えられます。