「Unityで作ったゲームは投稿できますか」：条件と非対応の機能

Q1. どんな形で投稿できますか

投稿の入口は二つです。

• HTML・ZIPの直接アップロード：ビルドしたファイルをアソバースに預けます。ZIPなら複数ファイルをまとめられます。
• 公開済みURL：すでにどこかで公開しているゲームのURLを入力します。

投稿画面は「入力→表示の確認→公開」の3段階です。下書き保存ができ、公開後も内容の更新、非公開化、削除ができます。公開にはメールアドレスの確認が必要です。

アップロードの場合、入口はZIP直下のindex.htmlです。素材は相対パスで参照する必要があります。Unityのビルド出力は、通常はindex.htmlのほかにBuildフォルダなどが並ぶ構成です。ZIPにするときは、出力フォルダを丸ごと包むのではなく、中身が直下に並ぶようにまとめます。親フォルダごと圧縮すると、index.htmlが一段深くなり、入口として見つからない原因になります。

URL投稿の場合は、ゲームがアソバースのプレイ画面に埋め込まれて動くことになります。ホスト側の設定によって埋め込みが拒否されることもあります。その場合の扱いは、現在の案内で確認してください。

Q2. 容量やファイル数の条件はどうなっていますか

確認済みの数値を、Unityの出力に当てはめる観点と並べます。

• アップロードの大きさ、確認済みの条件：20MiB以内、Unityで見る場所：作ったZIPのファイルサイズ
• ZIP展開後の合計、確認済みの条件：100MiB以内、Unityで見る場所：展開したフォルダ全体のサイズ
• ファイル数、確認済みの条件：1,000ファイル以内、Unityで見る場所：展開したフォルダ内の総数
• 1ファイルの大きさ、確認済みの条件：30MiB以内、Unityで見る場所：Build内で最大のファイル
• 1日の回数、確認済みの条件：1人あたりUTC1日10回、Unityで見る場所：試行錯誤の回数
• アカウントの総量、確認済みの条件：100アップロード・1GiBまで、Unityで見る場所：過去の投稿との合計

Unityでは、ゲームの本体データを大きな1ファイルにまとめる構成が一般的です。そのため、「合計」だけでなく「1ファイルの最大値」も確認が必要です。ZIPが20MiBに収まっていても、展開後の最大ファイルが30MiBを超えていれば条件外です。

もう一つ注意したいのは、UnityのWebGLビルドにはGzipやBrotliといった圧縮形式の設定があることです。圧縮形式によっては、配信する側が特定の応答ヘッダーを付けないと読み込めません。アソバースの配信がこの種の圧縮ファイルにどう対応するかは、確認済み事項にありません。現在の案内で確認するか、圧縮を無効にした出力をZIPに入れてプレビューで動作を確かめてください。Unity側の関連設定には、圧縮形式のほか、圧縮ファイルを自前で展開する代替設定もあります。名称と挙動はバージョンごとに違うので、Unity公式マニュアルで確認してください。

また、アップロード回数は1人あたりUTC（協定世界時）の1日で10回です。日本時間では朝9時にリセットされる計算になります。「容量を切り詰めては再投稿」を繰り返すと、回数を使い切ります。投稿前に、手元でZIPのサイズと最大ファイルを確認してから上げるほうが無駄がありません。

Q3. 対象外の機能は何ですか

アップロード作品の対象外として、次の三つが示されています。

1. サーバー用コード：サーバー側で動く処理は動かせません。ゲームはブラウザ内で完結する必要があります。
2. サービスワーカー：オフライン動作や通信の横取りのために登録する仕組みは使えません。
3. SharedArrayBufferを使うマルチスレッド：複数のスレッドでメモリを共有する構成は対象外です。

なお、ここでいう「サーバー用コード」は、作品に同梱して動かそうとするサーバー側の処理を指します。外部のサービスへ通信できるかどうかは、確認済み事項に書かれていません。通信を使うゲームは、現在の案内で確認してください。

SharedArrayBufferは、複数のスレッドが同じメモリを共有するための仕組みです。ブラウザでこれを使うには、ページを特別なセキュリティ条件で配信する必要があります。その条件は、配信側のヘッダー設定に依存します。UnityのWebGLビルドでスレッドに頼る構成にすると、この仕組みが必要になる場合があります。ここから、次の見立てが立てられます。

