Pourquoi votre map UEFN est morte : Corriger le Fortnite Creative No Discovery Push
Tout développeur UEFN connaît ce sentiment de vide au moment de cliquer sur « Publier » pour une map qui a nécessité 300 heures de travail, pour ensuite voir le nombre de joueurs actifs stagner à zéro pendant une semaine entière. Pire encore, le redoutable « sort de la mise à jour » : vous publiez un petit patch pour corriger un bug de spawn sur une map qui attire 5 000 utilisateurs simultanés, et du jour au lendemain, l'algorithme réduit votre trafic à néant. Vous n'êtes pas seul, et votre compte n'est pas cassé.
Le phénomène connu sous le nom de fortnite creative no discovery push est rarement un bug. C'est une conséquence mathématique stricte de la manière dont l'algorithme Discovery d'Epic Games pondère la télémétrie des sessions. Lorsque votre map ne reçoit plus d'impressions, cela signifie que vos métriques de base ont déclenché un shadowban automatisé conçu pour protéger l'expérience des joueurs.
Dans cette analyse technique approfondie, nous allons faire du reverse-engineering pour comprendre exactement pourquoi l'algorithme Discovery abandonne certaines maps. Nous verrons comment diagnostiquer les crashs serveurs silencieux, comment écrire des analytics Verse personnalisés pour suivre le churn des joueurs, et comment architecturer vos mises à jour pour survivre aux phases de calibration de l'algorithme.
L'anatomie de la calibration de l'algorithme Discovery
Pour comprendre pourquoi votre map a perdu son trafic, vous devez comprendre comment l'onglet Discovery évalue le nouveau contenu. L'algorithme d'Epic est une boîte noire, mais des années d'analyse collective de la télémétrie ont révélé une « phase de calibration » claire qui se produit chaque fois que vous publiez un nouveau code d'île ou une mise à jour.
Lorsqu'une map est publiée, Epic lui attribue un poids de base et envoie un petit échantillon de test de joueurs sur votre île. L'algorithme surveille ensuite de manière agressive la télémétrie de ce groupe de test. Si les données sont mauvaises, la calibration échoue et la map est immédiatement enterrée.
Alors, qu'est-ce qui constitue exactement une « mauvaise télémétrie » pour l'algorithme ? Cela se résume à quatre points de défaillance critiques :
- High Bounce Rate : Les joueurs partent dans les 60 premières secondes après avoir rejoint.
- Short Average Playtime : La durée totale de la session est inférieure à 10 minutes.
- Low Return Rate : Les joueurs ne mettent pas la map en favori ou ne reviennent pas pour des sessions à J+1 (D1) ou J+7 (D7).
- High Crash/Error Rate : Le Dedicated Server saccade, ou le client crash (particulièrement sur Nintendo Switch ou Mobile).
Lorsque vous poussez une mise à jour sur une map existante qui fonctionne bien, l'algorithme réduit temporairement votre placement Discovery pour tester la stabilité du nouveau build. Si votre mise à jour introduit accidentellement un memory leak ou un glitch d'UI qui pousse le groupe de test à partir prématurément, votre map échoue au test de recalibration. Votre trafic s'effondre, et vous ne pouvez plus compter que sur vos abonnés sur les réseaux sociaux.
Étape 1 : Diagnostiquer les crashs serveurs silencieux et les saccades
Avant de commencer à redessiner le gameplay loop de votre map, vous devez écarter les défaillances techniques. L'algorithme Discovery filtre agressivement les maps présentant des network desyncs élevés ou des problèmes de mémoire. Vous jouez peut-être sur un PC haut de gamme sans aucun problème, mais si votre map crash sur des consoles moins puissantes, vos métriques globales vont chuter.
Le coupable le plus courant d'une chute soudaine du trafic Discovery est une saccade serveur silencieuse causée par un code Verse non optimisé ou une utilisation excessive de la mémoire. Si votre map utilise le Spatial Thermometer, assurez-vous que vos cellules ne dépassent pas la limite de 100 000 en mémoire. Lorsqu'une cellule est surchargée, elle provoque des chutes de framerate massives pour les joueurs mobiles, entraînant des déconnexions immédiates.
De plus, vérifiez vos network drivers. Si vos joueurs freeze mais ne se déconnectent pas, vous faites peut-être face à un problème de network timeout qui ruine la session sans être enregistré comme un crash formel. Lisez notre analyse sur Uefn Session Launch Timeout Nightmares Diagnosing Unreal Engine Network Drivers pour débugger ce comportement réseau spécifique.
Étape 2 : Créer un pipeline d'analytics Verse pour isoler le churn
Si votre serveur est stable et la mémoire optimisée, le problème vient de votre game design. Les joueurs partent, et vous devez savoir exactement où et pourquoi ils quittent. Se fier à la métrique générique « Average Playtime » dans le Creator Portal ne suffit pas. Vous avez besoin de données granulaires.
En exploitant l'analytics_device via Verse, vous pouvez suivre des étapes spécifiques franchies par les joueurs. Si 1 000 joueurs spawnent, mais que seulement 200 déclenchent l'événement « Tutorial Completed », vous savez exactement où se situe votre goulot d'étranglement.
Voici une implémentation Verse robuste qui suit l'onboarding des joueurs et implémente un failsafe pour éviter le churn dû aux joueurs AFK.
Verse Code: Custom Analytics and Anti-Churn Failsafe
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")
Comment ce code sauve votre Discovery Push
Ce script fait deux choses essentielles. Premièrement, il envoie une télémétrie d'événements personnalisés à votre Creator Portal. Vous pouvez désormais comparer le ratio d'événements player_spawned par rapport aux événements tutorial_cleared. S'il y a une chute massive, votre salle de spawn est trop confuse ou votre UI est cassée.
Deuxièmement, il inclut un StartFailsafeTimer. L'un des plus grands tueurs d'Average Playtime est le fait que les joueurs restent bloqués dans la salle de spawn, s'énervent et retournent au lobby. En les téléportant de force dans l'arène principale après 30 secondes, vous les engagez immédiatement dans le core loop, réduisant ainsi drastiquement le taux de rebond à 60 secondes.
Gardez à l'esprit qu'Epic impose des limites strictes sur les chaînes de caractères que vous passez au dispositif d'analytics. Si vos événements n'apparaissent pas dans le portail, votre chaîne est peut-être trop longue. Consultez notre guide sur Cracking The 32 Character Uefn Analytics Device Event Name Limit Verse Tutorial pour les règles de formatage.
Étape 3 : Architecturer une progression Cross-Session pour une meilleure rétention
Faire passer les joueurs au-delà des 30 premières secondes résout votre bounce rate, mais pour maintenir un Discovery push pendant plus de 10 jours, vous devez conquérir la rétention à J+1 et J+7. Si les joueurs n'ont aucune raison de revenir demain, votre map sortira inévitablement de l'algorithme.
Pour obtenir une rétention élevée, vous avez besoin d'une progression persistante. Bien que l'UEFN fournisse des dispositifs de sauvegarde intégrés, ils sont très cloisonnés. Ils ne fonctionnent que sur une seule map, et modifier vos structures de variables lors d'une mise à jour peut facilement corrompre les fichiers de sauvegarde des joueurs, entraînant un churn massif.
Pour passer à l'échelle, les créateurs UEFN modernes construisent des systèmes de progression externes. Suivre les statistiques des joueurs à travers un univers de plusieurs maps, gérer des leaderboards mondiaux en temps réel ou accorder des récompenses VIP cross-game nécessite une architecture backend externe.
Construire cela soi-même nécessite de mettre en place des load balancers, du database sharding, des connexions WebSocket et la gestion des certificats SSL — soit facilement 4 à 6 semaines d'ingénierie dédiée. Avec horizOn, ces services backend sont pré-configurés. Vous bénéficiez d'un accès instantané à des bases de données scalables et à une infrastructure multiplayer en temps réel, vous permettant de livrer les systèmes de progression de votre jeu au lieu de lutter avec l'infrastructure cloud.
Étape 4 : Survivre à la « pénalité de mise à jour »
Abordons le problème spécifique d'une map qui perd son Discovery push immédiatement après une mise à jour. Comme mentionné précédemment, pousser une nouvelle version force l'algorithme à recalibrer votre map.
Si vous poussez une mise à jour pendant les heures de pic d'utilisateurs simultanés (CCU) de votre map, vous vous sabotez activement. Lorsque les serveurs redémarrent pour appliquer la nouvelle version, les joueurs actifs sont expulsés. Cela est enregistré comme un pic massif de terminaisons de sessions. L'algorithme voit des milliers de joueurs partir simultanément, suppose que votre map est cassée et retire instantanément votre placement Discovery.
Pour éviter la pénalité de mise à jour, vous devez traiter votre map UEFN comme un service live-ops :
- Ne mettez jamais à jour pendant les heures de pointe. Poussez toujours les mises à jour pendant la fenêtre de trafic le plus bas (généralement de 3h00 à 5h00 EST).
- Regroupez vos mises à jour. Ne poussez pas de correctifs quotidiens, sauf s'il s'agit d'un exploit majeur. Regroupez vos modifications dans des « Saisons » hebdomadaires ou mensuelles. Chaque mise à jour est un risque ; minimisez le nombre de fois où vous forcez l'algorithme à se recalibrer.
- Utilisez des versions privées pour la QA. N'utilisez jamais la branche de version publique pour tester si un script Verse fonctionne. Générez un code privé, invitez un groupe de 10-15 testeurs et vérifiez que le taux de crash reste à 0 % avant de promouvoir le build en public.
5 bonnes pratiques pour déclencher un Discovery Push
Si vous êtes bloqué sans trafic depuis plus de 10 jours, vous devez forcer activement l'algorithme à vous remarquer à nouveau. Appliquez ces cinq meilleures pratiques éprouvées lors de votre prochaine mise à jour :
- Optimisez le Time-to-First-Action (TTFA) : Supprimez vos cinématiques d'intro. Les joueurs devraient pouvoir effectuer une action significative dans les 5 secondes suivant le chargement. Si votre TTFA est supérieur à 15 secondes, votre bounce rate tuera vos chances de Discovery.
- A/B Testez les miniatures avec du trafic externe : L'algorithme d'Epic accorde un poids important au Click-Through Rate (CTR). Avant de compter sur le Discovery organique, générez du trafic depuis TikTok ou YouTube Shorts. Surveillez le taux de conversion. Si le trafic externe ne clique pas sur la miniature, le trafic organique d'Epic ne le fera pas non plus.
- Implémentez des spawners de secours : Ne comptez jamais sur un seul spawn pad. Placez des spawn pads secondaires et tertiaires dans des endroits cachés, et utilisez Verse pour alterner entre eux si le pad principal détecte une obstruction.
- Minimisez l'overhead de concurrence Verse : Avoir 50 blocs
spawn{}différents exécutant des boucles infinies causera des saccades serveur. Regroupez vos boucles concurrentes dans un seul dispositif manager qui met à jour tous les systèmes simultanément sur un tick rate contrôlé. - Surveillez le seuil des 8 minutes : Consultez quotidiennement votre Creator Portal. La « ligne de survie » non officielle pour l'algorithme Discovery est un temps de jeu moyen de 8 minutes. Si votre map descend en dessous de cette métrique, vous devez immédiatement pousser une mise à jour de contenu ajoutant des objectifs de milieu de partie pour prolonger artificiellement la durée de la session.
Arrêtez de deviner, commencez à mesurer
Le fortnite creative no discovery push n'est pas une malédiction ; c'est un manque d'optimisation. L'algorithme exige de la stabilité, un engagement immédiat et une rétention à long terme. En implémentant des analytics Verse stricts, en résolvant les timeouts serveurs silencieux et en gérant soigneusement la cadence de vos mises à jour, vous pouvez reprendre le contrôle de la visibilité de votre map.
Arrêtez de traiter vos îles UEFN comme des maps statiques et commencez à les traiter comme des produits live-service. Suivez vos données, optimisez votre onboarding et construisez des systèmes de progression qui incitent les joueurs à revenir jour après jour.
Prêt à passer à l'échelle votre backend multiplayer et à construire des systèmes de progression cross-map ? Essayez horizOn gratuitement ou consultez la doc API pour voir à quel point la gestion externe de l'état du jeu peut être simple.
Source : NO DISCOVERY PUSH FOR MORE THAN 10 DAYS WORKING DAILY