STL per i giochi, sì o no? [chiuso]

Ogni linguaggio di programmazione ha la sua libreria standard di contenitori, algoritmi e altre cose utili. Con linguaggi come C #, Java e Python, è praticamente inconcepibile usare il linguaggio senza la sua lib standard.

Eppure, su molti giochi C ++ su cui ho lavorato, o non abbiamo usato affatto lo STL, ne abbiamo usato una piccola parte o abbiamo usato la nostra implementazione. È difficile dire se quella sia stata una buona decisione per i nostri giochi, o semplicemente fatta per ignoranza della STL.

Quindi ... l'STL è adatto o no?

Quando lavoravo allo sviluppo di giochi professionali, STL era troppo immaturo e gonfio. Ma è stato> 10 anni fa.

Ora lavoro nella simulazione militare, che ha requisiti di prestazione ancora più severi (come il framerate non può mai andare al di sotto di alcuni FPS). Nella simulazione militare STL è utilizzato ovunque.

Alcune persone che ti dicono di non usare STL usano l'argomento che non è sempre la soluzione perfetta o addirittura migliore al problema. Ma questa non è una risposta alla domanda. La domanda dovrebbe essere: c'è qualcosa di intrinsecamente sbagliato nell'uso dell'STL nei giochi? Direi di no, la maggior parte delle volte STL è un'implementazione migliore di quella che un utente si inventerebbe da solo.

Assicurati di sapere come utilizzare l'STL e utilizzalo nel tuo gioco. Leggi alcuni libri e guarda il codice di implementazione nell'STL che stai utilizzando.

Direi che, al di sopra della mia testa, è un'idea migliore usare l'STL a meno che tu non sappia esattamente perché non vuoi usarlo.

Ecco la cosa sull'STL: è sviluppato da persone più intelligenti di te. Non è pensato per essere offensivo o altro, è solo che lo STL è sviluppato da persone il cui lavoro sta effettivamente costruendo lo STL. Sarà praticamente veloce quanto la piattaforma può consentire e sarà generalmente molto più robusto di una soluzione home-roll (e questo dovrebbe essere tanto preoccupante se non più di preoccuparsi della velocità pura - perché il tuo gioco ha bisogno robustezza un po 'più di quanto sia necessaria la velocità; quest'ultima non ha senso senza la prima).

Le lamentele secondo cui la STL impone una "visione ristretta del mondo" mi sembrano un po 'sciocche. Sono contenitori. Hanno un insieme limitato di operazioni perché i contenitori hanno un insieme limitato di operazioni. Cosa stai facendo che non ti fa arrabbiare con questo?

Ho visto pochissimi motivi per non utilizzare l'STL per i giochi.

Per i problemi di allocazione della memoria, molte persone non lo sanno, ma è possibile scrivere allocatori personalizzati per le classi del contenitore STL. Gli allocatori sono fondamentalmente classi di criteri che passi nei tuoi modelli per determinare come vengono eseguite le allocazioni. Usandoli di solito puoi aggirare qualunque problema di memoria sia problematico sulla tua piattaforma preferita.

Naturalmente, se stai usando l'STL e stai facendo cose stupide come mappe di stringhe a tipi grandi, senza puntatore, allora hai grossi problemi a portata di mano.

L'STL predefinito presenta un numero discreto di problemi che ne rendono difficile l'utilizzo con i giochi, soprattutto quando si tratta di allineamento della memoria.

Una variante personalizzata come EA STL è appositamente progettata per i giochi e può offrirti prestazioni di memoria e usabilità della console molto migliori. È diventato open source nel 2016, con una clausola BSD-3, con un repository su GitHub .

Ecco cosa ha detto Mike Acton (direttore del motore di Insomniac Games of Spyro the Dragon, Ratchet & Clank e Resistance) quando gli è stato chiesto qui . Nota che gli è stato chiesto sia di STL che di Boost in generale in relazione all'utilizzo nello sviluppatore di giochi.

STL / Boost, appartiene a gamedev? Se solo parti di esso, quali?

Stai chiedendo due cose diverse qui, giusto? STL e Boost, separatamente. Ma davvero, la mia risposta è la stessa: non c'è niente di sbagliato in nessuno dei due, ma scoraggio il loro uso. L'uso di entrambi incoraggia le persone a adattare una soluzione a un problema piuttosto che a trovare una soluzione a un problema. La soluzione dovrebbe essere sempre adeguata ai dati a portata di mano e ai vincoli dell'hardware, ecc. Sia STL che Boost hanno una visione estremamente ristretta del "mondo" e il loro uso appropriato è limitato. Davvero, li scoraggio perché guidano subito i programmatori nella direzione sbagliata, spesso dico che se senti di aver bisogno di uno dei due, probabilmente non capisci davvero il problema che

