Игра своими руками. Создание трехмерного игрового движка на базе GLScene

Чем лучше готовый движок

9459 просмотров

В данный момент существует множество игровых движков под разные типы игр. Можно взять любой и при наличии опыта программирования или огромного желания, начинать реализовывать проект своей мечты. Разные движки требуют различного уровня знаний и опыта. Если ориентироваться на платформу iOS можно выбрать SpriteKit или Cocos2D, если выбрать Android — выбор будет LibGDX или AndEngine. Но часто берут кроссплатформенные движки — код пишется один раз и с небольшими доработками или без них компилируется под разные платформы.

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

Выбор движка по бэкграунду знаний:

  • Cocos2Dx, Unreal Engine — C++
  • LOVE, Corona SDK, Defold — Lua
  • Unity3D — C#
  • SpriteKit — Swift \ ObjectiveC
  • AndEngine, LibGDX — Java

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

Видео

Пишем класс 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.

Советы для начинающих

Следовать туториалам несложно, но я очень советую избегать слепого копирования. Экспериментируйте: что будет, если задать другое значение параметра в скрипте; а если сделать совсем другую форму коллайдера; и так далее.

Один из официальных уроков Unity по коллайдерам

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

Главное — выйти за рамки простого повторения. Только тогда можно по-настоящему усвоить материал и приобрести устойчивые навыки.

Пиксельарт

Aseprite
Aseprite

Выбор программ для создания пиксель арта велик, но у каждой есть свои проблемы. Например одна из самых популярных программ для создания пиксельарт-анимации Aseprite так чудит с кисточкой, что мне много раз хотелось её бросить и перейти в PixelEdit, в котором тоже можно и анимацию делать и арты рисовать. Обе программы платные, но у первой в свободном доступе лежат исходники и если вы умеете — можете скомпилировать её самостоятельно и использовать.

Pixelformer и спрайт из Hotline Miami

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

Не поленитесь и поищите программу сами, их много. Главное не используйте Paint, он для этого плохо подходит.

Универсальность — не всегда хорошо

— Почему нет движков, которые подошли бы под любой игровой жанр?

— Идей очень много, и они всегда выходят за пределы того, на что рассчитывал разработчик движка. Вообще, универсальный движок сводится к простоте: чем меньше функционала, тем он универсальнее. А когда пытаешься все охватить, то универсальность, наоборот, страдает.

— Бывает так, что движок заточен под определенный жанр? Например, для стратегии подойдет, а для гонок — вообще нет.

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

В целом при разработке самое главное — не ставить глобальные задачи, пытаясь все охватить. И не пытаться в новой для тебя задаче с ходу сделать что-то фундаментальное и долгоживущее. Нужно подходить экспериментально: двинулся куда-то, понял, что есть проблема, — попробуй другой путь. Если видишь, что идея рабочая — можешь проработать ее детальнее. Свой игровой редактор я создал не с первой попытки. Было множество версий на разных языках, были и тупиковые версии, которые я бросал через две недели после начала разработки, так как понимал, что подход нежизнеспособный.

Кстати, важный момент в любой разработке — скорость итерации, то есть насколько быстро ты увидишь внесенные тобой изменения в действии. Бывают проекты, в которых на компиляцию и запуск игры уходит минута и больше, а бывают такие, где хватает 1—2 секунд. И простая математика: ты сразу становишься в 15—30 раз эффективнее. Даже не в том смысле, что сделаешь в 30 раз больше работы, а в том, что получишь в 30 раз меньше стресса и при этом будешь полон сил двигаться дальше.

— От чего зависит популярность движка? Например, CryEngine, несмотря на технологичность, почти нигде не использовался, а Unreal Engine много где встречается.

— Движков тысячи, есть удобные и не очень. У человека есть какое свойство: когда ты смотришь на что-то новое с большим количеством кнопок — оно тебе всегда не нравится. Допустим, работаешь год в 3ds Max, потом переходишь на Blender — кажется, что это полная муть и его инопланетяне придумали. Только дня через три начинаешь понимать, что к чему. То есть привыкание, инертность играют большую роль. Допустим, появился новый движок — он может быть объективно удобным и хорошим. Но кто захочет уйти от чего-то привычного и понятного? А когда речь идет о крупной компании, все в разы сложнее, тем более если на кону большие деньги.

— Почему многие студии делают собственные движки? Не проще ли лицензировать существующий?

— Я лицензированием движков не занимался, но по себе могу сказать, что свое всегда ближе, и ты меньше тратишь времени на доработку и исправление чужих «косяков». Цепляешься за какой-то недочет в стороннем движке — и либо тебе приходится от чего-то отказываться, либо тратить большое количество времени на поиск обходного пути.

Года три назад при переходе с Flash на HTML я около месяца просидел на Unity в качестве эксперимента. На мой вкус, там слишком много рутинных вещей, игровые объекты избыточно раздроблены на подкомпоненты, и 90% твоего кода занимают связи между этими подкомпонентами. Другие вещи, которые я считаю важными, реализованы не идеальным образом. Возможно, тут сыграла роль та самая человеческая инертность.

— Ты разрабатываешь только движок или игрой тоже занимаешься?

— Разрабатывать движок, отгородившись от игры, вредно. Если сам с ним не работаешь как пользователь, то понятия не имеешь, куда двигаться дальше. Только непосредственно при разработке игровой сцены ты заметишь, что чего-то не хватает или какая-то процедура занимает больше сил, чем могла бы. Как только я натыкаюсь на рутину или баг — сразу добавляю какую-то кнопку, галочку, пару дней проверяю, как оно работает в «боевых условиях», и если все в порядке, включаю ее для всех.

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

Домашнее задание

Кто-то мечтает сделать классический ПК-шутер, кто-то мобильный раннер, кто-то возродить жанр стратегий в реальном времени. Поэтому задание будет общим.

В следующий раз мы немного отойдем от Unity и более подробно разберем создание логики для прототипа без навыков программирования. Для этого мы используем Blueprints, о которых мы уже говорили, и которые входят в базовый комплект движка Unreal Engine.

Это статья из нашего большого проекта с . Если выполнять все задания, можно — ни много ни мало — научиться делать видеоигры. И выиграть лимитированное издание PS4 Pro в конце каждого цикла статей.

Цикл «Разработка»:

Узнать правила

Теги