CocosCreatorプロジェクト構造の仕組みの詳細な説明

1. プロジェクトフォルダ構造

Cocos Creator プロジェクトを初めて作成して開くと、開発者のプロジェクト フォルダーには次の構造が含まれます。

以下、各フォルダの機能を紹介します。

1. アセットフォルダ

アセットは、ゲーム内のすべてのローカル リソース、スクリプト、サードパーティ ライブラリ ファイルを保存するために使用されます。リソース マネージャーには、アセット ディレクトリ内のコンテンツのみを表示できます。アセット内の各ファイルがプロジェクトにインポートされると、対応するリソース構成とインデックス情報を格納するために、同じ名前の .meta ファイルが生成されます。 .meta ファイルはバージョン管理システムに送信する必要があります。詳細については、「リソース管理に関する注意事項--- meta ファイル」を参照してください。

TexturePacker の .tps ファイルや Photoshop の .psd ファイルなど、サードパーティ ツールによって生成された一部のエンジニアリング ファイルまたはデザイン オリジナル ファイルは、アセットの外部で管理できます。

2. 図書館

ライブラリは、アセット内のリソースをインポートした後に生成されます。ここで、ファイル構造とリソース形式が、最終的なゲームリリースに必要な形式に処理されます。ライブラリが失われたり破損したりした場合は、ライブラリ フォルダー全体を削除してからプロジェクトを開き、リソース ライブラリを再生成します。

3. ローカル設定（ローカル）

ローカル フォルダーには、エディター パネルのレイアウト、ウィンドウのサイズ、位置などの情報を含む、ローカル マシン上のプロジェクトの構成情報が含まれています。開発者はここでのコンテンツについて心配する必要はありません。

4. 拡張プラグインフォルダ（パッケージ）

パッケージ フォルダーは、このプロジェクトのカスタム拡張プラグインを配置するために使用されます。拡張機能を手動でインストールする必要がある場合は、このフォルダーを手動で作成できます。拡張機能をアンインストールするには、パッケージ内の対応するフォルダーを削除するだけです。

5. プロジェクト設定

設定には、ビルドおよびリリース メニューのパッケージ名、シーン、プラットフォームの選択など、プロジェクト関連の設定が保存されます。

6. 一時フォルダ（temp）

temp は一時フォルダーであり、Cocos Creator の一時ファイルをローカルにキャッシュするために使用されます。このフォルダは、Cocos Creator を閉じた後に手動で削除することができ、開発者はフォルダ内の内容を気にする必要はありません。

7.プロジェクト.json

project.json ファイルとアセット フォルダーは、Cocos Creator プロジェクトの正当性を検証する証拠として機能します。これら 2 つのコンテンツを含むフォルダーのみを Cocos Creator プロジェクトとして開くことができます。開発者はコンテンツを気にする必要はありません。

8. ビルドターゲット

メイン メニューの [プロジェクト] -> [ビルドとリリース...] を使用してデフォルトの公開パスを使用してプロジェクトを公開すると、エディターはプロジェクト パスの下にビルド ディレクトリを作成し、すべてのターゲット プラットフォームのビルド プロジェクトを保存します。

9. バージョン管理

新しいプロジェクトを作成すると、Cocos Creator は .gitignore ファイルを自動的に生成し、git リポジトリに送信しないファイルを除外します。開発者が他のバージョン管理システムを使用している場合、またはプロジェクトを他の場所に送信する必要がある場合は、アセット、パッケージ、設定、project.json、またはその他の手動で追加された関連ファイルのみを送信する必要があることに注意してください。

2. リソース管理に関する注意事項 --- メタファイル

Creator によって生成されたメタ ファイルの役割とメカニズムを理解することで、複数人での開発中によく発生するリソースの競合、ファイルの損失、コンポーネント属性の損失などの問題を、あなたとあなたのチームが解決できるようになります。メタファイルは何に使用されますか?以下で見てみましょう。

1. メタファイルの役割

まず、シーン内のメタファイルがどのようになっているかを見てみましょう。

プレハブのメタファイルはシーンと同じです。 PNG 画像のメタ ファイルには多くの情報が含まれています。基本的な ver と uuid に加えて、画像の幅、高さ、オフセット、9 グリッド レイアウトなどのデータも記録されます。上記には多くの情報がありますが、ここで重要なのは uuid だけです。 uuid: ユニバーサルユニーク識別子 uuid は、ゲームリソースを管理するために作成者によって使用されます。各ファイルに一意の ID が割り当てられ、アトラスは複数の ID を生成します。このことから、Creator エンジンでは、ファイルを識別するということは、単にパス + ファイル名でファイルを特定するということではなく、UUID を通じてファイルを参照するということであることがわかります。そのため、エディターのリソース管理では、ファイルを自由に削除したり移動したりすることができます。

2. メタファイルの更新タイミング

Creator は次の状況でメタ ファイルを生成します。

1. プロジェクトを開くと、Creator はまずアセット ディレクトリをスキャンします。ファイルのメタ ファイルがない場合、この時点で生成されます。

2. リソースを更新すると、リソースの更新によってメタファイルの更新もトリガーされます。

