Live Update

ゲームのバンドル（bundle）を作成すると、Defold はゲームのすべてのリソース（resource）を、対象プラットフォーム向けのパッケージにまとめます。実行中のエンジンがすべてのリソースにすぐアクセスし、ストレージから素早く読み込めるため、ほとんどの場合はこの方法が適しています。ただし、リソースの読み込みを後の段階まで遅らせたい場合もあります。たとえば、次のような場合です。

• ゲームが一連のエピソードで構成されていて、プレイヤーが残りのゲームを続けるかどうか決める前に試せるよう、最初のエピソードだけを含めたい場合です。
• HTML5 向けのゲームの場合です。ブラウザーでは、ストレージからアプリケーションを読み込むには、起動前にアプリケーションパッケージ全体をダウンロードする必要があります。このようなプラットフォームでは、起動に必要な最小限のパッケージを送信してアプリケーションを素早く起動し、残りのゲームリソースはその後でダウンロードしたい場合があります。
• ゲームに非常に大きなリソース（画像、動画など）が含まれていて、ゲーム内で表示する直前までダウンロードを遅らせたい場合です。これは、インストールサイズを抑えるためです。

Live Update 機能は、コレクションプロキシ（collection proxy）の概念を拡張し、ビルド時に意図的にバンドルから除外したリソースを、ランタイムが取得してアプリケーションバンドルに保存できる仕組みを提供します。

これにより、コンテンツを複数のアーカイブに分割できます。

• 基本アーカイブ
• レベル共通ファイル
• レベルパック 1
• レベルパック 2
• …

Live Update 用のコンテンツの準備

大きな高解像度画像リソースを含むゲームを作成しているとします。このゲームでは、ゲームオブジェクト（game object）と画像を表示するスプライト（sprite）を持つコレクション（collection）に、これらの画像を保持しています。

エンジンがこのようなコレクションを動的に読み込めるようにするには、コレクションプロキシのコンポーネント（component）を追加し、monalisa.collection を参照するように設定するだけです。これで、コレクションプロキシに load メッセージを送信することで、コレクションのコンテンツをストレージからメモリに読み込むタイミングをゲーム側で選べます。ただし、ここではさらに踏み込んで、コレクションに含まれるリソースの読み込みを自分で制御したいと考えています。

これを行うには、コレクションプロキシのプロパティで Exclude チェックボックスをオンにするだけです。これにより、アプリケーションバンドルの作成時に monalisa.collection 内のコンテンツをすべて除外するよう Defold に指示します。

Live Update の設定

Defold はアプリケーションバンドルを作成する際、除外されたリソースをどこかに保存する必要があります。Live Update のプロジェクト設定は、これらのリソースの保存先を制御します。設定は Project ▸ Live update Settings... から開けます。設定ファイルが存在しない場合は、ここで作成されます。game.project で、バンドル作成時に使用する Live Update 設定ファイルを選択します。これにより、本番、QA、開発など、環境ごとに異なる Live Update 設定を使用できます。

現在、Defold にはリソースの保存方法が3つあります。設定ウィンドウの Mode ドロップダウンで方法を選択します。

Zip

このオプションは、除外されたリソースを含む Zip アーカイブファイルを作成するよう Defold に指示します。アーカイブは Export path 設定で指定した場所に保存され、実行時に zip: URI と liveupdate.add_mount() を使用してマウント（mount）できます。

Folder

このオプションは、除外されたすべてのリソースを含むフォルダーを作成するよう Defold に指示します。アップロードやパッケージ化の前にファイルを後処理する必要がある場合に便利です。コンパイル済みの個々のファイルを、それぞれの想定されるリソースパスに配置したフォルダーは、実行時に file: URI を使用してマウントできます。

Amazon

このオプションは、除外されたリソースを Amazon Web Service（AWS）の S3 バケットに自動的にアップロードするよう Defold に指示します。AWS の Credential profile 名を入力し、適切な Bucket を選択して、Prefix 名を指定します。AWS アカウントの設定方法については、こちらの AWS ガイドを参照してください。

Live Update を使用したバンドルの作成

Live Update を使用したバンドルの作成は簡単です。Project ▸ Bundle ▸ ... を選択してから、アプリケーションバンドルを作成するプラットフォームを選択します。バンドル作成ダイアログが開きます。

バンドルの作成時に、除外対象のリソースはすべてアプリケーションバンドルから除外されます。Publish Live update content チェックボックスをオンにすると、Live Update 設定（上記参照）に応じて、除外されたリソースを Amazon にアップロードするか、Zip アーカイブを作成するよう Defold に指示します。公開される Live Update コンテンツには、リモート配信に必要な完全なリソース一覧を含む liveupdate.game.dmanifest が引き続き含まれます。

Live Update コンテンツを公開する際、Defold はバンドル内の game.dmanifest から Live Update 専用の項目を自動的に削除し、公開される liveupdate.game.dmanifest には完全なリソース一覧を保持します。これにより、バンドルサイズと実行時のメモリ使用量が削減されます。以前の liveupdate.exclude_entries_from_main_manifest 設定は削除されており、プロジェクトに項目が残っていても無視されます。

アーカイブを使用するワークフローでは、該当するアーカイブがマウントされるまで collectionproxy.get_resources() は {} を返します。マウント後は、そのプロキシのリソースハッシュを返します。

Package をクリックし、アプリケーションバンドルの保存先を選択します。これでアプリケーションを起動し、すべてが想定どおりに動作することを確認できます。

.zip アーカイブ

Live Update の .zip ファイルには、基本ゲームパッケージから除外されたファイルが含まれます。

