Il ruolo dei linguaggi di scripting nel gioco Programmazione

Question

Quindi mi sono imbattuto in un dibattito sul lavoro su quale sia il ruolo corretto di un linguaggio di scripting nello sviluppo del gioco. Per quanto posso dire ci sono due scuole di pensiero su questo:

1) Il linguaggio di scripting è potente e completo. Grandi porzioni di codice di gioco sono scritte nella lingua e il codice viene spostato in C++ solo quando la performance impone che sia necessario. Di solito è qualcosa come Lua o Unrealscript.

2) Questo linguaggio di scripting è estremamente limitato. Quasi tutto il codice di gioco è in C++ e la lingua è lì solo per esporre la funzionalità sottostante ai designer.

La mia frustrazione deriva dal vedere l'approccio numero due frequentemente abusato, con sistemi di grandi dimensioni implementati in un linguaggio che non ha le caratteristiche che rendono tale codice mantenibile.

Così ho iniziato l'approccio di supporto numero uno, ma dopo aver parlato con alcuni designer mi sono reso conto che molti di loro sembrano preferire il numero due, e per lo più programmatori che preferiscono uno.

Quindi mi rimane ancora da chiedermi quale approccio sia migliore. Sto solo vedendo un codice errato e incolpando lo strumento invece del programmatore, o abbiamo davvero bisogno di uno strumento più complesso?

Answer 1

Penso che i progettisti debbano vedere un linguaggio adatto a loro. Non è negoziabile: devono passare il loro tempo a progettare, non a programmare.

Se lo scripting consente di sviluppare rapidamente un codice di gioco degno di un prodotto, anche i programmatori dovrebbero farlo. Ma deve essere degno del prodotto: fare tutto due volte non risparmia tempo. Quindi devi tenere gli scripting al suo posto. Se uno sviluppatore può eseguire lo script del sistema di inventario in una settimana, o scriverlo in C++ in un mese, allora si desidera uno scripting completo, se non altro per dargli più tempo per ottimizzare le parti che potrebbero potenzialmente raggiungere dei limiti prestazionali. Quindi non l'inventario, o la tabella dei punteggi alti, o il sistema di mappatura dei tasti, o la logica di gioco di alto livello come quello che i personaggi dovrebbero fare. Tutto questo può essere copiato se così facendo si risparmia in qualsiasi momento per accelerare la grafica e la fisica: i programmatori devono essere in grado di capire esattamente quali sono i colli di bottiglia, e i programmatori esperti possono fare una previsione ragionevole di ciò che ha vinto " essere

I progettisti probabilmente non dovrebbero sapere o preoccuparsi che i programmatori stiano utilizzando il linguaggio di scripting per implementare il codice di gioco. Non dovrebbero avere un'opinione se (1) è buono o cattivo. Quindi, anche se i programmatori hanno ragione di volerlo (1), perché questo inconveniente è dovuto ai progettisti? Come hanno notato che il linguaggio di scripting è completo, se tutto ciò di cui hanno bisogno è un numero abbastanza piccolo di ricette standard? Qualcosa è andato storto, ma non credo che Lua sia una lingua troppo buona.

Una possibilità è che utilizzando lo stesso linguaggio di scripting per entrambi, diventa un ostacolo per tracciare una linea netta tra le interfacce utilizzate dai progettisti e le interfacce interne al codice di gioco. Questo, come ho detto all'inizio, non è negoziabile. Anche se utilizzano lo stesso linguaggio di scripting, i programmatori devono ancora fornire ai progettisti le funzionalità di cui hanno bisogno per svolgere il proprio lavoro. Solo perché i progettisti usano Lua per codificare strategie e alberi di conversazione e Lua è un linguaggio completo capace di scrivere un motore fisico, non significa che i tuoi progettisti debbano scrivere il proprio motore fisico. Oppure usa più del 10% delle capacità di Lua.

Probabilmente è possibile eseguire entrambi (1) e (2), mente. Non c'è motivo per cui non si possa dare ai programmatori Lua e ai progettisti qualche DSL in miniatura sottovoce che sia "compilato" in Lua con uno script Lua.

Answer 2

Non riesco davvero a vedere l'argomento secondo cui grandi quantità di codice scriptato saranno superiori a grandi quantità di C++. Si potrebbe fare la contro-argomentazione. Ho visto progetti terribili di grandi dimensioni scritti in linguaggi di scripting che hanno avuto inizio con la mentalità dello scripting: fare le cose in modo rapido e sporco. Questo purtroppo non scala bene. Non c'è davvero alcun modo di fare un argomento di qualità del codice basato esclusivamente sul linguaggio di programmazione. Le persone possono scrivere manie di codice gestibile in qualsiasi lingua, compilato o script.

In ogni caso, è davvero impossibile conoscere la linea tra il tuo "approccio 1" e "approccio 2" senza sapere dove sono i colli di bottiglia delle prestazioni e ciò che i tuoi utenti vorranno maggiormente "scrivere".

