Czy wszystkie gry nie mogły uniknąć ładowania po uruchomieniu?

Podobnie jak gigantyczne gry z otwartym światem dynamicznie ładują ogromne mapy, czy nie możemy załadować osobnych map, menu i praktycznie dowolnego interfejsu lub ustawień 3D za pomocą tej samej metody ładowania dynamicznego? Bez zmiany środowiska, wygląda na to, że interfejsy i różne lokalizacje w grze mogą być ładowane dynamicznie w taki sam sposób, jak ładowane są ogromne otwarte mapy świata podczas ich przechodzenia.

Dlaczego tego nie zrobiono? Widzę tak wiele nowoczesnych gier, w których trzeba czekać minutę lub dłużej, podczas ładowania meczu / mapy / poziomu. Wiem, że łączenie rówieśników wiąże się z pewnym opóźnieniem, ale moje doświadczenie nie zajmuje więcej niż kilka chwil. Jakie problemy wiążą się z tą koncepcją, aby zapobiec wykorzystaniu jej do wyeliminowania czasu ładowania związanego z ładowaniem danych mapy / poziomu / interfejsu?

Odpowiedź brzmi: tak, w większości przypadków można to zrobić przynajmniej w pewnym stopniu.

Powodów, dla których tego nie zrobiono, jest wiele:

• To wymaga czasu i pieniędzy, aby zrobić to dobrze.
• Ilość błędów, które przejdą testy, będzie wyższa
• Czasy ładowania są akceptowane przez użytkowników.
• Mogą istnieć inne przyczyny czasów ładowania, takie jak równoważenie obciążenia serwera.
• Ogólne rozwiązania, które można kupić z półki, są bardziej kompatybilne z „ładuj jednocześnie”.

Jeśli menu zawierają mnóstwo zasobów, ładowanie ich zajmuje trochę czasu. Nie masz również pojęcia, w jakiej kolejności ludzie będą poruszać się po twoim menu. Mogą kliknąć opcje -> wstecz -> kredyty lub kredyty -> wstecz -> rozpocząć grę w krótkim odstępie czasu. Dlatego nie ma rozsądnej strategii przesyłania strumieniowego.

W grze z otwartym światem wiesz, że gracz nie porusza się szybciej niż pewna prędkość, więc wiesz, że nie musisz ładować szczegółowych wersji odległych lokalizacji, dopóki się do nich nie zbliżą.

Dużym czynnikiem wpływającym na wykonalność takiego rozwiązania jest przewidywalność tego, co wymaga załadowania. Jeśli gracz wczyta zupełnie nowe poziomy, nie mogąc przewidzieć, co wybierze, całkowicie bezproblemowe rozwiązanie jest po prostu niemożliwe. Na przykład, kiedy gracz może wybrać dowolny poziom w grze, lub jeśli ma swobodę teleportacji do zupełnie innych obszarów w grach z otwartym światem.

Niektóre gry Halo zaczynają ładować wybrany poziom w tle podczas konfigurowania gier wieloosobowych. Skraca to czas oczekiwania, gdy gracze są gotowi do startu i jest prawdopodobnie najbliższym rozwiązaniem, gdy gracz może swobodnie wybierać różne poziomy z zupełnie innymi zasobami.

Oczywiście powiedziałeś „bez zmiany otoczenia”, ale chciałem tylko przywołać przykład Halo , ponieważ chciałbym zobaczyć więcej.

W ramach ciągłej kampanii lub za każdym razem, gdy programista ma dużą kontrolę nad lokalizacją gracza, takie rozwiązanie jest z pewnością realne, tak jak mówisz. Naughty Dog lubi zerwać z czasem ładowania, a Jak i Daxter znani nie mają czasów ładowania na PS2, a gry Uncharted mają na początku jeden czas ładowania.

Jednak dla wielu czas ładowania nie jest problemem, który wymaga rozwiązania . Lub jest to problem, który jest bardzo niski w stosunku do priorytetów programistów, kiedy zawsze można zrobić więcej między teraz a datą premiery .

Czas.

Potrzebujesz czasu, aby zaoszczędzić czas. Lub potrzebujesz pieniędzy, aby nadrobić brak czasu. W każdym razie „Brak czasu ładowania!” to funkcja, którą mogą zaoferować tylko ci, którzy mają na to luksus. Wymaga to bardzo starannego planowania i musisz bardzo dobrze zrozumieć, co robisz, i nie wszyscy twórcy gier mają na to środki.

Ostatecznie są to ograniczone zasoby.

Gry z otwartym światem, a zwłaszcza gry MMO, są silnie przygotowane na przewidywalność - zawsze wiesz, jakie dane musisz załadować z dużym wyprzedzeniem. Możesz to zobaczyć w architekturze światów - za każdym razem, gdy trzeba załadować wiele zasobów, możesz w jakiś sposób uniemożliwić użytkownikowi zobaczenie rzeczy, które nie zostały jeszcze załadowane. Najczęstszym sposobem są bramy i wejścia, które blokują widok na następny obszar na kilka kluczowych sekund potrzebnych do załadowania. Większość MMO stosuje również mniej szczegółowe modele i tekstury, co znacznie skraca czas ładowania.

