Quali sono alcuni modelli di progettazione di programmazione utili nello sviluppo di giochi? [chiuso]

Ora per una risposta meno impertinente, con alcuni suggerimenti. Non prenderli come consigli di implementazione, più come esempi di possibile utilizzo.

• Builder: imposta lentità basata su componenti un componente alla volta, in base ai dati
• Metodo di fabbrica: crea NPC o widget GUI basati su una stringa letta da un file
• Prototipo: memorizza un carattere “Elfo” generico con le proprietà iniziali e crea istanze di Elf clonandolo.
• Singleton: questo spazio deliberatamente lasciato vuoto.
• Adattatore: incorpora una libreria di terze parti facoltativa inserendola in un livello che assomiglia al tuo codice esistente. Molto utile con le DLL.
• Composito: crea un grafico di scena di oggetti renderizzabili o crea una GUI da un albero di widget
• Facade: semplifica complesse librerie di terze parti fornendo uninterfaccia più semplice per semplificarti la vita in seguito.
• Peso mosca: memorizza gli aspetti condivisi di un NPC (es. modelli, trame, animazioni) separatamente dai singoli aspetti (es. posizione, salute) in a modo più trasparente
• Proxy: crea piccole classi su un client che rappresentano classi più grandi e complesse su un server e inoltra le richieste tramite la rete.
• Catena di responsabilità: gestisci linput come una catena di gestori, ad es. tasti globali (es. per schermate), poi la GUI (es. nel caso in cui una casella di testo sia focalizzata o un menu sia in alto), poi il gioco (es. per spostare un personaggio)
• Comando: incapsula le funzionalità del gioco come comandi che possono essere digitati in una console, archiviati e riprodotti, o anche scriptati per aiutare a testare il gioco
• Mediatore: implementa entità di gioco come una piccola classe mediatore che opera su componenti differenti (es. lettura dal componente salute per passare i dati al componente AI)
• Observer: avere la rappresentazione renderizzabile di un personaggio ascoltare gli eventi dalla rappresentazione logica, al fine di cambiare la presentazione visiva quando necessario senza la logica del gioco ha bisogno di sapere qualcosa sul rendering del codice
• Stato: memorizza NPC AI come uno dei diversi stati, ad es. Attaccare, Vagare, Fuggire. Ognuno può avere il proprio metodo update () e qualsiasi altro dato di cui ha bisogno (ad es. Memorizzare da quale personaggio sta attaccando o da cui fugge, larea in cui sta vagando, ecc.)
• Strategia: passa da euristiche diverse per la tua ricerca A *, a seconda del tipo di terreno in cui ti trovi, o forse anche per utilizzare lo stesso framework A * per trovare percorsi e una pianificazione più generica
• Metodo modello: imposta un routine generica di “combattimento”, con varie funzioni di aggancio per gestire ogni passaggio, ad es. decremento delle munizioni, calcolo della probabilità di successo, risoluzione di hit o miss, calcolo del danno e ogni tipo di abilità di attacco implementerà i metodi nel proprio modo specifico

Alcuni schemi tralasciati per mancanza di ispirazione.

Commenti

• È possibile trovare una discussione molto illuminante sui singleton qui: misko.hevery.com / 2008/08/25 / root-cause-of-singleton
• +1 per il pattern Strategy. Lho ' lho usato per lo scopo esatto indicato sopra (inserendo diverse euristiche A *).
• grazie per questa risposta, quelle suonano più come un modello di progettazione che il solito " singleton " i ' m ascolto ovunque …
• Ottimo elenco di esempi. Nonostante labuso cronico del pattern singleton (stato globale sotto mentite spoglie), ci sono usi legittimi: quando rappresenta una risorsa di cui in realtà ne hai (o ne vuoi) solo una. Può essere qualcosa come il wrapping di hardware (ad es. Tastiera / mouse) o il wrapping di una libreria che non è rientrante (succede, e non tutte le lingue hanno parole chiave di sincronizzazione magiche).
• Non lo farei ancora ' t utilizzare singleton per le risorse hardware – gli elementi che ritieni di ' avranno sempre e solo 1 di tendenza a moltiplicarsi in seguito, proprio come facevano le schede video e i monitor gli anni passarono. Allo stesso modo, in alcune API è necessario leggere 2 joystick per comprendere 1 gamepad. Quindi, ' dico, se hai bisogno solo di qualcosa, creane solo unistanza, non ' t imponi restrizioni arbitrarie che probabilmente aren ' t necessario.

