Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Регистрируясь, я даю согласие на обработку данных и условия почтовых рассылок.
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр Обычные девчонки Алиса и Вика отправились на поиски друга, который перестал выходить на связь, и угодили в безумный водоворот странных событий на затерянном острове. Им очень нужна ваша помощь! Играйте три-в-ряд и выполняйте задания. Удачи!

ВегаМикс 2

Казуальные, Три в ряд, Головоломки

Играть

Топ прошлой недели

  • solenakrivetka solenakrivetka 7 постов
  • Animalrescueed Animalrescueed 53 поста
  • ia.panorama ia.panorama 12 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая «Подписаться», я даю согласие на обработку данных и условия почтовых рассылок.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Маркет Промокоды Пятерочка Промокоды Aroma Butik Промокоды Яндекс Путешествия Промокоды Яндекс Еда Постила Футбол сегодня
0 просмотренных постов скрыто
49
MakeY0urGame
MakeY0urGame
Лига Геймеров

Unreal Engine или Unity: какой игровой движок выбрать начинающему игроделу? Разбор плюсов и минусов⁠⁠

4 дня назад

Итак, начинающий игродел. Ты принял решение: хочу разрабатывать игры. Глядишь, повезёт, сделаю инди игру и заработаю кучу денег (что возможно), а то и вовсе устроюсь в крупную студию, перееду в Европу и буду разрабатывать игры (что тоже не влажные мечты, а действительно возможно. Например, боёвку в Cronos The New Dawn разрабатывал наш соотечественник, которого взяли на работу поляки).

Но тут встаёт вопрос: а какой движок выбрать для изучения? Unity? Unreal Engine? CryEngine? Godot? RPG Maker? GameMaker? К сожалению, начинающий игродел, если ты мечтаешь изучить движок RAGE (Rockstar Advanced Game Engine), на котором сделали GTA 5 и делают GTA 6 - то забудь. Многие крупные игровые студии используют свои внутренние движки, которые недоступны для общего пользования, а вот вышеперечисленные - доступны.

Но давай так. Сейчас основная конкуренция идёт между Unity и Unreal Engine. Остальные движки... Ну, они конечно используются в индустрии, но не прям уж активно. Сможешь ли назвать сходу игры на Godot?

Поэтому остаются только Unreal Engine, Unity и CryEngine. Но вот в чём незадача... Несмотря на то, что CryEngine - крутой движок, но вот особым спросом в разработке он не пользуется. Да, мы получили шикарный Kingdome Come на нём, а в 2017 году - Prey и ещё несколько хороших игр. Но этого мало, учитывая, что игр выходит каждый месяц очень много.

Поэтому если брать по соотношению качество/популярность, то остаются Unity и Unreal Engine.

И я имею право сравнивать эти движки. Как минимум потому, что у меня есть каналы по Unity и по Unreal Engine. По Unreal Engine я и вовсе имею сертификат от Epic Games, что я могу официально преподавать:

Поэтому - давай начнём.

Что легче изучать?

Unity:

Весь Юнити построен на компонентах и скриптах. Хочешь заставить своего персонажа двигаться? Пиши скрипт. Хочешь, чтобы была возможность управлять камерой игрока? Подключай компонент Cinemachine.

Весь код в Unity пишется на C#. Это не самый сложный язык программирования, но и не самый лёгкий. Иногда порой у тебя могут быть сложности с синтаксисом языка. Но это нормально. Любой язык можно изучить, приложив время. Это нормальный учебный процесс.

При этом если не хочешь писать код руками в C#, то в Unity есть другой язык программирования. Он называется Bolt. Если коротко, то такие визуальные языки программирования состоят из блоков, которые ты вызываешь, подаёшь нужные значения и устанавливаешь значения. Но вот в чём нюанс - этой системой в Unity практически не пользуются. Все привыкли писать код «по-старинке» на C#. И это нормально.

