Progresyvaus žaidimų krovimo įvaldymas: Išsamus išteklių valdymo vadovas

Žaidimų kūrimo pasaulyje krovimo ekranas yra ir neišvengiamas blogis, ir didžiausias žaidėjų įsitraukimo priešas. Momentinio pasitenkinimo amžiuje kiekviena sekundė, kurią žaidėjas praleidžia žiūrėdamas į progreso juostą, yra sekundė, per kurią jis gali nuspręsti žaisti ką nors kita. Būtent čia progresyvus žaidimų krovimas, paremtas išmaniu išteklių valdymu, paverčia žaidėjo patirtį iš laukimo žaidimo į sklandų nuotykį.

Tradiciniai krovimo metodai, kurie verčia žaidėjus laukti, kol visas žaidimas ar lygis bus įkeltas į atmintį, tampa atgyvena, ypač didelio masto, atviro pasaulio ar turtingo turinio žaidimuose. Sprendimas – krauti tik tai, kas būtina, ir tiksliai tada, kai to reikia. Šiame vadove išsamiai nagrinėjamos išteklių valdymo strategijos, kurios įgalina progresyvų krovimą, siūlant praktines įžvalgas kūrėjams, dirbantiems su bet kuria platforma – nuo mobiliųjų įrenginių iki aukštos klasės asmeninių kompiuterių ir konsolių.

Kas tiksliai yra progresyvus žaidimų krovimas?

Progresyvus žaidimų krovimas, dažnai vadinamas išteklių srautiniu krovimu arba dinaminiu krovimu, yra praktika, kai žaidimo ištekliai (pvz., modeliai, tekstūros, garsai ir scenarijai) yra kraunami iš saugyklos į atmintį pagal pareikalavimą žaidimo metu, o ne visi iš karto prieš pradedant žaisti.

Įsivaizduokite didžiulį atviro pasaulio žaidimą. Tradicinis metodas bandytų įkelti visą pasaulį – kiekvieną medį, veikėją ir pastatą – dar prieš žaidėjui pradedant. Tai yra skaičiavimo požiūriu neįmanoma ir lemtų astronomiškai ilgus krovimo laikus. Tačiau progresyvus metodas įkelia tik artimiausią žaidėjo aplinką. Kai žaidėjas keliauja po pasaulį, žaidimas protingai iškelia išteklius, kurie nebėra reikalingi (esantys už žaidėjo), ir iš anksto įkelia išteklius tos srities, į kurią jis keliauja. Rezultatas – beveik momentinis starto laikas ir nepertraukiama, sklandi didžiulio, detalaus pasaulio patirtis.

Pagrindiniai privalumai yra akivaizdūs:

• Sutrumpintas pradinis krovimo laikas: Žaidėjai greičiau įsitraukia į veiksmą, o tai ženkliai pagerina žaidėjų išlaikymo rodiklius.
• Mažesnis atminties naudojimas: Laikant atmintyje tik būtinus išteklius, žaidimai gali veikti aparatinėje įrangoje su griežtesniais atminties apribojimais, pvz., mobiliuosiuose įrenginiuose ir senesnėse konsolėse.
• Didesni ir detalesni pasauliai: Kūrėjai nebėra apriboti tuo, kas vienu metu telpa į atmintį, todėl gali kurti didesnes ir sudėtingesnes žaidimų aplinkas.

Kodėl išteklių valdymas yra progresyvaus krovimo pagrindas

Progresyvus krovimas nėra magija; tai inžinerijos žygdarbis, pastatytas ant kruopštaus išteklių valdymo pamatų. Negalite siųsti srautiniu būdu to, ko nesusitvarkėte. Be apgalvotos išteklių valdymo strategijos, bandymas įdiegti progresyvų krovimą veda į chaosą: trūkstamas tekstūras, našumo trikdžius ir strigimus. Efektyvus išteklių valdymas yra sistema, leidžianti žaidimo varikliui žinoti, ką krauti, kada tai daryti ir kaip tai daryti efektyviai.

Štai kodėl tai taip svarbu:

• Priklausomybių valdymas: Vienas, iš pažiūros paprastas išteklius, pavyzdžiui, 3D kėdės modelis, gali turėti priklausomybių nuo daugybės medžiagų, kurios savo ruožtu priklauso nuo didelės raiškos tekstūrų ir sudėtingų šešėlių programų (angl. shaders). Be tinkamo valdymo, vienos kėdės įkėlimas gali netyčia į atmintį įtraukti šimtus megabaitų susijusių duomenų.
• Saugyklos ir pateikimo optimizavimas: Ištekliai turi būti supakuoti į logines grupes, arba „dalis“ (angl. chunks), kad būtų efektyviai kraunami iš disko ar per tinklą. Prasta dalijimo strategija gali lemti nereikalingų duomenų krovimą arba našumo kliūčių sukūrimą.
• Mastelio keitimo įgalinimas: Tvirta išteklių valdymo sistema leidžia kurti išteklių variantus skirtingoms platformoms. Aukštos klasės kompiuteris gali įkelti 4K tekstūras, o mobilusis įrenginys – suspaustą 512 pikselių versiją iš tos pačios loginės ištekliaus užklausos, užtikrinant optimalų našumą visur.

Pagrindinės išteklių valdymo strategijos progresyviam krovimui

Norint įdiegti tvirtą progresyvaus krovimo sistemą, reikalingas daugialypis požiūris į išteklių valdymą. Štai pagrindinės strategijos, kurias turėtų įvaldyti kiekviena kūrėjų komanda.

1. Išteklių auditas ir profiliavimas

Prieš valdydami savo išteklius, turite juos suprasti. Išteklių auditas – tai kiekvieno projekto ištekliaus analizės procesas, siekiant suprasti jo charakteristikas.

• Ką profiliuoti: Naudokite savo variklio profilerį (pvz., „Unity Profiler“ ar „Unreal Insights“), kad stebėtumėte atminties naudojimą, disko skaitymo laiką ir procesoriaus poveikį. Atkreipkite dėmesį į ištekliaus dydį diske ir dydį atmintyje, nes glaudinimas gali būti klaidinantis. 1 MB suspausta tekstūra gali užimti 16 MB ar daugiau GPU atminties.
• Nustatykite kaltininkus: Ieškokite daugiausiai resursų reikalaujančių išteklių. Ar yra nesuspaustų garso failų? Nereikalingai didelės raiškos tekstūrų ant mažų fono objektų? Modelių su pernelyg dideliu poligonų skaičiumi?
• Surašykite priklausomybes: Naudokite įrankius išteklių priklausomybių grafikams vizualizuoti. Supratimas, kad paprastas dalelių efektas yra susietas su milžinišku tekstūrų atlasu, yra pirmas žingsnis link problemos sprendimo. Šios žinios yra labai svarbios kuriant švarias, nepriklausomas išteklių dalis.

2. Išteklių dalijimas ir grupavimas

Dalijimas (arba grupavimas) yra išteklių grupavimo į paketus procesas, kuriuos galima įkelti ir iškelti kaip vieną vienetą. Tai yra progresyvaus krovimo esmė. Tikslas – sukurti dalis, kurios būtų savarankiškos ir atspindėtų loginę žaidimo dalį.

Dažniausios dalijimo strategijos:

• Pagal lygį ar zoną: Tai yra pats paprasčiausias metodas. Visi ištekliai, reikalingi konkrečiam lygiui ar geografinei vietovei (pvz., „Drakono viršūnė“ arba „Sektorius 7-G“), sugrupuojami į vieną dalį. Kai žaidėjas įeina į zoną, dalis yra įkeliama. Kai išeina, ji iškeliama.
• Pagal artumą/matomumą: Detalesnis ir efektyvesnis metodas atviriems pasauliams. Pasaulis padalijamas į tinklelį. Žaidimas įkelia dalį, kurioje žaidėjas šiuo metu yra, plius visas gretimas dalis. Žaidėjui judant, naujos dalys yra įkeliamos kelionės kryptimi, o senos dalys iškeliamos iš užnugario.
• Pagal funkciją: Grupuokite išteklius, susijusius su konkrečia žaidimo sistema. Pavyzdžiui, „KūrybosSistemos“ dalis galėtų apimti visus vartotojo sąsajos elementus, 3D modelius ir garsus, skirtus kūrybos meniu. Ši dalis įkeliama tik tada, kai žaidėjas atidaro kūrybos sąsają.
• Pagal padalijimą į esminius ir neprivalomus: Lygio dalis gali būti padalinta į dvi dalis. Esminėje dalyje yra viskas, ko reikia, kad lygis būtų žaidžiamas (geometrija, kolizijos, kritinės tekstūros). Neprivalomoje dalyje yra didelio detalumo rekvizitai, papildomi dalelių efektai ir didelės raiškos tekstūros, kurias galima įkelti srautiniu būdu po to, kai žaidėjas jau pradėjo žaisti toje srityje.

