Dlaczego gry pozornie przeładowują cały poziom po ponownym uruchomieniu poziomu?

Czy dane są tak bardzo modyfikowane podczas gry?

Zakładam, że długa przerwa między ponownym uruchomieniem poziomu to przeładowanie całego poziomu. Wydaje mi się jednak, że dobrze zaimplementowany system powinien być w stanie „pingować” z powrotem na początek poziomu.

Jest bardziej zauważalny na konsolach, ale nie jest niezauważalny w grach na PC.

Cóż, teraz - jakie proste, ale interesujące pytanie.

Podczas przeładowywania poziomu należy wziąć pod uwagę tak wiele czynników, że odpowiedź może przebiegać na wiele sposobów.

Jeśli stan Twojego poziomu zawiera dużą listę zasobów, bardziej praktyczne może być rozpoczęcie od czystego konta podczas przeładowywania poziomu z powrotem do stanu zapisu / misji, ponieważ zachowuje on dokładny stan poziomu po przeładowaniu, ale nie zajmuje dużo przetwarzania. Jednak bardziej efektywne jest resetowanie samych zasobów, jeśli jest tylko kilka do wzięcia pod uwagę - upewniając się, że możesz szybko wznowić działanie na tych mniejszych poziomach. To drugie jest szczególnie ważne, gdy nie musisz niczego zachowywać na scenie lub nie wpływa to na twoje wybory w grze - jeśli nie potrzebujesz martwych ciał, które zostaną zachowane od pierwszego uruchomienia przez wioskę, nie będą trzeba ponownie załadować w drodze powrotnej przez ten poziom, oszczędzając w ten sposób czas procesora i oszczędzając czas dostępu do stanu misji.

Dobrym przykładem do pomyślenia jest strzelanka z perspektywy pierwszej osoby, która używała zniszczenia terenu / naklejek na pociski, które miały trwały stan podczas tej rozgrywki, ale nie pozostałyby, gdybyś ponownie uruchomił ten punkt kontrolny lub poziom .

Jeśli miałbyś przewinąć poziom zamiast go zniszczyć i załadować ponownie, musiałbyś prześledzić każdy zmieniany stan. Jeśli strzeliłeś dziurą w ścianę rakietą, z kawałków spadających ze ściany generowałbyś ślinę terenu, model ściany zmieniłby się, tworząc dziurę i miałbyś efekty cząsteczkowe, które zostały wygenerowane, aby wyglądać ładnie . Aby to wyczyścić, przewijając go z powrotem do stanu „restartowalnego”, musisz:

• Usuń wszelkie generowane dynamicznie giby dla tej ściany (ale nie usuwaj tych z załadowanego stanu)
• Usuń efekt cząsteczkowy pyłu z dziury po kuli
• Wymień / napraw ścianę, aby pozbyć się utworzonych otworów
• Zresetuj amunicję gracza
• Itp...

Przy tak wielu zasobach do śledzenia w celu przewinięcia poziomu często procesor jest po prostu mniej wymagający, aby po prostu zniszczyć cały poziom i ponownie załadować wszystkie zasoby w stanie domyślnym lub określonym dla misji. Konieczność zresetowania określonych obiektów wymaga przeszukania listy obiektów w scenie, a następnie uzyskania dostępu do ich właściwości, aby je zresetować. Zamiast naprawiania dziury po kuli w ścianie przez sprzątanie, nie trzeba wykonywać żadnych czynności porządkowych, wystarczy usunąć cały poziom z pamięci i załadować go od nowa.

Oznacza to, że przeładowanie poziomu jest zakończone z jednego obiektu stanu (zapisanego pliku gry lub skryptu misji) i nie wymaga dynamicznych obliczeń. W przypadku konsoli pogarsza to czas ładowania dysków. Pomaga także w grach komputerowych, ponieważ może uwzględniać komputery, które nie będą miały mocy obliczeniowej, aby czas ładowania był akceptowalny.

Tak więc w przypadku dużych poziomów zawartości - ładowanie jednego stanu zamiast jego obliczania i „przewijania”:

