XNA GameComponent Implementation Preferences ...?

Question

Ho recentemente fatto un salto nel pool XNA e sto imparando tutti i dettagli del framework in C#. Una cosa che ho notato nella mia ricerca è che non sembra esserci un modo "corretto" ampiamente accettato di implementare GameComponents.

Dopo aver letto this thread (tra gli altri), ho scoperto un ampio spettro di preferenze tra gli sviluppatori di giochi. Ho visto alcuni sostenitori che non usano affatto GameComponents (o solo con parsimonia), mentre altri sostengono di usarli per tutto, fino al giocatore/unità nemiche, missili, ecc. Poi ci sono alcuni che prendono un moderato approccio e riserva l'architettura GameComponent per entità di medio-alto livello come schermi, renderer, scene, ecc. che a loro volta contengono e guidano le loro unità di gioco più granulari.

Alla fine della giornata, è compito dello sviluppatore del gioco determinare il modo migliore per implementare il framework. Dal momento che StackOverflow è pieno di sviluppatori esperti che hanno dimenticato più di quanto io possa mai sapere, mi piacerebbe avere un'idea di ciò che il consenso è qui prima di continuare su questa strada con il mio uso del framework.

Qualcuno deve preoccuparsi di ascoltare i propri pensieri? Grazie in anticipo!

Answer 1

Sono abbastanza nuovo per XNA, quindi prendi questa risposta con un pizzico di sale.

Penso che possa ridursi a una preferenza di stile. Non sono sicuro delle caratteristiche prestazionali tra l'uso di GameComponent e altri modi manuali, ma so che per me, personalmente, sono diventato rapidamente frustrato nel cercare di utilizzare GameComponent perché non si adattava perfettamente al mio modo di pensare o di programmare. In fondo sono un mix di cose che ho raccolto da OOP, procedurale, funzionale e altri paradigmi di programmazione. GameComponent sembra utilizzare un approccio OOP rigoroso.

Ma direi che rendere tutto un GameComponent, o anche una classe in generale, può diventare problematico per quanto riguarda le prestazioni. Le domande di massima leggibilità e manutenibilità sembrano essere sul filo del rasoio nel mondo dello sviluppo del gioco, dove a volte devi solo spremere l'ottimizzazione dal tuo codice. Ad esempio, a volte è meglio trasformare uno dei tuoi oggetti di gioco in una struct (value-type) in modo da poter salvare un po 'di memoria e fermare il fastidioso garbage collector dal rallentare il gioco (come ho imparato in this question I asked).