Non tutti i giochi potrebbero evitare il caricamento post-avvio?

Proprio come i giganteschi giochi open world caricano dinamicamente enormi mappe, non possiamo caricare mappe separate, menu e praticamente qualsiasi interfaccia o impostazione 3D tramite lo stesso metodo di caricamento dinamico? Senza cambiare l'ambiente, sembra che le interfacce e le varie posizioni all'interno del gioco possano essere caricate in modo dinamico allo stesso modo in cui vengono caricate enormi mappe del mondo aperto mentre le percorri.

Perché questo non viene fatto? Vedo tanti giochi moderni in cui devi aspettare un minuto o più mentre la partita / mappa / livello si sta caricando. So che c'è una latenza nella connessione dei colleghi, ma ciò non richiede più di qualche momento nella mia esperienza. Quali sono i problemi con questo concetto per impedirne l'utilizzo per eliminare i tempi di caricamento associati al caricamento di dati mappa / livello / interfaccia?

La risposta è sì, questo potrebbe essere fatto, nella maggior parte dei casi, almeno in una certa misura.

I motivi per cui non è stato fatto sono molti:

• Richiede tempo e denaro per farlo bene.
• La quantità di bug che superano i test sarà maggiore
• I tempi di caricamento sono accettati dagli utenti.
• Ci possono essere altri motivi per i tempi di caricamento, come il bilanciamento del carico del server.
• Le soluzioni generiche che possono essere acquistate dallo scaffale sono più compatibili con "carica tutto in una volta".

Se i tuoi menu hanno un sacco di risorse, queste risorse impiegano del tempo per caricarsi. Inoltre non hai idea di quale ordine le persone navigheranno nel tuo menu. Potrebbero fare clic su opzioni -> indietro -> crediti o crediti -> indietro -> avviare il gioco in rapida successione. Quindi non esiste una strategia di streaming ragionevole.

In un gioco open world, sai che il giocatore non si muoverà più velocemente di una certa velocità, quindi sai che non è necessario caricare le versioni dettagliate di posizioni lontane finché non si avvicinano a loro.

Un grande fattore nella fattibilità di tale soluzione è la prevedibilità di ciò che deve essere caricato. Se il giocatore carica livelli completamente nuovi senza alcun modo di anticipare ciò che sceglierà, una soluzione completamente senza soluzione di continuità non è possibile. Ad esempio, quando il giocatore può selezionare qualsiasi livello nel gioco da cui giocare, o se ha la libertà di teletrasportarsi in aree completamente diverse nei giochi open world.

Alcuni giochi Halo iniziano a caricare il livello selezionato in background durante l'impostazione di giochi multiplayer. Ciò riduce i tempi di attesa quando i giocatori sono pronti per iniziare, ed è probabilmente il più vicino a una soluzione del genere quando il giocatore può scegliere liberamente diversi livelli con risorse completamente diverse.

Certo, hai detto "senza cambiare l'ambiente", ma volevo solo far apparire l' esempio di Halo , in quanto è qualcosa che mi piacerebbe vedere di più.

All'interno di una campagna continua, o ogni volta che lo sviluppatore ha molto controllo sulla posizione del giocatore, tale soluzione è certamente praticabile, proprio come dici tu. A Naughty Dog piace eliminare i tempi di caricamento, con Jak e Daxter notoriamente non hanno tempi di caricamento su PS2, e i giochi Uncharted hanno un solo tempo di caricamento all'inizio.

Tuttavia, per molti, il tempo di caricamento non è un problema che deve essere risolto . Oppure è un problema che è molto basso sulle priorità degli sviluppatori, quando c'è sempre di più da fare tra ora e la data di rilascio .

Tempo.

Hai bisogno di tempo per risparmiare tempo. Oppure hai bisogno di soldi per compensare la mancanza di tempo. In ogni caso, "Nessun tempo di caricamento!" è una caratteristica che solo chi ha il lusso di permettersi può offrire. Ci vuole una pianificazione molto attenta e devi capire molto bene cosa stai facendo e non tutti gli sviluppatori di giochi hanno le risorse per metterlo su.

In definitiva, sono risorse limitate.

I giochi open world e in particolare gli MMO sono fortemente orientati alla prevedibilità: sai sempre quali dati devi caricare con largo anticipo. Puoi vederlo nell'architettura dei mondi: ogni volta che ci sono molte risorse che devono essere caricate, hai un modo per impedire all'utente di vedere le cose che non sono ancora state caricate. Il modo più comune sono cancelli e ingressi che bloccano la vista nell'area successiva per i pochi secondi cruciali necessari per il caricamento. La maggior parte degli MMO utilizza anche modelli e trame meno dettagliati, il che riduce notevolmente i tempi di caricamento.

