1
0

More than 3 years have passed since last update.

開発期間におけるアセット管理戦略の選択

Posted at

今回の主な話題:開発期間におけるアセット管理戦略の選択、iOS 14起動時にクラッシュする、IL2CPP暗号化:iOSでglobal-metadata.datの復号化問題、プログラムでコントロールできる3Dアクションの実現方法、Unity Editor内ScreenのWidthとHeight。


Resource

Q:パッケージ化にAssetBundleが必要ですが、開発中にAssetBundleを使うことはあまり適していません。上記の2つのロードには、独自の問題があります。
Resource:Resourcesフォルダーの中に置く必要があり、パッケージ化は少し処理しにくいです。
AssetDatabase:非同期ロード方法はなく、開発中に非同期ロードが必要な状況をシミュレートする方法はありません。

現在、プロジェクトにResourcesを使用しています。パッケージャーが2つのプロジェクトに分割し、APKプロジェクトにResourcesを除外し、単独のバージョンを作成してアップデート命令を管理しますが、それでも非常に面倒です。ほとんどの会社はAssetDatabaseを使用していますが、何か非同期ロードをシミュレートする方法はありますか?

また、上記の2つの方法では、実際のアンロード状況をシミュレートすることはできません。チームメンバーが不当に操作すると、AssetBundleを開いた後、メモリリークや参照の欠落が発生する可能性があります。皆さんの会社が開発中に採用するアセット管理法を共有できますか?

AssetDatabaseを使用すると、非同期をシミュレートするためにランダムな遅延を追加できます。アセットロードのインターフェイスはカプセル化でき、配置によってAssetDatabaseとAssetBundleのどちらに行うことを決めます。
パッケージャーはパッケージされたAssetBundleをSVNに自動的に提出し、いつでもアップデートすることができます。エディターでAssetBundleをテストする方がより便利です。
さらに、新しいAddressableを試すこともできます。

あるプロジェクトチームのアプローチは、通常はResourcesを使用してロードします。AssetBundleまたは公式パッケージの場合、Resourcesディレクトリによって特定のルールに従って1つの新しいプロジェクトを自動的に生成します。これで2つのプロジェクトを維持する必要はありません。

以前にはLoadFromFileAsyncでAssetDatabaseの非同期をシミュレートしていました。
後で試した1つの方法は、単独のアートプロジェクトを使用してAssetBundleを処理し、プログラムプロジェクトはどんなアセットにも担当しなく、アートプロジェクトのみを使って生成するAssetBundleをパッケージすることです。少しだけ変更するでも2つのUnityプロジェクトを操作する必要があるため、複雑に聞こえますが、利点は非常に多いです。

以前は、Resourcesでロードしていました。ただアセットがパッケージ化されないためにEditor/Resourcesディレクトリに配置します。
そして、リリースする際にFlagを切り替え、Editor / ResourcesディレクトリのアセットをロードしてAssetBundleパッケージを作成します。しかし、現在にはすべてAddressablesに任せて管理します。


iOS

Q: iOS 14がリリースされた後、クラッシュ問題が発生しました。モデルには関係なく、iOS 14である限り、必然にクラッシュします、iOS 13の場合は正常です。使用しているUnityバージョンは2018.2.3です。誰かが以前にこれに遭ったことがありますか?
1.png

私たちのプロジェクトもiOS14に問題があります。2つの表現があります。
1、起動時にクラッシュし、数回再起動すれば通過できます。
2、起動後ある段階に入ると、クラッシュします。(回避できません)
XCodeから確認すると、いつもGfxDriverがエラーを報告していました。検出したら、XCodeの[BuildSetting-Packaging-Product Name]に日本語が含めるとこの問題が発生することがわかりました。変更したらよくなります。
根本的な原因はまだわかりません。個人的には、Product NameがHeader Folder Pathに影響があって、コードのロードバスに日本語がある場合に問題が引き起こす(初期のUnityの状況と同様)と推測します。


iOS

Q1: クラッキングの難易度を上げるには、global-metadata.datファイルを暗号化する必要があります。

達成する方法は次のとおりです。

1.暗号化はAndroidおよびXcodeプロジェクトのエクスポート後に実行され、global-metadata.datはバイト単位で暗号化されます。

2.変更:
Android:\Editor\Data\il2cpp\libil2cpp\vm\MetadataLoader.cpp
Mac:Unity.app\Contents\il2cpp\libil2cpp\vm\MetadataLoader.cpp
ファイル内のLoadMetadataFile関数は、ファイルからロードされた内容をバイトごとに復号化します。

