Dlaczego Twoja mapa UEFN umarła: Jak naprawić Fortnite Creative No Discovery Push

Każdy deweloper UEFN zna to uczucie, gdy po kliknięciu „Publikuj” na mapie, której budowa zajęła 300 godzin, liczba aktywnych graczy przez cały tydzień wynosi dokładnie zero. Co gorsza, istnieje osławiona „klątwa aktualizacji” – wypuszczasz drobny patch, aby naprawić błąd spawnu na mapie przyciągającej 5000 graczy jednocześnie, a z dnia na dzień algorytm obcina Twój ruch do zera. Nie jesteś sam, a Twoje konto nie jest zepsute.

Zjawisko znane jako fortnite creative no discovery push rzadko jest błędem. Jest to ścisła, matematyczna konsekwencja tego, jak algorytm Discovery od Epic Games ocenia telemetrię sesji. Gdy Twoja mapa przestaje otrzymywać wyświetlenia (impressions), oznacza to, że Twoje wskaźniki wyzwoliły automatyczny shadowban, zaprojektowany w celu ochrony doświadczeń graczy.

W tej technicznej analizie przeprowadzimy inżynierię wsteczną, aby zrozumieć, dlaczego algorytm Discovery porzuca mapy. Omówimy, jak diagnozować ciche crashe serwera, jak pisać własne analityki w Verse, aby śledzić player churn, oraz jak projektować aktualizacje, aby przetrwały fazy kalibracji algorytmu.

Anatomia kalibracji algorytmu Discovery

Aby zrozumieć, dlaczego Twoja mapa straciła ruch, musisz pojąć, jak karta Discovery ocenia nową zawartość. Algorytm Epica to czarna skrzynka, ale lata zbiorowej analizy telemetrii ujawniły wyraźną „fazę kalibracji”, która następuje za każdym razem, gdy publikujesz nowy kod wyspy lub wypuszczasz aktualizację.

Po opublikowaniu mapy Epic przypisuje jej wagę bazową i wysyła małą, kontrolowaną grupę testową graczy na Twoją wyspę. Algorytm agresywnie monitoruje telemetrię z tej grupy. Jeśli dane są słabe, kalibracja kończy się niepowodzeniem, a mapa zostaje natychmiast pogrzebana.

Co dokładnie algorytm uznaje za „słabą telemetrię”? Sprowadza się to do czterech krytycznych punktów zapalnych:

1. High Bounce Rate: Gracze opuszczają mapę w ciągu pierwszych 60 sekund.
2. Short Average Playtime: Całkowita długość sesji wynosi poniżej 10 minut.
3. Low Return Rate: Gracze nie dodają mapy do ulubionych ani nie wracają w sesjach Dnia 2 (D1) lub Dnia 7 (D7).
4. High Crash/Error Rate: Serwer dedykowany (Dedicated Server) zacina się lub klient crashuje (szczególnie na Nintendo Switch lub urządzeniach mobilnych).

Wypuszczając aktualizację dla istniejącej, odnoszącej sukcesy mapy, algorytm tymczasowo ogranicza Twoją pozycję w Discovery, aby przetestować stabilność nowego buildu. Jeśli Twoja aktualizacja przypadkowo wprowadzi memory leak lub błąd UI, który sprawi, że grupa testowa wyjdzie wcześniej, mapa nie przejdzie ponownej kalibracji. Ruch zamiera, a Ty zostajesz zdany wyłącznie na swoich obserwujących w mediach społecznościowych.

Krok 1: Diagnozowanie cichych crashy i przycięć serwera

Zanim zaczniesz przeprojektowywać gameplay loop swojej mapy, musisz wykluczyć awarie techniczne. Algorytm Discovery agresywnie odfiltrowuje mapy z wysokim network desync lub problemami z pamięcią. Możesz grać na high-endowym PC bez żadnych problemów, ale jeśli Twoja mapa crashuje na słabszych konsolach, Twoje globalne metryki polecą w dół.

Najczęstszym winowajcą nagłego spadku ruchu w Discovery jest ciche przycięcie serwera (server hitch) spowodowane nieoptymalnym kodem Verse lub nadmiernym zużyciem pamięci. Jeśli Twoja mapa korzysta ze Spatial Thermometer, upewnij się, że komórki nie przekraczają limitu 100 000 pamięci. Gdy komórka jest przeładowana, powoduje to ogromne spadki klatek u graczy mobilnych, co prowadzi do natychmiastowych rozłączeń.

