Domain Driven Design è adatto ai giochi?

Ho appena letto dei modelli di dominio e mi ha illuminato da quando ho sviluppato un gioco che ha una classe che contiene solo dati (pochi comportamenti / metodi). Ho assegnato il compito di gestire queste classi ai manager ... e ora il mio manager sembra assomigliare a un oggetto di Dio. Il mio oggetto di gioco che dovrebbe gestire la logica è solo un modello di dominio anemico.

Il mio modello di progettazione attuale è in Singleton e voglio fare un po 'di ricodifica per ottenere queste cose. Non ho mai visto un DDD sui giochi (per ora) ma è un buon approccio? Sono solo un programmatore inesperto (propenso al gioco dev't) quindi voglio saperne di più sulla buona architettura prima che il gioco diventi troppo gonfio per riprogettare.

Non avevo mai sentito parlare del design guidato dal dominio prima del tuo post. Un rapido sguardo ad un paio di riferimenti - qui e qui - sembra suggerire che è solo un nome di fantasia per il metodo tradizionale di programmazione orientata agli oggetti degli anni '90 che mi è stato insegnato all'università, dove cerchi di scrivere lezioni per ogni sostantivo che appare nella situazione stai provando a modellare con il software, in modo che la struttura del software sembra seguire la struttura del concetto del mondo reale.

Pertanto, la mia risposta è che non è "buono". Di solito è un ragionevole punto di partenza ma si rivela inadeguato man mano che procedi. Raramente hai un singolo dominio ma diversi domini diversi all'interno di un unico software: ad esempio, potresti avere il dominio del gioco (il mondo, i personaggi, gli oggetti), il dominio del renderer (gli shader, le mesh, i materiali), il dominio di input (il filesystem, la rete, la tastiera e il mouse), e i problemi si verificano quando i domini si sovrappongono e si influenzano a vicenda. Spesso nel corso dell'unione di 2 domini insieme, ti rendi conto che in realtà c'è una dipendenza lì che richiede un cambiamento, il che significa che una delle tue rappresentazioni diventa più un peso che un aiuto.

Un esempio vago potrebbe essere una libreria matematica su una console e i tuoi personaggi di gioco. La tua libreria matematica vorrà avere un ampio elenco di dati e quindi 1 istruzione da eseguire su quell'elenco, per funzionare in modo efficiente. I tuoi personaggi in-game avranno ciascuno il proprio set di dati vertici per il rendering e l'animazione, ecc. Ora, come puoi ottenere un lungo elenco di tutti i dati vertici da ciascuno dei tuoi personaggi per essere in grado di gestirli in una volta sola? Potresti eseguire un'operazione di copia lenta, o invece potresti riformattare i tuoi personaggi in modo che i loro dati siano più suscettibili di essere elaborati dalla biblioteca di matematica - ma poi uno dei tuoi domini si sta rompendo per favorirne un altro.

Personalmente sono molto diffidente nei confronti di qualsiasi etichetta che assomigli a "Qualunque sia il Driven-Design". Il software è allo stesso tempo troppo vasto e troppo complesso perché ci sia un approccio unico per crearlo. Invece, quando provo a scrivere il miglior software possibile, provo a ripiegare sui principi SOLIDI . Questi ti danno una buona idea di quanto è buono il tuo codice, senza promettere una panacea di un metodo che puoi seguire e magicamente arrivare a un buon codice. Sfortunatamente, senza una tale metodologia allegata, ci vuole molta esperienza prima di imparare a conformarsi a queste linee guida, motivo per cui probabilmente così tante persone amano le metodologie.

