Perché è così male ottimizzare troppo presto?

Dopo aver esaminato un po 'l'ottimizzazione, ho scoperto (letteralmente ovunque) che sembra essere un peccato universalmente riconosciuto per ottimizzare un gioco troppo presto.

Davvero non capisco questo, non sarebbe incredibilmente difficile cambiare alcune delle strutture principali del gioco alla fine, piuttosto che svilupparle la prima volta pensando alle prestazioni?

Aspetto che aspettare che il gioco sia finito ti dirà se hai anche bisogno di ottimizzazioni, ma non dovresti farlo comunque, dopo tutto, potrebbe ampliare la varietà di dispositivi su cui il gioco potrebbe funzionare, il che aumenterebbe il numero di potenziali Giocatori.

Qualcuno potrebbe spiegarmi perché è una cattiva idea ottimizzare troppo presto?

Preambolo:

Nei commenti sono state sollevate alcune obiezioni, e penso che derivino in gran parte da un fraintendimento di ciò che intendiamo quando diciamo "ottimizzazione prematura" - quindi volevo aggiungere un piccolo chiarimento al riguardo.

"Non ottimizzare prematuramente" non significa "scrivere codice che sai essere dannoso, perché Knuth dice che non ti è permesso ripulirlo fino alla fine"

Significa "non sacrificare tempo e leggibilità per l'ottimizzazione fino a quando non sai quali parti del tuo programma hanno effettivamente bisogno di aiuto per essere più veloci". Poiché un programma tipico trascorre la maggior parte del tempo in alcuni colli di bottiglia, investire nell'ottimizzazione di "tutto" potrebbe non ottenere lo stesso incremento di velocità del focalizzare lo stesso investimento solo sul codice del collo di bottiglia.

Ciò significa che, in caso di dubbio , dovremmo:

• Preferisci un codice semplice da scrivere, chiaro da capire e facile da modificare per i principianti

• Verifica se è necessaria un'ulteriore ottimizzazione (di solito eseguendo la profilazione del programma in esecuzione, anche se un commento sotto le note fa le analisi matematiche - l'unico rischio è che devi anche verificare che la tua matematica sia giusta)

Un'ottimizzazione prematura non è :

• Decisioni architettoniche per strutturare il codice in modo tale da adattarsi alle proprie esigenze, scegliendo moduli / responsabilità / interfacce / sistemi di comunicazione appropriati in modo ponderato.

• Semplici efficienze che non richiedono più tempo o rendono più difficile la lettura del codice. Cose come l'uso della digitazione forte possono essere sia efficienti che chiari le tue intenzioni. La memorizzazione nella cache di un riferimento invece di cercarlo ripetutamente è un altro esempio (a patto che il tuo caso non richieda una complessa logica di invalidazione della cache - forse tieni duro a scriverlo fino a quando non avrai profilato nel modo semplice prima).

• Utilizzando l'algoritmo giusto per il lavoro. A * è più ottimale e più complesso della ricerca esaustiva di un grafico di pathfinding. È anche uno standard del settore. Ripetere il tema, attenersi a metodi collaudati come questo può effettivamente rendere il codice più facile da capire rispetto a se si fa qualcosa di semplice ma in contrasto con le migliori pratiche conosciute. Se hai esperienza con i colli di bottiglia nell'implementazione della funzione di gioco X in un modo su un progetto precedente, non è necessario ripetere nuovamente lo stesso collo di bottiglia su questo progetto per sapere che è reale: puoi e dovresti riutilizzare le soluzioni che hanno funzionato in passato Giochi.