Ho anche notato che la maggior parte degli sviluppatori di giochi pro punta più al C che al C ++.

Se ti ritrovi a riscrivere qualcosa che esiste già nell'STL, per qualsiasi motivo, fermati . Usa STL.

L'STL è stato ottimizzato in anni di analisi e tempo, ed è una scommessa sicura che probabilmente non hai intenzione di scrivere qualcosa che sia più efficiente. Questo non vuol dire che dovresti usare STL dove potrebbe essere possibile una soluzione più semplice (cioè usa un array quando hai una quantità nota di cose, non una stl :: list), ma se stai scrivendo la tua implementazione di una mappa ( la struttura dei dati di base, non una mappa del mondo di gioco), stai sbagliando.

STL è adatto ai giochi? Decisamente. I giochi sono complessi software, l'STL offre funzionalità che aiutano a gestire la complessità, quindi è buono.

È adatto alla tua piattaforma? Non necessariamente. Se stai scrivendo per una console, devi fare molta attenzione all'utilizzo della memoria e della cache. L'STL non lo rende molto semplice.

Penso che troppo spesso scambiamo "giochi" per "giochi in tempo reale ad alte prestazioni che girano su hardware incorporato o su misura", ma è importante fare una distinzione. Se stai scrivendo un gioco per Windows che non sta cercando di essere eseguito a schermo intero a 60 fps costanti, non c'è motivo di evitare gli strumenti offerti dalla libreria standard.

So che è molto tardi per la festa, ma il tempo cambia e le risposte rimangono in giro. C ++ 11 presenta cambiamenti piuttosto ampi, molti dei quali aumentano le prestazioni del C ++ e della libreria standard. Sembra che coloro che non usano STL o Boost, tendano a non tenere il passo con i nuovi standard, lasciando le soluzioni filate a casa prive di importanti miglioramenti, ovviamente non è sempre così.

Ho usato STL su tutti i progetti dalla metà degli anni '90 ad oggi, ad eccezione di un breve periodo presso EA. Penso che il lato anti-STL avesse delle ragioni marginalmente razionali per non usarlo. Quelli sono in gran parte spariti. Gli allocatori personalizzati sono una soluzione, l'utilizzo di reserve è un'altra e non passare le cose in base al valore è un terzo, ma questi sono piuttosto semplici e qualsiasi programmatore dovrebbe saperli. Ancora più importante è l'uso di algoritmi. Gli autori di compilatori sanno esattamente cosa fa un for_each () e possono ottimizzare il codice. Ciò non può accadere con un ciclo home rolled. for_each () su un oggetto const è ancora meglio. Microsoft ottimizza for_each in molti modi, inclusa la serializzazione. Hanno anche la libreria AMP che ha parallel_for_each (). Se ne hai la possibilità, parla con gli ingegneri del compilatore. I compilatori di console ottimizzeranno ciò che viene utilizzato, quindi un po 'di problema con pollo e uova. Microsoft sta andando molto pesante con C ++ 11 e il prossimo XBox non sarà diverso. Non ho idea di PS4, non ne abbiamo ancora uno.

Gli allocatori personalizzati sono un modo per gestire il problema di memoria, ma un'altra opzione (spesso trascurata) è quella di utilizzare il nuovo ed elimina basato sulla classe. In questo modo si possono ottenere enormi aumenti delle prestazioni.

L'idea che Boost e STL abbiano una visione ristretta della risoluzione dei problemi è pura follia. Sono sbalordito da quante cose in STL e Boost sono personalizzabili attraverso tratti e politiche. Cerca un confronto tra maiuscole e minuscole come esempio.

Per quanto riguarda i tempi di collegamento lunghi e il bloat del codice, il nuovo modello extern dovrebbe aiutare in questo. Generalmente trovo che i tempi di compilazione lunghi derivino dall'accoppiamento eccessivo e dall'uso improprio di pch.

Il motivo più convincente per utilizzare STL su homespun è che ci sono milioni di persone che possono aiutarti con l'STL. Come sempre, non ottimizzare prematuramente e testare, testare, testare.

Questo è un argomento caldo nello sviluppo del gioco. Personalmente non lo consiglio, tranne forse per l'EASTL come menzionato sopra. Ho due problemi principali con STL (tecnicamente "The C ++ Standard Library", poiché STL non è più il nome) nei giochi. 1) L'allocazione dinamica della memoria spesso spreca molto tempo di esecuzione nei giochi quando si utilizza STL. 2) L'uso di STL incoraggia un approccio di array di strutture all'architettura di gioco, mentre un approccio di struttura di array è molto più intuitivo per la cache.

