¿Qué estrategia se debe utilizar al exponer C++ a Lua

Question

Tengo una biblioteca C++ que tiene una funcionalidad expuesta a Lua, y estoy buscando opiniones sobre la mejor manera de organizar mi código lua.

La biblioteca es un motor de juegos, con un sistema de Objetos de juego basado en componentes. Quiero poder escribir algunos de estos componentes como clases en Lua. Estoy usando LuaBind, así que puedo hacerlo, pero debo hacer algunas elecciones de implementación y me gustaría saber cómo lo han hecho otros.

¿Debo tener solo un lua_State global, o uno por objeto, uno por escena, etc.? Esto suena como una gran cantidad de memoria, pero mantendrá todo bien y separado.

¿Debo tener una tabla GLOBALS, o una por objeto, que se pueda colocar antes de llamar a un miembro? Esto parecería minimizar las posibilidades de que una clase decida usar globales, y otra sobreescribirlo accidentalmente, con menos memoria que tener muchos lua_States.

¿O debería tapar todo en una tabla global?

Otra pregunta involucra el código lua en sí. Se producen dos estrategias ... En primer lugar, empujar todas las definiciones de clase en un lugar, cargarlas cuando se inicia la aplicación, en segundo lugar poner una definición de clase por archivo y simplemente asegurarme de que el archivo se cargue cuando lo necesite.

Agradecería cualquier idea sobre esto, gracias.

Answer 1

Una consideración es cómo planea enhebrar cosas. Si quiere ejecutar el código para dos Game Objects en paralelo, por ejemplo, entonces realmente deberían tener sus propios lua_States separados para que ambos puedan ejecutarse al mismo tiempo. (Por supuesto, eso también significa que no pueden compartir ningún estado, excepto a través del código C, donde tendrían que ser conscientes de la seguridad del hilo.)

Answer 2

Mientras que LuaBind es ciertamente muy ingenioso y conveniente, ya que su motor crece, también lo harán sus tiempos de compilación, drásticamente.

Si ya tiene, o planea agregar, un sistema de mensajería (que recomiendo encarecidamente, especialmente para redes), entonces simplifica los problemas significativamente. En este caso, lo que tendrá que hacer es simplemente vincular algunas funciones clave para interactuar con el sistema de mensajería. Esto mantendrá sus tiempos de compilación reducidos y le dará un sistema muy flexible.

Dado que está haciendo un motor basado en componentes (buena opción por cierto), tiene más sentido integrar scripts como un componente de objeto. De esta manera, por lo general, tiene más sentido hacer que cada componente de scripting sea una nueva corutina que ejecuta el comportamiento para cada objeto en particular. No necesita preocuparse demasiado por la memoria, los estados Lua son muy livianos y se pueden hacer realmente rápidos si conecta su administrador de memoria con Lua.

Si implementa scripts como un componente, sigue siendo una buena idea tener scripts globales o por nivel cargados, (para coordinar desencadenantes de eventos por otros objetos, o quizás temporizadores de desove enemigos).

En lo que respecta a la carga de scripts, no sería una mala práctica cargar los scripts necesarios para un nivel todos a la vez, y mantenerlos en una tabla global para acceder rápidamente, cargar scripts de lua es bastante rápido, especialmente si los pre compiló.

Answer 3

En cuanto al código Lua, recomiendo cargar todo cuando se inicie la aplicación (a menos que realmente necesite realizar una carga "diferida" de sus clases principales bajo demanda). Por lo general, simplifica el mantenimiento y la depuración.Y en el caso de que se cargue código que ya no se necesita, el recolector de basura lo limpiará con rapidez. :-)