Если использовать вместо UE5 OpenGL или SDL2 и C++ для создания 2D и 3D игры будет ли она работать эффективнее и занимать меньше места?

Question

[Ланской Кирилл]

Если использовать вместо UE5 OpenGL или SDL(SDL или SDL2) и C++ для создания 2D и 3D игры, как и казуальной, так и полноценного открытого мира, будет ли она работать эффективнее и занимать меньше места? И, если да, то, как это сделать кроссплатформенным и для Google Play тоже(то есть ключи и .aab)?

Тем, кто считает, что у меня уже были похожие вопросы, то да, он внешне похож, но здесь я хочу понять есть ли в этом какой-то смысл, так как есть и те продукты, которые работают на общедоступных движках(UE и Unity), так и на собственных движках.

Comments

[Алексей Уколов]

В принципе, вы решаете свою задачу максимально эффективно, можно только позавидовать: меньше всего ресурсов будет потреблять ненаписанная игра, так что прокрастинация через такие вот вопросы - идеальное решение.

[Adamos]

Человек, задающий такие вопросы, никакого "собственного движка" не напишет никогда.
При этом движки, в т.ч. кроссплатформенные, на UE не заканчиваются, и писать свой тупо незачем.

[Ланской Кирилл]

Алексей Уколов, Если Вам не нравится вопрос, то пытаться уколоть через такие бесполезные и даже вредные не только для меня комментарии, но и для сообщества бессмысленно, Q&A Хабр не создан, как мусорная свалка для тебя

[Ланской Кирилл]

Adamos, Какие вопросы, а то у Вас очень расплывчатый комментарий?

[Saboteur]

Ланской Кирилл,

Если Вам не нравится вопрос,

У вас вопрос бесполезный.

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

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

[Василий Банников]

Ланской Кирилл, а какую проблему ты пытаешься решить то?

Хочешь меньше размер - бери движок полегче, чем UE и не накидывай модели в миллион полигонов и текстуры в UHD.
Маленьких движков сейчас достаточно много - вот Godot хайповый есть.

Хочется ещё легче - тогда бери какую-нибудь библиотеку типа raylib и вперёд.
Можно с плюсов пересесть на Rust и попробовать bevy - тоже очень лёгкий движок

Answer 1

[Wataru]

Теоретически - да. Специализированный движок лишь для вашей игры будет быстрее и легче многофункционального комбайна UE. На практике у вас там объем работы будет на сотню человеко-лет.

Comments

[Василий Банников]

Ну почему сразу на сотню то.
Вот из недавнего есть Highfleet, который на собственном движке работает. Делал один человек.

Правда там физика взята готовая и оно только на винде работает.
(На Линуксе даже через протон не запускается, не говоря уже о телефонах)

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

Answer 2

[Василий Банников]

будет ли она работать эффективнее и занимать меньше места

Если сделаешь более эффективно и компактно, то тогда будет работать более эффективно и компактно.

полноценного открытого мира

Это сразу забудь.
Полноценный открытый мир, разработка в одно рыло, эффективнее чем любой из общедоступных движков, адекватные сроки разработки - выбери, пожалуйста, 3 из 4х.

Учитывай, что UE развивается уже больше 20 лет и над ним работали уже сотни разных разработчиков.
Если ты хочешь сделать что-то подобное, то тогда:
1. Сразу забудь об OpenGL - это достаточно старый API и он не позволит получить максимальную производительность.
(Хотя вероятно он тебе таки понадобится для каких-то платформ)

2. Тебе нужен будет какой-то редактор

3. Раз тебе нужна кросс-платформенность, то тебе нужно поддержать графический SDK для каждой платформы.
На Windows - DirectX, Vulkan
На Linux - OpenGL, Vulkan
На MacOS - Metal

4. Для работы на Android у тебя два независимых куска, которые нужно учитывать:
А - как упаковать уже собранное приложение (на самом деле меньшая из проблем, тк решается)
Б - как собственно взаимодействовать с ОС, как получать инпут от пользователя, как выводить картинку и звук. Тут уже тебе надо обратиться к Android NDK и писать свой код.

5. Осталось малое - графика, физика, загрузка ресурсов (придется научиться обрабатывать файлы с 3d-оъектами и рисовать их), управление. И всё это надо как-то сделать универсальным, чтобы не пришлось для каждой платформы половину кода самой игры переписывать.

А ну и последнее - нужно ещё как-то убедиться, что оно работает лучше, чем уже готовое решение.

И это только по верхам прошёлся, внутри ещё много нюансов.