Niektóre rzeczy są nadal nieprzewidywalne, nawet przy starannym projektowaniu. Na przykład gracze mogą nosić niestandardowe banery, które są wyświetlane dopiero po przesłaniu odpowiednich danych do komputera za pośrednictwem sieci. Oczywiście większość gier stara się to ograniczyć, aby było tańsze (np. Banery Diablo III są prostymi kompozycjami, łatwymi do przesłania jak najmniej bajtów danych). Ale ostatecznie czasem trzeba po prostu czekać na dane. I musisz coś pokazać, gdy trwa ładowanie - w wielu grach może to spowodować przerwę w zanurzeniu, gdy widzisz szary model o niskiej szczegółowości pokazany podczas oczekiwania na załadowanie danych.

A przy tym wszystkim ładowanie w ten sposób jest rozwiązanym problemem (TM), ale to nie ułatwia. Kosztuje dużo zasobów i czasu, zarówno w optymalizacji zasobów, jak i ich wykorzystaniu w celu zapewnienia płynnego odtwarzania, a także w samym kodzie - kod asynchroniczny jest trudny. Może to również oznaczać zmniejszenie wrażeń z gry, nawet jeśli wszystko pójdzie dobrze - oznacza to, że musisz upewnić się, że nie przekraczasz przepustowości swojego najniższego wspólnego mianownika, więc musisz obniżyć jakość modeli i tekstur lub je wykonać mniej zróżnicowane, a geometria waszych światów jest poważnie ograniczona. Jeśli tego nie zrobisz, gra będzie całkiem niemożliwa do gry - podczas gdy pamiętam osoby, które grały w gry, które trwały 10 minut (lub nawet dłużej!), Aby załadować mapę, po prostu dlatego, że ich komputer nie był w stanie sprostać zadaniu, grze potem wszystko działa dobrze. Gdyby zamiast tego miał płynne ładowanie, gra cały czas zawieszałaby się lub pokazywała brzydkie tekstury i modele przez cały czas, czekając na załadowanie danych. Odroczone ładowanie nie jest korzystne dla wszystkich, jest to kompromis, ponieważ większość rzeczy w inżynierii :)

Jednym z powodów, dla których dynamiczne ładowanie nie zawsze jest idealnym rozwiązaniem, które inne odpowiedzi tak naprawdę nie brały pod uwagę, myślę, że to także pop-in i inne artefakty graficzne.

Przewidywanie, co należy załadować, a czego nie ładować, często zawodzi i może to być niekorzystne doświadczenie. Jednym z najgorszych przykładów jest Rage autorstwa id Software. Przynajmniej we wczesnych wersjach systemy megatexture sprawiły, że nawet coś takiego, jak zbyt szybkie obracanie się, powodowało pojawienie się ogromnej ilości tekstur, a nawet artefaktów geometrycznych, zanim powoli zanikało.

Te problemy po prostu nie stanowią problemu, wszystko jest wstępnie załadowane.

Coś do rozważenia niekoniecznie to, co załadować, ale co rozładować. Kiedy masz tak dużo budżetu na miejsce, kiedy ładujesz nowe rzeczy, jakie stare należy usunąć? Czy jesteś pewien, że te zasoby nie będą używane w ciągu kilku najbliższych sekund? Są to trudne problemy do rozwiązania.

Jeśli każdy stan gry jest wystarczająco mały, aby zmieścić się we wspólnym budżecie systemowym, wtedy każda korzyść jest widoczna, zamiast ładowania, po prostu wchodzisz prosto na poziom, a rzeczy znikają podczas gry. Ale, jak sugerują główne odpowiedzi, czas ładowania małej gry nie byłby zbyt długi, aby się o to martwić.

Myślę, że warto pomyśleć o powodach, dla których pierwotnie stworzono systemy dynamicznego ładowania, ponieważ wiesz, że niektóre stany gry mogą być zbyt duże dla wspólnego systemu, a gra o takim rozmiarze po prostu nie jest w stanie wczytać całkowicie.

Jednym z powszechnych powodów jest to, że nie zawsze równie łatwo jest ustalić, czy zasób będzie potrzebny w najbliższej przyszłości.

Ponieważ jako przykład posłużyłeś się stronicowaniem terenu, będę kontynuować.

Jest całkowicie rozsądne, jeśli jesteś na danej siatce mapy, aby załadować wszystkie sąsiednie siatki map w tle. Wiesz, że użytkownik może co najwyżej wprowadzić jedną z nich. Kiedy to zrobią, możesz usunąć te, które już nie sąsiadują i załadować te, które już są. Zauważyłeś to.

Teraz wyobraź sobie szybką podróż. Nie ma absolutnie żadnego sposobu, aby przewidzieć, dokąd użytkownik może się udać. Mają (zwykle) prawie całą mapę do wyboru. Wstępne ładowanie wszystkich możliwych lokalizacji szybkich podróży zajęłoby o wiele za dużo pamięci (możesz równie dobrze załadować całą mapę do pamięci) i zdecydowanie za dużo czasu (zakładając, że cała mapa nie została wcześniej załadowana). Kiedy to się stanie? Kiedy otworzą okno szybkiej podróży? Problem stałby się tylko kilka razy gorszy!

Dlatego nawet większość gier z funkcją stronicowania terenu „bez obciążenia” wciąż ma ekrany ładowania w czasie szybkiej podróży. Dlatego też, jeśli poruszasz się wystarczająco szybko, czasami możesz uruchomić ekrany ładowania nawet w grach z mapami bez obciążenia (pamiętam, że zrobiłem to w TES Oblivion).

Teraz wyobraź sobie, że dotyczy to ogólnie zasobów gry, w których relacje często nie są oczywiste. W końcu będziesz musiał albo załadować wszystkie możliwe opcje, albo zacząć zgadywać, co zrobi użytkownik. Zgadywanie jest kosztowne (zarówno w fazie projektowania, jak i procesora) i skomplikowany bałagan w programie. Konkretne przykłady:

• Zapisz pliki: musisz załadować każdy zapisany plik, zanim użytkownik dotrze do ekranu zapisywania, lub zgadnij, który plik może załadować (najnowsze 5 itp.).
• Interfejs użytkownika: wiele gier strategicznych zmienia interfejs w zależności od frakcji. Musisz załadować każdy możliwy projekt interfejsu użytkownika, zanim użytkownik rozpocznie grę.
• Świat gry: w grach generowanych proceduralnie, takich jak Minecraft lub RTS, takich jak Civilization, świat nie istnieje, dopóki się go nie obejrzy, w różnym stopniu. Wstępne ładowanie jest niemożliwe, ponieważ na początku nie istniały; ich wstępne obliczenie można w najlepszym wypadku wykonać podobnie jak wstępne ładowanie i nie ma zastosowania w przypadku RTS.

Mogą istnieć sposoby na obejście niektórych z tych problemów, ale znalezienie tego kosztuje prawdziwe pieniądze . Większość graczy akceptuje rozsądne ekrany ładowania, a jeśli tak, to zazwyczaj wydaje więcej na sprzęt, aby je złagodzić. Jest to postrzegane jako problem sprzętowy , a nie problem z grą , chyba że jest to nadmiernie nadmierne lub w inny sposób zakłócające (jak ładowanie na środku poziomów).

Pamiętaj, że ładowanie w tle nie jest bezpłatne. Współczesne wykorzystanie terenu ładującego w tle i niektórych plików modelu ma zwykle minimalny wpływ, ale jeśli nagle zgadujesz o wielu różnych zasobach, zwłaszcza jeśli nie masz wiarygodnych danych i musisz rozładować wiele zasobów i załadować zbędne , możesz zmielić system w pył.

Ideą ładowania w tle jest wykorzystanie martwych cykli dla lepszego wykorzystania, ale jest tylko tak wiele martwych cykli do użycia. To samo dotyczy pamięci - wstępne ładowanie może znacznie zwiększyć wykorzystanie pamięci przez grę. Za pomocą ekranu ładowania możesz zrzucić istniejące zasoby. Nie ma takiego luksusu z ładowaniem w tle, co oznacza, że ​​może podwoić zapotrzebowanie na pamięć gry pod tym względem.

Jest to częsty problem wynikający z faktu, że gry to produkty w czasie rzeczywistym, w których opóźnione dostarczanie treści nie jest tak przydatne, jak dostarczanie na czas (w przeciwieństwie do czasu rzeczywistego, np. W samochodach na komputerach, gdzie opóźniona dostawa nie może być lepsza niż brak dostawy). Musisz zdecydować, co załadować i gdzie.

Czasami późne dostawy są szczególnie złe. Na przykład, jeśli wolno ci biegać po świecie, zanim wszystkie ściany zostaną załadowane, możesz dostać się za ścianę, której nigdy byś nie przegapił, gdyby gra załadowała ściany przed umożliwieniem ci ruchu. Nie zawsze łatwo jest stwierdzić, kiedy można uciec z „leniwym” ładowaniem treści i kiedy trzeba zagwarantować pełne załadowanie treści.

Ładowanie dynamiczne jest również znacznie bardziej skomplikowane. Musisz stale zastanawiać się, co zrobić, jeśli zasób nie został jeszcze załadowany. Jest to obciążenie zasobów programistycznych. O wiele łatwiej jest rozwijać, gdy możesz polegać na istniejących zasobach.

Opóźnienia również nie zawsze są dopuszczalne. Słyszałem o przypadkach w Starcraft, w których „rozgrzałeś” swoją grę, ładując mapę, która ma efekt uboczny buforowania każdego dynamicznie ładowanego modelu / obrazu. Następnie wychodzisz i grasz normalnie. Dla elitarnych graczy to zminimalizowane zacinanie się GUI, które faktycznie wpłynęło na ich rozgrywkę. Próba udowodnienia, które opóźnienia będą dopuszczalne dla użytkowników, a które nie, jest trudna.