Comments 5
Александр, мое почтение! Даже если не выстрелит или забьете и приступите к другому проекту — все равно это хороший опыт.
Хотелось бы побольше мяса и подробностей в статье, а также прочее: предыстория разработки фреймворка (курсовая/дипломная работа или другое) или с чего начинали, работали один или с командой, что читали, чем вдохновлялись, на какой он стадии (картинку выводит или нет), к чему хотите прийти и т.д.
Воу! Спасибо) Вообще, 2 года работал с командой над игровым движком Case Engine (информацию можно найти в интернете), но то ли из-за нехватки опыта тогда, то ли из-за чего-то другого, проект не удалось довести до релиза. А этим летом решил начать разработку игрового фреймворка, ибо страсть делать игры на своём двигле не пропадала)
Ну, делать движок ради движка это идея, конечно, сомнительная, потому что такую вещь всегда лучше писать под конкретную игру. Поэтому начал с дизайн документа самого игрового проекта Oriol и т.д.
Что касается самого Oriol Engine, то фреймворк очень обширный, его части можно рассматривать на протяжении огромного количества статей. На данный момент полностью готов только его вспомогательный модуль Aid и пассивно-агрессивно разрабатывается графический Gfx модуль)
Про Case Engine тут слышал, две статьи их видел. Очень жаль, что не срослось с разработкой.
Я уверен — ребята клевые, но вот на Хабре статьи не взлетели, т.к. не о том писали — от разработчиков движков (даже начинающих) ждешь какой-нибудь жести и офигительных историй, а не туториалы по VS 2022 и избитые учебные статьи в духе, как писать на плюсах.
Под офигительными историями и жестью я понимаю: «Увидели на конференции такой-то доклад такой-то студии и решили запилить подобную фичу в наш движок. Сначала сделали так <описание во всех красках не очень гениального решения>, но не сложилось, потому что ... А затем мы пошли другим путем <описание во всех красках гениального решения> и всех победили. Вот вам бенчмарки и список литературы.».
Не обязательно же отвлекаться от разработки, тратить время и разжевывать для самых маленьких, как пилить свой движок от А до Я и все его возможности на 100500 статей ради плюсиков на Хабре. Достаточно редко, но метко раз в полгода-год вот такое выдавать.
В целом, желаю удачи.
есть утилита glslang, лучше не делайте сразу всё доделайте просто функционалы игры, тоесть движок через игру, может и не нужен будет кросс, кросс это уже движение во все стороны, да hlsl поинтереснее
лучше эти силы потратить на модуль lua или аля ввод скрипта по-типо блюпринтов ( интерфейс, программирование логики доступной на скрипте ), смена поведений на горячую, всякие сценарии (или даже пулы сценариев может быть ), тоесть я предлагаю сконцентрироваться на нитках от кор до конечных идей в игру, попутно оборачивая это в движок тогда наверное уже
по ниткам если идти там будет многое завершено, а кросс, во все стороны просто идёт поидее
glslang это больше про разбор самого языка GLSL. В нашем же случае требуется разбирать только HLSL. А насчёт всего остального, я изначально планировал фреймворк как кроссплатформенный. Ибо такой момент как кроссплатформенность должен решаться в самом начале. Добавлять его где-то на середине работы это мрак)
Насчёт lua или добавления других скриптовых языков, то это нарушило бы концепцию. Потому что цель сделать что-то похожее на SFML. Где весь код игры пишется на одних плюсах с помощью готовых компонентов фреймворка
Oriol Engine: как мы решили проблему кросс-компиляции шейдеров