При этом нужно отметить, что по Unity есть куча гайдов в Интернете, а то и скрипты лежат в открытом доступе готовые. Хочешь логику атаки для своего персонажа? Стащи в свой код. При этом у Unity отличная документация. Прям очень структурированная и удобная. Да и образовательные курсы официальные и бесплатные даже есть, а также собственный магазин ассетов.

Unreal Engine:

В Unreal Engine можно работать как на С++, так и на Blueprints. Давай по-порядку. С++ - крайне сложный язык. Ты можешь вбить «самые сложные языки программирования» в Интернете и С++ будет болтаться где-то рядом с Assembler. Например, в C# Unity нет множественного наследования, а в С++ множественное наследование есть (например, если нужно отнаследоваться от класса Actor и ещё отнаследоваться от Interface). Согласись, уже звучит сложно?

Но не беда. В Unreal Engine есть встроенный язык визуального программирования - Blueprints. Он тоже вызывает сложностей, но он всё равно дружелюбнее, чем С++ на старте. Логика та же самая: ты подключаешь нужные блоки друг к другу, задаёшь значения и так далее. «Что выбрать: С++ или Blueprints?» - спросишь ты. А я отвечу: сначала Blueprints, потом - С++, а потом комбинируй. Например, многая логика в Fortnite написана на Blueprints, а на С++ - сетевой код.

По Unreal Engine есть просто тонна уроков на любой вкус, много различных сообществ и обучающих официальных проектов от самих Epic Games (владельцы движка). Но вот за что я ругал, ругаю и буду ругать Epic Games - за их документацию. В ней много мусора, порой не хватает структуры. Ты можешь в документации искать одно, а он тебе выдаст совершенно другое. И окажется, что то, что ты ищешь - оно окажется вообще внутри другой большой темы. Это проблема. Также есть собственный огромный магазин ассетов.

Поэтому вывод здесь такой: Unity для обучения легче. Этим всё сказано.

Где что используется?

Unity:

Преимущественно на Unity делают мобильные игры и инди-проекты. Потому что, опять же, такие игры делать проще, ведь нам там не нужна мегакрутая графика на смартфонах, да и инди разработчики не могут себе позволить технологию фотограмметрии для получения реалистичных объектов и прочее.

Но то, что Unity используется чаще всего в мобильной разработке - это плюс. Ведь мобильный рынок игр обходит рынок игр на ПК по прибыли. Поэтому и вакансий по Unity намного больше, ведь разработка игр на мобилок чаще всего поставлена на поток: студии делают десять мобильных игр, из которых большинство провалится, но одна «залетит» и будет кормить студию долгие годы. Поэтому и разработчики требуются. Многие популярные китайские игры по типу Honkai: Star Rail на Unity сделаны и выглядят хорошо.

Unreal Engine:

Используется везде. Абсолютно. Даже в кино («Мандалорец» и «Мир дикого запада» и прочее). Видел даже музыкальные клипы. Игры, понятное дело, перечислять смысла нет. Их просто дофига. Это могут быть как различные АА игры (Clair Obscure: Expedition 33), так и AAA (серия Mortal Kombat). В Анриле также можно делать реалистичные эффекты прям внутри движка. На Unity тоже есть возможность создания системы частиц, но в Unreal Engine они выглядят намного симпатичнее.

При этом у Unreal Engine огромный инструментарий: вы можете записывать себя на телефон и закинуть в игру даже без аренды студии MoCap. Можете создавать очень реалистичные сцены и так далее. Поэтому будьте уверены: 90% крупных игр на Unreal Engine. Но что у Unreal Engine с мобилками? На самом деле, там тоже всё неплохо: Fortnite, PUBG Mobile, Dark and Darker Mobile. Но вот в чём проблема: это требовательные игры для телефонов. Поэтому бабушка в поликлинике в очереди выберет скорее собирать три в ряд в игре на Unity, чем нагибать других игроков в Fortnite. Не у всех есть мощные iPhone и Samsung последней модели.

Поэтому вывод здесь такой: для больших и красивых игр с реалистичной графикой (пусть и необязательно, можно сделать красиво и за счёт арта) - Unreal Engine, для мобилок и совсем инди-проектов - Unity (хотя на Unity есть Escape from Tarkov, которая пытается в реализм, но у игры огромные проблемы с оптимизацией и графика всё равно не впечатляет).