Alcune cose sono ancora imprevedibili, anche con un design accurato. Ad esempio, potrebbero essere presenti banner personalizzati indossati dai giocatori, che vengono visualizzati solo una volta che i dati rilevanti sono stati inviati al computer in rete. Naturalmente, la maggior parte dei giochi cerca di limitarlo per renderlo più economico (ad esempio, i banner di Diablo III sono composizioni semplici, facili da inviare come pochi byte di dati). Ma alla fine, a volte devi solo aspettare che arrivino i dati. Inoltre, devi mostrare qualcosa mentre è in corso il caricamento: in molti giochi, ciò può causare un'interruzione dell'immersione quando vedi un modello grigio e con dettagli bassi in attesa del caricamento dei dati.

E con tutto ciò, caricare in questo modo è un problema risolto (TM), ma ciò non lo rende facile. Costa un sacco di risorse e tempo, sia nell'ottimizzare le risorse che nel loro utilizzo per garantire un'esperienza di gioco fluida, e nel codice stesso - il codice asincrono è difficile. Può anche significare un'esperienza di gioco ridotta anche se tutto va bene - significa che devi assicurarti di non incrociare le capacità di larghezza di banda del tuo minimo comune denominatore, quindi devi abbassare la qualità di modelli e trame, o renderli meno vario e la geometria dei tuoi mondi è fortemente limitata. In caso contrario, il gioco sarà abbastanza ingiocabile - mentre ricordo le persone che hanno giocato a giochi che hanno impiegato 10 minuti (o anche più a lungo!) Per caricare una mappa, semplicemente perché il loro computer non era all'altezza del compito, il gioco si corre bene dopo quello. Se invece avesse un caricamento senza interruzioni, il gioco si bloccherebbe o mostrerebbe sempre brutti trame e modelli in attesa del caricamento dei dati. Il caricamento differito non è vantaggioso per entrambe le parti, è un compromesso come la maggior parte delle cose in ingegneria :)

Una ragione per cui il caricamento dinamico non è sempre la soluzione ideale che altre risposte non hanno davvero preso in considerazione, penso che sia anche pop-in e altri artefatti grafici.

La previsione di cosa caricare e cosa non caricare spesso fallisce, e può essere un'esperienza dannosa quando lo fa. Uno dei peggiori esempi di questo è stato in Rage di id Software. Almeno nelle prime versioni, i sistemi di megatexture hanno fatto in modo che anche qualcosa come girare troppo velocemente facesse apparire quantità enormatiche di trama e persino artefatti geometrici prima di svanire lentamente.

Questi problemi non sono un problema, è tutto precaricato.

Qualcosa da considerare non è necessariamente cosa caricare, ma cosa scaricare. Quando hai così tanto budget per lo spazio, quando carichi nuove cose, quali sono quelle vecchie da rimuovere? Quanto sei sicuro che tali risorse non saranno in uso entro i prossimi secondi? Questi sono problemi difficili da risolvere.

Se ogni stato del gameplay è abbastanza piccolo da rientrare in un budget di sistema comune, allora ogni vantaggio è evidente, invece di caricare, vai semplicemente a un livello e le cose svaniscono mentre giochi. Ma, come suggeriscono le risposte principali, il tempo di caricamento di un piccolo gioco non sarebbe troppo lungo di cui preoccuparsi.

Penso che valga la pena di pensare al ragionamento per cui i sistemi di caricamento dinamico sono stati creati originariamente, essendo che sai che molti dei tuoi stati di gioco potrebbero essere troppo grandi per un sistema comune e un gioco di quelle dimensioni semplicemente non è possibile precaricare completamente.

Una ragione comune è che non è sempre altrettanto facile determinare se una risorsa sarà necessaria nel prossimo futuro.

Dato che hai usato il paging del terreno come esempio, continuerò con quello.

È perfettamente ragionevole se ci si trova in una determinata griglia della mappa per caricare tutte le griglie della mappa adiacenti in background. Sai che l'utente può, nella migliore delle ipotesi, inserirne uno. Quando lo fanno, puoi scaricare quelli che non sono più adiacenti e caricare quelli che sono ora. Questo hai notato.