リソース マネージャーでは、リソース ファイル名の変更、ディレクトリの変更、ファイルの削除、ファイルの追加などを行うことができます。リソース マネージャーを参照してください。デスクトップまたはオペレーティング システムのファイル マネージャーからエクスプローラーにファイルを直接ドラッグすることもできます。もう 1 つの状況は、オペレーティング システムのファイル マネージャーでアセット ディレクトリ内のファイルを追加、削除、または変更した後、エディター インターフェイスに切り替えると、リソース マネージャーの更新プロセスが表示されることです。ファイルのメタ ファイルが存在しない場合は、上記の 2 つの状況によりエンジンがメタ ファイルを生成するようになります。

3. メタ ファイルが失敗する可能性のあるいくつかの状況とその解決方法 以下では、メタ ファイルが失敗する可能性のあるいくつかの状況を分析します。 UUID の競合 UUID はグローバルに一意です。異なるファイルに同じ UUID がある場合、競合が発生します。この問題が発生すると、Cocos Creator リソース マネージャーのディレクトリ構造が完全に読み込まれなくなります。下の図に示すように、このような状況に遭遇すると、おそらく冷や汗が出るでしょう。

プロンプトから競合する uuid 文字列を確認したら、オペレーティング システムのファイル管理またはコード エディターを開いて、この uuid を検索します。

このとき、まず Creator エディターを閉じ、メタ ファイルの 1 つをランダムに削除してから、再度 Creator エディターを開くと問題が解決します。この方法で問題は解決できますが、エディターで参照されているリソースは失われ、再編集または再構成する必要があります。このメタ ファイルをバージョン管理ツールを使用して復元するのが最適です。この問題には、一般的に 2 つの原因があります。オペレーティング システムのファイル マネージャーでファイルを移動するときに、切り取りと貼り付けではなく、誤ってコピーと貼り付けを実行し、メタ ファイルも同時にコピーされます。その結果、プロジェクト内に 2 つの同一のメタ ファイルが同時に表示されます。複数の人と共同作業を行う場合、バージョン管理ツールでリソースを更新すると、他の人が生成した UUID が自分のコンピューター上のファイルによって生成された UUID と同じになることがあります。ただし、このような状況は非常にまれです。一般的に、UUID 競合の発生を減らすには、エンジン リソース管理ツールでファイルを追加および移動することが最適です。

3. UUIDの変更

もう 1 つの状況は、UUID が変更され、古い UUID に対応するリソースが見つからないことです。この場合、編集したインターフェイスからリソースと画像が失われ、コンポーネント属性も失われる可能性があります。

古い uuid に対応するリソースが見つからない場合は、コンソールを通じて、Creator がシーン ファイル名、ノード パス、コンポーネント、uuid などの非常に詳細な警告情報を提供していることがわかります。警告メッセージはエラーを素早く見つけるのに役立ちます。この状況はどうして起こったのでしょうか?誰かがプロジェクトに新しいリソースを追加するときに、エディター インターフェイスに切り替えてメタ ファイルを生成することを忘れ、新しく追加されたこれらのファイル (メタ ファイルを除く) をバージョン管理に送信します。次に、別の人が自分が送信したリソースを更新し、エディター インターフェイスに切り替えて編集します。このとき、Creator は新しいリソースにメタ ファイルがないことを確認し、すぐにメタ ファイルを生成します。最初の人がエディターに切り替えると、メタ ファイルも生成されます。このように、両方の人のコンピューターに同じファイルが表示されますが、生成されたメタ ファイルの UUID は異なります。この場合、後からリソースを送信または更新する人は必ず競合に遭遇します。理由を知らずに競合を強引に解決しようとすると、上記のような問題が発生します。次のシーケンス図は、このエラーのワークフローを示しています。

最初の学生Aがメタファイルを生成して提出するのを忘れたため、その後他の人がプロジェクトを編集しましたが、各人が生成したuuidが異なり、無限のリソースエラーが発生していました。編集したものは、更新のために提出されるとすぐに再び競合します。

この問題を解決するには、以下の点に注意してください。l 提出前に新しいファイルがあるかどうかを確認してください。新しいファイルがある場合は、一緒に提出する必要があるメタファイルがあるかどうかに注意してください。l ファイルをプルするときは、新しいファイルがあるかどうか、およびそれらがメタファイルとペアになっているかどうかに注意してください。そうでない場合は、以前にファイルを提出した学生にメタファイルを一緒に提出するように思い出させてください。l 提出時に、新しいメタファイルしかないことがわかった場合、このメタファイルは自分で生成したはずなので、このメタファイルに対応するリソース（同じ名前のファイル）が使用されているかどうかに注意する必要があります。使用されていない場合は、最初のコミッターにメタファイルを送信するように依頼してください。このメタファイルは絶対に送信しないでください。上記の点に注意することで、メタファイルの UUID の変更によって発生するエンジニアリング エラーを基本的に防ぐことができます。

概要: メタ ファイルは Creator がリソースを管理するための重要な手段ですが、共同開発中に注意しないとリソース エラーが簡単に発生する可能性があります。この問題を解決するには、メタファイルの生成メカニズムと競合の原因を理解するだけでなく、リソース送信プロセスを標準化する必要があります。

以上がCocosCreatorプロジェクト構造の仕組みの詳しい説明です。CocosCreatorプロジェクト構造の仕組みについてさらに詳しく知りたい方は、123WORDPRESS.COMの他の関連記事もぜひご覧ください。