L'implementazione del proprio linguaggio di scripting è praticabile?

Sto programmando un picchiaduro in C ++ ed è giunto il momento di implementare lo scripting per eventi, trigger, filmati ecc. Ho letto su Internet e ho ottenuto un bel po 'di informazioni. La mia soluzione di prima scelta sarebbe quella di implementare il mio linguaggio di scripting come quello di Cave Story . Ho visto questo suggerito, ma la maggior parte delle persone suggerisce lua ma questo non sembra adattarsi al mio tipo di programmazione.

Hai creato il tuo linguaggio di scripting? Perché hai scelto di arrotolare il tuo invece di usarne uno esistente? Quali risorse hai consultato durante lo sviluppo?

No. Almeno, probabilmente no.

Questo è un caso molto frequente di reinventare la ruota è lo sviluppo del gioco, un errore che è ancora abbastanza popolare.

Se stai ponendo questa domanda, molto probabilmente sarai influenzato da ciò che fanno gli altri, quindi dai un'occhiata a ciò che Epic Games ha appena fatto con Unreal Engine:

• UE3 aveva un oggetto UnrealScript personalizzato, strano, non ottimizzato, difficile da eseguire il debug,
• Se la voce è vera, il suo supporto viene rimosso in UE4 , a favore di DLL C ++ ricaricabili a caldo.

Pensi di poter fare meglio di Epic?

La creazione di linguaggi di programmazione appartiene ai creatori di linguaggi di programmazione , non agli ingegneri di gioco.

Ci vogliono anni e anni prima che una lingua diventi completamente matura e che il relativo set di strumenti (compilatore, linker, interprete, debugger ...) sia utilizzabile. Al giorno d'oggi hai molte soluzioni disponibili a portata di mano, quindi non c'è assolutamente alcun motivo reale per iniziare una nuova cosa da zero, almeno non se l'obiettivo è semplicemente quello di fare un gioco. Periodo.

Per rispondere alle tue domande secondarie, no, proprio per questi motivi non ho mai implementato il mio linguaggio di scripting. Ma ho sofferto molto con alcuni semi-cotti. Poiché sono stati creati pensando a una funzionalità molto ristretta, hanno sempre avuto queste piccole stranezze folli che ti fanno impazzire. Spesso ti ritroverai a passare moltissimo tempo a cercare di aggirare i limiti della lingua invece di creare il tuo gioco.

Se il motivo si desidera creare una lingua è, perché è destinato all'uso da parte di persone che non conoscono la programmazione molto bene, o se credete avete bisogno perché si vuole qualcosa di molto Domain-Specific, lasciate che vi dica queste sono anche cattive ragioni. È possibile scrivere un'API di livello molto elevato con funzioni che do_what_they_say_and_say_what_they_do()e un codice della caldaia molto semplice che ne espone l'utilizzo di base. I tuoi utenti non così tecnici saranno felici di imparare un po 'di programmazione e sarai felice di non essere limitato da un linguaggio mal implementato.

Quindi, dato che questo sembrerà un po 'brusco o addirittura duro, dirò che c'è un caso in cui potrebbe avere senso: se vuoi imparare come è fatto un linguaggio di scripting. Ma per favore, per favore, se lo fai: non forzare gli altri a usarlo.

modificare

Ho appena dato un'occhiata all'elenco dei comandi di Cave Story che hai collegato. Ahia:

<ECJx:y      [EC?] Jump           @ Jump to event Y if any npc with ID X is present

Non voglio mostrare mancanza di rispetto allo sviluppatore dietro Cave Story, ma questo è un perfetto esempio di un semplice elenco di comandi mutato in un linguaggio di scripting personalizzato incontrollabile. Questo potrebbe essere ancora utilizzabile per un singolo sviluppatore o un team molto piccolo, ma in questa fase ti consiglio di passare a un linguaggio completo e ben collaudato di Turing (ad esempio Lua), dove puoi fare:

if (npc.id == x) then
    jump_to_event(y)
end

Ciò renderà le cose molto più facili quando, ad esempio, avrai bisogno di una condizione più complessa:

if (npc.id == x) or (npc.type == "enemy") then
    jump_to_event(y)
end

