ゲーム開発者だけでなく、共通コードライブラリの作成

先日、私はSofteqグループの一部であるzGamesゲームスタジオのテクライドであるArtyom Vorobyovと話をしました。彼はためらうことなく彼のチームの経験を共有しました。 特定の実用的なヒントを含むエレガントな説明を提供します。

1.動機：なぜ必要なのか

良いソリューションをコピーするのが大好きです。 プログラマはこれを「コードの再利用」と呼びます。 この記事では、コードライブラリの再利用を設定し、効率的に拡張する方法について説明します。

コードライブラリを作成するタスクは、通常、次の事実により複雑になります。
a）ライブラリは数人によって使用され、拡張されています
b）ライブラリは複数のプロジェクトに同時に関与しています

私たちの共通コードライブラリは4年前から存在しています。 それはすべて、Objective-Cのいくつかのクラスから始まりました。 その後、C ++に切り替えて、ライブラリを数回増やしました。 現在Unity3dで作業しており、共通のコードライブラリには約400のクラスがあります。

2.ゲームエンジンを持っているのに、なぜライブラリを作成するのですか？

ゲームエンジンには、さまざまなプロジェクトで再利用される多くの便利なコンポーネントが含まれています。 ただし、エンジンは、原則として、最も一般的なタスク（物理学、レンダリング、サウンド、ネットワーク、オブジェクトの一般的なアーキテクチャなど）にのみソリューションを提供します。 ただし、多くの場合、これらの決定の範囲を拡大するか、新しいサブシステムを作成する必要があります。

たとえば、Unity3dエンジンでのログの実装を検討してください。 Unityコンソールにメッセージを表示するDebug.Logメソッドがあります。 しかし、エンジンはこれらのメッセージを特定のファイルに書き込む方法を知りません。 また、エンジンでのログの実装では、メッセージをフィルタリングできません。 これらおよび他の多くのログ拡張機能は、共有ライブラリに移動できます。

3.名前：KST-常にzbs？

名前から始めます。 もちろん、ライブラリに「CommonCode」などの名前を付けることもできますが、プロジェクトにもっと「適切な」名前を付けた方がよいでしょう。 これにより、チームは共通のコードライブラリトピックについてより簡単にコミュニケーションを取ることができます。

私たちのライブラリはzLibと呼ばれます-「zGames Library」の短縮バージョンです。 美しく聞こえますが、データ圧縮の悪名高いライブラリの名前と少し一致しています。 かつては、この事実をどういうわけか無視していましたが、良い意味で、もっとユニークなものを思い付く価値があります。 したがって、ライブラリの名前を選択する際には、使用する他のライブラリの名前と重複しないようにしてください。

4.プロジェクトへの統合のスキーム。 リポジトリ、外部、SVN対Mercurial

次の質問は、ライブラリがどのようにプロジェクトに入るかです。 多くの場合、すべてを開始する簡単な方法があります-プロジェクトからプロジェクトへのコードのコピー。 ここで、いくつかの問題が発生します。バグ修正と新しいコンポーネントをプロジェクト間で交換するのは非常に困難です。

より高度な方法は、サードパーティのリポジトリを介してライブラリを統合することです。 SVNでは、このようなスキームは、Mercurialでは「外部包含」（英語の外部）、Gitでは「サブリポジトリ」（英語のサブリポジトリ、サブリポジトリ）、「サブモジュール」と呼ばれます。 この手法を使用すると、プロジェクトリポジトリを複合化でき、その結果、独自のコードだけでなく、他のプロジェクト（共有ライブラリなど）のコードも含めることができます。

ライブラリは、プロジェクト内のどこかにある独立したフォルダになり、別のリポジトリから更新されます。 サードパーティのリポジトリのアドレスだけでなく、プロジェクトが動作する特定のリビジョン（必ずしもHEADではない）も指定できます。 プロジェクト内の同じExternalsフォルダーにすべてのサードパーティリポジトリがあります（Externals / zLib、Externals / NGUIなど）

