Dzięki doskonałym odpowiedziom Seana i Blue na ograniczenia fizycznych platform i decyzje pro-con, zamierzam rozszerzyć komentarz na inne podejście:
Dlaczego powinieneś prawdopodobnie całkowicie przeładować poziom
Dzięki temu Twoje wywołanie loadLevel () działa idealnie, tak! Przesyłaj strumieniowo informacje o plikach poziomu i krok po kroku buduj świat na jego podstawie, tworząc obiekty oraz ładując tekstury i dźwięki w miarę upływu czasu. Następnie, kiedy wszystko jest zrobione - lub zrobione „wystarczająco”, aby rozpocząć grę, wywołujesz startPlay (), a świat zostaje ujawniony, a twoja muzyka zaczyna grać.
Teraz, kiedy skończysz z poziomem lub uciekniesz do menu lub opuścisz grę, wywołujesz unloadLevel (), aby zwolnić wszystkie zasoby i pamięć, które trzymałeś, aby umożliwić płynne działanie.
Co się teraz stanie, gdy chcesz dodać funkcję „Uruchom ponownie poziom”? Dobrze...
unloadLevel(currentLevel);
loadLevel(currentLevel);
startPlay();
I gotowe! Żadnego nowego kodu, tylko kilka prostych wywołań funkcji, a już to wszystko napisałeś i debugowałeś, więc teraz twoja nowa błyszcząca funkcja restartu została skreślona z listy i prawdopodobnie nigdy więcej się nie pojawi - bezkrwisty, nie rdzewiejący kod jest najlepszym rodzajem! Przenieś kod do funkcji restartCurrentLevel () i możesz go złożyć i nigdy więcej na niego nie patrzeć - być może po upewnieniu się, że jest poziom do ponownego uruchomienia, oczywiście :)
Ale potem zastanawiasz się, czy to nie marnotrawstwo, i tak rozładowujesz rzeczy, które właśnie zamierzasz ponownie załadować. Cóż, jeśli twoje poziomy i zasoby są małe, to najbardziej musisz zyskać kilka wolnych sekund ładowania za każdym razem, gdy „Restart” jest wywoływany nawet na wolnych systemach (i może starszych smartfonach), więc kogo to obchodzi? „Przedwczesna optymalizacja” masz lepsze rzeczy do roboty z czasem.
Ach, ale teraz Twoje poziomy rosną, a tekstury stają się bardziej szczegółowe, a ścieżka dźwiękowa została zgrana do 512 kb / s z osobnymi kanałami dla każdej warstwy głosu i muzyki (wydawało się to wtedy dobrym pomysłem, choć nie pamiętasz dlaczego. ..) i coś o „zależnym od stanu śledzeniu wiązki wokselowej wielowymiarowych macierzy transformacji Fouriera”, które według ciebie jest całkowicie wymyślone, a nie rzeczywiste, a ładowanie poziomów zajmuje teraz trochę czasu i zaczyna cię denerwować. Testowałeś nawet z prawdziwymi ludźmi, a oni naprawdę nie lubią czasu oczekiwania, ponieważ jest gorszy niż podobne gry (nie spodziewasz się, że stolica MMORPG ze 100 graczami załaduje się w ciągu <2 sekund, prawda?), i to jest problem.
Jak więc zoptymalizować? Cóż, jeśli ponowne ładowanie poziomu stanowi problem, to czy ładowanie poziomu nie stanowi problemu? Jeśli uważasz, że to tylko przeładowywanie, dlaczego, u licha, ludzie przeładowują twój poziom o wiele częściej niż po prostu ładują go na pierwszym miejscu? Brzmi jak problem z grą, a nie problem inżynierii kodu. Kto uważa, że fajnie jest przeładowywać poziom w kółko i po prostu żałuje, że nie był szybszy niż całkowicie unikalny ?
Najpierw napraw prawdziwy problem!
Ale powiedzmy, że twoja gra jest zaprojektowana tak, że powinieneś co najmniej raz uruchamiać się ponownie, a czas ładowania jest wystarczająco długi, aby można było zrobić to raz i całkowicie nieuniknione, ale nie musisz tego robić ponownie. Co to za gra? Wydaje się to trochę dziwnym problemem ... może gra portalowa o wysokiej rozdzielczości, w której zakłada się, że wielokrotnie będziesz psuć puzzle?
Przede wszystkim musisz zdać sobie sprawę, że nie będzie to trywialne. Będziesz musiał napisać zupełnie nowy, nieprzetestowany kod, który jest „zależny od stanu”, więc możesz nawet nie wiedzieć, co jest lub nie będzie ponownie używane między poziomami. Czy na twoim poziomie są przypadkowe elementy, spawny, zmienne tekstury (czy twoje szkielety tylko czasami noszą zbroje?) Lub inne zmieniające się elementy? Czy istnieją rzeczy, które różnią się w zależności od gracza, takie jak strój lub niestandardowy model lub kolory / drzwi / pułapki?
Będziesz robić porównania i wiele z nich. Będziesz zapętlał elementy poziomu, porównując to, co będzie potrzebne z tym, co jest teraz załadowane (co robisz z rzeczami, które zostały załadowane na ostatni poziom, ale nie na ten jeden - zwolnij je lub poczekaj, aby zapobiec przyszłości obciążenie?). Jeśli jest to naprawdę ważna sprawa dla Twojej gry, prawdopodobnie będziesz chciał zmienić kod ładowania / rozładowania, aby sprawdzić, czy coś jest już załadowane przed załadowaniem (czyniąc kod uniwersalnym, ale potencjalnie wprowadzając nowe błędy do wcześniej działających funkcji i funkcji które ostrożnie uwalniają zasoby, które nie będą używane w najbliższej przyszłości). Westchnienie.
Bez względu na to, co robisz, nawet jeśli gra jest prosta, dostaniesz się do niejasnych błędów opartych na poziomie / stanie gracza, gdy poziom został zrestartowany i nie zdarzyło Ci się go załadować za pierwszym razem. Możesz więc pisać aktualizacje gier z tekstem takim jak:
„Upuszczenie hełmu na bombę na płytkę, na której wybuchł pocisk znajdujący się w odległości 200 pikseli od wody, nie spowoduje już uszkodzenia danych gry ani awarii gry”.
Prawdziwy powód Większość gier nie przejmuje się
Czy zauważyłeś kiedyś, że większość ludzi po prostu maluje lub płytami gipsowo-kartonowymi na istniejących ścianach zamiast rozbierać się na warstwę podstawową lub kłaść dywan na podłodze z twardego drewna zamiast podciągać je?
Prostym faktem jest to, że to wszystko więcej pracy za minimalną nagrodę. Malowanie na istniejących ścianach działa przez większość czasu dobrze , a wartość zrywania podłóg z drewna twardego jest często minimalna lub nie istnieje.
To samo dotyczy oprogramowania, od gier po multimedialne prezentacje Power Point - jeśli tylko golisz się kilka sekund poza ekranem wczytywania, ludzie spędzają 1% swojego czasu na oglądaniu, to lepiej bądź niewiarygodnie trywialny, albo dostajesz bardzo niski zwrot z zainwestowanego czasu.
A więc większość gier nie przeszkadza i mam problem z myśleniem o wielu grach, w których ładowanie ekranów sprawiło, że gra była dobra, mniej warta, poza kilkoma skrajnymi przykładami; ekstremalne przykłady pokazują, że optymalizacja pod kątem szybszego ładowania poziomów ma sens, a jest to niewielki ułamek gier, który trafia do publicznej wiadomości, a prawdopodobnie nawet mniejsze ułamki gier, których nikt nigdy nie widzi, ponieważ nigdy nie zostaną wydane.