Ora immagina un viaggio veloce. Non c'è assolutamente modo di prevedere dove l'utente può scegliere di andare. Hanno (di solito) quasi l'intera mappa tra cui scegliere. Il pre-caricamento di tutte le possibili posizioni di viaggio veloce richiederebbe troppa memoria (potresti anche caricare l'intera mappa in memoria in primo luogo) e troppo tempo (supponendo che non avessi l'intera mappa pre-caricata). Quando sarebbe successo? Quando aprono la finestra di dialogo di viaggio veloce? Il problema peggiorerebbe solo diverse volte!

Questo è il motivo per cui anche la maggior parte dei giochi con paging del terreno "senza carico" ha ancora schermate di carico durante i viaggi veloci. È anche il motivo per cui, se ti muovi abbastanza velocemente, a volte puoi attivare il caricamento delle schermate anche nei giochi con mappe a vuoto (ricordo di averlo fatto in TES Oblivion).

Ora immagina questo applicato alle risorse di gioco in generale, dove le relazioni spesso non sono ovvie. Alla fine dovrai caricare tutte le opzioni possibili o iniziare a indovinare cosa farà l'utente. Indovinare è costoso (sia nello sviluppo che nella CPU) e un casino complesso da programmare. Esempi specifici:

• Salva i file: dovrai caricare tutti i file di salvataggio prima che l'utente raggiunga la schermata di salvataggio o indovinare quale file potrebbero caricare (ultimi 5, ecc.).
• UI: molti giochi di strategia cambiano la loro UI a seconda della tua fazione. Dovresti caricare ogni possibile progetto dell'interfaccia utente prima che l'utente inizi il gioco.
• Mondo di gioco: nei giochi generati proceduralmente, come Minecraft o RTS come Civilization, il mondo non esiste fino a quando non viene visto, in misura variabile. Il pre-caricamento è impossibile poiché non esistevano per cominciare; il pre-calcolo potrebbe nel migliore dei casi essere fatto in modo simile al pre-caricamento e non è applicabile nel caso RTS.

Potrebbero esserci dei modi per aggirare alcuni di questi problemi, ma questo costa capire i soldi della vita reale . La maggior parte dei giocatori accetta schermate di caricamento ragionevoli e, semmai, tende a spendere di più per l'hardware per mitigarle. È visto come un problema hardware , non un problema di gioco , a meno che non sia insolitamente eccessivo o altrimenti distruttivo (come il caricamento nel mezzo dei livelli).

E tieni presente che il caricamento in background non è gratuito. Di solito si ha un impatto minimo dall'uso moderno del terreno di caricamento in background e di alcuni file di modello, ma se improvvisamente si indovina molte risorse diverse, soprattutto se non si hanno metriche affidabili e si devono scaricare molte risorse e caricare quelle superflue , puoi macinare il sistema in polvere.

L'idea del caricamento in background è di usare i cicli morti per un uso migliore, ma ci sono solo tanti cicli morti da usare. Lo stesso vale per la memoria: il pre-caricamento può aumentare sostanzialmente l'utilizzo della memoria di un gioco. Con una schermata di caricamento, puoi scaricare le risorse esistenti. Nessun lusso del genere con caricamento in background, il che significa che potrebbe raddoppiare il fabbisogno di memoria del gioco da solo.

Questo è un problema comune derivante dal fatto che i giochi sono prodotti soft-realtime, in cui una consegna tardiva dei contenuti non è utile come una consegna puntuale (contrasto con il tempo reale, come le auto nei computer, dove una consegna tardiva non può essere migliore di nessuna consegna). Devi decidere cosa caricare e dove.

A volte, le consegne in ritardo sono particolarmente gravi. Ad esempio, se ti è permesso correre in un mondo prima che tutti i muri vengano caricati, puoi metterti dietro un muro che non avresti mai potuto raggiungere se il gioco caricasse i muri prima di farti muovere. Non è sempre facile dire quando è possibile cavarsela con un caricamento "pigro" del contenuto e quando è necessario garantire che il contenuto sia completamente caricato.

Anche il caricamento dinamico è molto più complicato. Devi costantemente considerare cosa fare se la risorsa non è ancora stata caricata. Questo è uno scarico delle risorse di sviluppo. È molto più facile da sviluppare quando si può fare affidamento sulle risorse esistenti.

Anche le latenze non sono sempre accettabili. Ho sentito parlare di casi in Starcraft in cui "riscalderesti" il tuo gioco caricando una mappa che ha un effetto collaterale nella memorizzazione nella cache di ogni modello / immagine caricato dinamicamente. Usciresti e giocherai normalmente. Per i giocatori d'élite, questa riduzione al minimo della balbuzie della GUI ha effettivamente influenzato il loro gameplay. Cercare di provare quali latenze saranno accettabili per gli utenti e quali no sarà difficile.