なぜあなたの UEFN マップは死んだのか：Fortnite Creative No Discovery Push の修正方法
すべての UEFN デベロッパーは、300 時間かけて構築したマップの「公開」ボタンを押した直後、アクティブプレイヤー数が 1 週間ずっとゼロのままなのを見る、あの絶望感を知っています。さらに悪いのは、恐ろしい「アップデートの呪い」です。5,000 人の同時接続ユーザー（CCU）がいるマップのスポーンバグを修正するためにマイナーパッチを適用したところ、一晩でアルゴリズムがトラフィックをゼロに落としてしまうのです。あなたは一人ではありませんし、アカウントが壊れているわけでもありません。
fortnite creative no discovery push として知られるこの現象は、めったにバグではありません。これは、Epic Games の Discovery アルゴリズムがセッションのテレメトリをどのように評価するかという、厳密で数学的な結果です。マップにインプレッション（表示回数）がつかなくなった場合、それは基礎となるメトリクスが、プレイヤー体験を保護するために設計された自動シャドウバンをトリガーしたことを意味します。
このテクニカルディープダイブでは、Discovery アルゴリズムがなぜマップを見捨てるのかを正確にリバースエンジニアリングします。サイレントサーバークラッシュの診断方法、プレイヤーの離脱（churn）を追跡するためのカスタム Verse analytics の書き方、そしてアルゴリズムのキャリブレーションフェーズを生き残るためのアップデートの設計方法について解説します。
Discovery アルゴリズム・キャリブレーションの解剖学
なぜマップのトラフィックが失われたのかを理解するには、Discovery タブが新しいコンテンツをどのように評価するかを理解する必要があります。Epic のアルゴリズムはブラックボックスですが、長年の集合的なテレメトリ分析により、新しい島コードを公開したりアップデートをプッシュしたりするたびに発生する明確な「キャリブレーションフェーズ」が明らかになっています。
マップが公開されると、Epic はそれにベースラインの重みを割り当て、制御された少数のテストバッチプレイヤーをあなたの島に送ります。アルゴリズムは、そのテストバッチからのテレメトリを積極的に監視します。データが不良であれば、キャリブレーションは失敗し、マップは即座に埋もれてしまいます。
では、アルゴリズムにとって具体的に何が「不良なテレメトリ」となるのでしょうか？それは 4 つの決定的な失敗ポイントに集約されます：
- High Bounce Rate（高い直帰率）： プレイヤーが参加後 60 秒以内に離脱する。
- Short Average Playtime（短い平均プレイ時間）： セッション全体の長さが 10 分未満である。
- Low Return Rate（低い再訪率）： プレイヤーがマップをお気に入りに登録しない、または 2 日目（D1）や 7 日目（D7）のセッションに戻ってこない。
- High Crash/Error Rate（高いクラッシュ/エラー率）： Dedicated Server がカクつく、またはクライアントがクラッシュする（特に Nintendo Switch やモバイル）。
既存の成功しているマップにアップデートをプッシュすると、アルゴリズムは新しいビルドの安定性をテストするために、Discovery の配置を一時的に制限します。アップデートで誤って memory leak や UI の不具合が導入され、テストバッチが早期に離脱した場合、マップは再キャリブレーションチェックに失敗します。トラフィックは横ばいになり、ソーシャルメディアのフォロワーだけに頼ることになります。
ステップ 1：サイレントサーバークラッシュとヒッチの診断
マップのゲームプレイ・ループを再設計し始める前に、技術的な失敗を排除する必要があります。Discovery アルゴリズムは、ネットワークの同期ずれ（network desyncs）やメモリの問題が多いマップを積極的にフィルタリングします。あなたはハイエンド PC で問題なくプレイできているかもしれませんが、ローエンドのコンソールでマップがクラッシュしている場合、グローバルメトリクスは急落します。
Discovery トラフィックが突然減少する最も一般的な原因は、最適化されていない Verse コードや過剰なメモリ使用量によって引き起こされるサイレントサーバーヒッチ（server hitch）です。マップで Spatial Thermometer を使用している場合は、セルが 100,000 のメモリ制限を超えていないことを確認してください。セルがオーバーロードすると、モバイルプレイヤーに大幅なフレームドロップが発生し、即座の切断につながります。
さらに、ネットワークドライバーを確認してください。プレイヤーがフリーズしているが切断されていない場合は、正式なクラッシュとして登録されずにセッションを台無しにする network timeout の問題に対処している可能性があります。この特定のネットワーク動作をデバッグするには、Uefn Session Launch Timeout Nightmares Diagnosing Unreal Engine Network Drivers のディープダイブをお読みください。
ステップ 2：離脱を特定するための Verse Analytics パイプラインの構築
サーバーが安定し、メモリが最適化されている場合、問題はゲームデザインにあります。プレイヤーが離脱しているのなら、どこで、なぜ辞めているのかを正確に知る必要があります。Creator Portal の一般的な「平均プレイ時間」メトリクスに頼るだけでは不十分です。詳細なデータが必要です。
Verse を介して analytics_device を活用することで、特定のプレイヤーのマイルストーンを追跡できます。1,000 人のプレイヤーがスポーンしたのに、200 人しか「チュートリアル完了」イベントをトリガーしなかった場合、ボトルネックがどこにあるか正確にわかります。
以下は、プレイヤーのオンボーディング（onboarding）を追跡し、AFK による離脱を防ぐためのフェイルセーフを実装した堅牢な Verse 実装です。
Verse コード：カスタム Analytics と離脱防止フェイルセーフ
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /EpicGames.com/Temporary/Diagnostics }
# A custom device to track player onboarding and prevent spawn-trapping
analytics_manager_device := class(creative_device):
@editable
SpawnPad : player_spawner_device = player_spawner_device{}
@editable
TutorialZone : mutator_zone_device = mutator_zone_device{}
@editable
MainArenaTeleporter : teleporter_device = teleporter_device{}
@editable
AnalyticsDevice : analytics_device = analytics_device{}
OnBegin<override>()<suspends>:void=
# Subscribe to critical onboarding events
SpawnPad.SpawnedEvent.Subscribe(OnPlayerSpawned)
TutorialZone.AgentEntersEvent.Subscribe(OnTutorialCompleted)
OnPlayerSpawned(Agent:agent):void=
# Log that the player successfully loaded into the map
AnalyticsDevice.RecordPlayerEvent(Agent, "player_spawned")
Print("Analytics: Player Spawned Logged")
# Start a failsafe timer to ensure they don't get stuck in spawn
spawn{ StartFailsafeTimer(Agent) }
OnTutorialCompleted(Agent:agent):void=
# Log that the player survived the initial onboarding
AnalyticsDevice.RecordPlayerEvent(Agent, "tutorial_cleared")
Print("Analytics: Tutorial Cleared Logged")
StartFailsafeTimer(Agent:agent)<suspends>:void=
# Give the player 30 seconds to figure out how to leave the spawn room
Sleep(30.0)
# If they are still in the spawn zone after 30 seconds, force them into the action
if (TutorialZone.IsInVolume[Agent] = false):
MainArenaTeleporter.Teleport(Agent)
AnalyticsDevice.RecordPlayerEvent(Agent, "failsafe_teleported")
Print("Failsafe: Teleported stuck player to arena")
このコードが Discovery Push を救う理由
このスクリプトは 2 つの重要なことを行います。まず、カスタムイベントのテレメトリを Creator Portal にプッシュします。これにより、player_spawned イベントと tutorial_cleared イベントの比率を比較できます。大幅なドロップオフがある場合、スポーンルームが混乱しすぎているか、UI が壊れています。
次に、StartFailsafeTimer が含まれています。平均プレイ時間を低下させる最大の要因の一つは、プレイヤーがスポーンルームで立ち往生し、イライラしてロビーに戻ってしまうことです。30 秒後に強制的にメインアリーナにテレポートさせることで、即座にコア・ループに参加させ、60 秒の直帰率を劇的に下げることができます。
Epic は analytics device に渡す文字列に厳しい制限を設けていることに注意してください。イベントがポータルに表示されない場合、文字列が長すぎる可能性があります。フォーマット規則については、Cracking The 32 Character Uefn Analytics Device Event Name Limit Verse Tutorial のガイドを確認してください。
ステップ 3：継続率向上のためのクロスセッション・プログレッションの設計
最初の 30 秒を突破させることで直帰率は解決しますが、10 日以上 Discovery push を維持するには、1 日目（Day 1）と 7 日目（Day 7）の継続率（retention）を克服する必要があります。プレイヤーに明日戻ってくる理由がなければ、マップは必然的にアルゴリズムから外れます。
高い継続率を達成するには、永続的な進行（persistent progression）が必要です。UEFN は組み込みのセーブデバイスを提供していますが、それらは高度に隔離されています。単一のマップでしか機能せず、アップデートで変数構造を変更するとプレイヤーのセーブファイルが簡単に破損し、大量の離脱につながります。
真にスケールさせるために、現代の UEFN クリエイターは外部の進行システムを構築しています。複数のマップからなるユニバース全体でプレイヤーの統計を追跡したり、グローバルなリアルタイム leaderboards を運営したり、ゲームをまたいだ VIP 報酬を付与したりするには、外部の Backend アーキテクチャが必要です。
これを自前で構築するには、load balancers、データベースのシャーディング（sharding）、WebSocket 接続、SSL 証明書管理の設定が必要で、優に 4〜6 週間の専任エンジニアリング作業がかかります。horizOn を使えば、これらのバックエンドサービスは事前設定済みです。スケーラブルなデータベースとリアルタイムのマルチプレイヤー・インフラストラクチャに即座にアクセスでき、クラウド・インフラストラクチャと格闘する代わりに、ゲームの進行システムをリリースすることに集中できます。
ステップ 4：「アップデート・ペナルティ」を生き残る
アップデート直後にマップが Discovery push を失うという特定の問題に対処しましょう。前述のように、新しいバージョンをプッシュすると、アルゴリズムはマップを再キャリブレーションせざるを得なくなります。
マップの同時接続ユーザー（CCU）のピーク時間帯にアップデートをプッシュするのは、自ら妨害工作をしているようなものです。新しいバージョンを適用するためにサーバーが再起動されると、アクティブなプレイヤーは追い出されます。これはセッション終了の巨大なスパイクとして記録されます。アルゴリズムは数千人のプレイヤーが同時に離脱するのを見て、マップが壊れていると判断し、即座に Discovery の配置を解除します。
アップデート・ペナルティを避けるには、UEFN マップを live-ops サービスのように扱う必要があります：
- ピーク時間帯には絶対にアップデートしない。 トラフィックが最も少ない時間帯（通常は米国東部標準時午前 3:00 〜 5:00）に常にアップデートをプッシュしてください。
- アップデートをバッチ化する。 ゲームを壊すようなエクスプロイトでない限り、毎日の修正はプッシュしないでください。変更を週単位または月単位の「シーズン」にまとめてください。すべてのアップデートはリスクです。アルゴリズムに再キャリブレーションを強いる回数を最小限に抑えましょう。
- QA には Private Versions を使用する。 Verse スクリプトが動作するかどうかを確認するために、パブリックリリース・ブランチを絶対に使用しないでください。プライベートコードを生成し、10〜15 人のテスターを招待し、ビルドを公開する前にクラッシュ率が 0% であることを確認してください。
Discovery Push をトリガーするための 5 つのベストプラクティス
10 日以上トラフィックがない状態が続いている場合は、アルゴリズムに再び注目させるために積極的に働きかける必要があります。次回のアップデートで、これら 5 つの実戦で証明されたベストプラクティスを適用してください：
- Time-to-First-Action (TTFA) の最適化： イントロのシネマティックをカットしてください。プレイヤーはロード後 5 秒以内に意味のある入力ができるべきです。TTFA が 15 秒を超えると、直帰率が Discovery のチャンスを潰します。
- 外部トラフィックによるサムネイルの A/B テスト： Epic のアルゴリズムはクリック率（CTR）を非常に重視します。オーガニックな Discovery に頼る前に、TikTok や YouTube Shorts からトラフィックを誘導してください。コンバージョン率を監視しましょう。外部トラフィックがサムネイルをクリックしないのであれば、Epic のオーガニックトラフィックもクリックしません。
- フェイルセーフ・スポナーの実装： 単一のスポーンパッドに決して頼らないでください。隠れた場所に予備のスポーンパッドを配置し、メインのパッドが障害物を検知した場合に Verse を使用してそれらを切り替えるようにします。
- Verse Concurrency オーバーヘッドの最小化： 無限ループを実行する 50 個の異なる
spawn{}ブロックがあると、サーバーヒッチの原因になります。並列ループを、制御されたティックレートですべてのシステムを同時に更新する単一のマネージャーデバイスに統合してください。 - 8 分のしきい値の監視： Creator Portal を毎日確認してください。Discovery アルゴリズムの非公式な「生存ライン」は、平均プレイ時間 8 分です。マップがこの指標を下回った場合は、セッション時間を人工的に延ばすための中盤の目的を追加するコンテンツアップデートを即座にプッシュする必要があります。
推測をやめ、測定を始める
fortnite creative no discovery push は呪いではなく、最適化の不足です。アルゴリズムは安定性、即時のエンゲージメント、そして長期的な継続率を求めています。厳格な Verse analytics の実装、サイレントサーバータイムアウトの解決、そしてアップデート頻度の慎重な管理により、マップの露出を再びコントロールできるようになります。
UEFN の島を静的なマップとして扱うのをやめ、live-service 製品として扱い始めてください。データを追跡し、オンボーディングを最適化し、プレイヤーが毎日戻ってきたくなるような進行システムを構築しましょう。
マルチプレイヤー・バックエンドをスケールさせ、マップをまたいだ進行システムを構築する準備はできましたか？horizOn を無料でお試しいただくか、API ドキュメントで外部ゲーム状態管理がいかに簡単かを確認してください。