Ekran startowy nie potrzebuje całej gry w pamięci
Podziel zasoby według momentu użycia. Menu wymaga innych plików niż ostatni poziom, a pierwszy ruch gracza zwykle nie potrzebuje wszystkich dekoracji i utworów muzycznych. Przygotuj minimalny zestaw umożliwiający rozpoczęcie oraz kolejne pakiety scen. Nie chodzi o ukrycie długiego ładowania za przyciskiem, lecz o świadome ograniczenie pracy przed pierwszym użytecznym działaniem. Im czytelniejsza granica pakietu, tym łatwiej diagnozować brak pojedynczego zasobu.
W przykładowej grze logicznej pierwsza plansza może korzystać ze wspólnego zestawu figur, podczas gdy późniejsze tła da się pobrać po rozpoczęciu. Ustal, które zasoby są krytyczne, a które opcjonalne. Brak kształtu potrzebnego do rozpoznania reguły powinien zatrzymać start z jasnym komunikatem. Brak ozdobnego tła może pozwalać na bezpieczny wariant zastępczy. Te decyzje muszą wynikać ze znaczenia informacji, nie tylko rozmiaru plików.
Manifest porządkuje zależności i wersje
Lista zasobów powinna wskazywać identyfikator, lokalizację, typ oraz przynależność do pakietu. Scena odwołuje się wtedy do stabilnych nazw wewnętrznych, a nie przypadkowych ścieżek rozsianych po kodzie. Przy aktualizacji wersjonuj pliki tak, aby nowy skrypt nie otrzymał starej grafiki o innym układzie klatek. Cache przyspiesza start tylko wtedy, gdy zachowuje spójny komplet. Mieszanka wersji może wyglądać jak błąd animacji, choć problem leży w dystrybucji zasobów.
Sprawdź zależności: atlas potrzebuje obrazu i opisu klatek, font może wymagać tekstury oraz metryk, a scena konfiguracji poziomu. Gotowość jednego pliku nie oznacza gotowości całej funkcji. Waliduj manifest przed wydaniem, wykrywając brakujące identyfikatory i duplikaty. W raporcie budowania zapisuj rozmiary pakietów. Pozwala to zauważyć, że drobna zmiana sceny przypadkowo dołączyła ogromny materiał używany tylko w innym trybie gry.
Rozmiar transferu i koszt pamięci to różne liczby
Skompresowany obraz może być mały na dysku, a po przygotowaniu do rysowania zajmować znacznie więcej pamięci. Dodatkowo dochodzi dekodowanie i przesłanie do układu graficznego. Dlatego nie oceniaj kosztu wyłącznie po wadze ZIP-a. Sprawdź wymiary tekstur i liczbę równocześnie używanych zasobów. Zbyt duży atlas może zmniejszyć liczbę plików, ale jednocześnie utrudnić pracę słabszym urządzeniom i wymusić pobieranie grafik niepotrzebnych w danej scenie.
Łącz grafiki według realnego wspólnego użycia. Elementy menu i końcowego bossa nie muszą dzielić jednej tekstury. Przewidź marginesy między klatkami, aby skalowanie nie pobierało pikseli sąsiedniego obrazu. Dla różnych gęstości ekranu dobierz rozsądne warianty jakości, zamiast zawsze wysyłać największy. Oceniaj czytelność w faktycznym rozmiarze gry: szczegół niewidoczny na telefonie nie uzasadnia dużego wzrostu zużycia pamięci.
Pasek postępu powinien opisywać rzeczywistą pracę
Postęp liczony liczbą plików może gwałtownie zwolnić, gdy ostatni zasób jest największy. Postęp transferu nie obejmuje z kolei całego dekodowania i inicjalizacji. Wyjaśnij etapy: pobieranie, przygotowanie i uruchamianie sceny. Nie pokazuj dokładnego procentu, jeżeli nie znasz całego zakresu. Uczciwy komunikat o aktualnym etapie jest lepszy niż „100%”, po którym użytkownik jeszcze długo ogląda nieruchomy ekran.
Loader powinien reagować na błąd konkretnego pliku, timeout i utratę połączenia. Pozwól ponowić potrzebne zadanie bez odtwarzania poprawnie przygotowanej części, jeśli jest to bezpieczne. Rozróżnij błąd sieci od niezgodnego formatu. Wielokrotne pobieranie uszkodzonego atlasu niczego nie naprawi. Zapisz identyfikator zasobu i wersję wydania w diagnostyce, a graczowi podaj zrozumiałą informację oraz możliwy następny krok.
Zasoby mają także moment zakończenia życia
Po opuszczeniu sceny część tekstur, dźwięków i obiektów można zwolnić, lecz inne są wspólne z następnym poziomem. Ustal właściciela każdego pakietu i regułę współdzielenia. Usunięcie zasobu nadal używanego przez menu może spowodować błąd dopiero po powrocie, a pozostawienie wszystkiego na zawsze doprowadzi do narastającego zużycia pamięci. Cykl życia powinien być zaprojektowany równie starannie jak pierwsze ładowanie.
Przy pobieraniu w tle uwzględnij zmianę decyzji gracza. Osoba może wrócić do menu, zanim zakończy się przygotowanie kolejnej planszy. Wynik nie powinien wtedy samoczynnie przełączyć aktywnej sceny. Powiąż zadanie z właściwą sesją i sprawdź, czy nadal jest potrzebne. Unikaj agresywnego pobierania całej reszty gry na połączeniu mobilnym tylko po to, by wykorzystać chwilę bezczynności. Oszczędność czasu musi być zestawiona z kosztem transferu i pamięci.
Sprawdź pierwszy start i dziesiąty restart
Test z rozgrzanym cache nie pokazuje doświadczenia nowego gracza. Uruchom grę z pustą pamięcią przeglądarki, wolną siecią i błędem pojedynczego zasobu. Następnie przejdź kilka scen, wróć do menu i powtórz cykl. Obserwuj czas do pierwszego sterowania, wielkość transferu oraz zużycie pamięci. Brak narastania błędów po wielu restartach jest równie ważny jak szybki pierwszy ekran. To dwa różne kryteria jakości.
Dodaj do procesu wydania kontrolę manifestu i budżet pakietu startowego. Przekroczenie limitu powinno wymagać świadomej decyzji, nie ginąć wśród innych plików. Zachowuj pomiary wraz z wersją gry i urządzeniem testowym. Wtedy wiadomo, czy nowa animacja rzeczywiście pogorszyła start, czy zmieniły się warunki sieci. Dobre ładowanie prowadzi do rozgrywki przewidywalnymi etapami, a nie tylko efektownie animuje pasek podczas niekontrolowanej pracy w tle.