Комментарии 34
Я вот в раздумьях, потратил где-то 8 лет для написания игры(с перерывами разной длительности). Изучал С++ и графическую библиотеку одновременно, напечатал карточную игру, но код был ужасный(код не сохранился). В чем проблема печатать свой движок расскажу вкратце. Сначала сталкиваешься с проблемами языка на котором печатаешь, потом с тем как обрабатывать изображения, звук, устройства ввода типа клавиатуры или мыши. Далее с тем как управлять камерой (если нужно), печатаешь алгоритм управления cpu, делаешь интерфейс ui, потом упераешься в то, что надо создавать 3d модели (а код одной модели выходит за рамки экрана и состоит из нескольких тысяч строк кода), потом когда думаешь чтобы вынести его в файл отдельный, приходится печатать универсальный загрузчик для любой модели в твою игру/программу(я нахожусь пока здесь). Далее надо создать мир/сцену грубо говоря terrain. И как бы готово! Но в чем медлительность этого всего на моем примере, скажу так чтобы добавить что-то новое в игру, приходится печатать несколько строк, а можно/нужно сделать так как например в unreal или например в maya. Чтобы мышкой перетягивать/задавать координаты, выбирать текстуры(что удобнее и быстрее), остается только разобраться как это все добавить. А дальше вас остановит только ваш полет фантазии. Но как сказал автор время=деньги и батрачить ради своего движка уйдет уйма времени и денег. Вы разве не заметили, что все эти движки типа creation engine, frostbyte, cry engine у каждой студии свой движок и они мало кому нужны, а ваш движок напечатанный одним человеком, будет очень минимальным для ААА проектов и никому не нужным. Если бы я мог вернуться во времени назад я бы не стал этого делать, молодость прошла незаметно потраченное на это.
Зато получен бесценный опыт в разработке.
на динозаврских технологиях никому не нужных теперь
А как же алгоритмы? Развитие мышления? Я думаю у вас всё не зря.
Самое забавное, что я не помню кода, уже год ничего не делал. И еще совет, не вкручивайте сложные конструкции кода и формулы, даже комментарии не помогут. Так что зря - не зря, люди которые моего возраста закалачивают неплохие деньжата, работая на всяких дядь изучив один фреймворк или пару. А у меня так голый опыт, на который если взять там например какого-нибудь профи по играм, разнесёт меня в пух и прах на собесе.
Слишком тонко
приходится печатать универсальный загрузчик для любой модели в твою игру/программу(я нахожусь пока здесь)
Простите, но зачем? Если ответ - чтоб набраться опыта, то ок. Но как по мне разработка движка и разработка каждого отдельного компонента - это разная работа, и цели у нее разные. По мне так важно соблюдать баланс между собственной разработкой и использованием готовых решений. В частности для импорта моделей есть assimp, работающий со всеми популярными форматами.
А иначе недолго до переписывания STL скатиться, что совсем далеко от написания игрового движка, и уж тем более от создания игры.
Да я слышал про assimp, но в том то и дело, что я не собираюсь же на ассемблере например печатать этот загрузчик. Но ведь даже его печатать тоже надо, а мотивации 0 это делать, сил уже никаких нет. Есть видео на ютубчике про него, на английском, ну может когда-нибудь, но не сегодня. Между завтра и никогда вот.
Ну... кто-то (не будем тыкать пальцем на Unreal engine) и stl свой имеет ) И у этого есть даже свои плюсы, поскольку туда можно всякое профилирование понатыкать и всяких крутых штук из C++20, чтобы потом видеть нормальный текст ошибки при компиляции, а не "в десятитысячной строке стотысячного файла stl возникла ошибка: _Ty не соответствует fhdvgdfhgdfg3!+333" ))
Мне тоже стало трудно добавлять в игру хоть что-то новое, придётся делать отдельный редактор эммитеров и пилить универсальные загрузчики. Хочу потратить молодость на это ;]
Уже трачу
Очень вас понимаю. Я вот к тому же хватаюсь и за разные технологии и языки. Вроде бы как и сказали опыт. Но кто-то, как вы скзаали выучить 1 фреймворк и зашибает деньги. А тут знания есть и разнообразные и опыт большой, но все этопо отдельности не нужно.
чтобы добавить что-то новое в игру, приходится печатать несколько строк, а можно/нужно сделать так как например в unreal или например в maya. Чтобы мышкой перетягивать/задавать координаты, выбирать текстуры(что удобнее и быстрее)Вот по этому же принципу, кстати, часто выбираются и готовые движки. Для последнего микро-проекта (платформер на пару уровней для встройки в сайт) изначально был вариант взять Phaser, он и оптимизирован под web лучше и сборка по итогу весит меньше, но в конечном итоге был выбран Godot, потому что сцены были довольно большие и сложные, а удобный визуальный редактор сцены и встроенный упаковщик ресурсов сократили время разработки, а значит и бюджет для заказчика, раза в 2.
Но помните, нет ничего постыдного в том, чтобы использовать для рендеринга готовые библиотеки типа Ogre3D
Эх, где мои 17 лет? Я иногда скучаю по тому ламповому времени, всем этим танцам с бубном по соединению Ogre, Physix, OpenAL, MyGui и Lua.. а все чтобы увидеть зеленого нинзю бегающего по полигону.
Взялся за игростроение, уже второй год пишу движок для своей 2d shoot'em'up игры. Всё взял прогрессивное - clang c++20, opus, stb_image, ffmpeg, webp, yaml, glfw. Начал бойко, а в середине разработки сильно просел - плохая модульность, зависимости классов друг от друга и баги что выстреливают через долгое время после их добавления, всё это сделало разработку рутиной не связанной с самой игрой да и тесты на публике добавили новых требований типа плавной анимации на 144гц мониторах и низких инпут лагах. Со всем этим я разобрался только сейчас благодаря гайдам от дедов, книжкам по гейм дизайну и советам по организации кода большого проекта. Если бы я знал бы это всё когда начинал, то... то ничего бы не изменилось, я бы даже не смог понять все эти советы, ведь не знал бы какие проблемы они могут решить. Надеюсь моя разработка не затянется на 7 лет, уж лучше бы на Годоте игры стряпал
Я конечно не против в геймдеве, но, как мне кажется, автор ещё больший дилетант:
1) Игровые движки отнють не универсальны, в большинстве случаев разработчик упёрся в ограничения, которые будут либо оооочень сложно обходиться либо вообще будут непреодолимыми без доступа к исходниками движка
2) Игровые движки не основываются на SDL (если мы говорим о движках уровня Unreal Engine), у них часто даже стандартная библиотека своя (хотя вот кодеки видео, аудио и т.д. обычно ни кто свои не изобретает)
3) Контроль частоты кадров - плохая практика (как то имел "счастье" общаться с одним игроком, который называл разработчиков игр рукопожатие ибо в одной старой игре у него на современной вилеокарте никогда не было больше 60 фпс). Контролировать надо физику, а кадры должны крутиться на максимум, на сколько позволяет железо
4) Ввод на SDL на винде (на других платформах не знаю как) - это обработка событий winapi, что для игр не очень походит. Следовательно SDL и для ввода тоже не очень
5) Ogre вроде как не библиотека, а полноценный графический движок
6) FMod бесплатный для некоммерческих проектов и инди проектов
круто)
Писать движок нужно, чтобы было портфолио или если дохлый комп.
Книга с нуля — интересный челлендж для писателя. Но если хотите пройти его на сложности Nightmare, можно еще и сделать собственную бумагу, обложку, сварить чернила заточенные специально под проект... а можно придумать ещё и свой алфавит или вообще язык...
Это я, собственно, к чему. Хочешь делать (уникальную, неповторимую, крутую, о которой все мечтали) игру - делай игру, хочешь делать (уникальный, неповторимый, крутой, о котором все мечтали) игровой движок - делай игровой движок, помоему так.
Как быть, когда ты делал-делал игру, и в какой-то момент понял, что не хватает какой-то вещи, более того, разобравшись, ты понимаешь, что ее нету и в других движках?
Ну и пример ваш не корректный, книге достаточно передавать набор букав, иногда картинок, сложно представить, чтобы имеющихся средств не хватало (внезапно, если их действительно не хватит, например, захочет автор, чтобы книга могла передавать определенный запах, то придется что-то выдумывать и даже внедрять в произодство). И уж совершенно смешно высказывание про придуманный язык, который только даст миру большую глубину (тот же властен колец).
А потом понимаешь что стек графики не работает так как ты хочешь и приходится пилить костыли которые просто хардкод или лезть в систему плагинов, изучать ещё как плагины работают а потом только добавить спецэффект "без гемора". База просто, в этом и проблема универсальности, подходит лишь 95% случаев.
Если про аналогию с книгами и языком, то как ты на Англ. сможешь написать "тоскую по родине"? Даже олды этого дела начали делать костыли что бы описать этот момент, так что не всё тут однозначно.
Ну вот Толкин и придумал свой язык и даже не один. В итоге его книги никто не считает "проходником". Более того, некоторые считают Толкина автором фэнтези.
Это я к чему - если хотите сделать шедевр, то надо пилить свой движок.
Как всё сложно :facepalm: Технические сложности всегда были последней проблемой в создание чего-либо. Всё упирается в команду, рынок, личные насущие потребности. Увы в наше время в нашем обществе очень часто как "Лебедь, рак и щука", каждый сильный программист хочет вытянуть что-то сам. Нету консолидации, доверия, веры в общее дело, как уверенности в своей изощренности. ИМХО.
Сейчас как раз изучаю тему программирования графики. Добавлю свои ссылки, если кому интересно:
Learning Modern 3D Graphics Programming - Классная книга, которая на пальцах объясняет базовые принципы работы 3D графики.
Vulkan - По моему мнению, самая продвинутая на данный момент api для работы с 3D графикой. Ничем не уступает DirectX.
Книга Роберта Нистрема "Паттерны Программирования Игр". Удалось урвать бумажный вариант. Просто отличная книга, где буквально написно, как логически создавать игры.
Книги Кнута по Алгоритмам. Лично мне они показались нудноватыми, по этому я взял книгу "Грокаем Алгоритмы" Адитья Бхаргава. По моему, там вполне достаточно информации по алгоритмам, что бы работать с 3D графикой.
Уже отчаялся, но может тут кто знает.
Какой бы специалист ни было хоть сколько движок не пиши, остаётся вопрос с физикой. В идеале распределённой, но это уже частность. Просто нужен физический движок не имеющий упрощений ни при каких условиях.
Все игровые движки по умолчанию имеют неотключаемве упрощения. А требуется именно 100% реализм, ограниченный только в мощность железа. Что бы вероятность прохождения плоскостей друг в друга хоть на 1мм, или улетания объекта в космос была 0.
А в идеале ещё и воксельная физика, что бы симулировать полную структуру любого объекта, с возможностью разрушений и ТД.
Цена/сложность не важна. Что бы не писать самому, может уже существует такой инструмент? Или я первый кто о таком задумался?
Среднему компьютеру не хватает мощности, что бы обработать текущую элементарную физику, что есть в играх, а вы говорите о полной симуляции.
Все игровые движки по умолчанию имеют неотключаемве упрощения. А требуется именно 100% реализм, ограниченный только в мощность железа.
Это не так. Все игровые движки упираются в мощность железа. А "урощения" - оптимизации, которые позволяют работать с текущим железом.
Если вам нужно симулировать некий закон природы, то можно самостоятельно написать симуляцию. Начать, к примеру, с принципов движения и взаимодействия атомов, а затем масштабировать эту модель. Но, само собой, ни о каком рендере в рельном времени, речи не идёт.
Так ограничений по мощности нет, так как это не для средних компьютеров, а для мощных вычислительных кластеров, считайте суперкомпьютеров.
Они считают физику на сервере, как эталон достоверности. А ни клиентах уже может использоваться упрощённая предскзательная, а сервер иногда сообщает реальное положение.
Но как понимаю, ваш ответ - такого инструмента нет, надо писать самому.
Если имеется в виду рендер в реальном времени - нет, такого нет и быть не может. Это физически невозможно.
Если имеется в виду симуляция различных физических моделей, то можно посмотреть в сторону программ 3D анимации. Также, думаю, есть научный софт, но, это всё уже не из моей области.
Так почему в реальном времени невозможно?
Если на расчёт требуется X мощности, а мощность железа 2X, то что помешает просчитать?
Нужна именно 3D симуляция, но динамическая.
Создал объекты, и они между собой взаимодеййствую в среде, подаются команды и тд.
Не заготовка.
Даже науучный софт подойдёт, только в виде именно библиотеки, а не просто программы где тольео внутри можно проводить симуляции.
Так почему в реальном времени невозможно?
Потому что невозможно просчитать движение всех частиц во вселенной?
Потому что, что бы посчитать элементарное освещение в мультике, потребуется пол года работы сервера на 55000 ядер?
Так мне и не нужно просчитывать много частиц.
Просто есть например 2 кубика, и нужно что бы на любой скорости столкнувшись друг с другом, они не вошли друг в друга, а строго всегда реалистично отскочили. Как минимум.
Или погнулись, или разрезались и тд.
Это точно выполнимая задача и на простом ПК, но нужна лишь библиотека..
Но ваш комментарий уже сподвиг меня переосмыслить методы поиска и найти сразу несколько библиотек, хоть и простых. Уже можно их разобрать и получить хоть сборную солянку. Но это уже не с нуля начинать.
А сколько частиц в ваших 2х кубиках? Какие физические эффекты (силы взаимодействия) вы хотите учесть? Ну и кроме моделирования физического взаимодействия останется такая "мелочь" как рендеринг. Он тоже должен быть на 100% реалистичным? Попробуйте начать с уравнений Максвелла, они покрывают большую часть нужных вам задач.
Часто меня неправильно понимают, когда я говорю про физику.
Частиц в кубиках 0, они являются 8 вершинами и 6 полигонами.
Мне не нужно обсчитыват их так, что бы сталкивались как симуляция столкновения галактик.
А просто что бы Невозможно было создать какие то ошибки физики.
Для предотвращения казусов в соревновательной онлайн игре.
И я нашёл то что мне нужно, видео вышло буквально черз несколько дней после моих комментариев тут 😏
https://youtu.be/tjtwSq3u6Dg
Протестировал и работает.
Так же узнал о существовании JoltPhysics. И постепенно сам разберусь в принципах.
Как и зачем создавать собственный игровой движок