5.コードの管理。 ライブラリに配置するコード

共有コードライブラリを作成するときに発生する最も重要な問題の1つは、そこに配置するコードです。 共通のコードライブラリを整理する試みが何度か失敗しました。 ほとんどの場合、失敗の理由は、1つのプロジェクトのフレームワーク内でのみ必要なものを共通のコードに配置し、誰にとっても有用ではなくなるためです。 ライブラリを機能させるために追加するには、実際に再利用できるコードのみが必要です。

ゲームには通常、この特定のゲーム用の特定のコードがたくさんあることに注意してください。 したがって、この特定のゲームプレイのクローンを開発する予定がない場合は、急いで最初のmatch-3 /ランナー/シューティングゲームの実装をライブラリに持ち込まないでください。 より体系的な方法でタスクにアプローチします。ソリューションの共通部分を強調するようにします。

単純なパターンに従います。
a）初めて解決されたタスクは、このプロジェクトのフレームワーク内で実行され、その目的のために「シャープ化」されます。
b）このタスクに繰り返し直面する場合、可能であれば、一般化され、ライブラリに送信されます
c）アプローチが一般化できるまで、ソリューションコードはプロジェクトからプロジェクトにコピーされ、特定のニーズに適応し続けます

私たちのプラクティスでは、いくつかのアーキテクチャ上の決定は、パターンを追跡してライブラリで決定を下すことができるまで、さまざまなプロジェクトで最大6回の変更を繰り返しました。

6.ファイル構造のモデレーション：単一のコードではない

重要なタスクは、共有ライブラリ内のファイルの構造を決定することでもあります。 どのアプローチも選択できますが、具体的であることが重要であり、チームのすべてのメンバーがそれを理解しています。 ライブラリのルートフォルダは次のとおりです。
zLib / _Externals
zLib / _Resources
zLib / ZGLib
zLib / ZGLib.Collections
など

_Externalsフォルダーには、当社のライブラリに統合するサードパーティのライブラリが含まれています。 _Resourcesフォルダーには、コードではないライブラリ関連のファイル（テキストファイルや画像など）が含まれています。
ZGLib、ZGLib.Collections、およびその他のフォルダーは、ライブラリ内の名前空間を示し、この名前空間に関連するクラスを含みます。 名前空間内では、フォルダ構造は任意です。

7.アーキテクチャの制限：焦点が合っていない場合

アーキテクチャの制限に関連するコードの共通ライブラリについて聞いた主な異論の1つ。 実際、時間の経過とともに、アプリケーションのフレームワークを形成するコンポーネントが共有ライブラリに表示されるため、プロジェクトを作成するときにそのフレームワークを順守する必要があります。
秘Theは、適切に編成すれば、フレームが能力をまったく制限しないことです。 フレームワークの正しい実装の鍵はモジュール性です。 インターフェイスをしっかりと定義するようにしますが、機能を制限するものではありません。

例を挙げましょう。 グローバルオブジェクトのフレームワーク-すべてのシングルトーン（英語シングルトン）を読み込むサブシステムがあります。 私たちが作成したすべてのシングルトーンは、特定のインターフェイス（ZGlob）を実装し、ゲームシーンの特別な場所に配置する必要があります（当然、これはサードパーティフレームワークで提供されるシングルトーンには適用されません）。 したがって、アプリケーションのロードと初期化の1つのポイントを作成します。 単一のインターフェイスにより、機能を制限することなく、グローバルオブジェクトの読み込み順序を柔軟に制御できます。

8.統一されたスタイル：極めて重要

コードライブラリを作成するための前提条件は、チームのコードを記述する一般的なスタイルの形成です。 原則として、単一のスタイルの問題はチームに関連しており、共通のコードライブラリが存在しない場合、少なくともプロジェクト間での切り替えが容易になります。 そして、共有ライブラリを作成するとき、スタイルの問題は非常に重要です。