Какие есть существенные проблемы у движков?

Unity:

Самодурство разработчиков движка. Создатели движка как-то сказали: «Мы будем брать деньги за КАЖДУЮ УСТАНОВКУ (!) игры на их движке». Т.е. создал ты игру, дорогой анон, загрузил в Steam. Установили два человека твою игру, не понравился им твой замечательный инди-хоррор на коленке и оформили рефанд (возврат) - пофиг, будь готов платить за эту установку. Ещё и в минус уйдёшь.

Вообще эту систему раскритиковали игровые разработчики и всё это откатили. Но факт остаётся фактом - у Unity проблема с деньгами. Они даже недавно присоединились к Unreal Engine для создания контента по Fortnite. А это, дорогие мои, говорит о финансовых проблемах создателей движка. Поэтому что им взбредёт в голову потом - сложно сказать, дорогой игродел. Как бы не оказалось, что ты создал игру, уже тестируешь её, а завтра выходит новость, что движок Unity становится полностью закрытым. Хотите разрабатывать дальше - покупайте лицензию на использование. А это может быть от 100 000 долларов (~ 8 000 000 рублей).

Unreal Engine:

Самодурство разработчиков игр. Тут вот в чём проблема. Многие слышали, что игры на Unreal Engine 5 выходят неоптимизированными. Почему так? Потому что разработчики хотят сделать супер-мега-красиво и не работают с оптимизацией таких сложных систем, как Lumen и Nanite. Что это такое - объяснять не буду, дабы не зарываться. Цель здесь проста - разработчики хотят показать инвесторам суперграфику, выжимая все соки из движка, а на оптимизацию как-то пофиг уже. Вот и получается, что получается.

Поэтому, дорогой игродел. Пожалуйста, молю тебя. Если будешь делать собственную игру - ну откажись ты от тяжёлых систем Анрила. Вон, в Split Fiction всё это убрали - вуаля, идеальная игра по оптимизации. Но даже если и хочешь использовать эти системы, как это было сделано в Expedition 33, то будь готов тестировать, настраивать и в общем прям заморочиться над оптимизацией.

Вывод здесь такой: все дурят, но в разных областях.

Почему движки бесплатные? В чём подвох?

Движки бесплатные до тех пор, пока игра не начнём вам приносить деньги.

Unity:

Тут чуть посложнее система, чем у Unreal Engine. У Unity есть несколько систем лицензирования. Есть Unity Personal, Enterprise и Pro. Простите меня, что не буду сюда всё переписывать, как там и что, ибо пост раздуется до больших высот. Если вам интересно - то вот ссылка.

Unreal Engine:

Если вы заработали на игре 1 000 000 долларов, то вы обязаны будете отдать 5% с последующих продаж в казну Epic Games. Если же вы опубликуете свою игру в Epic Games Store, то ставка снизится до 3.5%. Всё просто. Не набрала ваша игра 1 000 000 долларов? Ну, платить ничего не нужно.

Выводы здесь такие: как по мне, так система роялти от Unreal Engine более комфортная и удобная, в то время как для Unity порог снижен и в целом можно запутаться с их системами.

Заключение.

Поэтому я надеюсь, что я ответил на твой вопрос, юный игродел. Я бы посоветовал тебе вообще потыкать разные движки. Вдруг тебе ни Unity, ни Unreal Engine не зайдут. А вот какой-нибудь Godot - полюбишь с первого взгляда.

В конце концов, интересной игру делают не движки. А люди, которые хотят сделать интересную игру.

Показать полностью 14
[моё] Gamedev Инди Unreal Engine Игры Unity Игровой движок Компьютерные игры Длиннопост
16
14
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: Итоги 2025⁠⁠

8 дней назад

Традиционно подвожу итоги года и даю себе месяц на отдохнуть; примерно распланировать 2026 год. Правда в этот раз итоги получаются не за год, а за год с хвостиком, но не суть.