Hai creato il tuo linguaggio di scripting e perché hai scelto di usare il tuo linguaggio invece di usarne uno esistente?

Ho, anche se ho preso in prestito la sintassi da altre lingue. Tutto sommato è stata una grande esperienza di apprendimento e nel mio caso non così difficile perché la lingua era semplice.

L'ho fatto principalmente perché volevo usare una normale sintassi in stile C per i miei script, poiché tutti i membri del team lo conoscevano.

Mi interessava anche imparare un po 'sull'implementazione dei linguaggi di programmazione e dato che avevo solo bisogno di un sottoinsieme molto semplice di funzionalità (variabili, aritmetica, condizionali, loop e chiamate in-game funzioni o coroutine) ho deciso di provarlo.

Quali risorse hai consultato durante lo sviluppo?

La mia risorsa principale era questo libro:

Sono riuscito a imparare abbastanza da questo libro per implementare:

• Un lexer: che era quasi banale usando le espressioni regolari, semplicemente usando Regex.Match per identificare e dividere i token.
• Un parser di discesa ricorsivo: sostanzialmente una funzione per ciascuna regola della grammatica e alcuni metodi di supporto per guardare avanti e consumare i token. Ho preso in considerazione le specifiche grammaticali C # per l'ispirazione. La parte più difficile riguardava l'aritmetica e le precedenti delle relazioni con gli operatori senza andare in una ricorsione infinita.
• Un interprete AST: usando il modello di progettazione del visitatore, ho attraversato l'albero generato dal parser ed eseguito ricorsivamente ogni nodo di istruzione.

Mi sarei fermato lì poiché quasi tutto ciò di cui avevo bisogno stava già funzionando, tranne una cosa: chiamare e cedere alle coroutine Unity3D in profondità dall'interprete ricorsivo. Per risolvere quel problema, ho dovuto sbarazzarmi della ricorsione e mi sono rivolto di nuovo al libro. Questa volta ho finito per aggiungere:

• Un compilatore: un altro visitatore, ma invece di eseguire il codice, genera un elenco di piccole istruzioni atomiche da ciascun nodo dell'AST (ovvero un semplice linguaggio di assemblaggio personalizzato basato su stack). Operazioni come un ciclo while o una condizione if vengono convertite in etichette e istruzioni goto-type. A questo punto scrivo anche lo script compilato su disco come file binario.
• Un interprete bytecode: scorre semplicemente su un elenco semplice di istruzioni. Senza la ricorsione era ora facile integrarsi con le coroutine Unity3D.

L'intero processo è durato circa 2 settimane da zero conoscenze ed è stato molto divertente :)

PS: Alla fine volevo anche aggiungere l'evidenziazione della sintassi e l'intellisense per il mio linguaggio personalizzato sui nostri strumenti. Scintilla ha salvato la vita in questo senso. Ho usato il seguente wrapper:

http://scintillanet.codeplex.com/

Ho visto questo suggerito, ma la maggior parte delle persone suggerisce lua ma questo non sembra adattarsi al mio tipo di programmazione.

OK, proviamo questo da una prospettiva diversa: cosa ti piace di Lua che non ti piace? È qualcosa che è facilmente risolvibile o è qualcosa di fondamentale?

Ad esempio, utilizzare parole chiave come then/do/endper indicare il blocco di codice anziché le parentesi graffe in stile C / C ++. Se questo è il tuo problema ... è qualcosa che puoi risolvere. Tutto quello che devi fare è definire il tuo piccolo dialetto di Lua e scrivere un semplice strumento di trasformazione che convertirà la sintassi del parentesi graffa in Lua reale.

Vuoi + = in qualche forma? È anche qualcosa che puoi facilmente fare in un sistema di pre-elaborazione. Trasforma semplicemente le dichiarazioni del modulo expr1 += expr2in expr1 = expr1 + expr2.

Certo, dovrai trovare un modo per rilevare se una coppia di parentesi graffe rappresenta una tabella o una do/endcoppia. E che avrebbe dovuto collegare il sistema di pre-elaborazione in Lua da imperativi dofile, loadstringe altre funzioni della libreria standard Lua. Ma alla fine è tutto fattibile.