現在のパイプラインで作成できる .zip ファイルは1つだけですが、その zip ファイルをより小さな複数の .zip ファイルに分割することは可能です。これにより、レベルパックや季節ごとのコンテンツなど、ゲームのダウンロードを小さく分けられます。各 .zip ファイルには、その .zip ファイルに含まれる各リソースのメタデータを記述したマニフェストファイルも含まれます。

.zip アーカイブの分割

リソースの使用をより細かく制御するために、除外されたコンテンツをいくつかの小さなアーカイブに分割したいことはよくあります。たとえば、レベルで構成されるゲームを複数のレベルパックに分割する場合です。別の例として、祝日ごとのテーマに合わせた UI 装飾を個別のアーカイブに入れ、カレンダー上で現在該当するテーマだけを読み込んでマウントする場合があります。

リソースグラフは build/default/game.graph.json に保存され、プロジェクトのバンドルを作成するたびに自動生成されます。生成されたファイルには、プロジェクト内のすべてのリソースと、各リソースの依存関係の一覧が含まれます。項目の例を示します。

{
  "path" : "/game/player.goc",
  "hexDigest" : "caa342ec99794de45b63735b203e83ba60d7e5a1",
  "children" : [ "/game/ship.spritec", "/game/player.scriptc" ]
}

各項目には path があり、プロジェクト内でのリソースの一意のパスを表します。hexDigest はリソースの暗号学的なフィンガープリントを表し、Live Update の .zip アーカイブ内でファイル名として使用されます。最後の children フィールドは、このリソースが依存するほかのリソースの一覧です。上記の例では、/game/player.goc はスプライトとスクリプトコンポーネントに依存しています。

game.graph.json ファイルを解析し、この情報を使ってリソースグラフ内の項目をグループに分け、対応するリソースを元のマニフェストファイルとともに個別のアーカイブに保存できます（マニフェストファイルは実行時に、アーカイブ内のファイルだけが含まれるように不要な項目が削除されます）。

Android での Live Update

Play Asset Delivery を使用して、Live Update コンテンツをダウンロードしてマウントできます。詳細は公式マニュアルを参照してください。

コンテンツの検証

Live Update システムの主要な機能の1つは、異なる複数の Defold バージョンで作成されたものも含め、多数のコンテンツアーカイブを使用できることです。

liveupdate.add_mount() は、デフォルトではマウントを追加する際にエンジンのバージョンをチェックします。 このため、ゲームの基本アーカイブと Live Update アーカイブは、バンドル作成オプションを使用し、同じエンジンバージョンで同時に作成する必要があります。これにより、クライアントが以前にダウンロードしたアーカイブはすべて無効になり、コンテンツを再ダウンロードする必要が生じます。

この動作はオプションフラグで無効にできます。 無効にした場合、コンテンツの検証はすべて開発者の責任となり、各 Live Update アーカイブが実行中のエンジンで動作することを保証する必要があります。

アプリケーションがパッケージをマウントしたままにするかどうか判断できるよう、各マウントのメタデータを保存することを推奨します。マウントを追加した後に検証してください。これには、アプリケーションが起動時に必要なマウントを再追加する場合も含まれます。 その方法の1つは、ゲームのバンドルを作成した後に zip アーカイブへ追加のファイルを入れることです。たとえば、ゲームに必要な情報を含む metadata.json を追加し、マウント後に sys.load_resource("/metadata.json") で取得します。 各マウントのカスタムデータには一意のリソースパスを使用してください。そうしないと、リソースの検索で最も優先度の高いマウントのファイルが返されます。

これを怠ると、コンテンツがエンジンとまったく互換性がなく、エンジンを終了せざるを得ない状況になる可能性があります。

マウント

Live Update システムでは、複数のコンテンツアーカイブを同時に使用できます。 各アーカイブは、名前と優先度を付けてエンジンのリソースシステムに「マウント」されます。

2つのアーカイブに同じファイル sprite.texturec がある場合、エンジンは最も優先度の高いマウントからそのファイルを読み込みます。

エンジンは、マウント内のリソースへの参照を保持しません。リソースがメモリに読み込まれた後は、アーカイブをアンマウントできます。リソースはアンロードされるまでメモリに残ります。

マウントが有効なのは現在のエンジンセッションのみです。再起動後は、アプリケーションが必要とするすべてのパッケージに対して liveupdate.add_mount() を再度呼び出す必要があります。パッケージの場所、マウント名、優先度の選択をセッション間で引き継ぐ必要がある場合は、アプリケーションが管理する永続データに保存してください。

Live Update を使用したスクリプトの作成

Live Update コンテンツを実際に使用するには、データをダウンロードしてゲームにマウントする必要があります。 詳しくは、Live Update を使用したスクリプトの作成を参照してください。

開発時の注意点

デバッグ

バンドル版のゲームを実行する際は、コンソールに直接アクセスできません。これはデバッグの妨げになります。ただし、コマンドラインからアプリケーションを実行するか、バンドル内の実行ファイルを直接ダブルクリックして実行できます。

すると、ゲームはシェルウィンドウとともに起動し、print() 文の出力がそこに表示されます。

リソースを強制的に再ダウンロードする

開発者は任意のファイルやフォルダーにコンテンツをダウンロードできますが、多くの場合はアプリケーションのパス配下に保存します。アプリケーションサポートフォルダーの場所はオペレーティングシステムによって異なります。print(sys.get_save_file("", "")) で確認できます。強制的にダウンロードさせるには、ダウンロード済みのパッケージと、アプリケーションが管理する状態に含まれる対応する項目を削除してください。マウントは再起動後に引き継がれないため、削除するためのエンジン管理のマウント一覧はありません。