Dodatkowo sprawdź network drivers. Jeśli gracze „zamarzają”, ale nie zostają rozłączeni, możesz mieć do czynienia z problemem network timeout, który rujnuje sesję, nie rejestrując się jako formalny crash. Przeczytaj naszą analizę Uefn Session Launch Timeout Nightmares Diagnosing Unreal Engine Network Drivers, aby debugować to specyficzne zachowanie sieci.

Krok 2: Budowa potoku analitycznego Verse w celu izolacji churnu

Jeśli serwer jest stabilny, a pamięć zoptymalizowana, problemem jest game design. Gracze odchodzą, a Ty musisz wiedzieć dokładnie gdzie i dlaczego rezygnują. Poleganie na ogólnym wskaźniku „Average Playtime” w Creator Portal to za mało. Potrzebujesz szczegółowych danych.

Dzięki wykorzystaniu analytics_device przez Verse, możesz śledzić konkretne kamienie milowe graczy. Jeśli zespawnuje się 1000 graczy, ale tylko 200 wywoła zdarzenie „Tutorial Completed”, wiesz dokładnie, gdzie znajduje się wąskie gardło.

Poniżej znajduje się solidna implementacja w Verse, która śledzi onboarding graczy i implementuje failsafe zapobiegający churnowi 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")

Jak ten kod ratuje Twój Discovery Push

Ten skrypt robi dwie kluczowe rzeczy. Po pierwsze, przesyła niestandardową telemetrię zdarzeń do Twojego Creator Portal. Możesz teraz porównać stosunek zdarzeń player_spawned do tutorial_cleared. Jeśli następuje ogromny spadek, Twój pokój spawnu jest zbyt mylący lub UI jest zepsute.

Po drugie, zawiera StartFailsafeTimer. Jednym z największych zabójców Average Playtime są gracze utykający w pokoju spawnu, którzy frustrują się i wracają do lobby. Przez wymuszoną teleportację do głównej areny po 30 sekundach, natychmiast angażujesz ich w core loop, drastycznie redukując 60-sekundowy bounce rate.

Pamiętaj, że Epic narzuca surowe limity na ciągi znaków przekazywane do urządzenia analitycznego. Jeśli Twoje zdarzenia nie pojawiają się w portalu, Twój string może być za długi. Sprawdź nasz przewodnik Cracking The 32 Character Uefn Analytics Device Event Name Limit Verse Tutorial dotyczący zasad formatowania.

Krok 3: Architektura progresji między sesjami dla wyższej retencji

Przeprowadzenie graczy przez pierwsze 30 sekund rozwiązuje problem bounce rate, ale aby utrzymać Discovery push przez ponad 10 dni, musisz opanować retencję Dnia 1 i Dnia 7. Jeśli gracze nie mają powodu, by wrócić jutro, Twoja mapa nieuchronnie wypadnie z algorytmu.

Aby osiągnąć wysoką retencję, potrzebujesz persistent progression. Chociaż UEFN zapewnia wbudowane urządzenia do zapisu, są one mocno odizolowane. Działają tylko na jednej mapie, a modyfikacja struktur zmiennych w aktualizacji może łatwo uszkodzić pliki zapisu graczy, prowadząc do masowego churnu.

Aby naprawdę się skalować, nowocześni twórcy UEFN budują zewnętrzne systemy progresji. Śledzenie statystyk graczy w uniwersum wielu map, prowadzenie globalnych leaderboards w czasie rzeczywistym czy przyznawanie nagród VIP cross-game wymaga zewnętrznej architektury backendowej.

Samodzielne zbudowanie tego wymaga skonfigurowania load balancers, database sharding, połączeń WebSocket i zarządzania certyfikatami SSL – to łatwo 4-6 tygodni dedykowanej pracy inżynierskiej. Dzięki horizOn te usługi backendowe są wstępnie skonfigurowane. Otrzymujesz natychmiastowy dostęp do skalowalnych baz danych i infrastruktury multiplayer w czasie rzeczywistym, co pozwala Ci dostarczać systemy progresji w grze zamiast walczyć z infrastrukturą chmurową.

Krok 4: Przetrwanie „kary za aktualizację”

Zajmijmy się konkretnym problemem mapy tracącej Discovery push natychmiast po aktualizacji. Jak wspomniano wcześniej, wypuszczenie nowej wersji zmusza algorytm do ponownej kalibracji mapy.

