Dragon ruby

Пользуюсь этим фреймворком уже пару месяцев для разработки. И нашёл его достаточно интересным для прототипов.

Ограничения тоже есть - не полная поддержка руби и гемов.

Давайте рассмотрим со стороны плюсов, а потом зайдём на минусы и общее впечатление.

Учитывая, что он поддерживает динамическую перезагрузку кода (Юнити только обещает это, но на средней сложности проектах приходится прям долго ждать перекомпиляции, а возиться с ассемблями не всегда удобно - ведь если я уже имею архитектурный проект, то мне не нужна автоперегрузка, а когда мне нужно прототипирование - тут надо делать это быстро)

И это заметный плюс фреймворка.

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

Потом, можно постепенно улучшать код в сторону классов или функций - какая модель вам больше подходит.

Такая минимальная модель без трения удо на для прототипирования.

Очень напоминает работу с AppGameKit - поскольку так же быстро. Плюс преимущества Ruby vs basic в виде хешей и функционального и ооп подхода.

Приложения получаются очень маленькие и одной командой происходит публикация на несколько платформ.

Использование wasm позволяет посто использовать свой код в браузерах. И он просто работает так же (в отличие от AppGameKit)

Консоль для отладки и отладочные примитивы также помогают в разработке.

Последнее время много документации с примерами кода и даже часть библиотеки представлена кодом руби.

Теперь рассмотрим минусы, которые нашёл :

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

Часто проблемы были связаны со сложным кодом, который сам написал. И приходится переучиваться и выбрасывать старый код и переписывать заново кусок, который не работает.

Ветки гита в этом помогают.

Производительность оставляет желать лучшего. Bunnymark показывает три-пять тысяч спрайтов, что для среднего проекта сойдёт.

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

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

Публикация за платную версию на пк и хтмл. Мобильная версия или более сложные проекты с частью проекта в библиотеках на си требуют подписки до $200 в год. Напоминает Юнити с подпиской на $340 в год за логотип свой и сервисы.

Но у Юнити больше всего - и инструментов, и документации, и комьюнити.

В общем - напоминает геймекер, но с подпиской.

Выводы:

Для мелких проектов и прототипов самое то- быстрый цикл обратной связи позволяет быстро спрототипировать систему. После же, имея структуру проекта и документацию по механикам - можно выкинуть прототип и переписать на c#/raylib/sdl.