Vorrei suggerire un "approccio 3" che è quello di fare tutto o in parte in C++ ed esporre un SDK pulito in C++. Ciò avrebbe il vantaggio di costringerti a scrivere il tuo codice come se fosse un'interfaccia utente che qualcuno all'esterno della tua organizzazione deve utilizzare. Si spera che sia più manutenibile e abbia l'ulteriore effetto collaterale di implementare la tua interfaccia di scripting per te. Tutta la tua interfaccia di scripting dovrebbe fare ora è inoltrata al tuo SDK. Viola!

Con questo approccio si evita di dover tracciare una linea tra il regno di ciò che è "programmato" rispetto a ciò che è in C++. Tu e i tuoi utenti potete scegliere se aggiungere funzionalità in C++ con l'SDK o utilizzare un linguaggio di scripting.

Answer 3

Come al solito, penso che la risposta sia "dipende".

Non c'è modo Halo 3 o Call of Duty 4 potrebbe essere basato principalmente sullo scripting. I titoli AAA più votati devono, per definizione, spingere la busta di qualsiasi piattaforma che tocchino. Questo non può essere fatto con lo scripting.

I giochi casual, tuttavia, sono una storia diversa. Il gioco di maggiore importanza come Unity ha molti script integrati.

C'è anche un mercato per le mod. Un solido motore di gioco con un buon ambiente di scripting può essere una piattaforma per tweaks, derivazioni e, in alcuni casi, giochi completamente nuovi. Counter Strike è il mio esempio preferito personale. Penso che tu sia limitato in questo caso ai giochi tipo FPS run-and-gun.

Quindi, c'è un posto per lo scripting nei giochi ma probabilmente rimarrà nel gioco piccolo/casuale e nello spazio del modder.

Answer 4

penso che l'equilibrio che si desidera è una cosa di questo tenore: si desidera gioco logica nello script, ma la funzionalità di gioco nel codice.

Un grande vantaggio dello script è che è possibile impostare facilmente le attese. Ad esempio:

nemico = GetObjectFromScene ("enemy01"); in 5 secondi {enemy.ThrowGrenadeAt (player); }

Solo un esempio forzato. Questo tipo di logica sarebbe fastidioso da configurare in C++. Lo script può rendere più semplice esprimere questo tipo di logica, ma si vorrebbe che la funzionalità effettiva (le funzioni che chiama) sia in C++.

E lo script non ha essere lento. Ci sono giochi pesantemente programmati in esecuzione a 60fps su console, ma richiede un buon design e trovare il giusto equilibrio tra le opzioni 1 e 2 sopra.

Answer 5

La community di sviluppo giochi utilizza già lo scripting come metodo molto comune per creare interfacce utente e ottimizzare le risposte AI. Puoi trovare molte informazioni su siti come Gamasutra. La cosa interessante è che le lingue standard stanno iniziando a sostituire gli interpreti personalizzati.

Due dei migliori esempi di script nei giochi AAA che vengono in mente sono World of Warcraft (utilizza Lua) ed EvE Online (utilizza Python). EvE utilizza anche script sul lato server: hanno un investimento significativo in Stackless Python.

Aggiornamento: le prestazioni saranno essenzialmente un non problema a causa dei multicorpi. Anche le macchine di fascia bassa avranno più core rispetto al display e gli aggiornamenti dei modelli necessitano. Potresti anche spendere uno di quei core che eseguono una soluzione di scripting per l'interfaccia utente.

Answer 6

Il ciclo di compilazione-run-test per codice C++ compilato quando si ha a che fare con qualcosa di complesso come un videogioco è molto, molto lento. L'utilizzo di un motore di scripting consente di apportare grandi modifiche funzionali al gioco senza dover compilare il programma. Questo è un enorme risparmio di tempo. Come dici tu, le cose che necessitano di ottimizzazione possono essere spostate in C++ come richiesto.

I motori AAA sono altamente guidati dallo scripting. Torque, usato per Tribes II (e molti altri giochi!) È copiato, Unreal ha Unrealscript e così via. Lo scripting non è solo per le mod, è la chiave per uno sviluppo efficiente.

Answer 7

Come è stato detto prima; utilizzare lo scripting per la logica di gioco e C++ per la funzionalità di gioco. Un esempio potrebbe essere lo scripting di una modalità di gioco, ma l'uso di C++ per il rendering.

Answer 8

Uno dei migliori esempi di script in azione è Civilization IV. Usa Boost Python. Di conseguenza, è terribilmente lento. Un chiaro contrappunto all'affermazione che "il codice viene spostato in C++ quando la performance impone che è necessario".

Il modo corretto consiste nel progettare un'architettura al di sopra e decidere quali problemi sono computazionalmente rigidi e quali sono complessi da specificare in anticipo. Grafica, fisica, pathfinding, feedback istantaneo sull'input, text to speech - tutti chiaramente computazionalmente difficili. Le "decisioni amichevoli o ostili", "difendi o attacca", "spendi o salva" le decisioni di tipo AI sono tutte complesse da specificare in anticipo.

La conclusione è che si desidera esporre attori capaci, ma senz'anima, al proprio codice di scripting. Il codice di script descrive cosa devono fare gli attori, ma il codice C++ si occupa dello come.