Dipende. Quanto è grande il progetto, quale piattaforma (e) e quale è la sequenza temporale?

Se stai lavorando su un grande progetto, su piattaforme con risorse limitate, con una linea temporale e un budget significativi, puoi risparmiare un sacco di problemi evitando l'inevitabile inferno che guarderà una base di codice di mezzo milione di righe che è disseminato di STL, non può mantenere un framerate superiore a 30, mangia abbastanza RAM per adattarsi a molte altre risorse e richiede 2 ore per essere costruito.

In altre situazioni, tuttavia, STL e persino Boost possono essere molto utili se applicati in modo appropriato. Ho lavorato su titoli che utilizzavano una selezione di STL / Boost ed erano un sogno assoluto per cui codificare: meno bug / perdite e codice facile da mantenere significa più tempo per scrivere nuove divertenti funzioni! Soprattutto per i progetti di hobby, questa è una grande vittoria nel settore della motivazione.

Scopri quando scambiare le prestazioni per comodità!

IMHO direi che è una buona scelta poiché STL funziona già bene ed è ottimizzata per i compiti per cui è stata realizzata. Inoltre, stai lavorando a un gioco, quindi usa gli strumenti che hai a portata di mano che ti semplificano la vita e che il tuo codice è meno soggetto a bug.

Perché preoccuparsi di reinventare la ruota quando puoi lavorare su qualcos'altro come l'intelligenza artificiale del gioco, l'esperienza utente o ancora meglio; test e debug?

STL è assolutamente perfetto per l'uso nei giochi, purché tu lo capisca bene. Il nostro motore ne fa un uso piuttosto esteso e non è mai stato un problema. Non ho alcuna esperienza con lo sviluppo della console, che potrebbe essere una storia completamente diversa, ma è ben supportato su tutte le piattaforme PC (Windows / Mac / Linux).

La cosa più importante è capire quali sono i punti di forza e di debolezza di ogni tipo di contenitore e scegliere il contenitore corretto per il lavoro che stai facendo.

Il mio ex datore di lavoro è passato dall'uso di un solido set di classi di container personalizzate a STL. I tempi di costruzione sono aumentati e la facilità di debug è diminuita, entrambi in modo piuttosto significativo. Se avessimo iniziato da zero, STL (forse meglio utilizzato) avrebbe probabilmente avuto senso, ma non mi è mai stato chiaro che abbiamo ottenuto qualcosa nel passaggio a STL che giustificherebbe il lancio di codice funzionante, veloce e di debug.

Per i miei progetti personali, se STL si adatta o meno dipende dal progetto. Se sto provando a fare un lavoro ottimizzato per l'accesso ai dati e alla cache in stile Mike Acton, penserò almeno a far rotolare le mie strutture di dati personalizzate. Se sto prototipando alcuni algoritmi o gameplay e non mi preoccupo di prestazioni, scalabilità, piattaforma di destinazione, ecc. Prenderò automaticamente STL.

I miei 2 centesimi su questo è che l'STL funziona perfettamente. Ho sviluppato un motore di gioco 3D (non di qualità AAA, ma abbastanza avanzato: tipi di entità con script, renderer differito, fisica Bullet integrata) per PC e non ho ancora visto i contenitori diventare il principale collo di bottiglia. L'utilizzo errato dell'API 3D e gli algoritmi scadenti sono stati gli obiettivi migliori (determinati dalla profilazione!) Ogni volta che sono entrato e ho cercato di ottenere un po 'più di prestazioni.

Ho creato giochi usando STL e mi piace, e sembra funzionare bene.

Buona domanda! Una domanda più specifica è quali sono alcuni requisiti comuni che un gioco avrebbe che non può essere soddisfatto con STL e Boost.

Nella mia esperienza, i rigidi limiti di memoria dell'hardware della console rendono qualsiasi tipo di contenitore di dimensioni dinamiche una cattiva idea indipendentemente da quanto sia intelligente l'allocatore personalizzato. I contenitori che non hanno limiti deliberati incoraggiano i programmatori a scrivere codice che non limiti i limiti dei loro set di dati. A seconda delle innumerevoli variabili che sono difficili da tracciare, potresti superare i limiti di memoria. Ho la sensazione che questa sia una delle principali cause di instabilità nei giochi moderni.

Inoltre, l'uso eccessivo di modelli può portare a tempi di compilazione molto lunghi in una base di codice di grandi dimensioni e gonfia le dimensioni dell'eseguibile in modo che non si adatti più alla cache, per esempio, di un nucleo ausiliario su una ps3.

Tuttavia, per lo sviluppo solo su PC penso che STL e Boost siano molto buoni. Sebbene le soluzioni del caso generale non siano sempre ideali, spesso sono abbastanza buone. La tua prima soluzione a un problema non è quasi mai l'ideale e tu migliora o sostituisci le inadeguatezze fino a quando non è abbastanza buono.

