Структура проекта игрового движка (C++) (3 стр)

war_zes
> Тут другой вопрос - зачем тебе движок как DLL библиотека? Просто чтобы было?
> Если ты пишешь для себя-  делай статическую
Вот соглашусь с варзесом! Нахрена тебе DLL? Пиши в статической либе все. Какой смысл создавать себе кучу проблем из ниоткуда? Ускорять пересборку движка? А уже есть проблема долгой пересборки? Ты вообще уверен, что дойдешь до этого этапа?)))

Vlad2001_MFS
Hot reload а-ля Casey Muratori?
Те кто юзал хвалят, вроде.

ufna
> Или что не надо загоняться и делать просто "чтобы работало и навсегда" и
> учиться в процессе?

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

Vlad2001_MFS
> Нахрена тебе DLL? Пиши в статической либе все.
Если нет способа сделать хорошо используя DLL, то видимо придется отказаться от этой идеи. Но все же, если учитывать что DLL используют в игровых движках, можно сделать вывод что какой-то способ всё таки есть. Мне просто интересно, можно ли как-то решить эту проблему с экспортом API-шных классов. Если я пойму что так не делается (и пойму почему) при использовании DLL, буду делать иначе.

AlexNem
> У меня куча таких начатых репозиториев, где я пытался что-то делать чтобы это
> как-то работало.
Потому что ты ставишь перед собой задачи, которые тебе не под силу.
  Например написать аналог STL - там ты потратишь годы на его написание, но по движку при этом так и не продвинешься вперед.

  Тебе необходимо научиться ограничивать себя и не влезать в проЭкты, которые тебе предлагает твой мозг. Скажи ему "Хватит, надоело! Давай лучше реальные проекты будем делать! "

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

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

Это жизнь как бы. Любой, совершенно любой движок из известных на рынке - с точки зрения архитектуры в вакууме - кусок ужасного кода, набор костылей, велосипедов и вообще неудачных решений. Что анрил, что юнити, что край - там многие вещи просто заставляют плакать, не говоря уже о движках "второй волны" аля Годот, Дефолд и иже с ними.

Их сила просто совсем в другом. У них баланс "можно работать и развивать" vs. "архитектура табуреточки" смещен в "можно работать", и целая армия людей кто это все развивает. Потому что не смотря на все минусы есть плюсы, которые делают использование движка разумным.

Ну и не надо писать "движки в вакууме". У любой разработки должна быть некоторая достижимая цель. "Обучение" - вообще норм, проитерировался и выкинул. "Движок для игр" - для каких? "Универсальный" - тогда ты прям обязан изучить решения на рынке, чем твой должен быть лучше? "Движок для игры" - пиши эту игру, накрайняк - "движок для жанра", а не пиши "универсальный случай".

Кто пользователь твоего движка? Что нужно этому пользователю? И тому подобные вопросы - они помогут хорошо расставить приоритеты.

Также рекомендую к прочтению: https://seanmiddleditch.github.io/makes-games-not-engines-to-learn-engines/

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

ufna
Ты еще забыл уточнить, что над тобой обычно есть десятки экстремально крутых инженеров и лидов. Что 90% кода движка не меняется. Что какой-нибудь лид из соседней комнаты сам за неделю перенесёт всё на новый стандарт и прочее. А ты будешь писать парсеры gltf в уже написанной 20 лет назад потоковой модели. Что если хочется хеви тредед, то есть открытый proland. Что любая подсистема с продакшна это 50к+ строк кода. Что любая подсистема домашней демки это 2-3к строк кода. Что до 2013 всё было на 1 потоке. Что целые движки живут на frustrum culling + glDrawElements (и ничего сложнее). Что уметь сжимать текстуры из головы или резолвить дедлоки в таск графе для движка важнее, чем рендер.

FordPerfect
> Hot reload а-ля Casey Muratori?
> Те кто юзал хвалят, вроде.
Хот релоад прям всего движка? В моем понимании оно бы хоть как-то подошло как аналог игровых скриптов.
Но вообще, лучше просто прикрутить daScript к движку, чем извращаться с хот релоадом dll.

#!

Vlad2001_MFS
> прикрутить daScript к движку, чем извращаться с хот релоадом dll
одно другого не отменяет, в том же анриле ты можешь менять как блюпринты (аналог скриптинга), так и код игрового модуля (dll), и потом подгружать его на лету в открытый редактор

Vlad2001_MFS
> лучше просто прикрутить daScript
схренали высокоскоростной нативный с++ код хуже чем скриптошляпа какая-то?
зачем вообще dll по твоему были придуманы?

Misanthrope
> схренали высокоскоростной нативный с++ код хуже чем скриптошляпа какая-то?
Потому что эта "скриптошляпа" может в hot reload во время разработки. А еще при сборке полноценного бинарника эта "скриптошляпа" автоматически превращается в "высокоскоростной нативный с++ код".