• Jest mniej intensywny procesor
• Jest bardziej wydajny na maszynach niższego poziomu
• Umożliwia użycie skryptu misji i pliku składowania w taki sam sposób (potencjalnie użyj tego samego systemu ładującego, aby załadować stan składowania lub stan punktu kontrolnego misji podczas ponownego uruchamiania poziomu)
• Oznacza, że ​​masz mniej pracy jako programista na zresetowanie poziomu - O wiele łatwiej jest zaprogramować pełne przeładowanie z danych sesji niż śledzenie i przewijanie do tyłu. Jest to prawdopodobnie najbardziej wpływowy punkt

Jednak jako kontr-przykład gra walki (świetny przykład z życia w Street Fighter 4) może nie wymagać ponownego załadowania tylu zasobów w celu ponownego uruchomienia poziomu. 2 graczy, stan środowiska dla poziomu i proste liczniki poziomu są w większości statyczne i nie są dynamiczne (zdrowie graczy zawsze odradza się na 100% w każdej rundzie, liczniki resetują się do 90 sekund, a poziom nie ma dziur po kulach [lub robi to!] ), a więc zresetowanie poziomu polega na przywróceniu wojownikom pełnego zdrowia i przywróceniu środowiska z powrotem do pierwotnej pozycji (np. obserwatorzy na niektórych poziomach).

Dlatego w grze walki podczas rewanżu (bez przechodzenia z rundy do rundy) musisz:

• Zresetuj zdrowie i energię do wartości maksymalnej lub domyślnej (zawsze taka sama na postać)
• Zresetuj Timer
• Resetuj początkowe pozycje postaci
• Zresetuj teren do stanu domyślnego (brak dziur po kulach do naprawy lub przeładowania!)

I to w zasadzie cała lista - co oznacza, że ​​szybszy reset stanu zamiast przeładowania pełnego poziomu jest bardziej wykonalny. Może to również być pokazane przez czas ładowania, gdy początkowo rozpoczynasz mecz. Załadowanie wszystkich modeli postaci i poziomów zajmuje dużo czasu, ale tylko kilka tyknięć procesora resetuje pozycje początkowe postaci między meczami z już załadowanym modelem.

Ważne jest, aby pamiętać, że jest to również bardziej pożądany wymóg w grach walki, ponieważ ich gracze zwykle chcą bardzo szybko wrócić do akcji, ponieważ mecze mogą zwykle trwać tylko minutę - podkreślając, że ta odpowiedź jest bardzo zależna od gry i gatunek. FPS żąda bardziej dynamicznych zasobów, podczas gdy Fighters wymagają szybkiej powtarzalnej akcji.

Mam nadzieję, że rzuciło to nieco światła na twoje pytanie.

Aby wyjaśnić istniejące odpowiedzi na Twoje pytanie dotyczące konsol: nie mają wystarczającej ilości pamięci, aby zapisać zarówno stan początkowy, jak i bieżący dla większych złożonych gier.

Gra może przechowywać poziom i stan początkowy osobno, aby można było odtworzyć tylko stan, i jest to bardzo prawdopodobne, co robi wiele gier. Jednak nawet przesyłanie strumieniowe będzie nieco wolniejsze niż w przypadku przechowywania w pamięci.

„Najlepsza” konsola obecnej generacji ma tylko 512 MB pamięci współdzielonej między danymi procesora i grafiką. To jest malutkie. Jednym z obecnych problemów związanych z tworzeniem konsol jest próba dopasowania do gier, które spełniają dzisiejszy poziom jakości przy tak małej ilości pamięci. Liczenie kilobajtów może stać się ważne, szczególnie blisko daty wysyłki. Przechowywanie kopii stanu początkowego poziomu to pewna ilość danych, którą można zrobić bez, co pozwala na użycie większej ilości pamięci na rzeczy, które sprawiają, że gra jest bardziej interesująca podczas gry, niż po prostu przyspieszenie przeładowania poziomu.

W idealnym przypadku gracz spędza więcej czasu na grze niż na śmierci i ponownym uruchomieniu, więc optymalizacja w celu uzyskania lepszych wrażeń podczas gry ma większy sens.

Rzeczy mogą się drastycznie zmienić w przypadku konsol nowej generacji i ich 8 GB pamięci. Lub mogą pozostać niezmienione dzięki modelom i materiałom o wyższej rozdzielczości oraz dużej liczbie aktywnych obiektów w grze. Czas pokaże. Biorąc pod uwagę, że gry na PC zazwyczaj są kierowane na maszyny z 2 GB pamięci RAM i 512 MB pamięci VRAM (choć wiele z nich skaluje się do znacznie większych wartości), 8 GB nowych konsol jest dość luksusowe, jeśli chodzi o minimalne poziomy bazowe. W najbliższych latach prawdopodobnie nastąpi przejście do gier wymagających 64-bitowego procesora / systemu operacyjnego i 4-8 GB pamięci RAM z 1-2 GB pamięci VRAM. Przechowywanie wielu stanów w pamięci w celu szybkiego wykonania migawki powinno być znacznie łatwiejsze.

Nie zgadzam się z większością odpowiedzi Blue, nie sądzę, aby istniał techniczny powód, by nie resetować poziomów - z pewnością nigdy go nie spotkałem. Ładowanie poziomu jest prawie zawsze wolniejsze niż resetowanie poziomu, w rzeczywistości trudno mi wyobrazić sobie okazję, w której nie byłoby. W większości przypadków gry mogą oferować efektywne natychmiastowe ładowanie poziomów, jeśli twórcy zdecydują się na to.

Prawdziwa odpowiedź jest, zgodnie z sugestią, łatwiejsza i szybsza. Powtarzające się ładowanie poziomów i tak jest wymagane przez grę, więc zmiana przeznaczenia na restart poziomu jest stosunkowo prosta. Resetowanie wymaga złożonych nowych ścieżek z dużym potencjałem nowych błędów i wycieków pamięci oraz wymaga przyzwoitej inwestycji czasu programisty. W niektórych przypadkach może również przesuwać limity pamięci. Ponieważ gry rzadko są opracowywane z nadmiarem czasu twórców, elementy takie jak resetowanie poziomów mają godną ubolewania tendencję do upuszczania po drodze, szczególnie jeśli architektura gry nie jest najlepiej zbudowana.

Chociaż przypuszczam, że można by wymyślić sytuację, w której „przewijanie” było konieczne do zresetowania, w rzeczywistości większość gier wymaga jedynie zapamiętania stanu oryginalnego, zapewnia skuteczne środki do całkowitego przywrócenia tego stanu dla zatrzymanych obiektów oraz sposób oznaczania obiektów do porzucić po zresetowaniu. Informacje o stanie gry również muszą być przechowywane i odtwarzalne. Tego rodzaju informacje są zwykle stosunkowo mało pamięci w porównaniu z wymaganiami dla całego poziomu, więc eliminuje to potrzebę powolnego, kosztownego ładowania danych z dysku (w tym dużych elementów, takich jak tekstury i modele) i zastępuje je szybkim, w -pamiętanie sceny.

Aby umożliwić grę na dużych poziomach lub płynną grę na poziomie, nawet przy ograniczonej pamięci (pamięć jest zawsze zbyt mała, pytanie brzmi, czy najpierw przekroczysz limit w pamięci RAM, czy na karcie graficznej), istnieje inna strategia:

Pamięć zawiera tylko część poziomu, której gracz potrzebuje obecnie lub będzie potrzebował za kilka sekund. Modele, tekstury, próbki dźwięków ... które prawdopodobnie już nie są potrzebne są usuwane z pamięci.

Dungeon Siege przychodzi mi na myśl (programiści twierdzili kiedyś, że zarządzanie pamięcią wymagało większej mocy obliczeniowej niż rzeczywista rozgrywka), większość MMORPGS robi to, strzelcy z otwartym środowiskiem muszą to zrobić, ... W takich przypadkach początek poziom (lub nawet punkt odrodzenia 30 sekund temu) może już nie być (całkowicie) w pamięci.

Często odświeżanie jest najłatwiejszym, najtańszym i być może najszybszym sposobem.

Edycja: Oto artykuł o mechanizmach ładowania Dungeon Siege: The Continuous World of Dungeon Siege

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.

Ponieważ trudniej jest opracować odwrotne zachowanie polegające na przechowywaniu w pamięci statycznych danych gry (takich jak tekstury, informacje geologiczne, niezmienione moby) i przeładowywaniu tylko danych dynamicznych (takich jak pozycja gracza, statystyki gracza, status misji, ekwipunek) .

Ponieważ kosztuje to więcej pieniędzy i czasu, twórcy gier na ogół tego nie robią.