一般的なコードは、ピリオドという1つのスタイルで記述する必要があります。
まだ共通のスタイルがない場合は、形を整えてください。 Google Docsまたは他のオンラインドキュメントサービスでドキュメントを作成し、そこに一般的なルールを追加します。これは、コードを記述するときに既に従います。 その後、新しいルールを作成してドキュメントを展開することに徐々に同意します。 共通のスタイルをうまく形成するために、チームが共通の意見を得ることができない場合に決定を下すチームの人を任命する必要があります。

9.サブシステムの所有権：「とてもいい、王様」

正しく実行されると、共有コードライブラリはサブシステムに分割されます。 各サブシステムには所有者が必要です。所有者は、すべてのサブシステムに発生するすべての責任を負います。 サブシステムの変更については彼と話し合う必要がありますが、他の人が変更を加えることもできます。 サブシステムの所有者はその哲学を持ち、その作成の歴史を知っており、何よりもその目標を理解しています。

10.サードパーティのフレームワークへの依存：Facebook

ある時点で、他のサードパーティライブラリに関連付けられている一般的なコードで決定を下す必要が生じます。 これは、たとえば、Facebook SDKクラスと直接連携する一般的なFacebookコードの典型的な例です。

私たち自身のために、共有ライブラリを複数の部分に分割することでこの問題を解決しました。各部分は別々のリポジトリにあります。

特定のサードパーティサービスに関連付けられていないメインクラスを含むzLibコアがあります。 zLibFacebookには、Facebook SDKとそれを操作するための一般的なクラスがあります。 zLibTwitter、zLibChartboostなどがあります。 -すでに約10種類のzLibモジュール。 zLibカーネルは常にプロジェクトに追加され、必要に応じて、個別のサブリポジトリによって追加のモジュールが追加されます。

11.登録システムが追加されます。 行動

最も一般的なライブラリ（zLib、zLibFacebookなど）のモジュール性に加えて、共有コードライブラリ内に個別のサブシステムのモジュールアーキテクチャを作成する必要がある場合もあります。 上記のサブシステムの1つのモジュラーアーキテクチャの例は、グローバルオブジェクトのフレームワークです。

さらに強力な例は、ゲーム分析実装システムです。 いくつかのイベントのレジストラを異なるプロジェクト（この場合はzLibに配置）で共有および再利用できるように、共通の分析システムを作成するとします。 一部のイベントは一般的でもありますが、サードパーティのサービスに関連付けられています（私たちと一緒にzLibFacebookにあります）。 残りのイベントは、このアプリケーションに固有である必要があります（そのコードに配置されます）。

この問題を解決するために、制御シングルトンを使用して共有ライブラリにサブシステムフレームワークを作成します（この場合、これはZAnalyticsManagerです）。 次に、イベントロガー（ZAnalyticsTracker）の基本クラスを作成します。 ロガーは、ZAnalyticsManagerに動的に追加できます。 Unity3dでは、これはゲームオブジェクト（Eng。GameObject）の構成により簡単に行えます。 他のテクノロジーについては、これらのテクノロジーで一般的に受け入れられているアプローチを選択できます。

さまざまなサードパーティの分析サービス（Flurry、Google Analytics、Localyticsなど）をサポートするために、イベント送信者インターフェイス（ZAnalyticsSender）を作成します。 このインターフェイスは各分析サービスに実装されており、このプロジェクトで必要な送信者オブジェクトをZAnalyticsManagerに追加します。

したがって、分析システムを向上させるには、コントロールシングルトンオブジェクトを作成し、それにレジストラーと送信者を追加する必要があります。これらは、一般的なコードライブラリとプロジェクトの特定のコードの両方に実装できます。 主なことは、共通のインターフェースをサポートすることです。

12.分岐とプロジェクトの安定性：バグの幽霊