3. Griežtas priklausomybių valdymas

Priklausomybės yra tyliosios švaraus išteklių valdymo žudikės. Numanoma nuoroda tarp ištekliaus A dalyje ir ištekliaus B dalyje gali priversti B dalį įkelti į atmintį, kai buvo prašoma tik A dalies, taip paneigiant dalijimo prasmę.

Geriausios praktikos:

• Aiškios nuorodos: Projektuokite savo sistemas taip, kad jos naudotų aiškias, švelnias nuorodas (pvz., išteklių ID ar kelius), o ne tiesiogines, griežtas nuorodas. Šiuolaikinės sistemos, tokios kaip Unity „Addressables“ ar Unreal „Soft Object Pointers“, yra sukurtos būtent tam.
• Bendrai naudojamų išteklių dalys: Nustatykite išteklius, kurie naudojami daugelyje skirtingų dalių (pvz., žaidėjo modelis, bendri vartotojo sąsajos elementai, bendrinis uolos modelis). Įdėkite juos į atskirą „Bendrą“ dalį, kuri įkeliama žaidimo pradžioje ir lieka atmintyje. Tai apsaugo nuo ištekliaus dubliavimo kiekvienoje dalyje, sutaupant didžiulį kiekį vietos.
• Griežta projekto organizacija: Įdiekite aplankų struktūras ir taisykles, kurios padarytų priklausomybes akivaizdžias. Pavyzdžiui, taisyklė galėtų būti tokia, kad ištekliai konkretaus lygio aplanke gali nurodyti tik kitus išteklius tame pačiame aplanke arba tam skirtame „Bendrame“ aplanke.

4. Išmaniosios srautinio krovimo strategijos

Kai jūsų ištekliai yra tvarkingai suskirstyti į dalis, jums reikia sistemos, kuri nuspręstų, kada juos įkelti ir iškelti. Tai yra srautinio krovimo valdytojas arba kontroleris.

• Trigeriais paremtas srautinis krovimas: Paprasčiausia forma. Pasaulis užpildytas nematomais trigerių tūriais. Kai žaidėjas įeina į tūrį, jis sukelia įvykį, kuris įkelia atitinkamą išteklių dalį. Kai jis išeina iš kito tūrio, sukeliamas kitas įvykis, kad būtų iškelta dalis, kuri dabar yra toli.
• Prognozuojantis krovimas: Pažangesnė technika. Sistema analizuoja žaidėjo greitį ir judėjimo kryptį, kad iš anksto įkeltų dalis, su kuriomis jis greičiausiai susidurs. Tai padeda paslėpti krovimo trikdžius, užtikrinant, kad duomenys jau būtų atmintyje prieš juos prireikiant.
• Asinchroninis krovimas: Būtina, kad visos krovimo operacijos būtų asinchroninės. Tai reiškia, kad jos vyksta atskiroje gijoje nuo pagrindinio žaidimo ciklo. Jei krausite išteklius sinchroniškai pagrindinėje gijoje, žaidimas sustings, kol krovimas bus baigtas, o tai sukels trūkčiojimus ir trikdžius – pačią problemą, kurią bandome išspręsti.

5. Atminties valdymas ir šiukšlių surinkimas