Per quanto riguarda il problema di avere classi anemiche e oggetti manager, questo di solito è qualcosa che viene trattato nelle lezioni introduttive sull'orientamento degli oggetti e non richiede davvero di aderire a una metodologia speciale per "risolverlo". (Potresti voler prendere un libro sulla programmazione orientata agli oggetti se hai appena iniziato.) Una classe è un accoppiamento di stato e comportamento, in cui il comportamento modifica tale stato e questo si chiama incapsulamento. Generalmente si tenta di incapsulare il più possibile, il che significa che lo stato deve essere manipolato dall'oggetto stesso (e solo quell'oggetto). Solo per un comportamento che non può essere modellato all'interno della classe, delegheresti a una classe esterna, come un manager, motivo per cui l'esistenza di classi manager è spesso considerata un segno di codice orientato agli oggetti scritto male.

Il mio modello di progettazione attuale è in Singleton e voglio fare un po 'di ricodifica per ottenere queste cose.

Non so cosa intendi con quella linea. Un modello di progettazione è un modo ben noto di scrivere una piccola parte del programma. Non avresti un modello di progettazione "attuale", né modellerebbe il resto del tuo programma. Per i principianti, questi schemi sono utili per portarti sulla strada giusta, mentre per gli esperti sono più un modo per comunicare su situazioni di codice comuni. Una cosa è comunque importante: i single sono quasi sempre una cattiva idea e dovresti evitarli ogni volta che è possibile. Puoi trovare molte opinioni sui singoli su questo sito e su Stack Overflow, ma ecco una domanda pratica con risposte che ti aiutano a evitare di averne bisogno.

Paradigma

Dal momento in cui questa risposta è stata scritta, le altre risposte postate qui sono tutte sbagliate.

Invece di chiedere se il Domain-Driven Design è adatto ai giochi. Dovresti chiederti se "Domain Modelling" è adatto o meno ai giochi.

La modellazione di domini è buona per i giochi?

La risposta è: a volte è assolutamente favoloso. Tuttavia, se stai creando un gioco in tempo reale come un platform o un FPS o altro (MOLTI MOLTI tipi di giochi), allora no. Non è necessariamente adatto per quei sistemi. Tuttavia, potrebbero esserci sistemi all'interno di quei giochi in cui è efficace l'implementazione del modello del modello di dominio.

Come altri hanno già menzionato qui, i framework delle entità componenti tendono ad essere molto popolari e per buoni motivi. Tuttavia, nella cultura di sviluppo del gioco sembra esserci una netta mancanza di architetture a strati. Ancora una volta, questo è per una buona ragione poiché la maggior parte dei giochi che le persone svilupperanno cambieranno lo stato delle entità e lasceranno che le conseguenze emergenti siano il gioco.

TUTTO IL SOFTWARE NON È IL SOFTWARE CHE STAI SCRIVENDO. Alcuni sono abbastanza diversi dagli altri.

Alcuni esempi di domini in cui la modellazione di domini funziona bene sono i giochi di carte, i giochi da tavolo e altri tipi di sistemi guidati dagli eventi.

I giochi che girano alla frequenza dei fotogrammi X con movimento, ecc. Determinati da delta temporali come concetti di dominio di base probabilmente non sono adatti. In questo caso, il nostro "dominio" è spesso così semplice che non è necessario modellare il dominio. Il rilevamento delle collisioni, la generazione di nuove entità, l'influenza delle forze sulle entità esistenti ecc. Tendono a coprire la maggior parte del gameplay.

Tuttavia, man mano che le cose diventano complesse, inizi a vedere gli sviluppatori implementare modelli di dominio all'interno delle loro entità per gestire determinati tipi di comportamento e calcolo.

Modello del modello di dominio nelle architetture di gioco

Il tuo motore di gioco (ad esempio Unity3D) è spesso orientato all'entità componente. In un platform, potresti avere un'entità per il tuo personaggio e il suo stato è costantemente mutato per aggiornare la posizione ecc.

Tuttavia, in un gioco più orientato agli eventi, è più probabile che il ruolo del framework componente-entità esista più semplicemente come interfaccia utente. Si finisce con un'architettura a strati.

L'interfaccia utente visualizza lo stato del gioco per l'utente. L'utente interagisce con l'interfaccia utente, attivando i comandi nel livello di servizio. Il livello di servizio interagisce con gli oggetti di dominio. Gli oggetti di dominio hanno generato eventi di dominio. I listener di eventi ascoltano gli eventi e attivano le modifiche nell'interfaccia utente.

UI> Livello di servizio> Modello di dominio

In breve, si finisce con il modello-view-controller con un'implementazione del livello di servizio.

Usando questa architettura, hai un core di gioco completamente testabile dall'unità (Una rarità nella cultura dello sviluppo del gioco, e lo dimostra) con un'interfaccia basata sugli eventi.

Ok ora, cos'è DDD?

Il Domain-Driven Design in particolare è una cultura / movimento di enfasi sui modelli analitici che vengono utilizzati per conoscere il dominio, in modo che tu stia effettivamente costruendo la cosa giusta e quindi i modelli di implementazione che ti consentono di implementare un livello di modello che rappresenta il concetti nel modello di dominio usando il linguaggio della tua lingua. DDD nasce da una comunità che lavora con domini complicati e è sempre alla ricerca di modi per gestire un'elevata complessità nelle loro applicazioni concentrandosi sulla modellazione di domini.

DDD non funziona così bene se il tuo obiettivo è solo iniziare a scrivere codice, giocare con il sistema e poi capire cosa vuoi costruire in seguito, ecc. Presuppone che esista più o meno un dominio. Quindi, se non hai idea di quale sarà il tuo gioco .. Quindi, non funzionerà.

No, non credo che DDD o qualsiasi altra architettura "parola d'ordine" sia davvero buona per i giochi. Con la possibile eccezione del "sistema componente", che qui sembra molto popolare.

Quando sento domande e discussioni come questa, mi viene in mente questo sito. Riflettendo su varie parole d'ordine dell'architettura di solito ti farà meno bene che progettare e codificare la tua applicazione.

Sì, ma dovresti adattarti.

Quando usi DDD otterrai la modularità e la singola responsabilità di ciascun dominio. Ma qualsiasi altra cosa rende le cose complesse.

Vedi la mia risposta qui