Ho scritto un prenota esattamente questo argomento: Schemi di programmazione del gioco . I capitoli che ci sono potrebbero esserti utili.

Commenti

• +1 Speravo che qualcuno si fosse collegato a quello e vedo che lautore ha! La descrizione dello schema dei componenti è stata piuttosto utile e mi piace che tu provi a utilizzare esempi di codice completi per dimostrarlo.
• Sì, ricordo di aver letto il tuo link alcuni anni fa. Dovresti finire quegli articoli!
• Ora il libro è finito 🙂
• Una risorsa straordinaria che mi ha aiutato a tradurre le mie conoscenze di programmazione esistenti in programmazione per giochi. Grazie per averlo scritto!
• Questa spiegazione dei pattern di programmazione dei giochi mi ha effettivamente aiutato a capire i pattern di design in un modo che nessun libro di pattern design del software ha fatto! Questo è in parte il potere dello sviluppo del gioco (esempi concreti in un linguaggio che mi parla e mi permette di migliorare il mio sviluppo in generale), ma in parte più grande perché la scrittura è eccellente.

Una cosa che Brandon Eich ha avuto il buon senso di sollevare in Coder at Work è che i pattern sono hack e soluzioni alternative: [Patterns] mostrano qualche tipo di difetto nel linguaggio. Questi modelli non sono gratuiti. Non cè pranzo gratis. Quindi dovremmo cercare levoluzione nel linguaggio che aggiunge le parti giuste.

Come programmatori di giochi piuttosto che progettisti di compilatori raramente abbiamo la possibilità di evolvere i linguaggi usiamo, ma possiamo imparare a far evolvere il nostro stile per adattarlo meglio al nostro linguaggio e alle nostre esigenze. I pattern sono alcuni di questi, ma non usare i pattern è unaltra parte, soprattutto perché come dice Brandon, i pattern raramente vanno senza un notevole costo in termini di prestazioni o memoria o agilità del codice. MVC non è un ottimo modello per molte cose nei giochi. Singleton è una soluzione alternativa per le regole di inizializzazione statica C ++ scadenti, e probabilmente non dovresti farlo comunque. Factory semplifica la creazione di oggetti complicati: forse i tuoi oggetti dovrebbero essere più semplici per iniziare. I modelli popolari sono strumenti a cui ricorrere quando ne abbiamo bisogno per gestire qualcosa di complesso, non strumenti che dovremmo desiderare di utilizzare per costruire qualcosa di complesso allinizio.

Un buon codice (di gioco) potrebbe usare modelli, oppure no. Se utilizza schemi, va bene: sono un ottimo strumento di comunicazione per spiegare la struttura del codice ad altri programmatori a un livello elevato e indipendente dal linguaggio. Se pensi che il codice sia migliore senza usare uno schema, non picchiarti sopra esso – probabilmente lo è.

Commenti

• Sì, una delle cose chiarite nel libro originale (ma spesso trascurato) è che se sono stati scritti per C anziché per C ++ / Smalltalk, avrebbero potuto includere un pattern " Inheritance " e, per lo stesso motivo, alcuni le lingue potrebbero contenere alcuni dei pattern GoF già incorporati.
• Laltra cosa spesso trascurata nel libro originale (il libro originale originale di Alexander, non GoF) era che i pattern sono uno strumento di comunicazione , non implementazione . Consentono ai progettisti di comunicare sullimplementazione a un livello superiore e vengono identificati perché sono ricorrenti, non necessariamente perché dovrebbero essere utilizzati quando possibile.
• Tuttavia, la semplice terminologia può aiutarti a ragionare sul problema e riconoscere quando un tale approccio è una buona soluzione.I modelli migliori sono stati in genere perfezionati nel tempo da lavoratori qualificati ed esperti, e i lavoratori meno qualificati non scopriranno gli stessi modelli senza che ci siano questi esempi codificati.
• Sono daccordo che avere la terminologia è ottimo e parte della definizione di un pattern è che è una buona soluzione ricorrente per qualche problema. Sfortunatamente i lavoratori meno qualificati tendono a trovare principalmente Singleton e ad applicarlo a ogni problema, anche quando non cè ancora un problema.
• Grazie per questa risposta; Mi sento sollevato nel leggere che i design pattern sono fatti per risolvere i problemi creati dal design del software '. Penso che la struttura di un intero grande software dovrebbe essere pensata dallinizio alla fine prima di iniziare effettivamente a codificare qualsiasi cosa. Non puoi ' implementare sempre le funzionalità una volta alla volta, a volte devi pensare a ciascuna funzione particolare e controllare se ha vinto ' Non interferire con la struttura globale del software o semplicemente intralciare il modo in cui il software dovrebbe comportarsi. Dividere i compiti tra più programmatori a volte può creare contraddizioni …