Что было сделано за этот год:

  • Разработана архитектура и модель памяти движка.
    Создана фабрика всех движковых объектов, Сборщик мусора, отвечающий за автоматическое удаление и освобождение памяти от ненужных сущностей. И центральное хранилище объектов. Продуманы системы подгрузки подсистем, встроенных модулей и взаимодействие с проектами высокого уровня (читай играми).

  • Создана скрипт подсистема на основе языка Lua и внедрена в виде подключаемой подсистемы.

    Подробнее: Relict Engine: Скриптовая подсистема + DevLog 20250405

  • Разработана утилита для импорта внешних форматов в формат движка

    Подробнее: Relict Engine: RatTools. Меши. Статичные Меши

  • Разработан формат хранения статичной геометрической сетки (статичный меш)

    Подробнее: Relict Engine: Формат Статичного меша

  • Разработана система работы с асинхронными задачами

    Подробнее: Relict Engine: ThreadManager и DevLog 20250822

  • Разработана структура сцен
    Подробнее: Relict Engine: Мир и DevLog 20250928

  • Разработана система вывода графики и работа с ней

    Подробнее: Relict Engine: DevLog 20251120

    Иными словами за этот год я смог сделать некий полнофункциональный скелет. И теперь, на этот скелет следует наращивать мяско.


Что планируется на 2026

Начало 2026 года я планирую посвятить работе над ошибками. Например, очень хочется организовать очередь создания объектов, дабы была возможность управлять порядком их создания (сейчас некоторые объекты, например RenderObject, создают свои дефолтные экземпляры вне main рутины, а ДО нее, что не есть очень хорошо, и может привести к проблемам в какой-то момент).

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

Еще хочу напомнить, что у движка есть дорожная карта, ознакомится с которой можно вот тут: https://yougile.com/board/8o3quozyj1in , и где видно сколько было сделано. И сколько еще предстоит сделать.


И на этом год 2025 считаю закрытым.

И в заключении, от себя и от лица команды Delta-Proxima Team хотим заранее поздравить пользователей Пикабу, и отдельно Лигу разработчиков Видеоигр с новым, 2026м годом. Желаем, чтобы ваши проекты покоряли вершины чартов, а каждый новый релиз становился событием в мире игровой индустрии.
Пусть код пишется легко, баги находятся быстро, а вдохновение никогда не покидает вас!
А на кухне никогда не заканчиваются кофе и печеньки ;)

С уважением и наилучшими пожеланиями,
Delta-Proxima Team

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок Новый Год
3
8
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: Шейдеры. Часть 2. Материалы. Синтаксис⁠⁠

16 дней назад

Как я писал в пред. посте (Relict Engine: Шейдеры. Часть 1. Теория и вопросы), нам потребуется комбайн для перегона материала (или, если угодно, настроек шейдера) в spir-v формат. Для этого необходимо создать изначальный формат, желательно в текстовом виде, который и будет входной точкой в этот процесс.

Этот формат должен отвечать следующим требованиям:

  • В нем должно быть указано, с какими "сырыми" шейдерами компоновать этот материал

  • Иметь возможность обращаться к дополнительным файлам, содержащим кастомные функции

  • Иметь возможность самому определять дополнительные функции

  • Задавать входные опции

  • Определять параметры уже самого шейдера

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

первый вариант синтаксиса материала

первый вариант синтаксиса материала

Что мы тут видим:
Директива using
Она определяет компоновку с сырыми шейдерами. Определяет домен, модель смешивания альфы и модель освещения (не путать с моделью затенения из пред. поста).
Нейминг был взят из Unreal Engine, потом, возможно, поменяю на немного более логичные.

Директива in
Она определяет входные переменные для материала, используя типы GLSL

Директива include
Эта директива говорит комбайну, что следует обратится к функции, определенной в файле MaterialFunctions/getColor (Content/MaterialFunctions/getColor.minc проекта). Что важно, сам файл как самостоятельный ассет не будет использоваться, но его контент будет вставлен заместо директивы include при первичной компоновке.