Se i piccoli problemi di questo tipo sono la tua preoccupazione e sei troppo legato a uno stile di programmazione per cambiare il modo in cui scrivi il codice (nota: questa è generalmente una qualità terribile da avere come programmatore), questa è un'alternativa molto più praticabile che semplicemente scrivendo la tua lingua. Ciò richiederebbe forse un paio di settimane al massimo . Confrontalo con gli anni che verrebbero spesi in un linguaggio corretto, con un ricco supporto per il debug e simili.

Se i tuoi problemi sono più grandi di questo (i globali sono quelli predefiniti, quindi ti richiedono di usarli localovunque), alcuni di questi possono essere gestiti (rendi semplicemente la dichiarazione di un nuovo globale un errore, attraverso l'uso di ambienti e metatable alterati). Se odi le funzioni come oggetti di prima classe, coroutine, raccolta dei rifiuti o altri elementi di base di Lua ... beh, allora sei in un inferno di tua creazione;)

E se davvero, vuoi davvero essere hardcore, puoi scrivere la tua lingua che compili in Lua. Quindi almeno sarai in grado di sfruttare il runtime Lua molto collaudato, l'eccezionale API Lua e altre strutture Lua di base, tutto dalla tua lingua! Lua. Ci vorrà del tempo, ma non saranno ancora gli anni a spendere qualcos'altro.

Per completare le altre risposte, questa non è un'opzione strettamente binaria. All'interno di un linguaggio di scripting esistente, puoi anche creare il tuo linguaggio specifico per il dominio . I vantaggi di questo approccio sono:

• In realtà non devi fare confusione con grammatiche formali, parser, implementare editor personalizzati ecc.
• Stai ottenendo il massimo beneficio dall'implementazione di un linguaggio di scripting specializzato, ovvero un'astrazione aggiuntiva, specifica per il tuo gioco.
• vs. homebrew: gli utenti che hanno familiarità con il linguaggio di scripting di tua scelta saranno immediatamente in grado di utilizzare il tuo DSL.
• rispetto al semplice linguaggio esistente: gli utenti che non conoscono il linguaggio di scripting dovranno solo conoscere il DSL per modificare il gioco.

Lo svantaggio principale è che si progetterebbe il DSL con i vincoli del linguaggio "base".

Si potrebbe dare un senso a seconda delle meccanica del vostro gioco. Alcuni giochi con una meccanica abbastanza semplice potrebbero usare un linguaggio interpretato per salvarsi da una codifica Lua / Python troppo complicata, ma i risparmi di complessità potrebbero non valere troppo. Ad esempio, uno di quei giochi di Interactive Novel potrebbe facilmente utilizzare un motore di scripting personalizzato.

Se il tuo gioco coinvolge un motore fisico, vari componenti del gioco e una diversa complessità di personaggi e abilità, dovresti assolutamente considerare di guardare altri linguaggi di scripting esistenti, quindi non stai cercando di aggiungere le funzionalità necessarie a quello personalizzato o correggere i bug con esso. Mentre Lua è probabilmente il più veloce, ce ne sono molti altri che potrebbero piacerti di più per la loro sintassi, e molti di loro si vantano della facilità con cui si integrano con C. Python, Ruby e Angelscript. (Sentiti libero di menzionare gli altri nei commenti)

Se si garantisce che tali linguaggi vengano utilizzati solo per il "controllo logico" (ovvero la gestione di un caso di collisione specifico per determinati tipi di oggetti, come l'esplosione di fiamma che tocca un blocco di ghiaccio), le prestazioni non saranno quasi mai un problema. Naturalmente, d'altra parte, se li usi per più codice di routine (creando un algoritmo di controllo delle collisioni personalizzato che esegue ciascun frame) è più probabile che ti impantoni.

Dico, provaci. Su un curriculum sarebbe uno spettacolo in più di abilità. Tuttavia, tieni presente che devi prima avere questa capacità. Non sarà facile, sarà piuttosto difficile. Ci sono libri sull'argomento e anche tutorial online, ma alla fine dipenderà da te e dalla tua comprensione di come funziona un compilatore e di come il codice viene analizzato e tradotto.

Assicurati di iniziare in modo semplice, testare frequentemente e mantenere il tuo ideale. Ma ricorda sempre, LUA è lì per te.