Motore di gioco e progettazione guidata dai dati

Ho sentito parlare della progettazione guidata dai dati e ne ho fatto ricerche per un po '. Quindi, ho letto diversi articoli per ottenere i concetti.

Uno dell'articolo è Data Driven Design scritto da Kyle Wilson. Come ha descritto, mi sembra che il codice dell'applicazione (ovvero il codice per il controllo delle risorse come memoria, rete ...) e il codice della logica di gioco dovrebbe essere separato e il codice della logica di gioco dovrebbe essere guidato da origini dati esterne. A questo punto, posso immaginare che lo sviluppatore scriverebbe una sorta di editor di giochi che accetta dati esterni su oggetti di gioco (come informazioni sui personaggi, informazioni sulle armi, informazioni sulla mappa ...). Il design dello scenario sarà scritto da un linguaggio / strumento personalizzato scritto dal programmatore per consentire al progettista di giochi di creare interazioni tra oggetti di gioco. Il progettista del gioco utilizzerà un linguaggio di scripting esistente / personalizzato per scrivere script per il gioco o trascinerà lo strumento per creare il mondo di gioco. Un esempio di approccio agli strumenti che mi viene in mente è l'Editor mondiale, che di solito è confezionato insieme ai giochi di Bliizard.

Tuttavia, un altro articolo è contrario all'uso di Data Driven Design, The Case Against Data Driven Design . L'autore suggerisce di non lasciare che il design del gioco sia guidato dai dati, perché ci vorrebbe più tempo per sviluppare un gioco, poiché il progettista del gioco ha l'onere della programmazione. Invece, ci sarà un programmatore di giochi per programmare il gioco liberamente dal disegno dello schizzo, ed è verificato dal progettista del gioco al termine della programmazione del gioco. Lui chiama questo è guidato dal programmatore. Quello che penso di questo metodo è simile al modo in cui ero solito fare: la logica del gioco è l'applicazione stessa, come apposta all'idea precedente, l'applicazione è l'editor di gioco e il gioco reale è progettato in base allo strumento.

Per me, il primo metodo sembra essere più ragionevole, dal momento che i componenti di gioco possono essere riutilizzati per molti progetti. Con il secondo metodo che si oppone alla progettazione basata sui dati, il codice di gioco appartiene solo a quel gioco. Questo è il motivo per cui penso che Warcraft abbia così tanti generi di gioco, come l'originale Warcraft e varie mappe personalizzate, e uno dei più famosi: DOTA che in realtà definisce un nuovo genere. Per questo motivo, ho sentito che la gente chiama World Editor è il motore di gioco. È vero come dovrebbe essere un motore di gioco?

Quindi, dopo tutto questo, voglio solo verificare che ci sia qualche difetto nella mia comprensione di queste idee (data driven, drive del programmatore, scripting ecc ...)?

Rendere il tuo gioco (o qualsiasi prodotto software) guidato dai dati è quasi sempre un vantaggio. L'unico vero svantaggio è che potresti impiegare un po 'più di tempo a costruire in anticipo i relativi sistemi; pagherà per il resto della tua carriera come programmatore (anche se non riutilizzerai quegli stessi sistemi per tutto quel tempo, riutilizzerai le tecniche che hai impiegato per costruirli).

La sfida, e in cui entra in gioco la disconnessione in quei due articoli collegati, è ciò che si sceglie di inserire i dati e chi si sceglie di dare accesso a tali dati. Fondamentalmente, la progettazione e lo sviluppo basati sui dati significano semplicemente che le informazioni vengono archiviate in un archivio esterno, caricate tali informazioni in fase di esecuzione e agite su di esse. Il codice dell'applicazione fa ciò che i dati esterni gli dicono, piuttosto che scrivere il codice dell'applicazione che fa direttamente quello che pensi dovrebbe essere il risultato finale. Non è un'idea complessa.