プロジェクト間で同じコードを分割する場合、共通コードのバグを修正すると、すべてのプロジェクトのこのバグが同時に修正されるという点で大きなプラスがあります。 しかし、マイナス面もあります。一般的なコードにバグを導入すると、すべてのプロジェクトに表示されます。 バグの制御されない導入を防ぐために、共有コードリポジトリの各プロジェクトにブランチを作成できます。 次に、このプロジェクトで作業するチームが、メインブランチからの変更をいつマージするかを決定します。

13.非推奨の変更：スムーズで痛みなし

時々、一般的なコードの一部を変更する必要があります-インターフェイスのより良い名前が発明されるか、サブシステムの一般的な構造がリファクタリングされます。 この場合、開発者が新しいトラックに簡単に転送できるように、古いインターフェイスを禁止（英語は非推奨）としてマークし、しばらくは一般的なコードのままにしておくのが最善です。 C＃では、これはObsolete属性を使用して行われますが、他のテクノロジーには同様のメカニズムがあります。 大きな変更を行う場合、新しい実装への移行のための指示書を準備することは価値があります。

非常に劇的なリファクタリングが必要な場合があり、古いインターフェースを保存することはできません。 ここでは、現在の各プロジェクトで新しいアプローチの安定化を手動で制御する必要があります。 主要な変更の統合は、開発の最終段階（リリース、マイルストーン、締め切り前）で実行するのではなく、より静かな期間に延期することをお勧めします。 ここでは、共有ライブラリの分岐とバージョン管理のシステムが役立ちます。

14.テスト範囲：「2つを与える」

自動テストを作成することの利点は誰もが知っています。 また、それらがほとんど書かれていないことも知っています。 また、考えてみれば、それは必ずしも必要ではありません。 小規模なプロジェクトの場合、手動テストと安定化のコストは、自動テストを作成するコストよりも低くなる可能性があります。 ただし、共有コードライブラリの場合、自動テストはほぼ確実に費用を負担します。

したがって、自動テストの導入を計画しているが、まだうまくいかない場合は、共有ライブラリを作成してテストを作成してください。 優秀なマネージャーはそのメリットを理解し、そのための時間を与えてくれます。

ゲームの場合、自動テストは別の問題です。 ビジネスアプリケーションと比較して、ゲームオブジェクトはより多くの関係を持ち、個別にテストするのがより困難です。 現在、ユーティリティクラスを単体テストでカバーし、個別に動作できる一般的なゲームロジックのオブジェクトを統合テストでカバーする予定です。

15.一般的なコードライブラリ：竹を吸う時間はありません

共有ライブラリを作成することの興味深いボーナスは、ダウンタイムを取り除くことでした。 もちろん、仕事で「何もしない」という喜びの中で、もちろん苦労する開発者のカテゴリーが常に存在します。 しかし、仕事なしで酸っぱくなる人にとっては、これは普遍的な解決策です。 プロジェクトで忙しくない人は、共通のライブラリの開発に連れて行かれます。

プロセスを効率的にセットアップするには、共有ライブラリーにマネージャー、そして何よりもテクライドが必要です。 他のプロジェクトと同様に、共有ライブラリにはバグがあり、機能に対する変更要求もあります。 現在、共有ライブラリのタスクプールは60ポイントで構成されており、徐々に増加しています。 そこには、数時間と数週間の両方のタスクがあります。これにより、主要なプロジェクトの作業で短い無料のギャップさえ利用することができます。

16.コンテキストでのzLib：どのサブシステムがありますか

結論として、共有コードライブラリに入れたいくつかのサブシステムのリストを示します。
a）ログとアサーション
b）非同期タスクのラップ
c）JSON'amiでの作業
d）グローバルオブジェクトローダー
e）ゲーム内開発者インターフェースシステム（チートUI）
f）ジェスチャー認識システム
g）分析システム
h）ウィンドウシステム
i）アプリケーション構成システム
j）イベントシステム
k）サードパーティのフレームワークのラッパー

読者や同僚からのフィードバックをお待ちしております。 私たちの経験は役立ちますか、どのような推奨事項を提供できますか？ コメントを歓迎します！