Директива function
Директива означает, что следующий текст является функцией. Сама функция должна быть написана на языке GLSL. В прочем, возможно, логичнее будет определить блоковую директиву, в которой код будет интерпретироваться как есть.

Директива set
Эта директива передает конкретные значения в параметры "сырых" шейдеров. Иными словами, это и есть сам материал.

Показать полностью 1
[моё] Разработка Gamedev Инди Игровой движок Шейдеры
0
12
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: Шейдеры. Часть 1. Теория и вопросы⁠⁠

16 дней назад

Начнем, пожалуй, с теории.

Шейдеры и модель затенения

пример работы отложенного затенения (иллюстрация <!--noindex--><a href="https://pikabu.ru/story/relict_engine_sheyderyi_chast_1_teoriya_i_voprosyi_13424189?u=https%3A%2F%2Flearnopengl.com%2F&t=https%3A%2F%2Flearnopengl.com%2F&h=9d0d5ab19c1209e085c1ddb0125053715c6b9c32" title="https://learnopengl.com/" target="_blank" rel="nofollow noopener">https://learnopengl.com/</a><!--/noindex-->)

пример работы отложенного затенения (иллюстрация https://learnopengl.com/)

Шейдер это программа, написанная на одном из специализированных языков программирования, например GLSL, и выполняемая на GPU.
Шейдеры бывают разных видов: вершинные, фрагментные, геометрические и компьют. Каждый создан для своей задачи и работают чуть по разному.
Например, вершинный шейдер работает исключительно с вершинами (или набором точек) 3д модели, а фрагментный (или, как его еще называют, пиксельный), только с пикселями экрана или текстуры.

Для вывода графики на экран нам нужен как минимум вершинный и фрагментный шейдеры. Они будут исполнятся на каждый отдельно взятый объект. В случае вершинного для каждой вершины модели; в случае фрагментного для каждого пикселя экрана, занятого объемом результата вершинного шейдера.

А так-же есть две модели шейдинга (шейдинг ("затенение") - процесс в компьютерной графике, который придает объектам реалистичный вид, определяя их цвет и внешний вид в зависимости от освещения, текстур и материалов):
Forward (или прямое затенение) - при этой модели каждый отдельный объект обрабатывается самостоятельно. Свет и тени будут считаться отдельно для каждого объекта.
Deffered (или отложенное затенение) - отрисовка сцены происходит в несколько проходов с сохранением промежуточных данных в специальные текстуры, которые имеют общее название G-Buffer. А потом, отдельным проходом, единоразово будет просчитан свет и тень.

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


Шейдеры в Relict Engine

Таким образом, в первую очередь нам нужно выбрать, какую модель затенения использовать в движке. Т.к. проект, для которого Relict Engine создается, связан с космосом, то логично предположить, что прямое затенение даст больше производительности, нежели отложенное. И это будет верно, пока мы говорим о "сферическом космосе в вакууме". Как только появляются туманности, низкие орбиты и нагруженные космопорты на этих орбитах, все становится менее очевидно. Поэтому, несмотря на кажущуюся простоту этого вопроса , ответить на него не так уж и просто.

Следующие вопросы, который надо решить, и которые не связаны с моделью затенения напрямую, а больше относятся к архитектуре движка, является: А как хранить шейдеры? Как передавать в них параметры?

В спецификации OpenGL 4.5 появилась возможность использовать бинарные шейдеры Spir-V, которые являются основным форматом шейдеров для Vulkan. И это удобно, мы сможем использовать один и тот-же шейдер как для OpenGL, так и для Vulkan без модификации. Но это касается "статичных" шейдеров. Их нельзя изменять, можно добавить только заранее известные переменные, которые можно будет передать в шейдер через функции движка или скрипта, а если мы хотим чего-то более сложного? Например передать не текстуру, а некую математическую функцию, которая будет определять цвет пикселя по своим собственным законам?

Таким образом, нам понадобится система, которая будет компоновать наши кастомные навороты, а так-же вводные данные, в виде переданных параметров с набором функций базовых шейдеров в некую отдельную сущность, которая будет представлять из-себя скомпонованный шейдер из множества отдельно взятых функций и точки входа. И желательно, все это все равно сохранить в Spir-V формат для удобства дальнейшего перехода на Vulkan.
Более того, в зависимости от выбранной модели затенения, выходной результат так-же должен отличаться. Так например, если мы для Основного цвета (Diffuse Color) не будем использовать текстуру, а некую мат. функцию, то нам нужно будет скомпоновать эту функцию с шейдером G-Buffer, в случае использования отложенного затенения, когда как в случае прямого затенения, с итоговым фрагментным шейдером.

Иными словами только для подготовки шейдера к компиляции в кэш нам потребуется целый промежуточный комбайн. Этот комбайн будет работать с текстом, компонуя и генерируя исходный glsl код из пред написанных сниппетов и нашего материала. А на выходе должен быть Asset, уже в формате Spir-V, который и будет использоваться для компиляции уже в машинный код и исполнения на GPU.

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок Шейдеры
0
3
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: DevLog 20251120⁠⁠

19 дней назад

Краткий список изменений:

  • Добавлен Реликт RenderCore

  • Добавлен Реликт RenderGL

  • Добавлено дерево классов RenderObject; в частности: StaticMesh_GLRenderObject

  • Добавлен класс VertexArrayObject

  • Добавлены шаблон-делегаты

    как пример:
    using FOnAssetChanged = MulticastDelegate<StaticMesh*, StaticMesh*>;
    Работает, так-же как и делегаты в UE.

Комментарий:

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

Но немного подытожу, что у меня получилось с пайпом. А получилась довольно интересная загогулина.

Итак, первое, что у нас есть это Renderer. И как не странно, эта сущность не занимается обработкой графики. Она используется как загрузчик уже непосредственно самого класса отрисовки, а так-же как прокси к нему.

Второе, что у нас есть это RenderUnit. Производный от SceneUnit это объект игровой сцены, который может иметь что-либо связанное с выводом на экран (Меш, скелет, систему частиц, итд)

Третье что у нас есть это интерфейс IRenderObject и производные к нему. Это и есть те классы, которые занимаются непосредственно отрисовкой, т.е. сбором всех контекстов и вызовом команды графического апи на отрисовку. Примечательно то, что эти классы на прямую связаны с RenderUnit таким образом, что каждому RenderUnit соответствует свой RenderObject

Четвертое - VertexArrayObject. Название взято из спецификации OpenGL, и служит он ровно для той же цели, что и объекты VAO в спецификации. Он хранит вершины модели, индексы и их атрибуты, и прокидывает их в видеопамять. Связан с IAsset производными, но управляется из RenderObject (т.к. заполнение может быть специфическим, в зависимости от типа юнита). Но тем не менее хранит набор из ссылок на RenderObject'ы, юниты которых используют ассет, к которому привязан данный VertexArrayObject (сложна!). Почему именно так: А все просто. Чтобы максимально ускорить процедуру рендера я решил сократить издержки на переключение буферов на GPU. А для этого, мы переворачиваем порядок вызовов на отрисовке (если создаются таким образом: RenderUnit -> RenderObject->VertexArrayObject, то при вызове на отрисовку порядок переворачивается: VertexArrayObject -> RenderObject->RenderUnit). И заодно организовываем сортировку объектов по этому же VAO. Таким образом, если у нас на сцене есть, допустим 3 куба, 2 шара и одна пирамида, то отрисовано будет сначала именно 3 куба, потом 2 шара, и в конце пирамида. Таким образом, на 6 объектов, у нас придется только 3 переключения контекста (про инстансинг помню, но он отдельно и не для этого).

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

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

Показать полностью
[моё] Разработка Gamedev Инди Игровой движок Текст
0
7
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: DevLog 20251113⁠⁠

26 дней назад

Краткий список изменений

  • Заменен встроенный в glfw загрузчик GLAD на сгенерированный самостоятельно (https://glad.sh).

  • Добавлена документация RatTools для внутреннего использования

  • Работа с OpenGL полностью вынесена в VAO (Vertex Array Object) из последней ревизии спецификации

  • Изменена структура хранения StaticMesh для более удобного доступа к буферам из графического апи.

  • Добавлен предварительный код переключения LOD

  • Добавлен предварительный код отрисовки мульти материалов.

Комментарий:

В ближайшее время буду думать в сторону промежуточных объектов, связывающих графический пайп с игровым фреймворком. Скорее всего нужно будет навести один/два дополнительных реликта (модуля) для этого дела, да вынести отрисовку туда. Так-же нужно перепривязать эти объекты с RenderUnit на непосредственно Asset. А то сейчас получается, что один и тот-же меш будет иметь столько VAO, сколько RenderUnit на сцене, даже если они несут один и тот-же объект - это не порядок. В идеале должно быть так, чтобы был один VAO на один ассет, чтобы не напрягать GPU лишними переключениями контекста, да и в видео памяти получается по несколько раз одно и тоже лежит, что тоже есть очень не хорошо.
Правда в этом случае вылезет проблема с переключением LOD, т.к. на данный момент для переключения в VAO меняется буффер вершин. В случае, если VAO будет привязан к ассету, то переключать лоды для конкретного объекта не выйдет (только если все LOD в графическую память сразу отдавать). В общем, еще есть над чем подумать.

А пока что результат на сегодняшний день:

Лоды

Перейти к видео
Заготовка мульти материал. Один объект, два разных шейдера и очень много треугольников.

Заготовка мульти материал. Один объект, два разных шейдера и очень много треугольников.

Показать полностью 1 1
[моё] Разработка Gamedev Инди Игровой движок Видео Без звука Короткие видео
0
2
user10110747

Ответ на пост «Relict Engine: DevLog 20251103»⁠⁠1

1 месяц назад

Привет! Прочитал ответ на вопросы в предыдущем посте #comment_370534457

Ответ на пост «Relict Engine: DevLog 20251103»

Дам непрошенную рекомендацию - максимально рано приступай к созданию игры (логика, графика, локации, игры и тд); движок можно пилить до бесконечности, рано или поздно запал пропадёт, тем более если его не подпитывать.

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

Было бы интересно почитать отдельным постом почему ты выбрал писать свой движок, а не взять один из менйстримных (юнити, анрил, годот или подобное); например если бы ты собрал собрать мвп на юнити и анриле, и сравнил бы результаты и процесс, описал бы чего не хватает (А вдруг всего хватает?:), было бы очень содержательно и.
Или почему не вписался в какой-нибудь опен сорс движок, как контрибутор (Open 3D Engine - O3DE как пример)

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

Поздравляю с достигнутой вехой)

Показать полностью 1
Разработка Gamedev Инди Игровой движок Видео Без звука Короткие видео Длиннопост Ответ на пост
1
7
TehnoMagEG
TehnoMagEG
Лига Разработчиков Видеоигр
Серия Relict Engine

Relict Engine: DevLog 20251103⁠⁠1

1 месяц назад

Краткий список изменений

  • Обновлена зависимость Lua до 5.4.8

  • Обновлена зависимость glm до 1.0.2

  • Исправлено построение трансформы для Units::SceneUnit

  • Добавлены экспериментальные классы графического конвейера

  • Добавлен процесс унифицированной отрисовки RBUD (Render by unified data)

Комментарий

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

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

Простое приложение с двумя вращающимися кубиками

Простое приложение с двумя вращающимися кубиками

И результат работы этого кода.

Перейти к видео

Пока как-то так. Да, это все-еще не похоже на движок, однако маленькую вешку считаю достигнутой )

Показать полностью 1 1
[моё] Разработка Gamedev Инди Игровой движок Видео Без звука Короткие видео Длиннопост
3
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Маркет Промокоды Пятерочка Промокоды Aroma Butik Промокоды Яндекс Путешествия Промокоды Яндекс Еда Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии