In quali casi quali linguaggi di scripting sono meglio di altri?
Tutte le risposte sono apprezzate, si prega di fornire una descrizione e descrivere in quali casi eccelle la lingua.
(Ricorda, una lingua per risposta)
In quali casi quali linguaggi di scripting sono meglio di altri?
Tutte le risposte sono apprezzate, si prega di fornire una descrizione e descrivere in quali casi eccelle la lingua.
(Ricorda, una lingua per risposta)
Risposte:
Lua è ampiamente utilizzato nell'industria dei giochi . Dai giochi indipendenti ( Aquaria ) ai titoli AAA (Civilization).
La ragione principale? Direi perché è facile da imparare e facile da integrare nei tuoi giochi. Ma lo stesso si può dire per Python, ne sono sicuro. Lo scripting, in generale, non è difficile. Penso che la vera ragione per cui dovresti andare con Lua è perché è dimostrato che si traduce in molte più risorse là fuori per imparare da te. Se hai voglia di sperimentare qualcosa al di fuori della norma, allora inizierei a fare confusione con un'altra lingua.
Lo scoiattolo ha una storia interessante. È stato costruito dopo che un architetto del gioco ha avuto problemi con l'imprevedibile raccolta di rifiuti di Lua e tutto è pazzo anche se non esiste .
Lo scoiattolo è il linguaggio di sripting utilizzato in Left 4 Dead 2 . L'API è molto simile a lua (l'autore di Squirrel adora il design di Lua ).
Quindi lo scoiattolo è un linguaggio fantastico poiché è un po 'Lua di seconda generazione. Ha preso le buone idee e rimosso le fastidiose eccentricità.
Lo stesso di Lua:
Nuovo per lo scoiattolo:
Lo svantaggio principale dello scoiattolo è che non è Lua. Lua è molto più ampiamente utilizzata. Ma se questo non è un problema, lo scoiattolo è una vittoria facile. Tuttavia, spesso la popolarità della lingua è utile in sé, quindi la decisione non è così chiara.
V8 Javascript da google.
Professionisti :
Abbastanza facile da usare
Migliorare costantemente
Potente e flessibile
Altro Come molti hanno già detto, JavaScript è uno strumento di programmazione comune. L'aggiunta ai miei giochi ha aperto molte più persone che si sentono capaci rispetto ad altre lingue. Supporta anche un'enorme quantità di casting e conversione per risparmiare sul lavoro per il programmatore, lo rende anche molto facile da usare, funziona bene con STL.
Possibili CON:
La documentazione può confondere Non è davvero il migliore.
Esempi Spesso una rete di stranezze. Mancando di solida semplicità, si presenta come un livello molto più alto di quello che è.
Modelli A volte questi sono odiati o evitati.
Dimensione della base di codice dell'SDK La dimensione del codice generata può essere considerata gonfia.
Dipende dal gioco e dalla sua piattaforma di destinazione.
Un gioco che esegue 100 personaggi non giocatori (giochi RTS) ha esigenze diverse da un gioco che esegue solo 2 (Street Fighter). Un gioco che gira su un PC ha esigenze diverse rispetto a un gioco che gira su una console.
Lua è popolare
GameMonkey è utilizzato da diverse squadre. È più veloce di Lua e migliore nel threading.
Python è stato utilizzato in diversi giochi.
JavaScript è un'opzione possibile in quanto è possibile scaricare motori JavaScript. Esistono più programmatori JavaScript rispetto a qualsiasi altro tipo di programmatore.
Ci sono anche lingue specializzate.
SCUMM è stato utilizzato in diversi giochi di avventura ed è particolarmente adatto a quei giochi.
Per completezza, un'altra opzione è mono-script , che consente di utilizzare l'implementazione Novell di .NET framework per gli script. È ciò che utilizza Unity . Ecco un'altra pagina sull'incorporamento di mono nella tua applicazione.
Il framework Mono è più veloce della maggior parte (forse tutti?) Dei linguaggi di scripting là fuori perché non è interpretato, e poiché c'è un livello tra il compilatore e il set di istruzioni, ti consente di programmare in una varietà di lingue tra cui C # e dialetti di Python, Lua e Javascript.
Tuttavia, non sono sicuro che sia gratuito su tutte le piattaforme.
Personalmente, ho trovato AngelScript (vedi link sotto) molto più facile da associare a C ++ rispetto a Lua quando stavo scegliendo un linguaggio di scripting per il mio progetto. (In realtà ho scritto una piccola libreria wrapper per renderlo ancora più facile da usare, a costo di una certa flessibilità.)
http://www.angelcode.com/angelscript/
Detto questo, sospetto che Lua abbia alcuni vantaggi che la rendono interessante per gli sviluppatori di giochi commerciali:
(a) È più maturo e diffuso di AngelScript
(b) La sua sintassi è più semplice per i non programmatori (AngelScript è molto simile al C ++)
(c) Ha un footprint più piccolo di AngelScript (almeno per quanto ricordo)
Se stai solo scrivendo un progetto per hobby, direi che AngelScript merita almeno una visita.
Dovresti scegliere un linguaggio di scripting che abbia legami stabili e ben supportati con il linguaggio di sviluppo principale del tuo gioco. Se stai scrivendo il tuo gioco in C o C ++, allora ci sono collegamenti piuttosto solidi disponibili per Python e Lua. Se stai scrivendo il tuo gioco per la piattaforma .NET (usando C # o un'altra lingua), ti consiglio vivamente di usare IronPython o IronRuby. Entrambe sono implementazioni linguistiche complete che sfruttano il Dynamic Language Runtime (DLR) di Microsoft, che offre prestazioni eccellenti e una stretta integrazione con .NET Framework. L'interoperabilità tra C # e IronPython / IronRuby è piuttosto regolare in questi giorni, specialmente con l'introduzione dell'associazione dinamica dei siti in C # 4.0.
Bene, astuzia in particolare.
Con astuzia puoi avere il tuo DSL (Domain Specific Language) solo per il tuo gioco. Una volta abituati alle parentesi e alla notazione del prefisso, lo schema è il paradiso con cui lavorare.
Se hai intenzione di usare l'astuzia in un gioco serio, aspetterei un paio di mesi fino alla versione 2.0 in quanto includerà, IIRC, un interprete Ecmascript e l'attuale schema. Puoi anche aspettarti di vedere grandi miglioramenti della velocità.
Questo dipende da cosa ne hai effettivamente bisogno. Come sottolinea David, Lua è molto popolare, sebbene uno sviluppatore di giochi mi abbia notato che non era del tutto sicuro del perché. Penso che la sua leggerezza sia una ragione comune, ma a quel punto mi aspetterei che molte persone usino Lua perché è diventato di fatto lo standard. Sembra migliore per modifiche molto leggere.
Per un approccio più completo, direi che Python è la scelta giusta. Civ IV lo usò con effetto decente.
La scelta di un linguaggio di scripting rispetto a un altro dipende dai requisiti specifici dell'utente.
Alcune delle opzioni che devi scegliere potrebbero essere:
Velocità dell'interprete - se la funzione di scripting viene utilizzata esclusivamente dagli sviluppatori per eseguire script di comportamento statico, la velocità e un'API completa ed estensibile possono essere l'aspetto più importante. Lì ho avuto delle belle esperienze con LUA.
Facile da imparare, accessibilità - per un disegnatore di contenuti / livelli potrebbe essere difficile imparare linguaggi di scripting più complessi (dipende dallo sfondo) per generare comportamenti dinamici. In tal caso, l'uso di lingue facili da imparare (cioè comunemente usate) e ben documentate potrebbe essere più appropriato qui. JavaScript o Python potrebbero essere una buona soluzione qui.
Integrazione del flusso di lavoro: se si dispone di una specifica pipeline di produzione con strumenti già esistenti, potrebbe essere una cattiva idea utilizzare un linguaggio che sembra funzionare meglio per un determinato caso se gli altri strumenti funzionano con uno completamente diverso. Ciò è particolarmente valido se hai diversi programmatori che lavorano sui diversi strumenti. In tal caso, potrebbe essere più efficiente utilizzare il linguaggio "non del tutto adeguato".
Se stai lavorando a un titolo per Windows e stai scrivendo un codice gestito in esecuzione su Common Language Runtime (CLR) - diciamo ad esempio in C # - ti suggerirei di dare un'occhiata all'integrazione di (Iron) Python come linguaggio di scripting.
Nella mia esperienza, Python è molto facile da insegnare ai non programmatori / designer. È ancora più facile da raccogliere per gli sviluppatori poiché essenzialmente legge come pseudocodice. Essere digitati in modo dinamico è solo uno degli aspetti che aiutano le persone con poca o nessuna esperienza di programmazione precedente a funzionare velocemente con la lingua.
Oltre che la lingua è facile da imparare e potente, i team CLR e di lingua di Microsoft (Anders Hejlsberg, Eric Lippert, Mads Torgersen, Jim Hugunin e altri) hanno svolto un ottimo lavoro nell'esporre le funzionalità di compilatore e runtime tramite la nuova dinamica Language Runtime (DLR) in .NET 4, rendendo l'interoperabilità tra codice tipizzato staticamente e codice digitato dinamicamente molto più semplice. Da quello che ho visto e provato finora, il codice del boilerplate è ridotto al minimo. Manterrà il tuo codice base pulito e gestibile.
Puoi utilizzarlo per mantenere molto basso l'attrito tra le parti del tuo script e il motore. Avere entrambi eseguiti nella stessa macchina virtuale consentirà inoltre al runtime di ottimizzare una parte maggiore del codice durante l'esecuzione.
Se disponi di un team esistente che utilizzerà il linguaggio di scripting o un lead designer (di livello) che utilizzerà lo scripting, scegli la lingua che preferisce. Trascorreranno il loro tempo con esso, quindi dovrebbero essere soddisfatti.
[granello di sale] Se non hai nessuno o pianifichi a lungo termine, lancia il tuo . sì, scrivere un compilatore e / o un interprete per un linguaggio di scripting potrebbe richiedere una settimana o due, ma a lungo termine la flessibilità pagherà molte volte. Basta non andare troppo lontano e reinventare Brainfuck. [/granello di sale]