ユニティの選択。 長所と短所
Unityを支持する主な議論はC＃でした。 しかし、他にもプラスがあります：
- Unityの開発者にとってのエントリーしきい値はかなり低いです。
- Unityは、異なるプラットフォーム上でのアプリケーションの互換性と正しい操作に関連するすべての問題を処理します。 Unity Editorでビルドが機能していることを確認し、主要なデバイスでビルドを確認し、クラッシュレポートサービスとコミュニティマネージャーを介してアプリケーションを制御する必要があります。 Unityのメンバーに問題を通知し、通常のパッチリリースで修正し、その後ホットフィックスをリリースします。
- Unityは、高レベルの開発者サポートを提供します。 エージェントからの標準的な応答はまれです。 質問に問題の詳細な説明、スクリーンショット、実行するテストプロジェクトが含まれている場合、状況から抜け出す方法に関するヒントを含む包括的な回答を受け取ります。
悪い点について：
- エントリの低しきい値には欠点がありました。 私たちが知っていた就職面接官は、Unityは得意でしたが、C＃は得意ではありませんでした。 私たちは、C＃を深く理解し、最も人気のあるゲームエンジンを学びたいという意欲を持つ開発者を探す方が良いという結論に達しました。
- 不安定なリリース品質。 これは特にパッチに当てはまります。 Unityは、プロジェクトに影響するバグを修正する場合にのみインストールすることをお勧めします。 しかし、何かが他の場所で壊れる可能性があります。
- ロードマップの奇妙な優先順位。 たとえば、ポリモーフィックシリアル化またはネストされたプレハブの長い研究。 Unityはグラフィック品質の最も近い競合他社に追いつくことを試みており、大規模プロジェクトの開発を大幅に簡素化する機能を実装していないと思います。
- 閉じたプラットフォーム。 問題が発生した場合、その解決策はUnityに依存しているため、適切なリリースを待つ以外に選択肢はありません。
建築
長期にわたって市場に参入したい場合は、アプリケーションのアーキテクチャについて慎重に検討する必要があります。 すべてを熟考すれば、新しい機能をすばやく簡単に追加したり、古い機能を変更したりできます。 このトピックに関するネットワーク上の記事は多数ありますが、いくつかの重要な点に注意を喚起したいと思います。
- 開発の初期段階でアーキテクチャテンプレートを選択し、常にそれに従ってください。 Unityプロジェクトの場合、UIとビジネスロジック間のデータ交換がどのように行われるかを正確に理解するためにこれが必要です。 あなたの仕事は、同じタイプの交換を理解しやすく、透明にすることです。
- プロジェクトを開始する前に、アーキテクチャ全体を説明しようとしないでください。 彼女は開発段階でのみ現れ始めます。 開始するには、選択したテンプレートの原則に従い、アーキテクチャソリューションの形で同様のメカニズムを徐々に引き出していくだけで十分です。 それでも、開発の初期段階では、アーキテクチャは新しい機能を作成するよりも注意を払う必要があります。
- 新しいアーキテクチャソリューションを実装するためのリファクタリングに間に合わせます。
- コードでの作業に制限を設け、議論だけでは不十分です。 一部のオブジェクトは、特定の方法で、特定のストリームから、または特定の条件でのみ使用できることにチームに同意します。 数週間かかります。誰かが必要な場所ではなく、合意された方法でこのオブジェクトの使用を開始することは確実です。これは、判断が難しい問題につながることがよくあります。
- SOLIDの原則を順守しますが、熱狂はありません。 誰も常識をキャンセルしませんでした。 2つの方法があると想像してください。 最初の方法は、どこでも簡単に拡張可能な、思慮深いモジュール式技術ソリューションを実装することです。 2つ目は、限られた時間でビジネスタスクを完了することですが、技術的なソリューションの全体的な美しさは「ドラムで」です。 この場合、2番目のパスを選択します。 開発のために開発に屈しないでください。
- チームと重要な決定を下します。 議論のために、それぞれのアプローチの長所と短所でいくつかのオプションを提供してみてください。
なぜMVVM
テンプレートはWPF開発者によく知られており、その本質は、データモデルをビューから分離するときに「データバインディング」が使用されることです。 モデルは、MVCと同様に、アプリケーションの基本データであり、その処理のためのさまざまなメカニズムです。 ビューはグラフィカルインターフェイスオブジェクトです。 ビューモデルによって提供されるプロパティ値変更イベントのサブスクライバーです。 プレゼンテーションモデル-モデルのプレゼンテーションに必要なデータの集約。 プレゼンテーションがモデルに影響を与えることができるコマンドが含まれています。
アプリケーションの性質上、MVVMアーキテクチャテンプレートを選択しました。 MVC / MVPとは異なり、UIが機能するロジックとデータからUIをより高度に抽象化します。
モデル
アプリケーションのモデルは、サーバー、その処理メカニズム、およびコマンドと共有されるデータを持つクラスです。 データはクラスごとに目的別にグループ化され、アクセスおよび処理のためのメソッドも提供します。 これらはすべて、ViewModelからアクセスするためにファサードオブジェクトを介して提供されます。
ビューは、モデルに影響を与えることができる唯一のメカニズムです。 これらは、ローカルモデルを変更する操作を実行するための抽象化であり、サーバーとのデータ同期のロジックもカプセル化します。 すべてのコマンドはHttpWebRequestのラッパーであり、非同期に実行されます（非同期プログラミングモデル）。 WebGLビルドの場合、チームは、コルーチンを介して実行されるUnity WWWクラスのラッパーです。 サーバーと通信するために、データはJSON形式でシリアル化されます。
ThreadPoolからの他のスレッドのコマンドのコールバックの非同期実行、および別のスレッドで実行されるモデルの動的更新のメカニズムのため、データアクセス同期が必要です。 このロジックは、モデルにアクセスするファサードオブジェクトにカプセル化されています。これについては、前に説明しました。
ViewModel
アプリケーションのViewModelレイヤーは、コード量の点で最もボリュームがあります。 実際、機能の主な開発はすべてこのレベルで行われます。 このレイヤーでは、異なるモデルオブジェクトのデータがまとめて収集され、ビューでユーザーに表示されます。 ViewModelはViewの実装に関連付けられていませんが、データのセットと形式は、UIでの表示方法に直接依存します。 また、このレイヤーでは、UIを持たない可能性のあるさまざまなメカニズムが実装されますが、アプリケーションが機能するために必要です。ソーシャルネットワークなどを操作するためのさまざまなマネージャーです。
ViewModelは、プロパティやコンテキストなど、いくつかの基本的な概念で動作します。 プロパティは、ObservableObjectパターンのカスタムジェネリック実装です。 コンテキストは、プロパティおよびその他のコンテキストのコンテナとして機能します。 コンテキストは、プロパティ検索ロジックとコンテキストのアクティブ化および非アクティブ化ロジックもカプセル化します。 これは最適化として必要です。たとえば、UI内のオブジェクトのコンテキストが何かでオーバーラップし、イベントをキャッチせず、再度更新されないようにするためです。 検索メカニズムはリフレクションを介して実装され、一部のUI要素がViewModelからプロパティにラッチしたいときにのみ機能し、パフォーマンスのボトルネックからはほど遠い。
表示する
ビューレイヤーはUIを担当します。 このレベルで、コードがUnityで機能することを認識します。 このレベルのオブジェクトのグループは次のとおりです。
- バインディングメカニズム。
- ContextBoxオブジェクト-ViewModelからコンテキストのライフサイクルを作成および制御するため、ViewModelの使用を計画しているすべてのオブジェクトの基本であるMonoBehaviourスクリプト。
- ゲームプレイに必要なカスタムUnityコンポーネント。
- NGUIやUnity UIなどのUIスクリプト
私たちが実装したバインディングメカニズムは次のように機能します。
- GameObjectでラベルがハングします。
- LabelBindingスクリプトは同じGameObjectでハングし、パラメーターとして、動作するLabelへのリンクを受け入れます。 以下は、GameObjectが接続する必要がある文字列形式のViewModelのプロパティへのパスです。
- アウェイク中、ContextBoxを介したバインディングは、必要なプロパティのコンテキストを途中で検索し、見つかった場合はその変更をサブスクライブします。
- ViewModelでプロパティ値を変更すると、UIはこれらの変更にすぐに応答し、関連するラベルに表示します。
今のところすべてです。 2番目の部分では、マルチスレッド、スキンの操作、クエリの実行、キャッシュについて説明します。