Non è necessario creare complesse "architetture guidate dai componenti" (come è di moda in questi giorni). Inserire le costanti per ottimizzare la fisica (forza gravitazionale, coefficienti di restituzione) in un file di testo è guidato dai dati. Gli script (in Lua o qualcos'altro) sono guidati dai dati. Descrivere i dati di livello in XML. Qualcosa del genere.

Puoi guidare praticamente qualsiasi componente del software con i dati e puoi scegliere quelli con cui vuoi farlo. Il tempo degli sviluppatori è costoso; tempo del programmatore specialmente così. Se puoi risparmiare tempo a te o ad altri programmatori mettendo comportamenti e dati nella memoria esterna e non richiedendo la ricompilazione del gioco per ogni piccola modifica, dovresti. Risparmierai e realizzerai le cose più velocemente.

Inoltre, corri un rischio enorme nel tentativo di far "progettare i progettisti" e far sì che i programmatori "trasformino quei progetti in realtà", costringendo un programmatore a esistere nel ciclo di iterazione per il lavoro di un progettista: corri il rischio di far sentire il programmatore come se è solo una scimmia di codice, che fa continuamente piccole modifiche banali per il design. Ciò può essere fortemente demoralizzante per la grande maggioranza dei programmatori, che vogliono lavorare su sfide tecniche interessanti e non essere un delegato del progettista.

Per le tue domande specifiche:

È vero come dovrebbe essere un motore di gioco?

Un "motore di gioco" non ha una definizione fissa. Generalmente è la raccolta unificata della tecnologia di base utilizzata per creare un gioco, generalmente supportata da una serie di strumenti correlati (e quindi piuttosto basati sui dati). Ma varia abbastanza ampiamente da un contesto all'altro.

Quindi, dopo tutto questo, voglio solo verificare che ci sia qualche difetto nella mia comprensione di queste idee (data driven, drive del programmatore, scripting ecc ...)?

Sembri essere più o meno sulla strada giusta, anche se forse stai complicando troppo la progettazione e lo sviluppo guidati dai dati, confondendoli con i sistemi basati su componenti.

Come autore del secondo post, vorrei chiarire alcuni punti.

1. Come ha suggerito Josh Petrie, strutturare il proprio codice per utilizzare i dati anziché semplicemente codificare tutto è sempre una vittoria. Non stavo suggerendo il contrario. Stavo sottolineando che spingere tutto sul designer non è una buona idea. Il termine "progettazione guidata dai dati" significa cose diverse per persone diverse, quindi probabilmente avrei dovuto essere più specifico quando ho scritto l'articolo originale.
2. In ogni luogo in cui ho lavorato, creiamo strutture di dati modificabili nel motore. Per apportare una modifica, non è necessario ricompilare il gioco. Possiamo modificare il numero in modo dinamico in fase di esecuzione. Le strutture di dati sono spesso memorizzate nel codice, ma a seconda di chi le sta modificando, possono essere facilmente caricate da un "file di dati".
3. La maggior parte degli ambienti di sviluppo supporta una qualche forma di modifica e continua o ricarica del modulo per C / C ++.
4. La maggior parte degli studi di sviluppo del gioco ha programmatori di gioco. Il loro lavoro consiste spesso nel lavorare con il designer per creare un'esperienza divertente. La loro principale preoccupazione non è rappresentata dalle sfide tecniche, ma piuttosto dal divertimento derivante dal codice. Ho lavorato come programmatore di gameplay per molti anni e lo trovo più interessante del semplice tentativo di risolvere le sfide tecniche. Le mie responsabilità sono varie, ma ho trovato il mio lavoro più soddisfacente quando sono responsabile dell'implementazione e lavoro con i progettisti per creare qualcosa di interessante. Il problema con la programmazione o lo scripting dei progettisti è che i programmatori spesso devono risolvere i bug, che è una delle cose meno divertenti che puoi fare come programmatore.
5. Ciò che funziona meglio per uno studio dipende dal gioco. Se hai molto tempo per creare un gioco e vuoi dare le tue gambe al gioco per la comunità mod e creare qualcosa di enorme portata, allora ha senso creare un gioco completamente guidato dai dati. Molti giochi non hanno questo obiettivo. Devono sfornare un nuovo gioco in due anni e, a meno che non abbiano un franchise di successo, è probabilmente un tipo di gioco diverso rispetto al loro lavoro precedente
6. Ciò che fa un "designer" può variare da studio a studio. Ho sentito parlare di uno studio di sviluppo che assume programmatori di gameplay da altri studi, li chiama designer e li fa scrivere il comportamento del gioco. Questo elude il problema di avere persone che non sono addestrate nella programmazione di programmazione / scripting.
7. Dovrebbe esserci sempre una delimitazione tra il codice della logica di gioco e il codice del motore. Inoltre, normalmente si desidera avere una sorta di editor visivo per il posizionamento degli oggetti. Non ho mai lavorato in uno studio in cui le posizioni dei nemici sono fortemente codificate. Sono inseriti in un editor. Vorrei proporre un esempio di ciò di cui sto parlando. Diciamo che il designer pensa a un nemico. Il progettista non scrive il comportamento di questo nuovo tipo di nemico? Questo è ciò che considero la progettazione basata sui dati (in termini di ciò che Tim Moss ha scritto al riguardo). Nel modo in cui sto proponendo, il programmatore lavora con il progettista, fanno un nemico divertente insieme forse con parametri modificabili, e poi vengono posizionati nel livello.
8. Il codice nativo scritto da un programmatore verrà eseguito più velocemente in fase di esecuzione rispetto a uno script scritto da un programmatore, che verrà eseguito più velocemente di uno script scritto da qualcuno con meno esperienza tecnica. Questa prestazione può essere o non essere importante a seconda del tipo di gioco che stai facendo e di quello che stai facendo, ma è qualcosa da considerare.
9. È possibile condividere il codice di gioco tra i giochi indipendentemente dal metodo scelto. Non sono proprio sicuro di cosa tu stia arrivando con questo punto. Anche se non stai usando un linguaggio di scripting o uno strumento visivo per definire alcuni comportamenti, dovresti architettare il tuo codice di gioco in componenti riutilizzabili il più possibile. Ci saranno sempre cose che non sono applicabili al tuo prossimo gioco, ma ogni posto in cui abbia mai lavorato, quando iniziamo il gioco successivo, iniziamo con la base di codice del precedente, anche se non è un sequel. Quindi manteniamo le cose che hanno senso e rimuoviamo le cose specifiche del gioco.

Alla fine, non c'è una risposta giusta o sbagliata. È una questione di come tu e i tuoi colleghi vi sentiate a vostro agio nel lavorare. Quando ho scritto quel blog qualche tempo fa, si parlava molto di come tutto il lavoro dovesse essere spinto ai progettisti e volevo scrivere su quante aziende di giochi di successo che conoscevo trovassero un equilibrio diverso.

Inoltre, come nota a margine, il mio post sul blog ha 5 anni. Sembra che molti più studi si stiano muovendo verso linguaggi di scripting e quant'altro in questi giorni, ma stanno creando strumenti maturi per il debug, che è stata la mia lamentela principale. Quando ho scritto questo, non credo che Unreal Kismet esistesse, che non ho usato, ma sembra che stiano cercando di semplificare gli script e apparentemente ha un debugger. (Non ho idea di quanto funzioni bene)

Per i giochi su scala ridotta, non credo proprio che tu voglia provare a inserire un linguaggio di scripting o funzionalità simili nella tua tecnologia, ma se hai un team enorme e un sacco di tempo da dedicare alla tecnologia, è possibile farlo giusto e il tempo di investimento può avere senso a seconda del modo in cui il tuo team di sviluppo ama lavorare. Personalmente, probabilmente mi aggrapperò al C ++ il più a lungo possibile perché per me è il più semplice e veloce poiché spesso devo cercare di aggirare "funzionalità" come la garbage collection.

Dovresti guardare il motore tecnologico BitSquid . È costruito usando concetti DOD. Il blog di Niklas Frykholm è molto interessante. Ci sono molti articoli su come è progettato questo motore.

Al GDC 2011, Niklas ha fatto una presentazione su Data Driven Renderer .