Jeśli wypuścisz aktualizację w godzinach szczytu CCU (concurrent users), aktywnie sabotujesz własne działania. Gdy serwery restartują się, aby zastosować nową wersję, aktywni gracze zostają wyrzuceni. Jest to rejestrowane jako ogromny skok w przerwanych sesjach. Algorytm widzi tysiące graczy wychodzących jednocześnie, zakłada, że Twoja mapa jest zepsuta i natychmiast wycofuje Twoją pozycję w Discovery.

Aby uniknąć kary za aktualizację, musisz traktować swoją mapę UEFN jak usługę live-ops:

• Nigdy nie aktualizuj w godzinach szczytu. Zawsze wypuszczaj aktualizacje w oknie najniższego ruchu (zwykle 3:00 – 5:00 rano EST).
• Grupuj aktualizacje. Nie wypuszczaj codziennych poprawek, chyba że jest to błąd krytyczny (game-breaking exploit). Grupuj zmiany w cotygodniowe lub comiesięczne „Sezony”. Każda aktualizacja to ryzyko; zminimalizuj liczbę ponownych kalibracji algorytmu.
• Używaj Private Versions do QA. Nigdy nie używaj publicznej gałęzi wydawniczej do testowania, czy skrypt Verse działa. Wygeneruj prywatny kod, zaproś grupę 10-15 testerów i zweryfikuj, czy crash rate wynosi 0%, zanim upublicznisz build.

5 najlepszych praktyk, aby wywołać Discovery Push

Jeśli utknąłeś bez ruchu przez ponad 10 dni, musisz aktywnie zmusić algorytm, aby Cię zauważył. Zastosuj te pięć sprawdzonych w boju praktyk przy następnej aktualizacji:

1. Optymalizuj Time-to-First-Action (TTFA): Wytnij filmiki wprowadzające. Gracze powinni móc wykonać znaczącą akcję w ciągu 5 sekund od załadowania. Jeśli TTFA przekracza 15 sekund, bounce rate zabije Twoje szanse na Discovery.
2. Testy A/B miniaturek z ruchem zewnętrznym: Algorytm Epica przywiązuje dużą wagę do Click-Through Rate (CTR). Zanim zaczniesz polegać na organicznym Discovery, skieruj ruch z TikToka lub YouTube Shorts. Monitoruj współczynnik konwersji. Jeśli ruch zewnętrzny nie klika w miniaturkę, organiczny ruch od Epica też nie będzie.
3. Zaimplementuj zapasowe spawner-y: Nigdy nie polegaj na jednym spawn padzie. Umieść drugorzędne i trzeciorzędne pady w ukrytych miejscach i użyj Verse, aby przełączać się między nimi, jeśli główny pad wykryje przeszkodę.
4. Minimalizuj narzut współbieżności Verse: Posiadanie 50 różnych bloków spawn{} wykonujących nieskończone pętle spowoduje przycięcia serwera. Skonsoliduj pętle w jednym urządzeniu typu manager, które aktualizuje wszystkie systemy jednocześnie przy kontrolowanym tick rate.
5. Monitoruj próg 8 minut: Codziennie sprawdzaj Creator Portal. Nieoficjalną „linią przetrwania” dla algorytmu Discovery jest średni czas gry wynoszący 8 minut. Jeśli Twoja mapa spadnie poniżej tego wskaźnika, musisz natychmiast wypuścić aktualizację zawartości dodającą cele w środku gry, aby sztucznie wydłużyć sesję.

Przestań zgadywać, zacznij mierzyć

Zjawisko fortnite creative no discovery push to nie klątwa; to brak optymalizacji. Algorytm wymaga stabilności, natychmiastowego zaangażowania i długoterminowej retencji. Implementując ścisłą analitykę Verse, rozwiązując ciche timeouty serwera i ostrożnie zarządzając kadencją aktualizacji, możesz odzyskać kontrolę nad widocznością swojej mapy.

Przestań traktować swoje wyspy UEFN jak statyczne mapy, a zacznij traktować je jak produkty live-service. Śledź dane, optymalizuj onboarding i buduj systemy progresji, które sprawią, że gracze będą wracać dzień po dniu.

Gotowy na skalowanie backendu multiplayer i budowę systemów progresji między mapami? Wypróbuj horizOn za darmo lub sprawdź dokumentację API, aby zobaczyć, jak łatwe może być zewnętrzne zarządzanie stanem gry.

---

Źródło: NO DISCOVERY PUSH FOR MORE THAN 10 DAYS WORKING DAILY