I termini script e scripting sembrano essere usati in modo intercambiabile nello scambio di stack di sviluppo del gioco, ma oltre a leggere le domande su una scelta del linguaggio di scripting, non capisco la relazione tra script e scripting e il linguaggio principale. Cosa fa di solito uno script, quando verrà utilizzato, e gli script in alcuni contesti (come definiti dai programmatori di giochi) sono diversi da un linguaggio di scripting?

Gli script sono scritti per un linguaggio di scripting. Le persone possono usare le parole nelle frasi gergali per ottenere la confusione a cui ti stai riferendo ma chiedere a chiunque le definizioni di Script, Scripting e Scripting Language e otterrai qualcosa del tipo: Scripting è l'atto di scrivere Script usando un linguaggio di scripting.

Quando si incorpora un linguaggio di scripting in un motore di gioco o un linguaggio di base a cui ci si riferisce, si espongono non solo gli oggetti all'interno del motore di gioco, ma si consente anche la scrittura della logica per il motore di gioco. Un'altra cosa degna di nota è che questo trasforma il tuo gioco in una specie di macchina virtuale, poiché i linguaggi di scripting raramente vengono compilati in linguaggio macchina e vengono invece inseriti in una forma di codice byte e interpretati in fase di esecuzione dal tuo motore di gioco.

Questo ha alcuni enormi vantaggi per il team di sviluppo, alcuni dei quali puoi trovare elencati di seguito:

• I linguaggi di scripting sono generalmente gestiti dalla memoria, quindi non devi preoccuparti delle allocazioni
• Di solito sono un linguaggio vagamente digitato che elimina la necessità di assicurarsi di utilizzare il tipo di variabile per quello che stai facendo, basta creare una variabile e seguirla.
• Le lingue stesse sono spesso molto semplicistiche mentre offrono un bel po 'di controllo a persone che non sono programmatori
• La modifica degli script non richiede la ricompilazione del motore principale.
• Scripting vs Coding spesso riduce il tempo necessario per la messa a punto molto iterativa della logica di gioco.
• A seconda del design e della lingua, puoi spesso ricaricare uno script mentre il gioco è in esecuzione per una messa a punto / test ancora più semplice.

Sono sicuro che l'elenco possa continuare all'infinito, ne sono sicuro, soprattutto quando si entra in tipi di gioco specializzati e in che modo gli script possono aiutare a definire le regole di formazione di gruppi per lo spostamento di gruppi di unità in un RTS o come è possibile creare la logica di un'interfaccia utente in un linguaggio di scripting per fornire un'interfaccia utente estensibile agli utenti finali e simili.

L'uso dello scripting ha molti vantaggi rispetto al "linguaggio di base". Alcuni di questi includono:

• Spostamento (più) dei contenuti dagli sviluppatori principali agli artisti, liberando gli sviluppatori principali dalle attività di gioco dalle attività di gioco
• Gli script tendono ad essere sottoposti a sandbox, non possono farci nulla di veramente pericoloso
• La modifica degli script non richiede la ricompilazione e la riesecuzione del gioco

Uno script è in genere un pezzo di codice che viene eseguito al di fuori del tuo motore principale. Di solito è contenuto in file di testo ovunque tu voglia mantenerli. Quindi viene solitamente caricato dal motore, analizzato ed eseguito in fase di esecuzione.

Ciò che generalmente accade è che qualunque sia la lingua che usi (ad esempio Lua, Angelscript), questa lingua di solito ha alcune funzionalità che consentono al programmatore del motore di esporre le funzioni del motore o persino intere classi all'istanza del "motore di scripting" attualmente in esecuzione .

Ad esempio (esempio totalmente stupido, ma solo per far capire il punto) il tuo codice di gioco potrebbe avere una funzione pubblica che genera zombi da qualche parte:

void SpawnZombie(int x, int y, int hp /* whatever else */)
{
   //...
}

Il linguaggio di scripting utilizzato ora consente di esporre questa funzione al parser di script in esecuzione. Ciò significa effettivamente che è possibile aprire un file di testo, scrivere "SpawnZombie (200.300,1337)" e una volta che il motore esegue il codice, uno Zombi verrà generato in quella posizione.

Le altre risposte elencano già un paio di buoni esempi di come questo è tipicamente usato, ma tralasciano un punto che trovo molto importante:

Questo tipo di script semplifica il debug o il test del gameplay durante il runtime.

Diciamo che vuoi capire il modo perfetto per posizionare uno zombi sulla mappa in modo che abbia il massimo effetto di paura sul giocatore una volta scoperto. Senza il supporto degli script, dovresti uscire dall'applicazione, modificare alcuni numeri magici nel codice, ricompilarlo e testarlo.

Con il supporto per gli script (purché tu abbia già un metodo per inserire il testo durante il runtime, ad esempio una console di debug), digita semplicemente "SpawnZombie (333.444.555)" e vedi come appare.

Allo stesso modo potrebbe essere possibile generare armi, veicoli, caricare mappe diverse, modificare i valori di alcune cose nel gioco, ecc., Instaurare i nemici perché non si vuole perdere tempo a raggiungere la parte che deve essere testato ecc.

Ciò ti farà risparmiare un sacco di volte in giochi più complessi.

1) Gli script sono spesso molto più facili da modificare rispetto al codice.

2) Gli script sono spesso modificabili sul campo. Ciò consente di modificare il gioco.

La maggior parte dei linguaggi di scripting è molto più espressiva della lingua nel motore principale. Spesso il motore è scritto in un linguaggio di livello relativamente basso (es. C ++) per motivi di prestazioni, ma il codice di gioco non deve essere altrettanto performante e quindi le priorità si spostano verso la capacità di esprimere facilmente la funzionalità.

Ad esempio, tipizzazione dinamica vs. statica. Un altro esempio: garbage collection vs. gestione manuale della memoria.

Gli script consentono di scrivere la logica a un livello superiore. In altre parole, scrivi meno codice con più funzionalità.

Quindi un esempio, quanto segue mostra la differenza tra scrivere qualcosa nel codice e scriverlo in un linguaggio di script.

Codice del gioco

Update Loop
{
    if (CarExplodeAnimation.FinalFrame == true)
    {
        SceneGraph.Remove(Car);
        Message("You have destroyed the car.";
    }
    else
    {
        CarExplodeAnimation.AdvanceToNextFrame();
    }

}

Codice dello script

PlayAnimation(ShipExplode)  // blocks until animation completes
Message("You have destoryed the car.")

Vedi quanto meno codice deve fare il designer se usi un linguaggio di scripting?

Il motivo è dovuto al codice di gioco, devi dividere un evento in più frame e scrivere il codice da una prospettiva a più frame. D'altro canto, gli script consentono di pensare all'evento a più frame come a una singola riga di codice, poiché tutti i codici extra sono astratti dietro una funzione di script.

Potresti chiedere, ma questa funzione non può essere scritta anche nel codice di gioco? Bene, sì, ma ciò significa che i progettisti dovranno aprire il codice sorgente del motore di gioco e scrivere tutti i codici lì dentro, e non vuoi che i tuoi progettisti passino attraverso il codice sorgente del motore di gioco (potrebbero cambiare accidentalmente qualche altro codice e il tutto si blocca).

Invece, vuoi che il tuo designer faccia qualcosa del genere: fai clic con il pulsante destro del mouse su un'auto nell'Editor mappe, fai clic su Inserisci script, digita i codici dello script. Non si scherza con i codici sorgente del motore di gioco critico.