Jakiej strategii należy użyć przy eksponowaniu C++ do Lua

Question

Mam bibliotekę C++, która ma funkcjonalność wystawioną na działanie Lua, i szukam opinii na temat najlepszych sposobów na uporządkowanie mojego kodu lua.

Biblioteka to silnik gry z opartym na komponentach systemem Game Object. Chcę móc napisać niektóre z tych komponentów jako klasy w Lua. Używam LuaBind, więc mogę to zrobić, ale muszę dokonać pewnych wyborów dotyczących implementacji i chciałbym wiedzieć, jak to zrobili inni.

Czy powinienem mieć tylko jeden globalny status lua_State, jeden na obiekt, jeden na scenę itp.? To brzmi jak dużo pamięci na górze, ale zachowa wszystko ładnie i osobno.

Czy powinienem mieć jedną tabelę GLOBALS lub jedną na obiekt, który można umieścić przed wywołaniem połączenia z członkiem? To wydaje się minimalizować szanse niektórych klas decydujących się na używanie globaliów, a inne przypadkowo je nadpisywać, przy mniejszym obciążeniu pamięci niż posiadanie wielu lua_States.

Czy powinienem po prostu zakuć wszystko w jeden globalny stół?

Kolejne pytanie dotyczy kodu lua. Występują dwie strategie ... Najpierw popychanie wszystkich definicji klas w jednym miejscu, ładowanie ich po uruchomieniu aplikacji, Po drugie umieszczenie jednej definicji klasy dla jednego pliku i po prostu upewnienie się, że plik jest ładowany, gdy trzeba go wystawić.

Doceniam czyjeś myśli na ten temat, dziękuję.

Answer 1

Jednym z rozważań jest to, jak planujesz gwintować rzeczy. Jeśli chcesz na przykład uruchomić kod dla dwóch Obiektów Gry, to naprawdę powinni oni mieć własne oddzielne lua_States, aby oba mogły działać w tym samym czasie. (Oczywiście oznacza to również, że tak naprawdę nie mogą dzielić żadnego stanu, z wyjątkiem kodu C, w którym trzeba być świadomym bezpieczeństwa wątków).

Answer 2

Podczas gdy LuaBind jest z pewnością bardzo fajny i wygodny, twój silnik rośnie, więc czasy kompilacji drastycznie wzrosną.

Jeśli już masz lub planujesz dodać system przesyłania wiadomości (który stanowczo polecam, specjalnie do sieci), to znacznie upraszcza problemy. W takim przypadku wystarczy połączyć kilka kluczowych funkcji, aby połączyć się z systemem przesyłania wiadomości. Spowoduje to obniżenie czasów kompilacji i zapewni bardzo elastyczny system.

Ponieważ wykonywany jest silnik oparty na komponentach (dobry wybór BTW), bardziej sensowne jest zintegrowanie skryptów jako komponentu obiektu. W ten sposób zwykle bardziej sensowny jest uczynienie każdego komponentu skryptowego nową coroutine, która uruchamia zachowanie dla każdego konkretnego obiektu. Nie musisz zbytnio przejmować się pamięcią, stany Lua są bardzo lekkie i mogą być naprawdę szybkie, jeśli połączysz swojego menedżera pamięci z Luą.

Jeśli zaimplementujesz skrypty jako komponenty, dobrym pomysłem jest załadowanie skryptów globalnych lub na poziomie (w celu skoordynowania wyzwalaczy zdarzeń z innymi obiektami lub może być licznikiem wroga odradzania).

Jeśli chodzi o ładowanie skryptów, nie byłoby złym zwyczajem, wystarczy załadować skrypty, które będą potrzebne dla danego poziomu naraz i zachować je w tabeli globalnej, aby uzyskać dostęp do skryptów, ładowanie skryptów lua jest całkiem niezłe. szybko, zwłaszcza jeśli je wcześniej skompilowałeś.

Answer 3

Co do kodu Lua, zaleciłbym ładowanie wszystkiego po uruchomieniu aplikacji (chyba, że ​​naprawdę potrzebujesz "leniwego" ładowania swoich klas podstawowych na żądanie). Zwykle upraszcza konserwację i debugowanie.A w przypadku załadowanego kodu, który nie jest już potrzebny, pojemnik na śmieci wyczyści to szybko. :-)