---

...

Игра-то получилась?
Значит движок норм, достаточно хорош.

пора писать на нём ммо

Код не смотрел, но зачем core.delta не совсем ясно. Для отображения нужен (сглаженный) ФПС, а для игровой логики лучше таймер или что-то с фиксированной дельтой времени. Конечно фиксированную дельту легко свелосипедить на дельте, но зачем?

Джек Аллигатор
> Модули:
Архитектура может быть самой разной, нет одной правильной и для всех.

> получить критику от сообщества
Главная критика будет от того, кто движок использует. То есть от тебя самого. Тебе удобно, быстро сделал много игр? Хороший двиг. Мало сделал, медленно делаются? Плохой двиг.

Джек Аллигатор
> Так вот - правильно ли сделано ядро? Менеджер клавиатуры и тд? gui? Правильно
> ли я вообще распланировал архитектуру модулей, их связей, методов и тд?
У архитектуры есть вполне объективные факторы "годности".
- Легкость модификации и развития.
- Легкость использования.
- Безглючность.
Вот и смотри. Ну к примеру легкость модификации и развития можно проверить сделав перемещение фигур тетриса плавным, а не по блокам как наверное сейчас. Или заменив квадратные ячейки тетриса шестиугольными.
Если такие штуки делаются легко, без переписывания основ, то архитектура норм.

Для тайловых игр типа тетриса я бы сделал отдельную систему для тайловых карт. 
Профит очевиден —  после тетриса с минимумом геморроя сможешь сделать импорт из  Tiled, 
или свой редактор карт приделать. А там уже и более интересные темы пойдут заодно вроде
системы коллизий / физики,  потайлового освещения и т.д.

Квады которые не привязаны к сетке,  но статичные,  тоже нужно объединять в один меш — получишь статический батчинг.

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

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

После того как разберешься с адвансед частью выведения графония, надо будет задуматься об удобстве написания игровой логики.
Нужен будет достаточно гибкий фреймворк для управления  игровыми объектами,  скорее всего у него надо будет продумать API и
отправить на съедение какому нибудь скриптовому языку, например Lua или что-то более экзотическое.

Самым логичным действием считаю поход в мир какого-нибудь MonoGame, и анализ того как выстроена работа.
Понять что там удобно для тебя а что нет, и почему.

Джек Аллигатор
> Зачем вообще выносить игровую логику в скрипты?
В идеале для того чтобы сценарии писал не программист а какой-нибудь левел-дизайнер,
либо писал программист с набором скиллов именно в реализации игровой логики, а не в дебрях си++.

То бишь, должна быть быстрая низкоуровневая часть и высокоуровневая обертка над ней.
Можно делать и без скриптов, но высокоуровневая обертка в лице удобного фреймворка все равно будет нужна,
как пример опять же упомянутый мной выше MonoGameXNA.

Ну и допустим у нас не просто игровой движок, а движок с редактором. Нам нужно быстро вводить функционал в игру,
сделать это можно:
    1. через скрипты(пример — юнити);   
    2. через некий графический программинг(пример — анрил и юнити).
    3. через пинание программиста движка(а не игрового программиста, потому что получается что у нас у всех программистов специализация — движок) на реализацию очередного компонента для возникшей нетипичной задачи.

Естественно, в 1 и 2 случае тоже возможно пинание движкового программиста, но этот вопрос будет возникать намного реже, потому что чаще всего можно будет справиться своими силами.

У движка Godot открытые исходники. Считаю этот движок неплохим. Посмотри для интереса как там делают (я тоже хочу когда-нибудь это сделать но пока не смог), заодно по модулям и структуре фреймворка возможно вопросы прояснишь

Для 2д-движка на rust, возможно, технологии из 3д движков будут чрезмерным усложнением. Те же скрипты - по-моему в большинстве в 2д игр всего один программист, поэтому смысла в них при условии что движок и так написан на нормальном языке нет.
С другой стороны ты вроде трехмерный и собираешься делать, тогда всё ок, но имхо лучше и пример игры сразу трехмерный сделать, много ньюансов сразу выявится.

Ого, я как-то сразу не посмотрел на каком языке игра

Впервые вижу код на этом языке, но у меня есть вопрос. Тут каждый раз заново аллоцируется память?
// рендеринг
        render_state = game_state.clone();

        for (x, y) in active.shape {
            render_state.set(active.x+x, active.y+y, active.shape.get(x, y));
        }

ыы, я видел тему и уже собирался ответить, но потом отвлекли и я забыл.
В общем
- физика намного проще если она с фиксированным шагом. И считается быстрее и проблем меньше. Соответственно допустим у нас шаг 1/60 секунды.
Теперь есть два варианта тормозов - если тормозит физика (ну и игровая логика, в общем обновление мира) и если тормозит рендер.

Если тормозит физика - ничего не сделаешь, она просто не будет укладываться в 1/60 секунды и игра замедлится. Либо не допускать этой ситуации выбрав шаг побольше, либо смириться с тем что действие в игре будет замедляться.
Если тормозит рендер - нет смысла честно считать физику 60 раз в секунду если пользователь все равно увидит изменения только 5 раз в секунду. С тем же успехом мы могли бы считать по 12 апдейтов физики (все с тем же фиксированным шагом 1/60) перед каждым кадром. Ну и как это реализуется я думаю очевидно.

Насчет потоков - проблемы без синхронизации возникают если во время апдейта может возникать несогласованное состояние. Например игрок телепортировался и мы сначала обновили Х (тут вклинился рендер) а потом обновили Y. В итоге он нарисуется не в том углу.

Джек Аллигатор
> Здесь на этот случай есть каналы.
Ну каналы это один из способов синхронизации. А то "синхронизировать ничего не надо" меня уж очень поразило.