Ovviamente, come altri hanno detto , tutti i modelli sono utili nelle giuste circostanze e parte dellimparare a usarli è imparare quando usarli. Tuttavia, leccellente libro Core Techniques and Algorithms in Game Programming di Daniel Sanchez-Crespo Dalmau, elenca sei modelli di programmazione e sei modelli di usabilità particolarmente utile nella programmazione di giochi.

Programmazione:

• Singleton: non odio questo come fanno molte persone; può essere usato per cose come il singolo- giocatore giocatore o lettore di tastiera.
• Fabbrica: consente di creare e distruggere oggetti in modo efficiente.
• Strategia: consente di modificare le strategie di intelligenza artificiale con eleganza.
• Indice spaziale : Aiuta a eseguire query su set di dati spaziali.
• Composito: imposta unutile gerarchia di oggetti.
• Peso mosca: libera memoria generando cose come nemici identici.

Usabilità:

• Scudo: protegge dallattivazione accidentale di azioni drammatiche.
• Stato: segnali visivi del mondo / stato dellinterfaccia utente.
• Cancellazione automatica della modalità: fa funzionare il gioco in modo più intuitivo.
• Magnete ism: Autoaiming e facile selezione delle unità.
• Focus: eliminazione di elementi di distrazione dellinterfaccia utente.
• Progresso: universalmente utile.

Il libro, ovviamente , entra più in dettaglio su ciascuno di questi.

Commenti

• Grazie per linput! Non ero a conoscenza di quel libro, ma ora lo esaminerò come risultato del tuo post. Grazie ancora!
• Singleton per il lettore di tastiera è esattamente la situazione in cui devo chiedere: puoi davvero non renderlo un puntatore globale impostato allinizio della tua funzione principale? Hai mai creato accidentalmente unistanza di due lettori di tastiera?
• Per favore, odia il singleton. Fa male due cose. Accesso globale e arità. Spesso gli sviluppatori pensano che laccesso globale == singleton. Ci sono pochissimi problemi che necessitano di un vero singleton, e forse alcuni di più che sono più eleganti se risolti con un singleton.

sistemi di entità sono un bel tipo di pattern. Non è esattamente un design pattern poiché non è strickly OOP. Tuttavia puoi combinarlo con OOP.

Alcuni buoni collegamenti (iniziare dallalto per lintroduzione):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Commenti

• " ' non è esattamente un motivo grafico poiché ' non è rigorosamente [sic] OOP. " I design pattern non hanno nulla a che fare con OOP; semmai, lOOP stesso è un modello di progettazione. I modelli di progettazione appaiono non solo al di fuori dellOOP, ma completamente al di fuori dello sviluppo del software.
• Ci sono OOP design patterns che tipicamente mostrano relazioni e interazioni tra classi / oggetti. E ci sono molti altri modelli di design. OOP è un insieme di concetti, non uno schema in realtà. Design pattern è anche un concetto.
• Invece di parlare di semantica, non dovresti ' valutare lutilità di la risposta che ho dato?

Tutti. Tranne Singleton. [/ flippancy]

Commenti

• Potresti nominare uno o due design pattern che ' lo hai usato frequentemente nello sviluppo del tuo gioco, e per quale motivo?In quanto principianti rispetto ai modelli di progettazione, " tutti " non è una risposta particolarmente utile. Grazie per aver risposto, però.
• Chiedere " quali schemi hai usato? " è come chiedere " quali nomi di variabili hai utilizzato? " Dipende dallo stile e dai requisiti personali e dal dominio. Ad un certo punto, probabilmente utilizzerai qualsiasi modello a cui ' sia mai stato nominato. Probabilmente ne userete molti altri senza nome e forse ne inventerete di nuovi.
• @ jcurrie33: scusa, non potevo ' resistere prima uno scavo a singleton. 😉

Non proprio sui modelli, ma sui principi di base dietro di essi. In “Design Patterns: Elements of Reusable Object-Oriented Software” (1995) , la banda di quattro (Gamma, Erich; Richard Helm, Ralph Johnson e John Vlissides) consiglia solo due principi per la progettazione orientata agli oggetti: (1) programma a uninterfaccia e non a unimplementazione e (2) privilegia la composizione degli oggetti rispetto allereditarietà delle classi.