L'STL è adatto per il tuo gioco se l'STL è adatto per il tuo gioco.

Come per tutte le scelte tecnologiche fatte durante lo sviluppo, è necessario valutare i pro ei contro: il rotolamento della mia libreria mi offrirà un utilizzo della memoria, prestazioni e produttività più vantaggioso rispetto al semplice utilizzo dell'STL? Possibilmente; sebbene sia altrettanto facile creare vectorun'implementazione che utilizza più memoria, è più lenta e richiede grandi quantità di manutenzione per rimanere funzionale rispetto a ciò che già esiste.

Le persone non dovrebbero evitare di usare l'STL nei loro giochi perché altre persone evitano di usare l'STL nei giochi; dovrebbero evitare di usarlo se hanno valutato tutte le loro opzioni e credono sinceramente che un'altra implementazione migliorerà la qualità del loro prodotto.

Come per la maggior parte delle domande, la risposta non è mai "sì o no", bianco o nero. STL è adatto per alcuni problemi, usarlo per quei problemi dovrebbe andare bene. È un errore presumere che sia inutile, ma è anche un errore presumere che sia opportuno utilizzarlo in ogni situazione.

Il problema più grande a cui prestare attenzione quando si utilizza STL nello sviluppo del gioco è l'allocazione della memoria. Gli allocatori predefiniti di STL non sembrano adattarsi bene alle strategie di allocazione preferite per lo sviluppo del gioco. Naturalmente gli allocatori personalizzati possono essere usati, ma questo rende l'idea meno allettante se stai considerando se aggiungere STL a una base di codice non STL.

Aggiungete a ciò che se la vostra base di codice non è STL, potreste non avere abbastanza familiarità con i concetti STL o template per implementare correttamente gli allocatori personalizzati.

Penso che questa discussione possa essere riassunta come segue:

codice specifico per l'applicazione scritto in modo mediocre <codice per scopi generici ben scritto <codice specifico per l'applicazione ben scritto

Chiunque la cui soluzione di coltivazione domestica rientri nella categoria 3 sicuramente conosce la risposta alla domanda originale per il loro problema specifico. Lo STL rientra nella categoria 2. Quindi, per qualcuno che ha bisogno di porre la domanda, "dovrei io usare lo STL", la risposta è probabilmente sì.

STL è perfetto per l'uso su un PC, perché il suo avanzato sistema di memoria virtuale rende la necessità di un'attenta allocazione della memoria un po 'meno cruciale (anche se si deve ancora stare molto attenti). Su una console, con strutture di memoria virtuale limitate o assenti e costi esorbitanti di mancata memorizzazione nella cache, è probabile che tu stia meglio scrivendo strutture di dati personalizzate che hanno pattinazioni prevedibili e / o limitate di allocazione della memoria. (E certamente non andrai molto male facendo lo stesso su un progetto di gioco per PC.)

Penso che questa domanda sia davvero una domanda più grande e non posta - dovrei usare X nella mia Y ? E l'unico modo per rispondere veramente è provarlo tu stesso. Per ogni persona che trovi che dice che X funziona alla grande, troverai qualcuno che dice che è orribile. Ed entrambi sono giusti - per il loro progetto.

La cosa grandiosa del software, a differenza della maggior parte delle altre discipline, è che puoi sempre cambiare le cose in seguito se scopri che non funziona come vorresti. Scopri in seguito che STL non funziona per te in questo progetto? Strappalo, metti qualcos'altro al suo posto. Non ti piace come hai diviso i compiti tra i tuoi oggetti? Refactor. Non ti piace che hai usato oggetti? Sostituiscili con metodi C diritti. Non ti piace che tutto venga archiviato in strutture e metodi per manipolarli? Sostituiscili con oggetti C ++.

Dico no allo STL. La mia ragione è abbastanza semplice:

1. Non è necessario l'STL per scrivere giochi. Neanche quelli grandi.
2. STL aumenta notevolmente i tempi di compilazione.
3. I tempi di compilazione di grandi dimensioni comportano meno iterazioni sullo sviluppo.

Ritengo che il conteggio delle iterazioni sia della massima importanza, quindi sto solo alla larga dalla STL e da qualsiasi altra tecnica di sviluppo che rallenta le iterazioni (come l'architettura per il gusto di farlo, o i linguaggi di script che devono essere compilati).

Le costose iterazioni portano a enormi team di sviluppo di persone che cercano di fare cose con pochissimo successo. L'ho visto e ascoltato, e uno dei colpevoli sembra essere tempi di compilazione per le librerie di modelli.