Quale strategia deve essere usata quando si espone C++ a Lua

Question

Ho una libreria C++ che ha funzionalità esposte a Lua e sto cercando opinioni sui modi migliori per organizzare il mio codice lua.

La libreria è un motore di gioco, con un sistema di oggetti di gioco basato su componenti. Voglio essere in grado di scrivere alcuni di questi componenti come classi in Lua. Sto usando LuaBind, quindi posso farlo ma ci sono alcune scelte di implementazione che devo fare e vorrei sapere come gli altri l'hanno fatto.

Dovrei avere solo un lua_State globale, o uno per oggetto, uno per scena, ecc.? Questo suona come un sacco di memoria in testa, ma manterrà tutto bello e separato.

Devo avere una tabella GLOBALS o una per oggetto, che può essere messa in atto prima di una chiamata a un membro? Ciò sembrerebbe ridurre al minimo le possibilità che alcune classi decidano di utilizzare i globali e un'altra sovrascriverla accidentalmente, con un sovraccarico di memoria inferiore rispetto a molti lua_States.

Oppure dovrei semplicemente mettere tutto nella tabella globale?

Un'altra domanda riguarda il codice lua stesso. Due strategie si verificano ... Spingendo dapprima tutte le definizioni di classe in un unico posto, caricandole all'avvio dell'applicazione, in secondo luogo inserendo una definizione di classe per file e semplicemente assicurandosi che il file sia caricato quando ho bisogno di istanziarlo.

Gradirei i pensieri di qualcuno su questo, grazie.

Answer 1

Una considerazione è come pianificherai le cose. Se si desidera eseguire il codice per due oggetti di gioco in parallelo, ad esempio, è necessario che abbiano i propri lua_States separati in modo che possano essere entrambi in esecuzione contemporaneamente. (Ovviamente, ciò significa anche che non possono realmente condividere nessuno stato, eccetto tramite il codice C in cui dovresti essere consapevole della sicurezza del thread.)

Answer 2

Mentre LuaBind è sicuramente molto elegante e comodo, come il tuo motore cresce, così anche i tuoi tempi di compilazione, drasticamente.

Se si dispone già o si prevede di aggiungere, un sistema di messaggistica (che consiglio vivamente, specialmente per il collegamento in rete), semplifica notevolmente i problemi. In questo caso, ciò che è necessario fare è semplicemente associare alcune funzioni chiave all'interfaccia con il sistema di messaggistica. Ciò manterrà i tuoi tempi di compilazione e ti fornirà un sistema molto flessibile.

Poiché si sta eseguendo un motore basato su componenti (buona scelta BTW), ha più senso integrare lo scripting come componente di un oggetto. In questo modo, in genere è più sensato rendere ogni componente di scripting una nuova coroutine che esegua il comportamento per ogni particolare oggetto. Non devi preoccuparti troppo della memoria, gli stati Lua sono molto leggeri e possono essere fatti molto velocemente se si interfaccia il tuo gestore della memoria con Lua.

Se si implementa lo scripting come componente, è sempre consigliabile caricare script globali o per livello (per coordinare i trigger di eventi con altri oggetti o con timer di spawning nemici).

Per quanto riguarda il caricamento degli script, non sarebbe una cattiva pratica, caricare solo gli script necessari per un livello tutto in una volta e tenerli in una tabella globale per l'accesso fas, il caricamento degli script lua è carino veloce, specialmente se li hai precompilati.

Answer 3

Per quanto riguarda il codice Lua, ti consigliamo di caricare tutto quando l'app viene avviata (a meno che tu non abbia realmente bisogno di eseguire il caricamento "pigro" delle tue classi principali su richiesta). Solitamente semplifica la manutenzione e il debugging.E nel caso di caricamento del codice non più necessario, il garbage collector lo ripulirà con rapidità. :-)