Game Engine
Проектируем, пишем,
Внимание: статьи содержат много костылей!
Всем доброго времени суток. Не так давно решил заняться разработкой 3D игрового движка, так как структурированной информации по этому поводу немного, решил создать серию статей, в которой постараюсь показать больше техническую часть, нежели теоретическую.
Сейчас отойду от темы и хочу кое-что сразу оговорить… Я не являюсь хорошим программным архитектором и Senior developer(ом). Мне 21 и я маленький амбициозный C++ middle developer, могу ошибаться и писать глупости.
Only a Sith deals in absolutes. Obi-Wan “Ben” KenobiРад видеть замечания и предложения в комментариях.
Пожалуй, на этом я закончу вступительную часть и перейдем к делу.
Часть 1: Вступление
Во-первых, надо разобраться, в чем суть движка и зачем его писать.
Хм… И что же это?
Ссылка на Wiki
— Такс… Значит, просто написать пару классов мало?
Хорошие движки (UE, Unity, Cocos2D) состоят из пары сотен классов, нескольких подсистем и кучи менеджеров. Если конкретней:
- Графическая система
- Звуковая система
- Система для работы с сетью
- Менеджер процессов
- Менеджер задач
- Менеджер объектов
- Менеджер сцен
и многое другое…
И что же нам делать? Как, что, куда и зачем?
Самое первое и самое главное — разделить большую задачу на более мелкие и идти шаг за шагом. Маленькими, неуверенными, черепашьими шажочками.
Последовательность статей:
- Часть 1:
ЧеЧто это и зачем? (Вступление) . - Часть 2: Каркас (Начинаем писать код + архитектура).
- Часть 3: Логирование или запиши мне вот это, а это не надо.
- Часть 4: Работа с файлами, загрузчики и game assets.
- Часть 5: Внимание, будет много математики! (Графическая подсистема):
- От окна до камеры за 1 урок
- Модели, текстуры,
материалырановато еще. - А дальше свет, тени, слёзы и много-много математики, да ну ее в ***
Это только первые наброски, материала будет намного больше!
- Модульность. Слабая связность.
- Мультиплатформенность.
- Простота добавления нового функционала без изменения существующего кода.
- Использование разных графических библиотек: DirectX, OpenGL, Vulkan.
- Графические примочки: тесселяция, PBR, SSLR и много других
непонятныхнавороченных плюх. - Оптимизация рендеринга: отсечение невидимых граней, BSP деревья и прочая нечисть.
- Редактор уровней.
Для вводной статьи, думаю, хватит. В следующей статье мы напишем каркас для движка и задумаемся над взаимодействием систем и менеджеров, а также что туда должно входить. Жду ваших советов, материала и предложений
Также вот списочек материала для тех, кому интересно:
Комментарии (19)
Ravager
18.06.2019 23:13+1Самый главный вопрос зачем?
Какую ценность представляет собой абстрактный движок под абстрактную игру?
В реальном проекте этот движок придется выкинуть, потому что не имея многолетнего опыта разработки игр или хотя бы текущего контекста игры ты будешь проектировать коня в вакууме. Лучше написать парочку игр или поучаствовать в больших проектах, чтоб было понимание что вообще может потребоваться от движка.
na9ort
18.06.2019 23:16+7Чувак, я не хочу тебя огорчать, но готовься отгребать кучу минусов.
1. Если ты сидел и внезапно решил начать свой проект, то вовсе не обязательно сразу писать об этом на Хабр. Делай свой движок тихонечко и кайфуй.
2. Прежде чем писать статью нужно сделать наброски работающего (!!!) проекта. Мы хотим технических деталей, а не просто поток сознания. Нужно сделать сначала хоть что-то, и только потом садиться за статью. Не наоборот.
3. Даже для вводной статьи это кусок говна. Информации ноль. ТЗ в лучших традициях от типичных заказчиков. Воды типа: «программный компонент», «игровые консоли», «каркас для движка», «звуковая система» и т.д. — дохера. По существу вообще ничего.
4. На данный момент ты хоть первую статью сверстал? В статье обещано много материала, но такое ощущение, что эту «вводную» ты писал на коленке, пяткой, сидя на муравейнике.
AntonSazonov
18.06.2019 23:41+1Статья о том что будет цикл статей?
А дальше что? Сказ о первой главе?
Dim0v
19.06.2019 01:07Хорошие движки (UE, Unity, Cocos2D) состоят из пары сотен классов, нескольких подсистем и кучи менеджеров.
Вы немного недооцениваете сложность "хороших движков" из вашего списка.
Даже Cocos2D-x содержит ок. 1000 классов, а не "пару сотен". А такие монстры как UE и Unity — на несколько порядков больше. Для справки,
статистика Cocos2D-x--------------------------------------------------------------------------------------- Language files blank comment code --------------------------------------------------------------------------------------- C++ 979 115253 43794 648341 C/C++ Header 1239 39144 73795 92654 JavaScript 207 17199 37812 82731 Lua 619 15230 42647 36120 JSON 41 22 0 20939 Objective C++ 67 3214 2497 11586 C 43 1203 1504 10582 Java 51 1626 1860 7089 Objective C 27 1257 1160 5506 CMake 57 474 708 4773 Python 46 837 677 4346 Markdown 11 1201 0 2548 make 46 508 150 1974 Groovy 25 272 71 1850 INI 31 635 0 1668 GLSL 63 351 612 1647 XML 32 88 13 752 Bourne Shell 22 130 114 636 Windows Resource File 6 145 219 426 HTML 7 21 16 220 YAML 2 12 15 138 Prolog 5 25 0 136 PowerShell 2 35 15 134 Bourne Again Shell 1 20 21 123 DOS Batch 11 24 2 84 CSS 2 12 0 71 Ant 3 48 165 36 TypeScript 2 0 0 23 Windows Module Definition 1 0 0 3 --------------------------------------------------------------------------------------- SUM: 3648 198986 207867 937136 ---------------------------------------------------------------------------------------
FadeToBlack
19.06.2019 07:13так как структурированной информации по этому поводу не много
Когда я писал свой движок, структурированной информации по этому поводу было не только много, ей почти полностью был забит gamedev.ru gamedev.net. Насколько я понимаю, там и сейчас вся эта информация есть. И не только там. Когда я писал свой движок, у меня была целая папка с исходниками(!) движков, там было их штук 30, включая исходники движков Source(Valve), Quake(Id Software) и прочих доступных для скачивания и не очень доступных украденных исходников. И я считал эту папку самым лучшим пособием по написанию своего движка — наиболее структурированной информации невозможно себе представить. А сейчас, даже когда мне говорят на собеседованиях «мы будем делать свой движок, поэтому хотим нанять тебя», я спрашиваю: «а нафига»? Я знаю только несколько мест, где пишут движки, и советую всем, кто хочет их писать — не тратить время а сразу устраиваться туда. Одно из мест — это Unigine Corp. Не уверен, что они хантят, но пишите Дену Шергину и он с радостью примет вас на работу, если вы — крутой.
P.S: мой движок
kiwhy Автор
19.06.2019 16:25Ребят, я уже и забыл об этой статье xD
Это было написано около 2-х лет назад
kiwhy Автор
19.06.2019 16:44Я писал эту статью для новичков, но потом забил слегка.
Если есть какие-то предложения по статьям (Rust, C++, Gamedev), могу написать.
Graf_Nosferatu
19.06.2019 16:45Интересное совпадение, сегодня тоже начал писать 3D движок, но правда на C#. Будет интересно сравнить.
alexesDev
Вот человек 8 лет пишет движок
https://magnum.graphics/
Лучшего кода на C++ я не видел.
И подобного добра на github.com сейчас много. На память пару примеров:
https://github.com/floooh/sokol
https://github.com/skypjack/entt
https://github.com/GameFoundry/bsf
Надо быть реально крутым, чтобы пытаться что-то написать, вместо многочасового изучения кода в github.
Wilk
Справедливости ради, Magnum — всё же графический движок.
alexesDev
Большей частью да, но сценграф с features (крайне простая и удобная штука), аудио, подпиливание под удобную интеграцию с другими либами. Может кого-то станет движком.
Я больше клонил к тому, что 8 лет на хобби движок — сроки на которые стоит расчитывать.
Wilk
Надеюсь, что сам по себе Magnum не станет игровым движком. Всё-таки, игровой движок — вещь весьма специфичная, расчитанная на решение определённых задач определённым образом. Использование игровых движков может быть не совем удобно тогда, когда нужна, по большому счёту, только визуализация. С другой стороны, игровой движок, основанный на Magnum, был бы и правда интересен.