Ereditarietà vs composizione

Guadagno i miei soldi in C # Generalmente in quella lingua mi piace disaccoppiare tutto con il cielo usando le interfacce. Questo mi è servito bene nel codice aziendale, ma nella scrittura di giochi in C # mi ritrovo a tendere all'eredità a causa della capacità di definire alcuni comportamenti predefiniti per le classi di base. Mi sento sporco mentre faccio questo, come se disobbedissi a un dio dell'architettura che una volta disse "favorisci la composizione sull'eredità". So che non è in bianco e nero, ma sento anche che potrei usare le interfacce con un po 'più di lavoro e ottenere all'incirca la stessa cosa.

Cosa fanno le altre persone? L'ereditarietà è l'approccio giusto per i giochi o devo refactoring in alcune interfacce?

L'ereditarietà nei giochi è in realtà una delle peggiori cose che puoi fare, in particolare per quanto riguarda le entità. Leggi questo per il perché. La composizione rispetto all'eredità ti porta molto lontano con i giochi. Per quanto riguarda le altre aree del tuo motore, non importa. Supponiamo ad esempio che tu stia effettuando una chiamata a una sorta di servizio di rete esterno, quindi puoi ereditare un servizio di tipo generico per es. HTTPService e SocketService - proprio come nelle app aziendali a cui sei abituato.

A meno che il gioco è molto semplice, si verrà desidera utilizzare un'entità un'architettura basata su componenti (CBE). L'idea generale è che con le entità, il motivo per cui sono così comunemente composte piuttosto che ereditate è perché non si può sapere fino al runtime quali capacità avrà una data entità. Ad esempio, prendi la nave del giocatore in uno sparatutto spaziale. Non sai fino a un certo punto durante il gioco, quali armi, armature, sistemi (cioè componenti) quel giocatore sta per raccogliere, acquistare, vendere, perdere, aver distrutto, ecc. Quindi l'unico modo realistico per modellarlo è attraverso la composizione dell'oggetto. Il lato positivo in questo scenario è che puoi anche avere nemici completamente personalizzabili, costruiti nello stesso modo, piuttosto che nemici che sono sempre esattamente gli stessi ogni volta che vedi quel tipo di nemico. Quindi, con i CBE, potresti vedere un Martian Freighter e pensare "Ah ha solo minuscoli laser, lo prenderò giù", e di solito questo sarebbe vero, ma quando arrivi nel raggio d'azione improvvisamente ti rendi conto che ha un grosso culo pistola wormhole. Sorpresa sorpresa!

La componentizzazione sta rimuovendo l'accoppiamento implicito della logica, e questo è BUONO.

Per coloro che parlano tedesco un libro interessante: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Uno sguardo più da vicino su quando e perché usare quale architettura può essere trovata qui: /programming/1901251/component-based-game-engine-design

Per quanto mi riguarda, decido la mia architettura in base alle dimensioni del progetto e alla possibilità di estendere o riutilizzare il codice. Perché investire ore e ore nell'architettura di un microprogetto in cui non è possibile utilizzare nuovamente il codice? Allo stesso tempo è possibile terminare il progetto.

Composizione contro componenti I componenti sono fantastici oggetti ma nella maggior parte dei progetti / architetture anche la composizione farà lo stesso (senza sovraccarico basato sui componenti). Dipende da cosa può fornire il tuo sistema di componenti che la composizione non può.

Ad esempio, prendi la nave del giocatore in uno sparatutto spaziale. Non sai fino a un certo punto durante il gioco, quali armi, armature, sistemi (cioè componenti) quel giocatore sta per raccogliere, acquistare, vendere, perdere, aver distrutto, ecc. Quindi l'unico modo realistico per modellarlo è attraverso la composizione dell'oggetto.

tutto ciò era possibile anche senza componenti molto tempo fa