Czym jest port gry na przeglądarkę?
Większość silników potrafi wyeksportować build do przeglądarki. Unity ma platformę Web, Godot ma eksport webowy, a gry z Constructa od początku działają w HTML5. Przy porcie zespół idzie dalej. Zmienia rozmiar pobierania, sterowanie, dźwięk, zapisy, reklamy i pierwszą sesję, tak żeby gra dobrze działała w przeglądarce.
Jeśli chcesz zobaczyć, jak radziły sobie z tym inne zespoły, zajrzyj do poradnika o przenoszeniu gier mobilnych do przeglądarki. Poniżej opisujemy praktyczną stronę tej samej pracy.
1. Zrób audyt projektu
Zacznij od kodu i aktualnego buildu. Zanim ktokolwiek napisze nową linijkę, spisz wszystko, od czego zależy gra. Z tej listy dowiesz się, jak duży będzie port.
- Silnik i wersja. Zapisz dokładną wersję silnika oraz render pipeline albo renderer, z którego korzysta gra.
- Wtyczki i kod natywny. Oznacz każdą wtyczkę, bibliotekę natywną i SDK. Kod pisany pod iOS albo Androida nie ma wersji webowej i trzeba go czymś zastąpić.
- Assety. Sprawdź łączny rozmiar tekstur, dźwięku, wideo i fontów. Najczęściej kłopot sprawiają duże atlasy i długie utwory muzyczne.
- Backend. Wypisz logowanie, zakupy, rankingi, zdalną konfigurację i analitykę. Sprawdź, jak każdy z tych elementów łączy się z serwerem.
- Projekt gry. Sprawdź orientację ekranu, długość sesji i to, co nowy gracz widzi w pierwszej minucie.
Po audycie wiesz, co zostaje, co trzeba wymienić i z czego można zrezygnować w wersji przeglądarkowej.
2. Wybierz silnik dla wersji webowej
Teraz trzeba zdecydować, czy gra zostaje w obecnym silniku, czy przechodzi do innego. Odpowiedź zależy od silnika i od wymagań platformy, na którą celujesz.
- Unity. Platforma Web w Unity wymaga przeglądarki z WebGL 2 i WebAssembly. Unity podaje jako obsługiwane przeglądarki mobilne Safari od wersji 15 na iOS i Chrome od wersji 58 na Androidzie. Największe ryzyka to rozmiar pierwszego pobrania, zużycie pamięci na telefonach i natywne wtyczki.
- Godot. Eksport webowy w Godocie 4 wymaga WebGL 2 i renderera Compatibility. Według dokumentacji Godota projektów w C# z Godota 4 nie da się na razie wyeksportować do przeglądarki. Od wersji 4.3 eksport webowy jest domyślnie jednowątkowy. Twórcy Godota piszą, że taki build lepiej sprawdza się u wydawców gier webowych, takich jak Poki i CrazyGames.
- Construct. Gry z Constructa już działają w HTML5. Praca dotyczy głównie sterowania, wydajności na słabszych telefonach i SDK portalu.
- Inne silniki i kod natywny. Gry napisane w Swifcie, Kotlinie, Javie, Objective-C albo we własnym silniku nie mają eksportu do przeglądarki. Zespół zachowuje projekt, grafikę i zawartość, a runtime buduje od nowa w silniku z dobrym wsparciem webu, na przykład w Defoldzie.
Jeśli portal ma ostre limity rozmiaru, warto rozważyć przeniesienie gry do Defolda. Szczegóły opisujemy w poradnikach o portowaniu gier na przeglądarkę w Defoldzie i o portowaniu gry z Unity do Defolda.
3. Renderowanie i WebGL
W przeglądarce grafika gry jest rysowana przez WebGL. Większość mobilnych gier 2D i lekkich gier 3D dobrze się w tym odnajduje, ale część efektów trzeba zmienić.
- Zastąp shadery, które korzystają z funkcji niedostępnych w WebGL. Testuj je w Safari i w Chrome.
- Ogranicz liczbę draw calli dzięki atlasom i batchowaniu. Telefon w przeglądarce ma mniejszy zapas mocy niż ten sam telefon w natywnej aplikacji.
- Wybierz formaty tekstur, które obsługują docelowe przeglądarki, i zostaw nieskompresowaną wersję zapasową dla starszych urządzeń.
- Obsłuż utratę kontekstu WebGL, na przykład gdy gracz przełączy się na inną aplikację i wróci do gry.
4. Sterowanie: od dotyku do myszy i klawiatury
Gry mobilne projektuje się pod palec na ekranie. W przeglądarce ludzie grają w tę samą grę myszą, klawiaturą, touchpadem albo padem.
- Przypisz każdemu gestowi odpowiednik na komputerze. Przesunięcie palcem może zamienić się w strzałki, a długie przytrzymanie w prawy przycisk myszy albo przytrzymany klawisz.
- Pokazuj podpowiedzi pasujące do urządzenia. Gracz z klawiaturą nie powinien widzieć samouczka o stukaniu w ekran.
- Zablokuj przewijanie i powiększanie strony, gdy gracz dotyka obszaru gry.
- Pełny ekran i blokadę kursora włączaj tylko po kliknięciu albo naciśnięciu klawisza, bo są dostępne dopiero po akcji użytkownika.
- Zwalniaj przytrzymane klawisze i przyciski, gdy karta traci fokus, żeby sterowanie się nie zacinało.
5. Rozmiar assetów i ładowanie
Na portalu gracz może wyjść, zanim gra w ogóle się uruchomi. Pierwsze pobranie musi być małe, a resztę warto dociągać w trakcie gry.
- Ustal budżet rozmiaru pierwszego ładowania na samym początku. Poki zaleca pierwsze pobranie do 5 MB i łącznie do 8 MB. CrazyGames wymaga najwyżej 20 MB od gier pokazywanych na stronie głównej w wersji mobilnej.
- Kompresuj tekstury i dźwięk, usuń nieużywane assety, a poziomy albo skórki podziel na paczki pobierane później.
- Serwuj pliki z kompresją gzip albo Brotli i cachuj je z wersjonowanymi nazwami.
- Pokazuj prawdziwy postęp na ekranie ładowania i po załadowaniu od razu przechodź do gry.
Więcej technik znajdziesz w artykule o optymalizacji gier HTML5.
6. Dźwięk i zasady autoodtwarzania
W przeglądarkach dźwięk jest zablokowany, dopóki gracz nie wejdzie w interakcję ze stroną. MDN opisuje tę zasadę: audio może zagrać dopiero po kliknięciu, dotknięciu ekranu albo naciśnięciu klawisza. Muzyka, która w edytorze startuje sama, w przeglądarce będzie milczeć.
- Uruchamiaj system audio przy pierwszym kliknięciu albo dotknięciu, na przykład na przycisku Graj.
- Wstrzymuj muzykę, gdy karta jest ukryta, i wznawiaj ją po powrocie gracza.
- Wyciszaj grę na czas reklam i przywracaj głośność po ich zakończeniu.
- Używaj skompresowanych formatów obsługiwanych przez wszystkie docelowe przeglądarki i testuj na iPhonie z włączonym i wyłączonym trybem cichym.
7. Zapisy i pamięć przeglądarki
Na telefonie zapisy zostają na urządzeniu. W przeglądarce trafiają do pamięci strony albo portalu, a gracz może ją wyczyścić.
- Przenieś lokalne zapisy do pamięci przeglądarki, na przykład do localStorage albo IndexedDB, i pilnuj, żeby były małe.
- Testuj zapisy w iframe, bo w ten sposób większość portali osadza gry. Unity zaznacza w dokumentacji, że Safari nie obsługuje IndexedDB dla treści uruchomionych w iframe.
- Jeśli portal ma własny system zapisów, korzystaj z niego. Moduł data w SDK CrazyGames pozwala synchronizować postęp zalogowanych graczy między urządzeniami, z limitem 1 MB zapisanych danych.
- Zaplanuj migrację, jeśli gracze mają już postęp ze starszej wersji webowej.
8. SDK, reklamy i portale z grami webowymi
Mobilne SDK reklamowe i analityczne nie działają w przeglądarce. Każdy portal ma własne SDK do reklam, nagradzanych wideo, zapisów i zdarzeń w grze.
- Schowaj wszystkie wywołania platformy za jedną małą warstwą w kodzie gry. Wtedy przy nowym portalu piszesz nowy adapter, a kod rozgrywki zostaje bez zmian.
- Wysyłaj zdarzenia startu i końca rozgrywki tam, gdzie portal tego wymaga. Portale na ich podstawie wybierają momenty na reklamy.
- Zakupy w aplikacji zastąp opcjami portalu, reklamami z nagrodą albo prostszą ekonomią, zależnie od zasad platformy.
- Usuń wszystko, na co portal nie pozwala, na przykład linki do sklepów z aplikacjami albo zewnętrzne logowanie.
9. Testy wydajności na słabszych urządzeniach
Na laptopie gra może chodzić płynnie, a na tanim Androidzie gubić klatki. Testuj na urządzeniach, z których korzystają Twoi gracze, i zacznij wcześnie.
- Miej w zestawie testowym kilka starszych telefonów z Androidem i starszego iPhone'a. Testuj w Chrome i w Safari.
- Mierz czas do pierwszej interakcji, liczbę klatek w najcięższych scenach i zużycie pamięci w długiej sesji.
- Sprawdź, co się dzieje po przełączeniu karty, połączeniu telefonicznym albo zablokowaniu ekranu.
- Testuj też na wolnym łączu, poza biurowym Wi-Fi.
Na iOS karta przeglądarki dostaje mniej pamięci niż natywna aplikacja. Gdy gra zużyje za dużo, strona zostaje przeładowana w Safari, więc pamięć obserwuj równie uważnie jak liczbę klatek.
10. Publikacja na portalach z grami webowymi
Każdy portal sprawdza gry według własnych zasad technicznych i treściowych. Przeczytaj je przed końcem prac, bo część z nich wpływa na projekt gry.
- Przygotuj materiały dla portalu: miniatury, krótki opis, zrzuty ekranu albo wideo i listę sterowania.
- Sprawdź build pod kątem wymagań technicznych portalu, takich jak rozmiar, zdarzenia SDK i rozmieszczenie reklam.
- Utrzymuj jeden kod gry i przygotowuj osobny build dla każdego portalu przez warstwę platformy.
- Po premierze obserwuj statystyki portalu: ilu graczy odpada w trakcie ładowania, jak długie są sesje i jak działają reklamy. Aktualizuj grę małymi krokami.
Kto powinien zrobić port?
Port we własnym zespole sprawdza się, gdy Twoi ludzie znają buildy webowe i mają na to czas obok prac nad wersją mobilną. W innym przypadku zewnętrzny zespół, który robił już porty na przeglądarkę, szybciej zauważy ryzyka. W poradniku jak zlecić stworzenie gry opisujemy, jak przygotować brief i porównać oferty studiów.
Codeward to studio gier z Krakowa z wieloma projektami dla klientów na koncie. Przenosiliśmy mobilne gry z Unity do Defolda na przeglądarki, a w zespole mamy doświadczonych programistów Unity, którzy dobrze znają zaawansowany C#. Jeśli szukasz programistów Defold do własnego zespołu, zajrzyj na stronę programiści Defold do wynajęcia.