Per quanto riguarda il ciclo di compilazione, è importante disporre di un'architettura modulare adeguata. Quando si lavora sulla logica del path path, non si dovrebbe mai dover compilare il codice grafico. Inoltre, strumenti come Incredibuild possono aiutare a velocizzare i tempi di compilazione. Probabilmente le aziende di grandi dimensioni hanno già una farm di rendering, che può raddoppiare abbastanza bene come farm di compilazione.

Answer 9

Se dividiamo un gioco in due parti: il motore e il gioco reale (design).

Un solido motore di gioco di prima classe è molto probabilmente scritto in C/C++ e alcune persone addirittura ottimizzano ulteriormente con il codice assembler. Puoi fare un sacco di roba davvero veloce per grafica e fisica con istruzioni specifiche della CPU. Non è possibile ottenere prestazioni quando si esegue il rendering di paesaggi di grandi dimensioni o più oggetti complessi solo da un linguaggio di scripting.

Quando si tratta del gioco in sé, ci sono molti aspetti che possono essere fatti in linguaggi di programmazione più lenti ma di livello superiore. L'intelligenza artificiale e altre logiche di gioco possono essere scritte con successo in sceneggiatura.Può accelerare lo sviluppo e si apre per il modding e le espansioni della community in modo semplice.

Answer 10

così ho iniziato l'approccio di supporto il numero uno, ma dopo aver parlato con alcuni stilisti ho capito che molti di loro sembrano preferire il numero due, e le sue per lo più programmatori che preferiscono uno.

Questo dovrebbe avere un significato ovvio: se il linguaggio di scripting è "potente e completo", c'è un onere sui progettisti di dover creare i sistemi, poiché questa opportunità è a loro disposizione. D'altra parte, se il linguaggio di scripting espone solo piccoli dettagli del gioco hard-coded, allora i programmatori devono creare quei sistemi, poiché i designer non possono farlo. Non sto dicendo che entrambe le parti sono pigre, ma ovviamente entrambe hanno capacità individuali che il progetto richiede loro di concentrarsi (dato che nessun altro le può fare in modo efficace), il che significa che c'è sempre interesse nel far svolgere a qualcun altro un determinato compito se possibile.

E seguendo naturalmente da questo, il ruolo appropriato dipenderà dal modo in cui le risorse umane nella vostra azienda sono disposte, in concomitanza con qualsiasi esigenza di prestazioni del vostro gioco. Una volta che hai idea di quante persone avranno bisogno di script, saprai quanto del gioco lo richiederà e, quindi, potrai decidere quanto deve essere ampia o ristretta l'interfaccia. Ciò contribuisce a ciò che sarebbe il "dominio" della lingua, come menzionato sopra da onebyone.livejournal.com.

(per quel poco che vale, io sono uno sviluppatore di giochi professionale e anche il moderatore del forum Linguaggi di scripting sul Gamedev.net.)

Answer 11

Penso che il manifesto qui è corretto per favorire il metodo # 1. È un metodo più pulito e produrrà risultati migliori a lungo termine nonostante i reclami dei progettisti. Alla fine il codice determinerà il buon game programming da mediocre (cattivo).

Answer 12

Dire che i giochi dovrebbero essere fatti solo con C++ (o sostenere che i titoli AAA sono fatti così) è semplicemente ignorante. La maggior parte dei giochi al giorno d'oggi sono script in un modo o nell'altro, sia linguaggi di scripting proprietari (UnrealScript), linguaggio generico (Lua, python, C#, Java ecc.) O basati su dati (xml, formato binario proprietario ecc.). Basta fare delle ricerche e scoprirai che la maggior parte dei motori utilizza script in una forma o nell'altra.

Penso che la questione se avere 1) linguaggio di scripting potente e completo rispetto a 2) linguaggio di scripting estremamente limitato si sta avvicinando al problema dalla parte sbagliata. L'ambiente di scripting (lingua o basato sui dati) dovrebbe essere progettato in modo da supportare al meglio il processo di creazione del gioco. L'espressività del sistema è cruciale qui: i progettisti e gli sceneggiatori dovrebbero essere in grado di risolvere facilmente i problemi che hanno senza troppi grattacapi mentre non dovrebbero essere esposti a sistemi troppo complessi che hanno difficoltà di comprensione e apprendimento. Spesso i programmatori (me compreso) tendono a progettare sistemi facendo ipotesi su come verrà utilizzato e cercando di garantire che tutte le caratteristiche tra terra e cielo possano essere implementate, con il risultato di sistemi complessi. Essendo travolti da questa complessità, i progettisti finiscono per usare il minimo per portare a termine il lavoro. Per esempio nel nostro gioco (Rochard) abbiamo ad esempio progettato un sistema di IA basato sui dati completamente espandibile e con script, ma i progettisti di livelli hanno finito per utilizzare solo i modelli di IA azionari perché non avevano tempo o sforzo per utilizzare l'IA sistema nella sua massima estensione. Quindi alla fine ho appena creato una buona interfaccia utente per scegliere facilmente i modelli di IA di serie.

Direi che non esiste un proiettile d'argento in questa materia.