Krovimas – tai tik pusė darbo. Išteklių iškėlimas yra lygiai taip pat svarbus, norint kontroliuoti atminties naudojimą. Nesugebėjimas tinkamai iškelti išteklių sukelia atminties nutekėjimus, kurie galiausiai prives prie žaidimo strigimo.

• Nuorodų skaičiavimas: Dažna technika yra skaičiuoti, kiek sistemų šiuo metu naudoja įkeltą išteklių dalį. Kai skaičius nukrenta iki nulio, dalį saugu iškelti.
• Laiku paremtas iškėlimas: Jei dalis nebuvo naudojama tam tikrą laiką (pvz., 5 minutes), ją galima pažymėti kaip iškeliamą.
• GC šuolių valdymas: Valdomos atminties aplinkose (pvz., C# Unity variklyje), iškeliant išteklius susidaro „šiukšlės“, kurias reikia surinkti. Šis šiukšlių surinkimo (GC) procesas gali sukelti didelį našumo šuolį, sustabdydamas žaidimą kelioms milisekundėms. Gera strategija yra iškelti išteklius mažo intensyvumo momentais (pvz., meniu, per vaizdo intarpą) ir rankiniu būdu inicijuoti GC nuspėjamu laiku, o ne leisti jam netikėtai įvykti intensyvios kovos metu.

Praktinis įgyvendinimas: Platformai neutralus požiūris

Nors konkretūs įrankiai skiriasi, koncepcijos yra universalios. Pažvelkime į įprastą scenarijų ir tada aptarkime konkretiems varikliams skirtus įrankius.

Pavyzdinis scenarijus: atviro pasaulio RPG

1. Sąranka: Pasaulis padalintas į 100x100 ląstelių tinklelį. Kiekviena ląstelė ir jos turinys (reljefas, augmenija, pastatai, NPC) supakuoti į unikalią išteklių dalį (pvz., `Cell_50_52.pak`). Bendri ištekliai, tokie kaip žaidėjo veikėjas, dangaus skliautas ir pagrindinė vartotojo sąsaja, yra `Shared.pak` faile, įkeliamame paleidžiant žaidimą.
2. Žaidėjas atsiranda: Žaidėjas yra ląstelėje (50, 50). Srautinio krovimo valdytojas įkelia 3x3 dalių tinklelį, centruotą ties žaidėju: ląsteles nuo (49,49) iki (51,51). Tai sudaro „aktyvųjį burbulą“ su įkeltu turiniu.
3. Žaidėjo judėjimas: Žaidėjas juda į rytus, į ląstelę (51, 50). Srautinio krovimo valdytojas aptinka šį perėjimą. Jis žino, kad žaidėjas juda į rytus, todėl pradeda asinchroniškai iš anksto krauti kitą dalių stulpelį: (52, 49), (52, 50) ir (52, 51).
4. Iškėlimas: Tuo pačiu metu, kai įkeliamos naujos dalys, valdytojas nustato, kad labiausiai į vakarus nutolęs dalių stulpelis nebėra reikalingas. Jis patikrina jų nuorodų skaičių. Jei niekas kitas jų nenaudoja, jis iškelia dalis (49, 49), (49, 50) ir (49, 51), kad atlaisvintų atmintį.

Šis nuolatinis krovimo ir iškėlimo ciklas sukuria begalinio, nuolatinio pasaulio iliuziją, išlaikant atminties naudojimą stabilų ir nuspėjamą.

Konkrečių variklių įrankiai: trumpa apžvalga

• Unity: „Addressable Assets“ sistema
  Šiuolaikinis Unity sprendimas, `Addressables`, yra galinga abstrakcija, pakeitusi senesnę `AssetBundles` sistemą. Ji leidžia priskirti unikalų, nuo vietos nepriklausomą „adresą“ bet kuriam ištekliui. Tada galite įkelti išteklių pagal jo adresą, nežinodami, ar jis yra vietinėje versijoje, nuotoliniame serveryje ar konkrečiame pakete. Ji automatiškai tvarko priklausomybių sekimą ir nuorodų skaičiavimą, todėl tai yra pagrindinis įrankis progresyviam krovimui Unity variklyje įgyvendinti.
• Unreal Engine: „Asset Manager“ ir „Level Streaming“
  Unreal Engine turi tvirtą, integruotą sistemą šiam tikslui. `Asset Manager` yra globalus objektas, kurį galima sukonfigūruoti, kad jis nuskaitytų ir valdytų pirminius išteklius. Galite padalinti savo žaidimą į dalis, sukurdami atskirus lygio failus (`.umap`) skirtingoms sritims, o tada naudoti `Level Streaming` funkciją, kad dinamiškai juos įkeltumėte ir iškeltumėte. Norint gauti detalesnį valdymą, išteklius galima supakuoti į `.pak` failus, kuriuos valdo variklio „kepimo“ ir dalijimo taisyklės. `Soft Object Pointers` ir `TSoftObjectPtr` naudojami kuriant neblokuojančias nuorodas į išteklius, kuriuos galima įkelti asinchroniškai.

Pažangios temos ir geriausios praktikos

Glaudinimas ir išteklių variantai

Ne visos platformos yra vienodos. Jūsų išteklių valdymo sistema turėtų palaikyti variantus. Tai reiškia, kad turite vieną šaltinio išteklių (pvz., pagrindinę 8K PSD tekstūrą), kuris kūrimo proceso metu yra apdorojamas į skirtingus formatus ir raiškas: aukštos kokybės BC7 formatą kompiuteriui, mažesnį PVRTC formatą iOS ir dar mažesnės raiškos versiją žemos specifikacijos įrenginiams. Šiuolaikinės išteklių sistemos gali supakuoti šiuos variantus kartu ir automatiškai pasirinkti tinkamą vykdymo metu, atsižvelgiant į įrenginio galimybes.

Testavimas ir derinimas

Progresyvaus krovimo sistema yra sudėtinga ir linkusi į subtilias klaidas. Griežtas testavimas yra privalomas.

• Sukurkite žaidime veikiančius derinimo vizualizatorius: Sukurkite derinimo perdangas, kurios rodytų įkeltų dalių ribas, išvardytų šiuo metu atmintyje esančius išteklius ir grafiškai atvaizduotų atminties naudojimą laikui bėgant. Tai neįkainojama norint aptikti nutekėjimus ir diagnozuoti krovimo problemas.
• Testavimas nepalankiausiomis sąlygomis: Testuokite blogiausius scenarijus. Greitai judinkite žaidėją pirmyn ir atgal tarp dalių ribų, kad pamatytumėte, ar sistema suspėja. Teleportuokite žaidėją į atsitiktines vietas, kad patikrintumėte, ar nėra trikdžių ar trūkstamų išteklių.
• Automatizuotas testavimas: Sukurkite automatizuotus testavimo scenarijus, kurie skraidintų kamerą per visą žaidimo pasaulį, tikrintų krovimo klaidas ir rinktų našumo duomenis.

Išvada: Ateitis yra sklandi

Progresyvus žaidimų krovimas nebėra prabanga, skirta tik aukščiausios klasės AAA žaidimams; tai yra pagrindinis reikalavimas kuriant konkurencingus, šiuolaikiškus bet kokio didesnio masto žaidimus. Jis tiesiogiai veikia žaidėjų pasitenkinimą ir atveria kūrybines galimybes, kurias anksčiau ribojo aparatinės įrangos apribojimai.

Tačiau srautinio krovimo galia atsiskleidžia tik per disciplinuotą, gerai suplanuotą požiūrį į išteklių valdymą. Atlikdami turinio auditą, strategiškai jį dalindami, tiksliai valdydami priklausomybes ir įgyvendindami protingą krovimo bei iškėlimo logiką, galite įveikti krovimo ekraną. Galite kurti didžiulius, įtraukiančius pasaulius, kurie atrodo beribiai, ir tuo pačiu metu teikti sklandžią, reaguojančią ir nepertraukiamą patirtį, kuri išlaiko žaidėjų įsitraukimą nuo pat momento, kai jie paspaudžia „Pradėti“. Žaidimų kūrimo ateityje geriausias krovimo ekranas yra tas, kurio žaidėjas niekada nemato.