Tutti questi tipi di ottimizzazioni sono ben giustificati e generalmente non sarebbero etichettati "prematuri" (a meno che non si stia scendendo in una tana di coniglio implementando un tracciato all'avanguardia per la mappa della scacchiera 8x8 ...)

Quindi ora con quello chiarito, sul perché potremmo trovare questa politica utile nei giochi in particolare:

Soprattutto in gamedev, la velocità di iterazione è la cosa più preziosa. Spesso implementeremo e reimplementeremo molte più idee di quelle che alla fine verranno fornite con il gioco finito, cercando di "trovare il divertimento".

Se riesci a prototipare un meccanico in un modo semplice e forse un po 'ingenuo e testarlo il giorno successivo, sei in una posizione molto migliore rispetto a se trascorri una settimana a crearne prima la versione più ottimale. Soprattutto se si scopre che fai schifo e finisci per lanciare quella funzione. Farlo in modo semplice in modo da poter eseguire i test in anticipo può risparmiare un sacco di lavoro sprecato ottimizzando il codice che non conservi.

Il codice non ottimizzato è anche generalmente più facile da modificare e provare diverse varianti rispetto al codice che è finemente ottimizzato per fare una cosa precisa in modo ottimale, che tende a essere fragile e più difficile da modificare senza romperlo, introdurre bug o rallentarlo. Pertanto, mantenere il codice semplice e facile da modificare spesso vale una piccola inefficienza di runtime durante gran parte dello sviluppo (di solito stiamo sviluppando su macchine al di sopra delle specifiche di destinazione, in modo da poter assorbire l'overhead e concentrarci sull'esperienza di destinazione prima) fino a quando abbiamo bloccato ciò di cui abbiamo bisogno dalla funzione e possiamo ottimizzare le parti che ora sappiamo essere lente.

Sì, il refactoring di parti del progetto in fase avanzata di sviluppo per ottimizzare i punti lenti può essere difficile. Ma lo è anche il refactoring ripetutamente durante lo sviluppo perché le ottimizzazioni apportate il mese scorso non sono compatibili con la direzione in cui il gioco si è evoluto da allora, o stavano risolvendo qualcosa che si è rivelato non essere il vero collo di bottiglia una volta ottenute più funzionalità e contenuti nel.

I giochi sono strani e sperimentali: è difficile prevedere come si evolverà un progetto di gioco e le sue esigenze tecnologiche e dove le prestazioni saranno ridotte. In pratica, finiamo spesso per preoccuparci delle cose sbagliate: cerca tra le domande sulla performance qui e vedrai emergere un tema comune di sviluppatori che vengono distratti da cose su carta che probabilmente non è affatto un problema.

Per fare un esempio drammatico: se il tuo gioco è associato alla GPU (non insolito), tutto quel tempo speso per l'ottimizzazione e il threading del lavoro della CPU potrebbe non produrre alcun beneficio tangibile. Invece, tutte quelle ore di sviluppo avrebbero potuto essere impiegate per implementare e perfezionare le funzionalità di gioco, per una migliore esperienza del giocatore.

Nel complesso, la maggior parte del tempo che passi a lavorare su un gioco non sarà speso per il codice che finisce per essere il collo di bottiglia. Soprattutto quando si lavora su un motore esistente, le cose super costose del circuito interno nei sistemi di rendering e fisica sono in gran parte fuori dalle tue mani. A quel punto, il tuo compito negli script di gioco è sostanzialmente quello di stare alla larga dal motore - fintanto che non ci metti una chiave lì, probabilmente uscirai abbastanza bene per una prima build.

Quindi, a parte un po 'di igiene del codice e budget (ad es. Non cercare / costruire ripetutamente roba se puoi riutilizzarla facilmente, mantieni modeste le tue ricerche di pathfinding / fisica o i readback della GPU, ecc.), Prendendo l'abitudine di non esagerare -ottimizzare prima di sapere dove sono i veri problemi si rivela positivo per la produttività - salvarci dal perdere tempo a ottimizzare le cose sbagliate e mantenere il nostro codice più semplice e facile da modificare nel complesso.

nota: questa risposta è iniziata come un commento sulla risposta di DMGregory, e quindi non duplica gli ottimi punti che fa.

"Non sarebbe incredibilmente difficile cambiare alcune delle strutture principali del gioco alla fine, piuttosto che svilupparle la prima volta pensando alle prestazioni?"

Questo, per me, è il nocciolo della domanda.

Quando crei il tuo design originale, dovresti provare a progettare per l'efficienza, al massimo livello. Questa è meno ottimizzazione e riguarda più la struttura.

Esempio:
è necessario creare un sistema per attraversare un fiume. I disegni ovvi sono un ponte o un traghetto, quindi quale scegli?
La risposta ovviamente dipende dalle dimensioni della traversata e dal volume del traffico. Questa non è un'ottimizzazione, ma inizia invece con un design adatto al tuo problema.

Quando ti vengono presentate scelte di design, scegli quella più adatta a ciò che vuoi fare.

Quindi, supponiamo che il nostro volume di traffico sia piuttosto basso, quindi decidiamo di costruire due terminali e acquistare un traghetto per gestire il traffico. Una semplice implementazione semplice
Sfortunatamente, una volta installato e funzionante, scopriamo che sta vedendo più traffico del previsto. Dobbiamo ottimizzare il traghetto! (perché funziona e costruire un ponte ora non è un buon piano)

Opzioni:

• Acquista un secondo traghetto (elaborazione parallela)
• Aggiungi un altro ponte auto al traghetto (compressione del traffico)
• Aggiorna il motore del traghetto per renderlo più veloce (algoritmi di elaborazione riscritti)

Qui è dove dovresti cercare di rendere il tuo design originale il più modulare possibile.
Tutti i precedenti sono possibili ottimizzazioni e potresti persino fare tutti e tre.
Ma come si apportano questi cambiamenti senza grandi cambiamenti strutturali?

Se hai un design modulare con interfacce chiaramente definite, dovrebbe essere semplice implementare queste modifiche.
Se il codice non è strettamente accoppiato, le modifiche ai moduli non influiscono sulla struttura circostante.

Diamo un'occhiata all'aggiunta di un traghetto extra.
Un programma "cattivo" potrebbe essere costruito attorno all'idea di un singolo traghetto e avere gli stati del molo e lo stato del traghetto e posizionare tutti raggruppati insieme e condividendo lo stato. Questo sarà difficile da modificare per consentire l'aggiunta di un ulteriore traghetto al sistema.
Un progetto migliore sarebbe quello di avere le banchine e il traghetto come entità separate. Non c'è alcun accoppiamento stretto tra loro, ma hanno un'interfaccia, in cui un traghetto può arrivare, scaricare passeggeri, prenderne di nuovi e partire. Il dock e il traghetto condividono solo questa interfaccia e ciò semplifica le modifiche al sistema, in questo caso aggiungendo un secondo traghetto. Al dock non importa cosa siano effettivamente i traghetti, tutto ciò che riguarda è che qualcosa (qualsiasi cosa) stia usando la sua interfaccia.

tl; dr:

• Prova a progettare per l'efficienza in primo luogo.
• Quando ti vengono presentate due opzioni, scegli quella più efficiente.
• Scrivi il tuo codice nel modo più modulare possibile con interfacce ben definite.

È quindi possibile modificare i meccanismi all'interno di ciascun modulo senza ristrutturare l'intera base di codice quando è necessario ottimizzare.

"Non ottimizzare in anticipo" non significa "scegliere il modo peggiore possibile per fare le cose". Devi ancora considerare le implicazioni delle prestazioni (a meno che tu non stia solo prototipando). Il punto non è quello di paralizzare altre cose più importanti a quel punto nello sviluppo - come la flessibilità, l'affidabilità, ecc. Scegli ottimizzazioni semplici e sicure - scegli le cose che limiti e le cose che mantieni libere; tenere traccia dei costi. Dovresti usare la tipizzazione forte? La maggior parte dei giochi funzionava bene; quanto ti costerebbe rimuoverlo se trovassi interessanti usi della flessibilità per il gamemplay?

È molto più difficile modificare il codice ottimizzato, in particolare il codice "intelligente". È sempre una scelta che rende alcune cose migliori e altre peggiori (ad esempio, potresti scambiare il tempo della CPU per l'utilizzo della memoria). Quando fai questa scelta, devi essere consapevole di tutte le implicazioni: potrebbero essere disastrose, ma possono anche essere utili.

Ad esempio, il comandante Keen, Wolfenstein e Doom sono stati ciascuno costruito su un motore di rendering ottimizzato. Ognuno aveva il suo "trucco" che consentiva al gioco di esistere in primo luogo (ognuno aveva anche ulteriori ottimizzazioni sviluppate nel tempo, ma non è importante qui). Va bene . Va bene ottimizzare fortemente il nocciolo del gioco, il pensiero che rende possibile il gioco; soprattutto se stai esplorando nuovi territori in cui questa particolare funzionalità ottimizzata ti consente di prendere in considerazione progetti di gioco che non sono stati molto esplorati. Le limitazioni introdotte dall'ottimizzazione possono offrire anche un gameplay interessante (ad esempio, i limiti di conteggio delle unità nei giochi RTS potrebbero essere iniziati come un modo per migliorare le prestazioni, ma hanno anche un effetto di gameplay).

Ma nota che in ciascuno di questi esempi, il gioco non potrebbe esistere senza l'ottimizzazione. Non hanno iniziato con un motore "completamente ottimizzato", hanno iniziato con la nuda necessità e sono saliti su. Stavano sviluppando nuove tecnologie e le stavano usando per creare giochi divertenti. E i trucchi del motore erano limitati alla minima parte possibile della base di codice: le ottimizzazioni più pesanti venivano introdotte solo quando il gameplay era per lo più fatto, o dove permetteva l'emergere di una nuova interessante funzionalità.

Ora considera un gioco che potresti voler creare. C'è davvero qualche miracolo tecnologico che fa o distrugge quel gioco? Forse stai immaginando un gioco open world su un mondo infinito. È davvero il pezzo centrale del gioco? Il gioco semplicemente non funzionerebbe senza di esso? Forse stai pensando a un gioco in cui il terreno è deformabile senza limiti, con geologia realistica e simili; puoi farlo funzionare con un ambito più piccolo? Funzionerebbe in 2D anziché in 3D? Divertiti al più presto - anche se le ottimizzazioni potrebbero richiedere di rielaborare un grosso pezzo del tuo codice esistente, potrebbe valerne la pena; e potresti persino capire che rendere le cose più grandi non migliora il gioco.

Come esempio di un gioco recente con molte ottimizzazioni, vorrei indicare Factorio. Una parte fondamentale del gioco sono le cinture: ce ne sono molte migliaia e trasportano molti singoli pezzi di materiale in tutta la tua fabbrica. Il gioco è iniziato con un motore a cinghia fortemente ottimizzato? No! In effetti, il design originale della cintura era quasi impossibile da ottimizzare - in un certo senso ha fatto una simulazione fisica degli oggetti sulla cintura, che ha creato alcune cose interessanti che potresti fare (questo è il modo in cui ottieni un gameplay "emergente" - gameplay che sorprende il designer), ma significava che dovevi simulare ogni singolo oggetto della cintura. Con migliaia di cinture, ottieni decine di migliaia di articoli simulati fisicamente: anche solo rimuovendola e lasciando che le cinture facciano il lavoro, puoi ridurre il tempo della CPU associato del 95-99%, anche senza considerare cose come la località di memoria. Ma è utile farlo solo quando si raggiungono effettivamente questi limiti.

Praticamente tutto ciò che aveva a che fare con le cinture doveva essere rifatto per consentire l'ottimizzazione delle cinture. E le cinture dovevano essere ottimizzate, perché avevi bisogno di molte cinture per una grande fabbrica e le grandi fabbriche sono un'attrazione del gioco. Dopotutto, se non puoi avere grandi fabbriche, perché avere un mondo infinito? Divertente che dovresti chiedere - le prime versioni no :) Il gioco è stato rielaborato e rimodellato molte volte per arrivare dove sono ora - incluso un rifacimento al 100% quando hanno realizzato che Java non è la strada da percorrere per un gioco come questo e passato a C ++. E ha funzionato alla grande per Factorio (anche se era comunque una buona cosa non è stato ottimizzato fin dall'inizio - soprattutto perché si trattava di un progetto di hobby, che altrimenti avrebbe potuto fallire semplicemente per mancanza di interesse).

Ma il fatto è che ci sonomolte cose che puoi fare con una fabbrica di portata limitata - e molti giochi hanno dimostrato proprio questo. I limiti possono essere ancora più potenti per il divertimento delle libertà; Spacechem sarebbe più divertente se le "mappe" fossero infinite? Se avessi iniziato con "cinture" fortemente ottimizzate, saresti praticamente costretto ad andare in quel modo; e non puoi esplorare altre direzioni di progettazione (come vedere quali cose interessanti puoi fare con i nastri trasportatori simulati dalla fisica). Stai limitando il tuo potenziale spazio di progettazione. Potrebbe non sembrare così perché non vedi molti giochi incompiuti, ma la parte difficile è ottenere il divertimento giusto - per ogni gioco divertente che vedi, probabilmente ce ne sono centinaia che semplicemente non potevano arrivarci e venivano scartati (o peggio, rilasciato come disastri orribili). Se l'ottimizzazione ti aiuta a farlo, vai avanti. Se non lo fa ... è probabilmente prematuro. Se ritieni che alcune meccaniche di gioco funzionino alla grande, ma hanno bisogno di ottimizzazioni per brillare davvero, vai avanti. Se non hai meccaniche interessanti,non ottimizzarli . Trova prima il divertimento: scoprirai che la maggior parte delle ottimizzazioni non ti aiutano e spesso sono dannose.

Finalmente hai un gioco fantastico e divertente. Ha senso ottimizzare adesso ? Ha! Non è ancora chiaro come potresti pensare. C'è qualcosa di divertentepuoi fare invece? Non dimenticare che il tuo tempo è ancora limitato. Tutto richiede uno sforzo e tu vuoi concentrarlo su ciò che conta di più. Sì, anche se stai realizzando un "gioco gratuito" o un gioco "open source". Guarda come si gioca; notare dove la performance diventa un collo di bottiglia. L'ottimizzazione di questi luoghi rende più divertente (come costruire fabbriche sempre più grandi, sempre più intricate)? Ti consente di attirare più giocatori (ad es. Con computer più deboli o su piattaforme diverse)? Devi sempre stabilire le priorità: cerca lo sforzo per raggiungere il rapporto. Probabilmente troverai un sacco di frutta a basso consumo solo giocando e guardando gli altri mentre giocano. Ma nota la parte importante: per arrivarci, hai bisogno di un gioco . Concentrati su quello.

Come una ciliegina sulla torta, considera che l'ottimizzazione non finisce mai. Non è un'attività con un piccolo segno di spunta che termina e passa ad altre attività. C'è sempre "un'altra ottimizzazione" che puoi fare e gran parte di ogni sviluppo è capire le priorità. Non si esegue l'ottimizzazione per motivi di ottimizzazione - lo si fa per raggiungere un obiettivo particolare (ad esempio "200 unità sullo schermo contemporaneamente su un Pentium a 333 MHz" è un grande obiettivo). Non perdere la traccia dell'obiettivo terminale solo perché ti concentri troppo sugli obiettivi intermedi che potrebbero non essere più nemmeno prerequisiti per l'obiettivo terminale.

Molte delle risposte sembrano concentrarsi molto sull'aspetto prestazionale dell '"ottimizzazione", mentre a me piace guardare l'ottimizzazione e l'intera prova dell'ottimizzazione troppo presto a un livello più astratto.

Umorizzami mentre cerco di elaborare la mia prospettiva con l'aiuto dei poliomino.

Supponiamo di avere dei limiti fissi stabiliti dal framework o dal motore con cui stiamo lavorando.

Quindi procediamo a creare il nostro primo strato / modulo del gioco in questo modo.

Andando avanti costruiamo il nostro secondo strato / modulo.

A questo punto, potremmo notare che c'è uno spazio disponibile tra i due moduli e potremmo essere tentati di ottimizzarlo per sfruttare appieno i confini che ci sono stati assegnati.

Perfetto, ora l'applicazione sta sfruttando appieno le risorse a nostra disposizione, l'applicazione è migliore, va bene?

Procediamo a costruire il terzo strato / modulo della nostra applicazione e improvvisamente arriviamo alla realizzazione (forse anche uno che non avremmo potuto prevedere durante la pianificazione iniziale) che il 3 ° strato / modulo non funziona per noi.

Cerchiamo un'alternativa, ne troviamo una e, alla fine, ciò richiede anche che cambiamo il secondo modulo della nostra applicazione poiché è incompatibile con il nostro terzo modulo appena selezionato. (Per fortuna è in qualche modo compatibile con il nostro primo modulo, quindi non dobbiamo riscrivere tutto da zero.)

Quindi abbiamo messo tutto insieme ...

Vedi cosa è successo?

Ottimizzando troppo presto ora abbiamo effettivamente peggiorato le cose dal punto di vista dell'efficienza, dal momento che ciò che abbiamo ottimizzato non è quello con cui siamo finiti.

E se avessimo voluto aggiungere alcuni moduli aggiuntivi o bocconcini in seguito, potremmo non avere più la capacità di farli a questo punto.

E regolare il livello più basso del nostro sistema non è più così fattibile poiché è stato sepolto sotto tutti gli altri livelli.

Se, tuttavia, avessimo deciso di attendere con il nostro bisogno di ottimizzarlo immediatamente, saremmo finiti con qualcosa del genere:

E ora se eseguiamo l'ottimizzazione a questo punto otteniamo qualcosa di soddisfacente da guardare.

Spero che almeno alcuni di voi si siano divertiti a leggere questo quanto mi sono divertito a farlo :) e se ora avete la sensazione di avere una migliore comprensione dell'argomento - tanto meglio.

I soldi.

Dipende da quello. I soldi. Dato che il tempo è denaro *, maggiore è il tempo che dedichi ad attività che non sono garantite per generare più denaro (ovvero non puoi considerare queste attività come investimenti ), più soldi rischi di sprecare e meno soldi farai con il gioco.

Ecco alcuni altri potenziali effetti collaterali dell'ottimizzazione troppo precoce e motivi per cui dovresti evitarlo:

• I tuoi colleghi ti odiano perché giochi nella tua sandbox con i tuoi giocattoli mentre lavorano sodo per ottenere funzionalità.
• I ritardi non piacciono al management superiore e fanno perdere al team le date di consegna, il che provoca il rilascio del gioco in primavera anziché prima delle festività, il che a sua volta non fa vendere abbastanza il gioco. E per questo motivo, la sede centrale decide di chiudere lo studio, rendendoti effettivamente senza lavoro. E nessun lavoro significa niente soldi. (E poiché non piaci a nessuno perché hai trascorso troppo tempo a fare l'ottimizzazione precoce, nessuno vuole scrivere una recensione positiva sul tuo lavoro per te su LinkedIn, che ti terrà senza soldi per un tempo più lungo.)

^{* Altre risposte hanno evidenziato abbastanza bene la parte "tempo"}

Come nota a margine, in generale , l'esperienza aiuta a determinare cosa è e cosa non è ottimizzazione prematura e cosa ha valore per l'azienda e cosa no.

Ad esempio, se hai lavorato sul gioco A e ti sei reso conto alla fine del progetto che la funzione XYZ era particolarmente pesante nel tuo ciclo di gioco e alla fine inizi a lavorare sul gioco B che ha la stessa identica funzione, decidendo di riscrivere la funzionalità e ottimizzarla dall'inizio non è in realtà un'ottimizzazione prematura, dato che sai che sarà un collo di bottiglia se non si fa nulla.

L'ottimizzazione è, per definizione, il processo di aumento dell'efficienza di una soluzione fino al punto in cui perde la sua efficacia. Questo processo implica quindi una riduzione dello spazio della soluzione.

In una fase iniziale di sviluppo del software possono esserci ancora "requisiti nascosti": se si riduce troppo lo spazio della soluzione, si potrebbe finire in una situazione in cui non si è in grado di soddisfare un "requisito nascosto" quando si apre in una fase successiva di sviluppo, costringendoti quindi a modificare l'architettura aggiungendo in questo modo instabilità e un possibile gruppo di comportamenti indesiderati.

L'idea è quindi di far funzionare l'intera soluzione e solo allora, quando tutti i requisiti sono fissi e implementati, stringono il codice. Vedrai quindi che molte ottimizzazioni che avresti implementato con leggerezza contemporaneamente durante la codifica, ora non sono più realizzabili a causa dell'interazione con requisiti tardivi.

Lo spazio reale della soluzione è sempre più grande di quello che ci aspettiamo all'inizio perché non possiamo avere una perfetta conoscenza di un sistema molto complesso.

Fallo funzionare prima. Quindi stringere le corde.

In breve, molto spesso l'ottimizzazione precoce diventa uno sforzo sprecato se si desidera cambiare le cose in seguito, e poi si scopre di aver ottimizzato le strutture di codice facilmente modificabili in qualcosa di livello molto più basso, e ora è necessario riportarlo ad un livello elevato approccio di livello e ottimizzazione del risultato ancora una volta.

Questo è un errore comune per gli sviluppatori principianti a cui piace concentrarsi sul piacere di "aver fatto un lavoro utile", come l'ottimizzazione, non pensare a se è il momento giusto per farlo. Man mano che acquisisci esperienza nella programmazione di grandi progetti come i giochi, imparerai quando è garantito l'ottimizzazione della base di codice esistente e quando è troppo presto. Non abbiate paura di fare questo errore, ne trarrete beneficio solo imparando da esso.

In generale, ottimizza solo se non puoi davvero lavorare con la build di sviluppo in questo momento. Ad esempio, se stai creando ed eliminando milioni di oggetti 60 volte al secondo.

Quindi, direi che è buono, in termini di esperienza di apprendimento, ottimizzare presto alcune volte: p

L'ottimizzazione si concentra su come far funzionare meglio il computer sul codice mentre lo sviluppo richiede che il programmatore funzioni meglio sul codice.

L'ottimizzazione non fa emergere approfondimenti. Fa lavorare meno il computer e il programmatore di più.

Certo, ci sono diverse categorie, come nel progettare un'auto. Non c'è niente di male nell'ottimizzare un motore prima di costruire il tuo primo telaio, ma l'ottimizzazione del telaio prima di non conoscere la forma del motore potrebbe far perdere tempo. Modularità e specifiche possono rendere fattibile un certo numero di posti per il lavoro di ottimizzazione ancor prima che il prodotto nel suo insieme venga assemblato.

Sono fortemente in disaccordo con tutte queste affermazioni secondo cui il codice non dovrebbe essere ottimizzato nelle fasi iniziali. Dipende da quale fase sei. Se questo è MVP - prototipo e stai solo cercando di guardare il gioco che dura da 1 a 2 settimane, sei pronto a riscrivere tutto ciò che hai già scritto. Sì, l'ottimizzazione non ha importanza. Ma se stai già lavorando su un gioco che sai che verrà rilasciato, dovrebbe avere sempre un codice ottimizzato. Le storie che la gente dice su nuove funzionalità e cose che potrebbero essere aggiunte è un errore di concezione. È un'architettura di codice mal progettata piuttosto che un codice ottimizzato. Non è necessario riscrivere nulla per aggiungere nuovi elementi se si dispone di un buon design del codice.

Ad esempio, se si dispone di un algoritmo di pathfinding A *, non sarebbe meglio scriverlo nel modo più ottimale possibile? Invece di cambiare la metà del codice che hai in seguito perché hai dovuto apportare alcune modifiche all'algoritmo perché ora ha bisogno di un altro metodo per chiamate e callback? E se hai già un codice ottimizzato dall'inizio ti farà risparmiare un sacco di tempo. Perché puoi disegnare te stesso le relazioni tra gli oggetti e il modo in cui interagiscono, invece di creare ciecamente tonnellate di nuovi script e creare immediatamente tutte le connessioni - questo porta a un codice sphagetti poco chiaro.

L'ultima cosa che voglio aggiungere è che in seguito, anche se non vuoi più creare il gioco, hai il tuo algoritmo A * ottimizzato che puoi usare per i tuoi prossimi giochi. Riusabilità. Ad esempio, molti giochi hanno inventario, ricerca di percorsi, generazione procedurale, interazioni tra PCN, sistema di combattimento, AI, Interazione interfaccia, gestione input. Ora dovresti chiederti: "Quante volte ho riscritto quegli elementi da zero?" Sono il 70-80% del gioco. Hai davvero bisogno di riscriverli tutto il tempo? E se non fossero ottimizzati?