現在の問題は、Androidでは問題がなく、ゲームの暗号化と実行は正常に行えます。しかし、Macでは、復号化機能が有効になっていませんようです。ゲームを起動するとクラッシュが発生しました。

皆さんにお聞きたいです。
global-metadata.datがMacでのロードはこの関数を介しますか?MacのUnityインストールディレクトリにも1つのPlaybackEnginesフォルダーがあり、MetadataLoader.hなどのIL2CPP関連ファイルも含まれていますが、このファイルは読み取り専用であり、変更できず、MetadataLoader.cppが見つかりません。Macで復号化が機能しないのは、このファイルと関係がありますか?

A1:iOSでは直接にリンクしてコンパイル済みです。
PlaybackEngines\iOSSupport\Trampoline\Libraries\libil2cpp.a
自分でプロジェクトから.aを削除し、IL2CPPソースコードをプロジェクトにインポートする必要がある場合があります。

Q2: プロジェクトとは、iOS Support/Tramponlineフォルダー内のXcodeプロジェクトですか?Unity.app\Contents\il2cpp\libil2cppにあるすべてのファイルをこのプロジェクトに追加する必要がありますか?

A2:エクスポートされたプロジェクトエンジニアリングを指します。具体的にどのファイルを指すことは自分で試す必要があります。Windowsで1つのIL2CPPのVSプロジェクトをエクスポートしてファイルとコンパイルパラメータを比較できます。

Q3: 最近、このiOS暗号化Metadata問題が発生しました。最後に解決しましたか?
この記事を読むと、Unityのソースコードが必要なようです。

A3:IL2CPPコードをXCodeプロジェクトに直接ドラッグすれば可能なようです。


Animation

Q:私たちの需要は、下図のように、プログラムで柔軟な拍手アクションを実現したいです。
2.png
真ん中は1つの大きいモデル、両側には両手で、拍手アクションをさせたいです。すべての青い点は拍手ポイントとして使用でき、プログラムでどちらの点に拍手することをコントロールする必要があります。

現在考えている方法は下記のようです。
1、拍手アニメーションをたくさん実現してから、Blend Treeで2Dブレンディングを行うことができますが、この方法は正確ではありません。
2、Final IKを使用して両手のアクションをコントロールできますが、動きは不自然です。

Kアクション作業を最小限に抑えたいですが、何か他の方法ありますか?

A1:このような需要は基本的にIKを使用する必要があります。Final IKは現在のUnityエンジンにある最も成熟したIKソリューションです。それでも機能しない場合は、自分で開発することを検討する必要があります。

A2: 以前、2D FreeformDirectionalのBlendTreeを使用して上下左右の動きを融合した経験がありました、融合効果は理想的でした。理論的に、最左、最右、最上、最下の4つの拍手動作を別々作成し、2つのパラメーターで左右と上下の融合をコントロールすれば、より直線的に対応でき、精確さも納得できるようです。しかし、私にはテスト用のアセットもないし、キミが精度への要件もわかりません。Demoを作成して試すことをお勧めします。


Editor

Unity2018.4.23バージョンでテストを行って、1つの9:16解像度を増加しました。この時点で、取得されるWidthとHeightは515×916です。Gameウィンドウのサイズを変更すると、この値も変更されます。これについて具体的なルールな何ですか?

対応する解像度のScale値を掛けたそうとわかりました。例えば、720×1280の解像度でGameウィンドウのScale値は0.741であり、9:16に変更したら解像度はちょうど533×948(720×0.741 : 1280×0.741)になります。現在には、この値を取得できるAPIはありますか?

いくつのUI操作があるため、例えば、1枚の画像を画面と同じサイズに設定されます。しかし、EditorのUI解像度は720×1280であるため、期待値とは異なります。解像度が720×1280(これも9:16)に設定されている場合、取得された値は正しくなります。

主にルールを知りたいです、そして515×916に基づいて720×1280を推測できます。

Editorで、GameウィンドウがAspect Ratioモードを採用する場合、Screenが取得するのは実際のGameウィンドウのサイズです。GameウィンドウがFixed Resolutionモードを採用する場合、Screenが取得するのは設定されたウィンドウのサイズです。


UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析最適化ソリューション及びコンサルティングサービスを提供している会社でございます。

今なら、UWA GOTローカルツールが15日間に無償試用できます!!
よければ、ぜひ!

UWA公式サイト:https://jp.uwa4d.com
UWA GOT OnlineレポートDemo:https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ:https://blog.jp.uwa4d.com

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0