Как сделать собственный игровой движок
Написать игровой движок на первом курсе: легко! (ну почти)
Привет! Меня зовут Глеб Марьин, я учусь на первом курсе бакалавриата «Прикладная математика и информатика» в Питерской Вышке. Во втором семестре все первокурсники нашей программы делают командные проекты по С++. Мы с моими партнерами по команде решили написать игровой движок.
О том, что у нас получается, читайте под катом.
Всего нас в команде трое: я, Алексей Лучинин и Илья Онофрийчук. Никто из нас не является экспертом в разработке игр, а тем более в создании игровых движков. Для нас это первый большой проект: до него мы выполняли только домашние задания и лабораторные работы, так что едва ли профессионалы в области компьютерной графики найдут здесь новую для себя информацию. Мы будем рады, если наши идеи помогут тем, кто тоже хочет создать свой движок. Но тема эта сложна и многогранна, и статья ни в коем случае не претендует на полноту специализированной литературы.
Всем остальным, кому интересно узнать о нашей реализации, — приятного чтения!
Графика
Первое окно, мышь и клавиатура
Для создания окон, обработки ввода с мыши и клавиатуры мы выбрали библиотеку SDL2. Это был случайный выбор, но мы о нем пока что не пожалели.
Важно было на самом первом этапе написать удобную обертку над библиотекой, чтобы можно было парой строчек создавать окно, проделывать с ним манипуляции вроде перемещения курсора и входа в полноэкранный режим и обрабатывать события: нажатия клавиш, перемещения курсора. Задача оказалось несложной: мы быстро сделали программу, которая умеет закрывать и открывать окно, а при нажатии на ПКМ выводить «Hello, World!».
Тут появился главный игровой цикл:
Hello World
Камера
Следующим шагом нужно было написать камеру, которая могла бы перемещаться и смотреть в разные стороны. Чтобы понять, как решить эту задачу, нам потребовались знания из линейной алгебры. Если вам это не очень интересно, можете пропустить раздел, посмотреть гифку и читать дальше.
Мы хотим нарисовать в координатах экрана вершину, зная ее координаты относительно центра объекта, которому она принадлежит.
Начнем с получения координат объекта в базисе мира. С объектом можно делать три преобразования: масштабировать, поворачивать и перемещать. Все эти операции задаются домножением исходного вектора (координат в базисе объекта) на соответствующие матрицы. Тогда матрица Model будет выглядеть так:
Чтобы получить координаты вершины на экране, нужно перемножить вектор на матрицу по крайней мере пять раз. Все матрицы имеют размер 4 на 4, так что придется проделать довольно много операций умножения. Мы не хотим нагружать ядра процессора большим количеством простых задач. Для этого лучше подойдет видеокарта, у которой есть необходимые ресурсы. Значит, нужно написать шейдер: небольшую инструкцию для видеокарты. В OpenGL есть специальный шейдерный язык GLSL, похожий на C, который поможет нам это сделать. Не будем вдаваться в подробности написания шейдера, лучше наконец-то посмотрим на то, что вышло:
Пояснение: есть десять квадратов, которые находятся на небольшой дистанции друг за другом. По правую сторону от них находится игрок, который вращает и перемещает камеру.
Физика
До этого момента мы думали сделать графику в движке абсолютно двумерной, а для освещения, если решим его добавлять, использовать технику raycasting. Но у нас под рукой была замечательная камера, которая умеет отображать объекты во всех трех измерениях. Поэтому мы добавили всем двумерным объектам толщину — почему бы и нет? К тому же в перспективе это позволит делать довольно красивое освещение, которое будет оставлять тени от толстых объектов.
Освещение появилось между делом. Для его создания потребовалось написать соответствующие инструкции для рисования каждого пикселя — фрагментный шейдер.
Текстуры
Для загрузки изображений мы использовали библиотеку DevIL. Каждому GraphicalObject2d стал соответствовать один экземпляр класса GraphicalPolygon — лицевая часть объекта — и GraphicalEdge — боковая часть. На каждую можно натянуть свою текстуру. Первый результат:
Все основное, что требуется от графики, уже готово: отрисовка, один источник освещения и текстуры. Графика — на данном этапе все.
Машина состояний, задание поведений объектов
Каждый объект, каким бы он ни был, — состоянием в машине состояний, графическим или же физическим — должен «тикать», то есть обновляться каждую итерацию игрового цикла.
Проблема: хотим поставить группу объектов на паузу, например, систему частиц и частицы внутри нее. В текущем состоянии для этого нужно вручную вызвать onPause для каждого объекта, что не очень удобно.
И так далее, для каждой функции.
У состояния есть три стадии: оно началось, оно тикает, оно остановлено. К каждой из стадий можно добавлять какие-то действия, например, прикрепить к объекту текстуру, применить к нему импульс, установить скорость и так далее.
Сохранения
Чтобы сделать сохранение, остается просто переопределить dump() для каждого объекта. Загрузка — это конструктор от строки, содержащей всю информацию об объекте. Загрузка завершена, когда такой конструктор сделан для каждого объекта.
На самом деле, игра и редактор — это почти один и тот же класс, только в игре уровень загружается в режиме чтения, а в редакторе — в режиме записи. Для записи и чтения объектов из json-а движок использует библиотеку rapidjson.
Графический интерфейс
В какой-то момент перед нами встал вопрос: пусть уже написана графика, машина состояний и все прочее. Как пользователь сможет написать игру, используя это?
В графическом интерфейсе количество действий, которые можно произвести с объектом, будет ограничено: перелистнуть слайд анимации, применить силу, установить определенную скорость и так далее. Та же ситуация с переходами в машине состояний. В больших движках проблему ограниченного количества действий решают связыванием текущей программы с другой — например, в Unity и Godot используется связывание с C#. Уже из этого скрипта можно будет сделать что угодно: и посмотреть, в каком созвездии Уран, и какой сейчас курс евро. У нас такой функциональности на данный момент нет, но в наши планы входит связать движок с Python 3.
Для реализации графического интерфейса мы решили использовать Dear ImGui, потому что она очень маленькая (по сравнению с широко известным Qt) и писать на ней очень просто. ImGui — парадигма создания графического интерфейса. В ней каждую итерацию главного цикла все виджеты и окна отрисовываются заново только если это нужно. С одной стороны, это уменьшает объем потребляемой памяти, но с другой, скорее всего, занимает больше времени, чем одно выполнение сложной функции создания и сохранение нужной информации для последующего рисования. Тут уже осталось только реализовать интерфейсы для создания и редактирования.
Вот как в момент выхода статьи выглядит графический интерфейс:
Редактор машины состояний
Заключение
Мы создали только основу, на которую можно вешать что-то более интересное. Иными словами, есть куда расти: можно реализовать отрисовку теней, возможность создания более чем одного источника освещения, можно связать движок с интерпретатором Python 3, чтобы писать скрипты для игры. Хотелось бы доработать интерфейс: сделать его красивее, добавить больше различных объектов, поддержку горячих клавиш…
Работы еще предстоит много, но мы довольны тем, что имеем на данный момент.
За время создания проекта мы получили много разнообразного опыта: работы с графикой, создания графических интерфейсов, работы с json файлами, обертки многочисленных C библиотек. А еще опыт написания первого большого проекта в команде. Надеемся, что нам удалось рассказать о нем так же интересно, как было интересно им заниматься 🙂
Пишем собственный игровой движок с помощью C++
С нуля создадим собственный игровой движок с помощью библиотеки SFML и C++, чтобы разобраться, как происходит создание ядра.
В этом проекте мы создадим собственный игровой движок на C++. Движок будет очень простым, но готовым к расширению возможностей. Конечная игра с использованием этого кода тоже крайне проста: наш персонаж сможет перемещаться влево и право, а из графики – только бэкграунд и фигурка персонажа.
Подготовка Visual Studio
Создадим новый проект в Visual Studio. Обратите внимание, что проект требует библиотеку SFML, поэтому если вы не настраивали окружение для нее, прочтите сначала небольшое руководство по настройке.
Теперь можно приступить к коду. Исходный код и дополнительные ресурсы будут доступны на этой странице.
Проектируем собственный игровой движок
Самое важное – запуск движка, который будет происходить в файле Main.cpp, но им мы займемся немного позже.
Класс персонажа
Bob – простой класс для представления фигурки персонажа, управляемой игроком. Код класса будет легко расширяться, а что самое главное – его несложно переписать под любой другой игровой объект, который вы захотите добавить. Для этого потребуется заменить текстуру и описать поведение нового объекта в методе update().
Займемся заголовками класса. Выберите правой кнопкой Header Files в Solution Explorer и нажмите Add | New Item. В окне Add New Item выберите Header File (.h), затем в поле Name введите Bob. Нажмите Add и добавьте код заголовка класса:
Здесь мы объявили объекты типа Texture и Sprite. Дальше мы свяжем эти объекты и любое действие на экране с объектом Sprite будет сопровождаться изображением Боба:
Кликните правой кнопкой, чтобы сохранить
Bob.cpp
Теперь приступим к описанию методов.
Выберите правой кнопкой мыши Source Files в Solution Explorer и откройте Add | New Item. В окне Add New Item кликните по C++ File (.cpp), а в поле Name укажите Bob.cpp. Теперь добавьте в файл код:
В конструкторе мы установили значение переменной m_Speed на 400. Это значит, что Боб пересечет экран шириной в 1920 пикселей за 5 секунд. Также мы загрузили файл Bob.png в Texture и связали его с объектом Sprite. В переменных m_Position.x и m_Position.y установлено начальное положение Боба.
Функция update обрабатывает два If. Первое If проверяет, нажата ли правая кнопка (m_RightPressed), а второе следит за левой (m_LeftPressed). В каждом If скорость (m_Speed) умножается на elapsedTime. Переменная elapsedTime рассчитывается в функции Start движка (класс Engine). Им мы и займемся далее.
Пишем класс Engine
Класс Engine будет контролировать все остальное.
Engine.h
Добавим заголовок. Откройте окно Add New Item (так же, как для класса Bob), выберите Header File (.h) и в поле Name введите Engine.h. Добавьте в файл следующий код:
Класс библиотеки SFML, RenderWIndow, используется для рендера всего, что есть на экране. Переменные Sprite и Texture нужны для создания фона. Также в заголовке мы создали экземпляр класса Bob.
Engine.cpp
В Engine.cpp мы опишем конструктор и функцию start. Создайте файл класса так же, как для Bob.cpp, и добавьте в него код:
Функция конструктора получает разрешение экрана и разворачивает игру на весь экран с помощью m_Window.create. В конструкторе же загружается Texture и связывается с объектом Sprite.
Пример фонового изображения
Скачайте пример изображения или используйте любое другое на свое усмотрение. Переименуйте файл в background.jpg и поместите в каталог Simple Game Engine/Simple Game Engine.
Игровой цикл
Следующие три функции будут описаны каждая в своем файле, но при этом они должны быть частью Engine.h. Поэтому в начале каждого файла укажем директиву #include «Engine.h», так что Visual Studio будет знать, что мы делаем.
Обрабатываем пользовательский ввод
Создайте файл Input.cpp и добавьте в него код:
Функция input обрабатывает нажатия клавиш через константу Keyboard::isKeyPressed, предоставляемую SFML. При нажатии Escape m_Window будет закрыто. Для клавиш A и D вызывается соответствующая функция движения.
Обновляем игровые объекты
Теперь опишем простую функцию update. Каждый игровой объект будет иметь собственную функцию update.
Создайте файл Update.cpp и добавьте в него код:
Поскольку у нас пока только один объект «Боб», мы вызываем только функцию m_Bob.update.
Отрисовка сцены
Это последняя функция класса Engine. Создайте файл Draw.cpp и добавьте в него код:
Экран очищается методом clear, затем отрисовывается фон. Первым делом должен быть отрисован фон, чтобы потом поверх него можно было отрисовать Боба.
Запускаем движок в main()
Теперь вернемся к нашему Main.cpp. Время добавить в него немного кода:
Несколько слов в конце
Наш собственный игровой движок получился очень простым: он умеет только двигать главный объект и закрывать программу. Он не умеет обрабатывать столкновения, работать с интерфейсом и еще много чего. Однако он отлично описывает то, как строится ядро игрового проекта с нуля. К тому же, как мы уже выяснили, класс Bob расширяется и адаптируется под другие объекты, так что дайте волю фантазии и попробуйте поэкспериментировать с окружением.
Как за 3 дня создать игровой движок для новелл
Одним дождливым питерским днем мой проект в UE4 перестал загружаться, и из-за этого я захотел сделать свой собственный движок. И одна новелла подтолкнула меня сделать движок именно для новелл. Если вам хочется узнать побольше и вы не боитесь goto, gosub и других ужасов, добро пожаловать под кат. 
Оглавление
Этот же друг зная, что я пытаюсь создать игру уже третий месяц предложил мне портировать Катаву на iPad без Jailbreak. Выбор пал на smart BASIC, так как я пользуюсь этой программой уже полтора года и знаю синтаксис её внутреннего языка программирования (также у smart BASIC есть SDK для XCode).
Сразу же был скачан архив со всеми файлами игры кроме текста. Но ни он не я не знали, что это приведет к созданию своего движка для удобства разработки.
Акт 2. Разработка
1. Текст
Файл Katawa Shoujo Port.txt будет подгружать все скрипты.
Файл colorcodes.txt будет содержать RGB цвета имен для рендера, для примера возьму Сидзунэ и ее синее выделение:
Основные приготовления сделаны, теперь можно писать скрипт для показа текста. В Катаве, как и в любой визуальной новелле, текст показывается в поле, и над текстом пишется имя персонажа, от чьего лица этот текст.
За это будет отвечать скрипт speak.txt.
Для начала в файл load.txt я прописал загрузку спрайта bg-say.png (поле для реплик) и шрифта playtime_cyrillic:
После я решил использовать в скрипте сценария знак “|” как разделитель команды, цели команды, вторичной цели, действия и аттрибута.
Как написать свой игровой движок с нуля
Возможно, тема надоевшая, но я поискал в интернете на эту тему и понял что в интернете(youtube, yandex, habr) нет ничего полезного, вернее оно есть, но без объяснений.
Сразу скажу что, C# я знаю больше чем C++, просьба отталкивать от этого.
Что я подразумеваю под словом ‘с нуля’.
1. Нужно определиться с языком программирования. C++ или C#?
Если я напишу: «Мне нужен обоснованный ответ!», будет немного грубо.
По этому, желательно обосновать ответ и написать названия книг по выбранному языку.
Не нужно писать: вот C++ быстрее чем C#, пиши на C++ и т.д.
2. Какой фреймворк? (Если неправильно назвал поправьте)
OpenTK, GLFW и т.д. Источники, где можно поподробнее разобраться.
3. Что нужно знать в языке программирования что бы написать свой игровой движок?
Пример ответа: Нужно уметь пользоваться массивами, отладчиком, искать ошибки и т.д.
4. Ну и с чего стоит начать, после изучения языка.
Написать свой движок с нуля
Как написать свой движок с нуля при помощью C++. Заранее спасибо.
Можно ли в Visual Basic написать свой игровой движок
Здравствуйте господа программисты. Я хотел сделать свою игру, и для этого я искал разные движки.
Свой игровой движок
Я писал 3 раза игровой движок. Теперь предстоит четвертый. Подскажите, на чем лучшего его написать.
Как написать игровой движок
доброй ночи уважаемые, прошу помочь, я взялась прописывать движок на игру, и не очень понимаю что.
Ответ на твой вопрос зависит от того что ты хочешь получить на выхлопе?
По тому что если тебе нужен CryBiteUnrealUnity 10K5000 то запросы одни, а если тебе двиг для майнкрафта то запросы другие.
Добавлено через 1 час 0 минут
Я предположу, что ты делаешь CryBiteUnrealUnity 10K5000.
Те же фростбайты, анриалы, юнити и край энжины написаны на c/c++, сам сделай выводы.
У шарпа вообще плюсов нет :), помогите их найти? Единственный аргумент в таких спорах что я слышал, это дот нет и куча библиотек, так ведь у с++ тоже их море, один qt если вспомнить, а в контексте разработки с нуля с# не о чем
Опять же, если ты будешь писать свой серьезный движ то использовать сторонние библиотеки не будешь, по тому что все будешь писать под свои запросы. По тому openTK тебе не нужен, тебе нужно что-то типа glfw+gluw, которые только лишь создают окно и импортируют функции api opengl (ты же на opengl смотришь?), но можешь и по хардкору #include и самому импортировать функции и создавать окна.
Все что нужно знать об openGL есть тут.
Конкретно тебе нужно знать:
1.1) как создать окно
Первый самый простой этап.
2.1) ты должен узнать что такое шейдер, как его скомпилить на гпу, как его применить.
2.2) как создать vao (обязательно нужно разобраться как использовать несколько атрибутов), и как его выводить (рисовать), тут ты узнаешь что заходит на вход вершинному шейдеру и что выходит из фрагментного.
Тут ты уже поймешь как работает opengl, тебе станет очень радостно если ты добрался до сюда.
2.3) Ты должен загрузить изображение, создать текстуру, установить ее в семплер, внести изменения в код шейдера и любоваться своей текстурой.
Второй этап закончен. Ты уже можешь что-то рисовать посредством шейдеров. 
Вот от сюда будет начинаться что-то серьезное.
3.1) Нужно будет разобраться с тем что такое fbo, как его создавать, как его применять/чистить и как в него рендерить.
3.2) Зная что такое fbo, нужно будет в первый раз что то отрендерить в текстуру (тобишь в fbo), сделаешь тени.
Вот на этом моменте кончается 90% работы. Можешь начать с этого после изучения языка.
Потом ты еще должен будешь выбрать аудио апи аля OpenAl.
Что нужно знать о языке?
Само собой нужно уметь работать с массивами, циклами (for, while), блоками ветвлений (if/else, switch/case), структуры. Потом ты должен знать как алоцировать память динамически, аля new и delete, указатели ( не умные, а обычные, умные таковыми только называются).
Не плохо бы знать ооп (классы, наследование), опять же, перегрузка и таблицы виртуальных функций для риалтайма зло.
Самые важные вопросы ты не спросил. Это что нужно знать о том что нужно знать о программировании.
Так вот, знать нужно алгоритмы и патерны проектирования. Если с первым все ясно, то второе нужно по тому что иначе твой вдиж станет лапшой с такой скоростью что ты не заметишь.
«Начинайте с идеи игры, а не движка». Разработчик игровых движков — о том, что это и как устроено
Василий разрабатывает игровые движки с 16 лет, с того момента, как дома появился первый ZX Spectrum, — и не представляет, чем еще мог бы заниматься в жизни. Айтишник выпускал мобильные и веб-игры, создавая их в одиночку, а также написал несколько движков (вот один из них). В рамках спецпроекта Onliner и BGaming мы узнали у разработчика этой компании, как устроен игровой движок и что он собой представляет.
Как выглядит движок
— Простым языком: движок игры — что это такое?
— Изначально у тебя есть язык программирования, в котором ты можешь сделать все что угодно. Но примерно ко второй игре становится ясно, что многие вещи повторяются из игры в игру, и чтобы не писать их повторно, ты объединяешь их в некий набор библиотек и инструментов, который и принято называть движком. Хороший движок избавляет от необходимости делать то, что уже сделано раньше, но в то же время оставляет тебе свободу действий. Продвинутый и удобный движок — это не просто набор библиотек, понятный только программистам. Это инструмент, в котором можно увидеть и отредактировать игру. То есть это, если сильно утрировать, как Photoshop или Word, только для игр. Такого пути при разработке движка я всегда придерживался.
Обычно в движке есть окно, в котором ты видишь то же, что и игрок, когда запускает твою игру. С тем лишь отличием, что ты можешь выделить любой объект и изменить его свойства, переставить в другое место. Есть окно, в котором показана иерархия игровых объектов в виде дерева или списка. По большому счету эти два окна позволяют тебе собрать игру как из кирпичей.
Иногда эти кирпичи, то есть объекты игрового мира, нужно настроить, придать им свою логику и свойства. Выглядит это так: создаешь свой новый тип игрового объекта, который наследует свойства одного из стандартных объектов, и дописываешь ему свою логику — то, как объект ведет себя в игре при взаимодействии с другими объектами. Нажимаешь кнопку запуска — и смотришь результат.
— По такому принципу можно любую игру сделать?
— Визуально вся игра сводится к тому, что каждый объект перед каждым кадром обновляет свою позицию. У него есть координаты — X и Y. Если к X прибавить 1, объект сдвинется на один пиксель. А если на каждом кадре прибавлять к X по единице, то объект будет непрерывно двигаться вправо. Вот и все: когда в 16 лет я узнал, как вывести произвольную букву в произвольную точку экрана, мне хватило, чтобы уйти в это с головой. Я составлял человечков из букв, которые бегали по лестницам, собирали монеты и так далее.
Но есть более продвинутый способ двигать объекты по экрану — это когда мы работаем не с X и Y объекта напрямую, а с его скоростями по оси X и Y. Назовем их speedX и speedY, значения которых попросту прибавляются к X и Y каждый кадр. Теперь, однажды установив speedY значение, равное 1, мы заставим объект двигаться вниз со скоростью 1 пиксель за кадр. А если мы начнем каждый кадр увеличивать speedY на 1, то объект будет двигаться вниз с ускорением — получится действие гравитации. Нам останется проверить наличие препятствия под объектом и установить speedY в 0, чтобы объект не проваливался сквозь пол. А можно при касании пола speedY умножить на минус один (изменить скорость на противоположную), и тогда объект «отскочит» и полетит вверх.
Другая, обычная для игры задача — определить момент, когда два объекта друг друга коснулись. В упрощенном виде касание — это когда расстояние между центрами двух объектов стало меньше, чем размер этих объектов. Пересеклись — соответственно, есть касание: наносим урон, добавляем на экран взрывы. Во многих движках это реализовано, и тебе остается написать, что именно произойдет при столкновении.
Универсальность — не всегда хорошо
— Почему нет движков, которые подошли бы под любой игровой жанр?
— Идей очень много, и они всегда выходят за пределы того, на что рассчитывал разработчик движка. Вообще, универсальный движок сводится к простоте: чем меньше функционала, тем он универсальнее. А когда пытаешься все охватить, то универсальность, наоборот, страдает.
— Бывает так, что движок заточен под определенный жанр? Например, для стратегии подойдет, а для гонок — вообще нет.
— Одни заточены, другие нет. Это зависит от количества реализованного в них функционала. Например, есть движок для текстовых адвенчур. Понятно, что там можешь сделать только текстовую адвенчуру. Но вообще, возможности движка ограничены только фантазией разработчика, который его использует: если горишь этим и хочешь что-то сделать, то даже в простейшем движке реализуешь интересные вещи.
В целом при разработке самое главное — не ставить глобальные задачи, пытаясь все охватить. И не пытаться в новой для тебя задаче с ходу сделать что-то фундаментальное и долгоживущее. Нужно подходить экспериментально: двинулся куда-то, понял, что есть проблема, — попробуй другой путь. Если видишь, что идея рабочая — можешь проработать ее детальнее. Свой игровой редактор я создал не с первой попытки. Было множество версий на разных языках, были и тупиковые версии, которые я бросал через две недели после начала разработки, так как понимал, что подход нежизнеспособный.
Кстати, важный момент в любой разработке — скорость итерации, то есть насколько быстро ты увидишь внесенные тобой изменения в действии. Бывают проекты, в которых на компиляцию и запуск игры уходит минута и больше, а бывают такие, где хватает 1—2 секунд. И простая математика: ты сразу становишься в 15—30 раз эффективнее. Даже не в том смысле, что сделаешь в 30 раз больше работы, а в том, что получишь в 30 раз меньше стресса и при этом будешь полон сил двигаться дальше.
— От чего зависит популярность движка? Например, CryEngine, несмотря на технологичность, почти нигде не использовался, а Unreal Engine много где встречается.
— Движков тысячи, есть удобные и не очень. У человека есть какое свойство: когда ты смотришь на что-то новое с большим количеством кнопок — оно тебе всегда не нравится. Допустим, работаешь год в 3ds Max, потом переходишь на Blender — кажется, что это полная муть и его инопланетяне придумали. Только дня через три начинаешь понимать, что к чему. То есть привыкание, инертность играют большую роль. Допустим, появился новый движок — он может быть объективно удобным и хорошим. Но кто захочет уйти от чего-то привычного и понятного? А когда речь идет о крупной компании, все в разы сложнее, тем более если на кону большие деньги.
— Почему многие студии делают собственные движки? Не проще ли лицензировать существующий?
— Я лицензированием движков не занимался, но по себе могу сказать, что свое всегда ближе, и ты меньше тратишь времени на доработку и исправление чужих «косяков». Цепляешься за какой-то недочет в стороннем движке — и либо тебе приходится от чего-то отказываться, либо тратить большое количество времени на поиск обходного пути.
Года три назад при переходе с Flash на HTML я около месяца просидел на Unity в качестве эксперимента. На мой вкус, там слишком много рутинных вещей, игровые объекты избыточно раздроблены на подкомпоненты, и 90% твоего кода занимают связи между этими подкомпонентами. Другие вещи, которые я считаю важными, реализованы не идеальным образом. Возможно, тут сыграла роль та самая человеческая инертность.
— Ты разрабатываешь только движок или игрой тоже занимаешься?
— Разрабатывать движок, отгородившись от игры, вредно. Если сам с ним не работаешь как пользователь, то понятия не имеешь, куда двигаться дальше. Только непосредственно при разработке игровой сцены ты заметишь, что чего-то не хватает или какая-то процедура занимает больше сил, чем могла бы. Как только я натыкаюсь на рутину или баг — сразу добавляю какую-то кнопку, галочку, пару дней проверяю, как оно работает в «боевых условиях», и если все в порядке, включаю ее для всех.
Если делать движок отдельно от игры, то ты не сможешь до конца понять, что именно нужно разработчику, и то, что ты сделаешь, не будет таким удобным и полезным, каким могло бы быть.
Принципы оптимизации
— Как выглядит оптимизация под разные платформы, железо?
— Устройств много, и в первую очередь нужно думать о самых слабых девайсах. Наиболее простой способ оптимизации выглядит так. Допустим, у тебя есть набор анимаций, частиц. Их можно сделать в десять раз меньше по количеству. На маленьком экране разницу даже не заметишь, а нагрузка на железо серьезно уменьшится.
Однако больше всего производительность страдает от отрисованной на экране площади за один кадр. Когда картинка состоит из нескольких слоев, каждый слой в ней отъедает значительную часть ресурсов, даже если она неподвижная. Неподвижные объекты из разных слоев нужно склеивать в один везде, где это возможно, и не отправлять на отрисовку то, что находится за пределами экрана. Например, изображение для фона в играх часто имеет размер намного больше, чем сам игровой экран, видимый пользователю. Если такое изображение отрисовывать как есть, то области за пределами экрана будут нагружать видеокарту. Значит, нужно вычислить область в пределах экрана и отрисовать только ее. В нашем движке для этого есть специальный объект, который обрезает у себя «лишние» части.
Даже если у тебя игра уже работает максимально быстро и дополнительная оптимизация не дает видимого глазу эффекта, есть батарея телефона, которая будет греться и быстро садиться, если не подойти к вопросу оптимизации с душой или хотя бы с серьезными намерениями.
— Разработчик игры должен быть технарем?
— Человек, отвечающий за программирование, — да. Для художника это не обязательно, но когда он имеет опыт разработки игр собственными руками — это очень сильно помогает и экономит время. Он может заранее организовать слои максимально близко к тому виду, в каком они будут организованы в игре. Не потратит время на то, что будет в любом случае вырезано и реализовано программно.
Даже в отрыве от арта и кода игра — это сложная инженерная система, в которой пересекается множество идей и механик. Если ты не видишь все эти пересечения наперед, всплывает множество неожиданных переделок, которые дорого обходятся.
«Самое сложное — не начать разработку, а закончить ее»
— По каким признакам можно понять, хороший в игре движок или нет?
— Если движок хороший, то его присутствие в игре не заметно. Бывает, вижу какую-нибудь известную игру, а спустя годы узнаю, что ее сделали в GameMaker.
В 3D-играх возможны некоторые особенности в освещении и цветообработке. Но в случае с 2D все обычно сводится к отрисовке картинки такой, какая она есть, и движок не оставляет своих признаков. У меня была игра Iron Impact: она сделана в 2D с динамическим освещением, то есть каждый спрайт был не плоским, а имел карту высот и нормалей. И если бы на этом моем движке мне показали другую игру, я бы его узнал.
— Что посоветуешь разработчикам игровых движков?
— Начинайте с игры и ее идеи, а не движка. Нельзя сделать движок, а потом думать, какую игру на нем разработать. Только в процессе создания игры будет понятно, в какую сторону двигаться по расширению движка, как его адаптировать и оптимизировать.
Главный совет — не делайте чего-то глобального. Даже если уверены в своих силах, лучше сделать что-то простое, тогда будет шанс закончить дело и выпустить игру. Самое сложное — не начать разработку, а закончить ее. Ведь как все идет: за второй день разработки ты удвоишь объем сделанной работы, и это очень много. А день разработки после трех месяцев работы — это лишь один процент от уже проделанного. Чувство прогресса замедляется, и радость от разработки улетучивается.
BGaming — быстрорастущий игровой провайдер с белорусскими корнями, предлагающий качественные продукты для онлайн-казино по всему миру.
Игрок и его выбор — главная ценность компании, поэтому мы постоянно изучаем и анализируем потребности и предпочтения аудитории, чтобы создавать яркие и запоминающиеся продукты. Студия разрабатывает онлайн-игры на стыке gambling и gaming, в которых идеально сбалансированы визуальные эффекты и математика. Это возможно благодаря команде экспертов с безграничной энергией и более чем 20-летним опытом в индустрии.
Спецпроект подготовлен при поддержке ООО «Меркелеон девелопмент», УНП 193084780.
Читайте также:
Наш канал в Telegram. Присоединяйтесь!
Есть о чем рассказать? Пишите в наш телеграм-бот. Это анонимно и быстро