• 通常のシングルスレッドのWebGLビルドであれば、この対象外には当たらない可能性があります。
• スレッドを前提にしたプラグインや設定を入れている場合は、対象外に当たる可能性があります。

どちらに当たるかは、プロジェクトの設定と、使っているUnityのバージョンの仕様で決まります。確認済み事項には、Unityの個別の設定に関する情報はありません。まず自分のプロジェクトで、スレッド関連の設定を使っていないかを確かめてください。

サービスワーカーも同様です。標準のWebGLテンプレートで登録されるかどうかは、バージョンやテンプレートによって異なります。カスタムテンプレートやPWA向けのテンプレートを使っている場合は、index.htmlや関連するスクリプトに、サービスワーカーの登録処理が含まれていないかを検索して確認してください。

Q4. 保存や実行環境で気をつけることはありますか

アップロードしたゲームは、sandbox付きのiframeで実行されます。コードは、アソバースのメインサイトとは別のオリジンから配信されます。ブラウザ機能の一部は、この環境で制限を受ける可能性があります。たとえば全画面表示、ポインターのロック、クリップボードなどです。どれが使えるかは確認済み事項にありません。ゲームで使っているなら、現在の案内で確認し、プレビューで実際に操作して確かめてください。

保存まわりでは、次のことが確認されています。

• アップロードしたゲームには、SDKが自動で追加されます。
• SDKを使うと、作品専用のプレイヤーIDと、クラウドセーブ（作品ごとにJSONで128KiBまで）が使えます。
• アップロード作品内のlocalStorageとsessionStorageは、一時メモリーの互換処理です。永続的な保存先としては当てにできません。
• ゲームにFirebaseのUID、認証トークン、メールアドレスを渡してはいけません。

Unityは、PlayerPrefsなどの保存をブラウザの保存機構に結びつけて動かします。ここが一時メモリー扱いになると、ブラウザを閉じたときに進行が消える可能性があります。進行を残したいゲームは、128KiBまでのJSONに収まるセーブデータの設計を検討してください。SDKとUnityのコードの具体的なつなぎ方は、確認済み事項にありません。現在の案内で確認してください。

URLで投稿する場合は、作者がSDKを読み込むと、同じ作品専用のプレイヤーIDとクラウドセーブが使えます。この場合は、SDKの読み込みを作者側で用意します。

Q5. 投稿前に何を確かめればよいですか

自分で答えが出せるように、確認の順番を示します。

1. ビルドを書き出す：Unityの出力先フォルダを用意します。
2. ZIPの直下を確認する：ZIPを開いて、最初の階層にindex.htmlがあるか確かめます。
3. サイズを3か所で測る：ZIP全体、展開後の合計、Build内の最大ファイルを見ます。20MiB、100MiB、30MiBのどれかを超えるなら、アセットの削減などで小さくします。
4. ファイル数を数える：展開後のフォルダにあるファイルの総数を確かめます。1,000以内が条件です。
5. 対象外の機能を検索する：サービスワーカーの登録処理と、スレッド関連の設定が出力に含まれていないかを確認します。
6. 相対パスを確認する：index.htmlが読み込む先が、相対パスになっているかを見ます。
7. プレビューで動かす：投稿画面の「表示の確認」で、起動、操作、音、保存を一通り試します。
8. 下書きで止める：問題があれば下書き保存のまま直します。回数の制限があるため、公開前に手元でできる確認は済ませておきます。

結果の読み方は次のとおりです。起動しない場合は、まず入口の位置と圧縮形式の扱いを疑います。途中で止まる場合は、対象外の機能を使っていないかを見ます。サイズの超過は、数値で明確に判断できます。原因が特定できないときは、最小のシーンだけのビルドを作って投稿し直すと、どこから動かなくなるかを切り分けられます。ただし、これも1日10回の枠を使います。

次の行動

まず、Unityのビルド出力でZIPの直下にindex.htmlがあるか、Build内の最大ファイルが30MiBを超えていないかを確かめてください。次に、スレッドとサービスワーカーに関する設定がないかを見て、投稿画面の「表示の確認」まで進めます。アソバース側で書かれていない挙動は、現在の案内で確認してから判断してください。

参考資料

• Unity公式マニュアル（WebGLビルドと圧縮形式に関する項目）
• 各ブラウザ公式ドキュメント（SharedArrayBufferとサービスワーカーに関する項目）