Questi 2 principi sono molto utili in molte attività di gioco sviluppo. Ad esempio, molti programmatori di giochi hanno utilizzato una profonda gerarchia di classi per rappresentare le entità di gioco. Esiste un altro approccio basato sulla composizione : oggetti di gioco basati su componenti. Articolo su questo approccio. Ancora più link . È un esempio di motivo decorativo .

Commenti

• Componenti utilizzati in il design del gioco è più simile a un modello di strategia stateful, che è naturalmente espresso come chiusure al di fuori di C / C ++ / Java / C # e come oggetti componenti al loro interno. Il motivo del decoratore è più simile a un proxy; la sua proprietà e il flusso di dati sono opposti a quelli che normalmente intendiamo quando parliamo di sistemi a componenti nei giochi.
• Anche i componenti devono dialogare tra loro, introducendo modelli come Mediator, Observer e Composer. " Gioco basato su componenti " è un modello di progettazione composito tutto da solo.
• @CodexArcanum, Observer, decisamente , ma non sempre Mediatore (al suo posto è possibile utilizzare Catena di responsabilità). È Composer solo se GameObject (composto da GameObjectComponent) è GameObjectComponent stesso (non necessario).

Il modello di modello curiosamente ricorrente può essere davvero utile per evitare metodi virtuali e la riduzione delle prestazioni che può derivare dalle chiamate di funzioni virtuali.

Questo può essere il modello appropriato quando non hai effettivamente bisogno di avere un contenitore del tipo di classe base che ha linterfaccia che stai cercando, ma ti piacerebbe avere comportamenti e interfacce con nomi simili.

Ad esempio, puoi usarlo quando compili classi per più piattaforme o motori (dx vs. opengl) dove la varianza del tipo è nota in fase di compilazione.

Commenti

• Ho sempre odiato che il livello di astrazione del sistema operativo fosse virtuale. ' non è come te ' Avrò mai bisogno di due astrazioni del sistema operativo livelli. Molto meglio usare CRTP.
• M aybe ' sono solo vecchio, ma ' non userei nemmeno CRTP per DX / OpenGL o interfacce piattaforma. ' è troppo lento per la compilazione. ' ho solo usato typedef. CRTP è utile quando vuoi condividere interfacce e implementazioni tra classi ma non hai altre relazioni, non quando vuoi solo scegliere una struttura o laltra.

Un design pattern che ho sviluppato nel corso di molti anni e che mi è stato straordinariamente utile, è qualcosa a cui mi riferisco come “insiemi di definizioni mediate”; come riassumerlo in termini GOF sembra essere controverso, ma questa domanda che ho scritto su StackOverflow entra in alcuni dettagli al riguardo.

Il concetto centrale è che alcune proprietà di un modello, come le specie di una creatura, sono impostate in modo che ogni possibile valore per la proprietà abbia una definizione di oggetto corrispondente – un singolo oggetto condiviso per valore – che ne specifica il comportamento , e questi sono accessibili tramite un broker centrale (che, dal punto di vista GOF, può essere un registro, una fabbrica o entrambi). Nel mio utilizzo, sono generalmente accessibili anche tramite chiavi scalari, per facilitare il binding debole per scopi di morfismo di runtime.

Commenti

• Non ' non vedo come questo sia affatto un singleton e quando si discute del modello flyweight la parola " registry " è ridondante. Questo è solo peso mosca.
• La mia comprensione dal thread SO era che le persone identificavano Singleton come parte di esso a causa delle definizioni impostate come classi. Per quanto riguarda Registry, non ' per vedere come può essere ridondante quando può essere sostituito o combinato con Factory.
• -1, nella misura in cui i modelli riguardano la comunicazione rapida, questo è probabilmente il più grande errore che ' abbia mai visto. Non posso ' prendere sul serio questa descrizione.
• Gesù, perdonami se non ti faccio abbastanza lo stampino. Voterai anche la risposta " Entity systems " perché non è ' Non è immediatamente riassumibile in termini GOF?
• Una certa quantità di " cookie cutter, " o almeno di chiarezza semantica , è esattamente ciò che i modelli devono essere per essere utili. Termini come " flyweight " e " singleton " come sono comunemente intesi si escludono a vicenda. Il primo riguarda la condivisione automatica dei dati tra più istanze; il secondo riguarda avere esattamente unistanza. ' non sto dicendo che la tua scelta di design è inutile o addirittura sbagliata, ma ti sto mettendo " abbastanza vicino " nomi di pattern insieme confonde di più tutti. (Si prega di non ' prendere personalmente i voti negativi, specialmente in CW.)