Вы видимо вообще не о том подумали. API я не делю.

Я делю стейты луа, для движка вся важная инфа будет в сингелтоне и из него же будет вызывать любой API не связанный с конкретной частью игры.
Если меню, ему не доступна физика. и.т.д и.т.п

Луа не хеширует таблицы, мы их сравнить даже не можем.
Или я чего то не знаю? Может вы подумали про хеширование ключей в таблице?

ТО есть по юзердате управлять компонентами, которые и так и так будут на стороне раста.
Грубо говоря мы получаем ссылку на компонент или айди. По которму можем использовать функционал.
Куда мы закинем этот айди, это уже решает юзер. Но я не хочу давать создавать свои компоненты пользователю, только компоненты на основе встроенных.

Многопоточность мне пока не нужна, но в перспективе вынести системы которые могут быть использованы из другого потока, это хороший буст.

Враперы есть, но как работать со стеком без стека?
Я не понимаю.. Но я и так юзаю mlua.

Хаос потому что таблицы луа неограниченны ничем , это буквально бесконечная пропасть.
Что бы это все валидировать, нужно тратить лишние ресурсы? Зачем. Я не видел чего то такого в игровых объектах. А в бизнес логике , там уже как юзеру удобнее.

Почему я усложняю? Наверное потому что архитектура самая важная вещь.
В большинстве Lua движков ее нет и работать не приятно.
Я хочу писать кор вещи на расте, а на луа писать игру.

> создание компонентов в Lua > Хаос потому что таблицы луа неограниченны ничем у вас ECS чтоль? я не понимаю... Никто не запрещает использовать комплексный подход, когда компоненты обрабатываемые растом (корневые) хранятся как userdata, а кастомные из луашки - как таблицы этой самой луашки. Т.е некоторые имена компонентов рарезервированы и им соответствует определённый тип в расте и из луа он не может быть переопределён. Создавать компоненты на основе встроенных - звучит супер непонятно. > Отдельный файлик для меню, для настройки и уровня. зачем? Я понимаю отдельный стейт луа для аудио, может быть потенциально отдельных потоков, но зачем на уровне движка делать такие колоссальные различия и определять такие специфичные вещи как меню? А если завтра нужно будет добавить маркетплейс? На расте будешь новые компоненты и отдельные стейты под это выделять?

Про хаос без ограничений. Можно же сделать ограничения. Перегрузить __newindex чтобы контролировать создание новых полей, их значения и типы. Использовать прокси-таблицу, чтобы контролировать доступ. Порядок сначала наводится в логической структуре. А потом (при желании) реализуется методами языка :)

Зачем делать ограничения на стороне Lua? Которые будут еще и менее производительнее. Если можно создать четкую структуру на Rust? и контролировать ее из Lua?