Пишем собственный игровой движок с помощью C++


Оглавление (нажмите, чтобы открыть):

Пишем собственный игровой движок с помощью C++

Сразу же перейдем к геймдеву и будем писать маленькую игрульку нашего детства.

Для начала подключаем библиотеку OpenGL к своей среде разработки, я лично программирую в Microsoft Visual Studio 2013.

200?’200px’:»+(this.scrollHeight+5)+’px’);»>
#include «stdafx.h»
#include
#include
#include
#include // подключаем все необходимые инклюды.

int N = 30, M = 20; // т.к. змейка будем ездить по квадратикам, создадим их, для нашего окна в идеале будет 30×20 квадратов
int scale = 25; // размер квадрата. Когда OpenGL будет расчерчивать поле для игры, расстояние между гранями квадрата будет 25 пикселей

int w = scale*N; // ширина поля
int h = scale*M; // его высота

int dir, num = 4; // 4 направления и начальный размер змеи.
struct < int x; int y; >s[100]; // структура змеи, X и Y координаты, массив с длинной.

class fruct // класс фруктов, тех самых, которые будет есть наша змея
<
public:
int x, y; //координаты фруктов, что и где будет находится

void New() // паблик с новыми фруктами. Он будет вызываться в начале игры и в тот момент, когда змея съест один из фруктов
<
x = rand() % N; // вычисление X координаты через рандом
y = rand() % M; // вычисление Y координаты через рандом
>

void DrawFruct() // паблик, отрисовывающий фрукты
<
glColor3f(0.0, 1.0, 1.0); // цвет фруктов. в openGL он задается от 0 до 1, а не от 0 до 256, как многие привыкли
glRectf(x*scale, y*scale, (x + 1)*scale, (y + 1)*scale); // «Закрашиваем» квадрат выбранным цветом, таким образом в нем «появляется» фрукт
>
> m[5]; // масив с фруктами, таким образом, у нас появится одновременно 5 фруктов в разных местах, а не один, как мы привыкли

void Draw() // функция, которая отрисовывает линии
<
glColor3f(1.0, 0.0, 0.0); // цвет наших линий, в данном слуае — красный
glBegin(GL_LINES); // начинаем рисовать и указываем, что это линии
for (int i = 0; i 0; —i) // движение змеи. Система остроумна и проста : блок перемешается вперед, а остальные X блоков, на X+1( 2 блок встанет на место 1, 3 на место 2 и т.д. )
<
s[i].x = s[i — 1].x; // задаем Х координату i блока координатой i — 1
s[i].y = s[i — 1].y; // то же самое делаем и с Y координатой
>
// далее у нас система направлений.
if (dir == 0) s[0].y += 1; // если направление равно 0, то первый фрагмент массива перемещается на один по Y
if (dir == 1) s[0].x -= 1; // если направление равно 1, то первый фрагмент массива перемещается на минус один по X
if (dir == 2) s[0].x += 1; // аналогиная система
if (dir == 3) s[0].y -= 1; // аналогичная система

for (int i = 0; i N) dir = 1; // Ей обратное направление. Например, если она выйдет за экран по высоте, то задаем ей направление, при котором она ползет
if (s[0].y > M) dir = 3; // вниз
if (s[0].x <
Display(); // Вызов функций
tick();
glutTimerFunc(100, timer, 0); // новый вызов таймера( 100 — промежуток времени(в милисекундах), через который он будет вызыватся, timer — вызываемый паблик)
>

Пишем собственный игровой движок с помощью C++

Приветствую тебя!
Если ты посетил эту тему, значит у тебя есть желания узнать нечто больше, чем: «как налепить текстуру на модель в Blitz3D» или «как сделать чтоб при нажатии клавиши воспроизводилась анимация модели».

Так вот, я решил что пришло время мне заняться очень серьёзным и большим делом.
«Уверен ли я что доделаю это не забив на старте?» — возможно спросите вы. Да не уверен, потому и пишу здесь чтобы мне было с кем обсуждать и генерировать идеи. Но не забью болт это уж точно, потому что я взял эту тему как тему моего будущего диплома.

Начнём!
Игровой движок — это такое срединное (middleware) ПО что упрощает разработку конечного ПО (software), в нашем случае компьютерной игры.
То есть в игровой движок должны входить все возможные библиотеки, утилиты + среда разработки для возможности создать конечный продукт.

Мой движок будет состоять из:

  1. Графического движка
  2. Физического движка
  3. Звукового движка
  4. AI движка
  5. Сетевого движка

Вроде бы ничего не забыл.

Он будет:

  1. Кросс-платформенным ( , , -?)
  2. OpenSource

Поскольку первый пункт: «Графический движок» — значит это самая важная часть игрового движка. А поскольку я буду писать его как 3Д то здесь вариантов не много — OpenGL

Честно говоря, писать с «0» я буду только графический движок. Все остальное использую уже готовенькое, но до этого еще ох как далеко.

Вопрос: А почему не выбрать и готовенький графический движок, их же туева хуча?
Ответ:

  1. Я хочу сделать свой, а не ковыряться в чужих
  2. Я хочу получить ценный опыт

Вот это было введение, далее самый важный (я так считаю) и самый первый этап жизненного цикла этого проекта:

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

Начнем с простых вопросов:
В: Сколько на это есть времени?
О: На первый экземпляр ГД (графического движка) — до 20-о Мая 2012г. На весь проект — до Декабря 2012г.
В: Сколько на это есть денег?
О: 0
В: Какой мой уровень знаний С++?
О: Низкий или средне низкий. (Будем повышать в процессе работы)
Если вас интересует что-то еще, пожалуйста задавайте ваши вопросы!

ОК, а теперь займемся планированием ГД. Поскольку это то что нужно сделать в первую очередь, и неизвестно наперед сколько на это востребуется времени, буду разрабатывать по итерациям. То есть сперва фундамент, а потом наращивать по возможности. Но чтобы понять что делать сперва, и куда двигаться потом нужен план, который называется: «спецификация требований». Иными словами — «хотелка». Вот эту вот «хотелку» я и предлагаю ВАМ дорогие мои составить. Сперва все что можно придумать крутого, а потом мы придём к тому, с чего можно начать.

Буду очень благодарен за все ваши идеи и вопросы!

На Github выложены исходники нового игрового движка на C++ 14

Недавно на GitHub были выложены исходники Banshee — высокопроизводительного игрового движка, написанного на C++14. Он подходит для создания как 2D, так и 3D игр, и предлагает широкий выбор высокоуровневых систем, необходимых для разработки игр, начиная с математических и утилитарных библиотек, и заканчивая поддержкой DirectX 11 и OpenGL, созданием GUI, физикой и поддержкой большинства популярных форматов для ресурсов (FBX, PNG, PSD, TTF и т.п.).

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

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

Движок распространяется под лицензией LGPL v3, однако есть возможность приобрести коммерческую лицензию. Что интересно, “приобрести” её можно даже за $0 — создатели решили применить модель “Pay What You Want”, как и разработчики CryEngine.

На странице проекта так же выложен видеообзор движка.

Выбор движка для первой игры


Разбор технологий и платформ — первая статья из цикла о разработке.

Автор: Антон Григорьев. Первую игру написал самостоятельно ещё в школе, а на 4-м курсе устроился на позицию джуниор-разработчика. В Pixonic работает заместителем технического директора и руководит отделом клиентской разработки. Отвечает за запуск новых проектов, обучение и внедрение новых технологий. Говорит на пяти языках, а программирует на десяти.

Когда вместе с vc.ru мы запускали проект «Пора создать свою первую игру», то не ожидали увидеть так много крутых работ в первом конкурсе. После цикла «Геймдизайн» нас завалили концептами с продуманными идеями, геймплеем, метой. С таким уровнем можно смело переходить к прототипированию на движке и тестированию конкретных механик.

За несколько недель мы:

  1. Придумали идею для игры.
  2. Написали концепт.
  3. Сделали бумажный прототип.
  4. Расписали мету.
  5. Целый день отвечали на вопросы о геймдизайне и не только
  6. И разыграли PS4 Pro God of War Limited Edition.

Эта статья — первая из нового цикла «Разработка», где мы будем учиться делать цифровые прототипы, выбирать движок, заполнять пробелы в кодинге с помощью обучающих материалов и не только. В конце снова разыграем крутые призы, а главным станет вышедший недавно бандл PS4 Pro Spider-Man Limited Edition. Поехали.

Платформы

Разработка игр для смартфонов, ПК и консолей значительно отличается. Хотя бы потому, что у них разные технические характеристики, устройства ввода/вывода и способы распространения продукта. Сразу сделать одну игру на несколько платформ не получится, но об этом мы еще поговорим. А пока рассмотрим особенности каждой из платформ и перейдем к движкам.

Мобильные устройства

  • Тачскрин для ввода и вывода информации — следовательно, пальцы не должны закрывать важные элементы интерфейса.
  • Смартфоны и планшеты должно быть удобно держать, чтобы играть одной/двумя руками. Отлично подходит для казуальных игр (match-3, hidden object, интерактивных историй и так далее), а для шутеров — не очень.
  • Ограниченная оперативная и графическая память, которые часто совмещены. Нужно постоянно следить за ними, отгружать ненужные ресурсы, текстуры и ужимать звук, то есть использовать форматы с компрессией.
  • Ограничения графики. Можно сделать крутые шейдеры как в Crysis, но на телефоне это будет жутко тормозить.
  • Частые потери пакетов, пинг в 200 мс — норма. В случае сетевых игр это нужно учитывать.
  • Распространение через сторы (App Store, Google Play, Amazon). Понадобится поддержка API покупок, социальных функций и так далее.
  • Для Android придется учитывать огромное количество гаджетов с разной производительностью, соотношением сторон экрана и разрешением.
  • Ввод с клавиатуры и мыши — то, к чему мы привыкли с детства.
  • Вывод картинки на экран монитора. Моделей мониторов много, они отличаются частотой смены кадра, размерами, разрешением — это нужно учитывать во время создания интерфейса игры.
  • Большой размер оперативной и видеопамяти. Можно позволить себе детализированные текстуры, плавные анимации, высокополигональные объекты мира и большие карты.
  • Огромное разнообразие видеокарт, процессоров и других комплектующих, что делает тестирование игры трудоёмким процессом.
  • Возможность распространения старым добрым способом (диски) либо через онлайн-магазины (самый популярный на данный момент — это Steam).

Консоли


  • Управление с джойстика. Лучше подходит для аркад, файтингов, игр от 3-го лица, но не так удобно для шутеров. Хотя последнее поколение геймеров играет с джойстика не хуже, чем с клавиатуры и мыши.
  • Продвинутые графические технологии.
  • Ограниченное количество конфигураций устройств. Например, если разработка ведётся под Xbox One или PS4, то нужно знать особенности только этих устройств, а значит и тестировать будет проще. В отличии от различных конфигураций ПК или целого «зоопарка» устройств на Android.
  • Не все плагины портированы или хорошо работают, например, сетевые библиотеки и плагины аналитики. Но в последнее время их становится больше).
  • Вывод на экран телевизора/проектора. У кого-то может стоять новый изогнутый Samsung, а у кого-то бабушкин «ящик» с электронно-лучевой трубкой — это тоже нужно учитывать.
  • Чтобы выпустить игру на консоли, нужно пройти лицензирование — процесс проверки соответствия игры стандартам платформы. Это долгий процесс, со множеством условий и ограничений. Например, при портировании одной игры на консоль от Nintendo я с командой когда-то не прошёл лицензирование с первого раза из-за того, что время загрузки уровня было больше половины секунды, а по их правилам это нужно обозначать в виде иконки загрузки или надписи Loading. И таких нюансов немало.
  • Ограничения на размер игры, поскольку она будет загружаться в браузере. Никто не любит долго ждать. А еще некоторые играют в браузере телефона и платят за трафик. В общем, делать полноценный AAA-тайтл нет смысла.
  • Ограничения по 3D (используется WebGl). Поэтому в Web в основном выходят 2D-игры.
  • Ограничения по сетевой игре, ведь обычные сокеты недоступны. Можно делать запросы по https или использовать WebSockets. В основном на Web можно делать простые игры с небольшим количеством запросов к серверу. Например, фермы. Сетевые 3D-шутеры делать тоже можно, но сложно.
  • Дешёвая интеграция с соцсетями. В первую очередь, Facebook. Поэтому делается упор на социальную составляющую.
  • Необычное управление: головой, перчатками, перемещением, джойстиками. Все эти устройства нужно поддерживать, у них обычно свой SDK. Кроме того, управление нужно сделать «естественным» для человека.
  • Эффект укачивания. Не всем шлем может «зайти», а при плохой реализации игры стошнит даже самого стойкого. Чтобы этого не было, движения в игре обычно делают плавными.
  • «Экран» VR-шлема делится на две части — по одной на глаз. Поэтому, чем выше разрешение, тем качественнее получается картинка. Если сравнить картинку на PS VR и HTC Vive, у последнего она будет детальнее, а потому и погружение ощущается лучше.
  • Совершенно другой пользовательский интерфейс, по сравнению с ПК и мобильными устройствами Обычно он трехмерный, а чтобы нажать на какой-нибудь элемент нужно задержать взгляд на определенной кнопке.

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

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

  • Лучше начать с одной платформы, на которой вам самим нравится играть — вы уже хорошо в ней разбираетесь.
  • Тестировать игры для мобильных устройств или ПК обычно в разы проще, чем, например, для консоли. Смартфоны и компьютеры есть почти у всех, и от нажатия кнопки Build в редакторе до загрузки прототипа на устройство может пройти лишь несколько секунд.

Обзор основных движков

Сначала поговорим про «взрослые» движки. Они позволяют разрабатывать под несколько платформ сразу, кроме того, у них есть очень много полезных инструментов. Пугаться и начинать с более простых не стоит — список составлен с учетом доступности для новичков, количества обучающих материалов в открытом доступе, наличия хороших вышедших игр на движке и цены.

Unity

Один из самых популярных движков на сегодня.

Платформы: мобильные устройства, ПК, Mac, Linux, консоли, Facebook, WebGl, VR и другие.

Unity идеально подходит для разработки под мобильные устройства (но не только). На нём сделаны Angry Birds 2, Hitman Go, Heartstone, Monument Valley, Fallout Shelter, Ori and the Blind Forest, Pillars of Eternity, Firewatch, Inside, Pokémon Go, Super Mario Run, Cuphead, Escape from Tarkov, Life Is Strange: Before the Storm и множество других популярных игр.

В Unity можно спокойно разрабатывать как 2D, так и 3D-проекты. В Asset Store есть много готовых платных и бесплатных решений: модели, текстуры, анимации и полноценные проекты. Например, шутер про зомби. Очень много обучающих материалов как от самих Unity, так и от энтузиастов на YouTube (подробнее расскажем в следующем материале цикла). Плюс множество плагинов для рекламы и внутриигровых покупок.

Язык программирования: C #, по сравнению c С++ у него меньше возможностей выстрелить себе в колено, в частности, это касается работы с памятью. Также поддерживается JavaScript, который на самом деле UnityScript. Если писать код совсем лень или нет навыков, есть плагины, которые позволяют делать игры без написания кода, например, Playmaker. Правда, за него придется выложить 45 долларов.

Кто-то ругает Unity за графику, но на самом деле графику можно сделать красивой на любом движке, просто в Unity она по умолчанию средняя. В последней версии движка появился новый Rendering Pipeline, и с ним вполне можно делать графику на уровне топовых AAA-проектов.


Стоимость движка: бесплатно, если разработчик зарабатывает на игре меньше $100 тысяч в год. Иначе — подписка, но тогда это не будет большой проблемой.

Мастер Йода рекомендует:  Серия коротких видео об уязвимости, взломе и способах защиты

Unreal Engine

Очень продвинутый движок, сообщество которого в последнее время быстро растет, чему способствует компания-разработчик Epic Games. По Unreal Engine проводятся митапы, стримы, а в этом году прошла первая конференция, посвященная разработке на Unreal.

Платформы: движок в первую очередь для тех, кто хочет делать проекты с крутой графикой на ПК и консолях. Для мобильных устройств тоже подходит, но пока популярных мобильных игр на Unreal Engine немного: Fortnite и PUBG. Ещё на нём сделаны серия Infinity Blade, Batman: Arkham Knight и Life is Strange.

Язык разработки: C++. Кого-то это может отпугнуть, но есть решение — блюпринты. С их помощью теоретически можно разработать игру, не написав ни строчки кода. На практике — это очень полезно для быстрой разработки прототипов. Также есть магазин ассетов Unreal Engine Marketplace, где можно скачать готовые модели, звуки и полноценные проекты.

Злые языки говорят, что Unreal Engine превосходит Unity по графике. На самом деле это просто разные движки. Хотя частицы и пост-эффекты в Unreal Engine по умолчанию всё же красивее.

Стоимость движка: 5% роялти, если разработчик зарабатывает на игре больше $3000 за квартал.

CryEngine

Стал известным после выхода Crysis — прорывной для своего времени игры. На нём вышло очень много крутых больших игр: первый Far Cry, MechWarrior Online, Sniper: Ghost Warrior 3, Armored Warfare, Homefront: The Revolution, Prey 2020-го года.

Платформы: ПК, консоли и VR. Официальной поддержки мобильных устройств нет, но по слухам разрабатывать можно.

Код движка можно модифицировать, что приносит как радость, так и боль. Я сам работал с CryEngine 2 — много модифицировали движок, исправляли баги, а когда попытались перейти на CryEngine 3 — потратили месяц и в итоге вернулись на предыдущую версию, так и не справившись с некоторыми проблемами.

Язык разработки: C++. Совсем недавно появился Marketplace с ассетами.

Стоимость движка: начиная с пятой версии — 5% роялти с при доходе с игры более $5000, а ведь помню времена, когда он стоил миллион евро.

Lumberyard

Молодой и бесплатный движок с открытым исходным кодом от Amazon на основе CryEngine для разработки игр AAA-класса. Главная особенность — встроенная поддержка сервисов от Amazon, например, AWS и Twitch.

Платформы: Windows, PlayStation 4, Xbox One, iOS, Android, VR (Oculus Rift, HTC Vive).

Серьезных проектов на Lumberyard в разработке пока можно пересчитать по пальцам, а выпущенных проектов нет вообще.

Язык разработки: C++.

Стоимость движка: бесплатный, но за поддержку сервисов Amazon придётся заплатить.

Другие движки

В последнее время среди разработчиков игр для Web набирают популярность HTML5-движки. В их основе лежит WebGL, WebAudio и JavaScript. Самые популярные движки: Phaser и Turbulenz.

Phaser

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

Лучше всего подходит для простеньких браузерных 2D-игр (match-3, hidden object, гонки).

Платформы: ПК, iOS, Android.

Turbulenz

Этот движок уже поддерживает 3D-графику с динамическим освещением, физику, обрабатываемую в реальном времени и мультиплеер с присоединением к игре в один клик по ссылке и интеграции с соцсетями. Но игр на Turbulenz пока немного.

Платформы: Web, ПК и PlayStation 4.

Есть и нишевые движки для визуальных новелл, головоломок, RPG старой школы и других 2D-игр. Например, Corona SDK, GameSalad, Cocos2d, Game Maker. В Википедии есть большой список игровых движков, но перечисленных выше должно быть достаточно.

Мы в компании считаем, что для новичков лучше всего подходит Unity. По нему очень много подробных обучающих материалов, простейшую игру можно сделать за день (умелец запилит Flappy Bird за пару часов), легко деплоить на девайсы. Мы сами используем Unity для разработки игр и прототипов, поэтому в следующих материалах цикла «Разработка» будем больше акцентировать внимание именно на этом движке.

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

  1. Выберите платформу, для которой вы будете делать игру в первую очередь, учитывая все особенности своего проекта.
  2. Выберите и установите движок, который вам подходит (для начала мы рекомендуем Unity).

В следующей статье рассмотрим источники обучающих материалов для разработки 2D-игр.

Game Engine своими руками #1

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

Если ты решил написать игровой движок, то значит ты уже хоть что-то знаешь, а как минимум неплохо владеешь тем или иным языком программирования. Если ты вынес со школьной скамьи основы Бейсика, то тебе, конечно, выбирать не приходится, но я, все же, не советовал бы тебе браться за игру, пока ты не овладеешь более совершенным инструментом. Если ты пишешь только на Delphi, и пишешь довольно долго, то у тебя есть хоть какие-то шансы выжить, но в идеале желательно овладеть языком Си, все-таки все солидные игры пишутся сегодня именно на нем. Лучше всего для нашего дела подойдет Visual C++ от Microsoft, желательно шестой версии, хотя это и не принципиально. Если ты долгое время общался с другими компиляторами, например от Borland, то тебе, конечно, имеет смысл оставаться в родной среде.

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

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

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

Если твой движок будет предназначаться для простенькой двухмерной аркады или скроллера, то тебе имеет смысл оформить свой движок в виде статичной (LIB) или динамической (DLL) библиотеки, описать в ней несколько необходимых высокоуровневых функций для вывода спрайтов, анимации палитры и воспроизведения звуков. Этого тебе вполне хватит. Потом, когда ты будешь писать игры, ты просто подключишь эту библиотечку с движком и воспользуешься
необходимой функцией.

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

При создании 3D движка для шутеров вроде Анрыла и Квейка, очевидно, в первую очередь стоит позаботиться о рендере, т.е. той части движка, которая будет отвечать за прорисовку (рендеринг) окружающего мира. Ты должен заранее определиться с системой, которую ты планируешь использовать. Будут ли это BSP-деревья (Quake), портальный движок (Unreal) или quad-деревья (Tribes). Особо ярые энтузиасты могут заняться строганием воксельного движка.

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

Уверен, что про моды ты слышал не раз. Может быть, даже сам принял участие в их создании и уж точно попробовал клепать уровни для любимой Кваки или Халф-лайфа. Сейчас инет просто расходится по швам от обилия модов для игрушек, есть люди, которые до сих пор пишут моды для первоквака. С помощью мода первоначальную игру можно просто-таки вывернуть наизнанку, поменять не только внешний вид, но и
кардинально перевернуть гейм-плей, а можно просто слегка изменить правила, например замедлить практически до нуля скорость снарядов от BFG и так вот резвиться. Всей этой романтики
не было бы вообще, если бы умные программеры, такие как Джон Кармак, не предусмотрели бы поддержку этих самых модов в своих движках.

Ты можешь спросить, почему большинство игр все же не поддерживают моды если это так круто? Ответить однозначно на этот вопрос довольно сложно, но можно привести несколько основополагающих доводов. Во-первых, поддержка модов дело довольно сложное, а порой совсем и не нужное, представь себе мод «Rocket Arena» для Сапера. Во-вторых, поддержка модов может нанести, не очевидные сначала, как моральные, так и финансовые убытки разработчику, если какой-нибудь Вася из Таганрога выложит в сеть мод, форматирующий винт при каждом запуске игры. Поэтому-то Кармак и пишет собственные компиляторы, чтобы еще на этапе создания мода присечь попытки деструктивной деятельности.

Существует вариант, когда движок поддерживает не моды, а внешние ресурсы в виде самодельных карт к игре, моделек, текстурок, звуков и т.п. Но в этом случае стоит серьезно задуматься о написании собственных утилит или о поддержке существующих бесплатных редакторов, потому что не у всех юзеров на компе стоят лицензионные 3D Studio MAX и Photoshop (ха-ха).

ОК, ты окончательно и бесповоротно решил писать поддержку модов, тогда давай обсудим как это все дело можно обустроить. Если ты хочешь разрешить пользователям модифицировать только ресурсы, то тебе не о чем беспокоиться, всего лишь нужно предусмотреть чтение небольшого файлика из каталога с модом, в котором будет сказано, как сам мод называется и какую карту нужно запустить первой, этого достаточно (в Half-Life этим файликом был ‘liblist.gam’). Если же ты хочешь разрешить программирование мода, то это более серьезно. Нужно подумать о безопасном месте в котором код мода будет храниться. Это не может быть самостоятельное приложение, так как моду необходимо, чтобы была запущена сама игра. Самым популярным решением является использование DLL (иногда разработчики меняют у файла расширение, чтобы смутить окружающих). DLL (Dynamic-Link Library) или динамические библиотеки это файлы в которых хранится набор некоторых функций, которые затем могут быть вызваны из любой другой программы при условии, что программа знает имя функций содержащихся в DLL. Когда моды организуются в виде динамических библиотек, заранее оговаривается какие функции по умолчанию должны содержаться в коде мода, а затем движок просто вызывает эти функции, не задумываясь над тем с каким именно модом он работает и где расположены функции, которые он вызывает. Причем код самой «родной» игры также можно выполнить в виде мода.

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

Наиболее распространенной является модель «Клиент-Сервер», когда один компьютер назначается сервером и начинает игру, а другие машины-клиенты потом к нему коннектятся, т.е. подсоеденяются. Сервер периодически опрашивает клиентов на предмет новых совершенных игроками действий, собирает инфу обрабатывает и раздает обратно, чтобы клиенты могли узнать последние новости друг о друге. На сервере хранится вся информация о положении и действиях игроков и других важных объектов. Если связь с клиентом была потеряна, то сервер либо делает его недоступным для других клиентов, либо просто оставляет его на растерзание врагам. Всякая мелочь типа разлетающихся гильз, облачков дыма от выстрелов, пятен крови и т.п. дело сугубо личное для каждого клиента и поэтому обрабатывается именно на клиентской машине. Сервер просто сообщает клиентам, что, например, игрока номер 2, только что офигенно разнесло на куски взрывом гранаты, а клиент уж сам решает рисовать эти куски или нет,
в зависимости от игровых настроек. Само собой игрок сидящий на сервере получает некоторые преимущества, так как вся информации крутится на его компе, особенно это заметно при плохом коннекте у клиентов. Что самое интересное, при такой организации сетевых взаимоотношений в движке можно не писать отдельно код для сингл-плейера и код для мултиплейера, просто при одиночной игре одна и та же машина выполняет роль как сервера, так и клиента. Все очень просто ��

Ну что, надеюсь ты понял, что написание движка дело довольно ответственное и это тебе не под «Ya mama» зажигать. Но я верю, что у тебя все получится, а если ты еще не почувствовал силы в своих руках, тогда не расстраивайся, мы сделаем все что сможем, чтобы помочь тебе в твоих девелоперских начинаниях. Главное не останавливайся перед трудностями и у тебя все получится!

Свой игровой движок. Для обучения (С++, OpenGL)

Во время своего #shaderchallenge (заинтересовался как устроена красивая графика, какие визуальные эффекты можно делать шейдерами и тд,- и решил непременно изучить) я пришел к тому, что мне необходимо знать как устроены внутри игровые движки. И, конечно, нет способа лучше изучить устройство чем попробовать написать свой!

Так сказать позаколачивать знания в свою голову, наступая на разные грабли, изгугливая разные форумы, доски и тп.

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

С какими-то простыми эффектами я познакомился в Unity3d, я по роду своей деятельности программирую именно на этом движке. Делал скринэффекты, простой аутлайн и тп. Кстати, знание того, как устроен пайплайн и какие эффекты можно получить, развязывают руки и в некоторых ситуациях просто думаешь: — Ага, так можно вот шейдерочек написать.

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

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

Про графическую библиотеку пояснил. Теперь про язык. Я очень доволен выбором именно C++, какой он крутой, ребята! Сколько всего я о нем не знал! Сколько добавилось в новых стандартах и сколько еще предстоит изучить!

Итак, встречайте, первое более-менее презентабельное демо, в моей собственном игровом движке Rudy Engine.

Первое демо

Реализовано: cubemap/skybox, загрузка моделей через assimp, half-lambert для освещения, overlay-рендерер для прицела и маркера-указателя на космическую станцию.

(очень дрожит видео, не стал искать какую-то хорошую программу для записи, воспользовался monosnap, наверное он не очень для этого подходит)

Дальнейшие планы

В дальнейшем я хочу сделать туман, shadow-mapping, и какие-то эффекты для этой демки и, возможно, переключиться на какую-то следующую. В целом, стараюсь придерживаться взрослой и мучительной разработки: дорабатывать движок таким образом, чтобы старые демо оставались рабочими. Подрихтовываю и подлатываю его. Для чего? Нужно понять этот trade-off как у Unity, чего стоит сделать универсальный инструмент?

Update 2020


Летом в 2020ом году, у меня закончился испытательный срок в крупной игровой студии и я написал в блоге, как я пересел с Unity на C++, вся вот эта практика с игровым движком, мне очень помогла!

Разработка движка [Ищу литературу][C++]

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

P.S. Сам я читал «Язык Программирования С++» С.В. Глушакова А.В. Коваля С.В. Смирнова (использую по сей день как справочник), «Оформление программного кода» А.В. Столярова.
Сейчас собираюсь читать Страуструпа и что-нибудь по ООП С++. А вот как проектировать структуру программы и как работать с графикой и т.п. я понятия не имею.

P.S.S. Интересует 2д движок, а не 3д (о 3д и мечтать не могу =))
P.S.S.S. Я знаю, что скорее всего идея закончится «ничем». Однако опыт — он и в Африке опыт 🙂

Надеюсь на ваше понимание и с нетерпением жду минимальный список литературы «must have» для разработки движка! =)

Laynos
> Какой минимальный набор книг программист должен прочесть, чтобы он был в
> состоянии написать движок? Сделаем акцент на том, что человек бездарь и ни разу
> не видел программный код.
все зависит от того какой двиг.

Laynos
> P.S.S.S. Я знаю, что скорее всего идея закончится «ничем». Однако опыт — он и в Африке опыт 🙂
для опыта рекомендую пописать игру, чтоб понять что нужно от движка.

Laynos
> Какой минимальный набор книг программист должен прочесть, чтобы он был в
> состоянии написать движок?

Правильный вопрос звучит так:
Какой минимальный практический опыт должен иметь программист, чтобы он был в состоянии написать движок?

Ответ: прежде чем начать изобретать собственный велосипед, не мешает поездить на уже существующих велосипедах, и побывать на заводах, где их изготавливают.

Laynos
> Сделаем акцент на том, что человек бездарь и ни разу не видел программный код.

Может тогда ему и не стоит начинать с создания движка?)

Laynos
> и ни разу не видел программный код.
Увидеть программный код. В репозиториях полно чужих двухмерных движков разного уровня сложности и качества, плюс получаешь скилл ковыряния чужого кода

И не делай ошибку, которую сделал я — изучи математику, от банальных косинусов и синусов (очень часто требуется в 2D) до векторов и матриц (очень облегчает работу) (я вот сейчас читаю 3D Math Primer for Graphics and Game Development и думаю, почему я раньше ее не читал? 🙂 )

Laynos
> Я знаю, что скорее всего идея закончится «ничем»
Если у тебя идея закончится ничем, стоит серьезно подумать — а твое ли программирование. Написание 2D движка (точнее каркаса), это очень элементарно. Я свой первый написал за пару дней (тоже без всякого опыта и знаний), и там было всего 2 тысяч строк кода из которых половина — чужой копипаст.

А вообще мой план был (и есть) таков

— добить знание С++ (Страуструп в тему)
— Алгоритмы (мой выбор Седжвик, говорят еще что стоит читать Ахо и Вирта)
— STL (лучше изучить, а уж потом писать свои суперскоростные строки и массивы), мне хватает «C++. Стандартная библиотека. Для профессионалов. Н.Джосьютис» (юзаю как шпалгалку, вспомнить как там правильно удалять и подобное:) )
— Boost (книг мало, но ознакомится хоть поверхностно стоит)
— Все от Мейерса, плюс опционально Макконелла (слишком специфичен и холиварен его «Совершенный код»)
— Александреску, я еще не читал, но раньше тут модно было его упоминать, сейчас как-то мало упоминают
— Паттерны. Книга банды четырех сложновата (я не осилил их стиль), но в гугле есть сто и один разбор каждого паттерна с примерами (часто из игр)

Потом берешь, на чем ты там хочешь писать свой 2D. Я брал SDL. И ковыряешь.

Laynos
> Какой минимальный набор книг программист должен прочесть, чтобы он был в состоянии написать движок?
Мне было достаточно MSDN-а и микрософтовских SDK-ов.

ASD
=)) Вы правы. Но я так выразился, так как хочу знать какими знаниями человек вообще должен обладать (соответственно — какую литературу читать)
war_zes
с математикой уже всё хорошо. Конечно иногда знаний не хватает, потому что я учусь на 1 курсе, однако в интернете можно найти всё.
Векторы и матрицы знаю, синусы и косинусы тоже. Векторную алгебру в целом не полностью, конечно, знаю, но кое-каким багажом знаний обладаю.
По поводу программирования: оно моё. Загорелся стать программистом с шести лет, с четырнадцати (сейчас мне 18) начал писать программы. Не могу сказать, что я мега гений, нет, много чего я ещё не знаю. Но в любом случае желание не исчезло. Мне нравится то, чем я занимаюсь и не боюсь трудностей
war_zes за пункты спасибо, буду знать где рыться)

вот это довольно полезная книженция http://www.gameenginebook.com/

war_zes
> — добить знание С++ (Страуструп в тему)
в страуструпе в основном базовые знания. если не боишься указателей и ссылок, умеешь использовать шаблоны то читать страуструпа особого смысла нет.

war_zes
> Алгоритмы
сейчас хвалят Кормена, но я не читал.

war_zes
> STL
Саттер, Мейерс

на английском очень много книг можно найти здесь https://github.com/vhf/free-programming-books
советую сразу учится на английском, программист со свободным английским зарабатывает в 1.8 раза больше чем без него.

Laynos
1) Боресков А. В. Графика трехмерной компьютерной игры на основе OpenGL.
2) Андре Ламот. Программирование трёхмерных игр для Windows. Советы профессионала по трёхмерной графике и растеризации.

Не думаю что кто то найдет нормальную литературу по архитектуре игро движков.
Удачная идея я считаю начать делать движок с написания этой самой демо игры.

1.Учишь инструмент
2.Ковыряешь чужой код
3.Офигеваешь как все хорошо у других
4.Вкуриваешь понемногу
5.Офигеваешь как все плохо у других
6.Пишешь идеальный код
7.Офигеваешь что нет идеального кода
8.Пишешь просто работающий код

Рекомендую такой план:
1. Пишешь игру А.
2. Общий код, какой найдёшь, подходящий для таких же игр в будущем, выносишь в «движок».
3. Закончил игру А, опубликовал, начинаешь писать точно такую же игру Б. Игры в одном стиле с одинаковым почти геймплеем.
4. «Движок» сэкономит тебе половину или более времени.

Не стоит надеяться, что игра Б может стать другой, нет конечно она окажется почти такой же, только потому, что движок заточен под такой вид игр. Нет универсального движка для хрен пойми какой абстрактной игры в вакууме. Есть движки для конкретного типа игр, и пишутся они людьми, которые написали как минимум одну такую игру руками на чужом движке. Движки для 3 в ряд, движки для шахмат, движки для roguelike, движки для думов, квейков, нитфорспидов, и так далее.

kvakvs
Полностью поддерживаю. Хотя я бы рекомендовал начинать даже не с игр, а с демосцен. А потом уже переходить к играм.

kvakvs
А я вот не согласен, большинство великих движкописателей как раз не шли по этому плану — unity, unigine, CryEngine, Unreal Engine или даже Ogre. Все сначала писали движок, а потом на нем игры.


Вообще думаю есть два варианта — или делать игры и выделять из них движок, или писать движок и делать на нем движок.

Laynos
Вообще могу написать пошагово, как делать:

— сначала создай окно, либо сам, либо через SDL или там GLFW (или любым другим способом)
— разберись с вводом с клавиатуры и мыши, и другими событиями (изменение размера, активность окна и т.д.). в SDL опять же есть

— выведи спрайт
— сделай возможность его вращения, масштабирования, вывода части спрайта
— выведи кучу спрайтов
— если надо, оптимизируй (в ручную отбрасывай спрайты за пределами окна, добавь атласы, батчинг)
— сделай вывод слоев для спрайтов (чтобы спрайты на одном слое всегда рисовались поверх спрайтов на других слоях независимо от порядка рисования)
— опционально добавь пиксельный шейдер если OGL или DX юзаешь

— Выведи текст. Текст рисуется двумя способами — либо из текстуры (bitmap font), либо из ttf (но это медленный способ). Можешь сделать два сразу

— Добавь крутое 2D освещение (есть много статей про то как делать)

— Мультиплатфрому, если осилишь

— прикрути физику (какой-нибудь box2d)

На этом у тебя уже и будет неплохой 2D движок

Разработка игр. С чего начать?

Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?

Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.

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

К чему стремиться?

Перед походом в магазин вы составляете список покупок (хотя бы в голове). Перед поездкой в другой конец города – прокладываете маршрут. Ну а перед тем, как обучаться разработке игр, целесообразно задаться вопросом: чем именно вы хотите заниматься? Создавать мобильные приложения или браузерные игры? Трудиться в крупной компании или маленькой? Профессионально заниматься разработкой игр или посвящать этому свободное от работы время? И если первое, то что интересует вас больше: создание интерфейса, отшлифовка геймплея или написание скриптов?

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

Какой язык учить?

Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?

Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив «Основы Java-программирования», тем более, что это бесплатно. Тем, кто заглядывается в сторону iOS – на Objective-C. Для браузерных игр порой хватает знания Ruby-On-Rails. Для совсем маленьких и простых временами достаточно HTML. В производстве Flash-игр используется ActionScript, а для написания скриптов любой сложности вам понадобится JavaScript или, возможно, не столь распространенная Lua. Для создания же небольших консольных игр требуется знание C#.

Что до наиболее крупнобюджетных игр (так называемого класса AAA), то большинство из них оснащены своим или заимствованным у коллег «движком». Нередко, впрочем, весь «движок» или его большая часть написана на C++. Именно этот язык использовался при создании множества известных «игрушек» – от Doom 3 и Call Of Duty до FIFA и The Sims. В то время как классика вроде Quake была написана на C.

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

Достаточно ли одного языка?

Одна из прелестей программирования – возможность постоянного саморазвития. В разработке же игр (особенно крупных) самосовершенствование, в том числе изучение как можно большего количества языков, – не прихоть, а жизненная необходимость. Так, опытные разработчики, трудящиеся на благо гигантов игровой индустрии, нередко сталкиваются с необходимостью поочередно писать на 7-8 языках. При этом, помимо вышеуказанных языков, им приходится изучать, к примеру, Python либо и вовсе SQL (как вы понимаете, для создания баз данных).

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

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

Практически все опытные разработчики вне зависимости от регалий и таланта начинали с небольших приложений: настольных игр, вариаций известных «игрушек», простеньких «флэшек». Тогда они не думали о крупных выставках вроде E3, а накапливали бесценный опыт. Почему бы не последовать их примеру? При этом не обязательно писать архисложный код. Для дебюта достаточно использования специальных программ для создания игр (к примеру, Game Maker). Ведь даже благодаря несложному инструментарию вы значительно облегчите себе жизнь. Во-первых, в миниатюре поймете логику и структуру практически любого игрового приложения. Во-вторых, набьете шишки, которые заживут во время перехода к серьезным проектам. Наконец, в-третьих, обогатите портфолио. Ведь даже простая «игрушка» требует массу времени, терпения и творчества для выдумки концепции, написании кода и устранения багов. Кроме того, показывает, что с производством игр вы знакомы не только в сухой теории.

Что брать за ориентир?

Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.

В разработке игр действует тот же принцип. Вы не сможете развиваться в вакууме. Поэтому играйте, вдохновляйтесь мастерами и, как губка, впитываете лучшее. При этом старайтесь смотреть на приложения не глазами «геймера», а взором разработчика. Иными словами: транспонируйте игру. Задумайтесь, почему в данный момент времени «бот» побежал налево, а не назад? Из-за каких факторов меняется сила и точность удара в спортивном симуляторе? Как создать «эффект усталости» при долгом беге персонажа? Как сделать так, чтобы во время дождя игрок слышал звук капель, а не свиной визг? В общем, проникайте в суть. Постарайтесь воссоздать в голове алгоритмы, с которыми сталкиваетесь во время игры. Поверьте, подобный конструктивный подход поможет вам в будущей нелегкой, но чертовски увлекательной карьере разработчика игр.

Автор: Александр Мороз

Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?

Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.

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


К чему стремиться?

Перед походом в магазин вы составляете список покупок (хотя бы в голове). Перед поездкой в другой конец города – прокладываете маршрут. Ну а перед тем, как обучаться разработке игр, целесообразно задаться вопросом: чем именно вы хотите заниматься? Создавать мобильные приложения или браузерные игры? Трудиться в крупной компании или маленькой? Профессионально заниматься разработкой игр или посвящать этому свободное от работы время? И если первое, то что интересует вас больше: создание интерфейса, отшлифовка геймплея или написание скриптов?

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

Какой язык учить?

Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?

Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив «Основы Java-программирования», тем более, что это бесплатно. Тем, кто заглядывается в сторону iOS – на Objective-C. Для браузерных игр порой хватает знания Ruby-On-Rails. Для совсем маленьких и простых временами достаточно HTML. В производстве Flash-игр используется ActionScript, а для написания скриптов любой сложности вам понадобится JavaScript или, возможно, не столь распространенная Lua. Для создания же небольших консольных игр требуется знание C#.

Что до наиболее крупнобюджетных игр (так называемого класса AAA), то большинство из них оснащены своим или заимствованным у коллег «движком». Нередко, впрочем, весь «движок» или его большая часть написана на C++. Именно этот язык использовался при создании множества известных «игрушек» – от Doom 3 и Call Of Duty до FIFA и The Sims. В то время как классика вроде Quake была написана на C.

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

Достаточно ли одного языка?

Одна из прелестей программирования – возможность постоянного саморазвития. В разработке же игр (особенно крупных) самосовершенствование, в том числе изучение как можно большего количества языков, – не прихоть, а жизненная необходимость. Так, опытные разработчики, трудящиеся на благо гигантов игровой индустрии, нередко сталкиваются с необходимостью поочередно писать на 7-8 языках. При этом, помимо вышеуказанных языков, им приходится изучать, к примеру, Python либо и вовсе SQL (как вы понимаете, для создания баз данных).

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

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

Практически все опытные разработчики вне зависимости от регалий и таланта начинали с небольших приложений: настольных игр, вариаций известных «игрушек», простеньких «флэшек». Тогда они не думали о крупных выставках вроде E3, а накапливали бесценный опыт. Почему бы не последовать их примеру? При этом не обязательно писать архисложный код. Для дебюта достаточно использования специальных программ для создания игр (к примеру, Game Maker). Ведь даже благодаря несложному инструментарию вы значительно облегчите себе жизнь. Во-первых, в миниатюре поймете логику и структуру практически любого игрового приложения. Во-вторых, набьете шишки, которые заживут во время перехода к серьезным проектам. Наконец, в-третьих, обогатите портфолио. Ведь даже простая «игрушка» требует массу времени, терпения и творчества для выдумки концепции, написании кода и устранения багов. Кроме того, показывает, что с производством игр вы знакомы не только в сухой теории.

Что брать за ориентир?

Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.

В разработке игр действует тот же принцип. Вы не сможете развиваться в вакууме. Поэтому играйте, вдохновляйтесь мастерами и, как губка, впитываете лучшее. При этом старайтесь смотреть на приложения не глазами «геймера», а взором разработчика. Иными словами: транспонируйте игру. Задумайтесь, почему в данный момент времени «бот» побежал налево, а не назад? Из-за каких факторов меняется сила и точность удара в спортивном симуляторе? Как создать «эффект усталости» при долгом беге персонажа? Как сделать так, чтобы во время дождя игрок слышал звук капель, а не свиной визг? В общем, проникайте в суть. Постарайтесь воссоздать в голове алгоритмы, с которыми сталкиваетесь во время игры. Поверьте, подобный конструктивный подход поможет вам в будущей нелегкой, но чертовски увлекательной карьере разработчика игр.

Написание игрового движка с нуля с помощью OpenGL [закрыто]

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

Мои языки и инструменты программирования:

  • C /C ++ полезно использовать только C?
  • Python
  • OpenGL
  • Git
  • GDB

Что я хочу извлечь из него:

  • Основной игровой движок
  • Рендеринг /Графика
  • Игра /правила игры
  • Вход (клавиатура /мышь /контроллеры, и т.д.) литий>

В рендеринге /графике:

3 ответа

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

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

Основной игровой движок

Игра /Правила игры

Вход (клавиатура /мышь /контроллеры и т. д.)

и т. д. Оттуда вы можете даже иметь подтемы. В рендеринге /графике

ГПИ /Huds /интерфейсы.

Только один из этих под-подтемов мог съесть много часов (или лет!) изучения!

Итак, сначала определите, что вы хотите узнать. Начните просто.

Используйте любой язык, на котором вам удобно, хотя некоторые из них лучше подходят для определенных задач. Например, основной движок и рендеринг, вероятно, лучше всего делать с языком более низкого уровня, например C /C ++ (если вам нужна производительность); но что-то вроде AI или Game Rules может быть лучше сделано на языке более высокого уровня. Ничто не говорит, что вы не можете смешивать и сочетать. Вы можете написать свой движок в C ++, ваш рендеринг в C (поскольку он хорошо работает с OpenGL), а затем используйте LUA для написания ваших правил игры и т. Д.

В качестве примера есть игровой движок Slick2D. Он написан на Java и является открытым исходным кодом. Это пример простого 2d-процессора, написанного и разработанного очень хорошо. Вы можете изучить основные понятия из этого, как игровые циклы, управлять состояниями игры и т. Д.

Если вам нравится C /C ++; Я бы предложил взглянуть на SDL /OpenGL. Он управляет некоторыми домашними делами, такими как вход, звук, создание окон и т. Д. И может фокусироваться на других вещах.

SDL + OpenGL — отличный выбор для запуска пользовательского игрового движка.

Я лично использую C-ish версию C ++, потому что я узнал, что работает лучше для меня. Под этим я подразумеваю, что я не использую никаких исключений. Для этого есть две причины: в первую очередь исключения требуют безопасного кода исключения, вплоть до OpenGL и SDL не так просто достичь. Что еще более важно, однако таким образом очень легко выставить объекты C ++ над C ABI, что невероятно полезно, если вы попытаетесь привести язык сценариев в микс.

Я нахожусь в подобной лодке, чем вы, и я записал некоторые из моих приключений с SDL и OpenGL в блоге ( immersedcode .org ) в случае, если кто-то заинтересован.

Для общей архитектуры у меня есть два предложения: если вы хотите, чтобы 3D-движок просматривал книгу «Game Engine Architecture» Джейсона Ландера. Если все, что вам нужно, это 2D, держите дизайн максимально простым и позволяйте себе вдохновлять XNA или другие проекты.

Наконец: не вызывайте OpenGL повсюду. Сделайте себе одолжение и выделите его на несколько мест, чтобы вы могли переключаться между настольным OpenGL /OpenGL ES или даже DirectX на более позднем этапе, если хотите.

Не используйте C, если деталь реализации не держит вас под прицелом. В противном случае используйте C ++, потому что он имеет более удобный язык, и вы всегда можете отказаться от использования этих возможностей позже. Я лично ничего не имею для /против Python, я никогда не использовал его.

Я бы не рекомендовал OpenGL против DirectX, потому что DX имеет современный объектно-ориентированный подход, который намного более понятен и более понятен /менее подвержен ошибкам. Интерфейс, предлагаемый OpenGL, крайне низок в сравнении.

Последнее, что у меня есть, это то, что я слышал от многих людей, которым я доверяю, что GDB полностью, полностью отстой, а отладчик Visual Studio — лучшая. Это не мой личный опыт, так что возьмите его с небольшим количеством соли.

Social Gaming с Playtika. Свой движок для слот-игры: блажь или необходимость?

В прошлой статье в рамках совместного проекта dev.by и компании Playtika мы упомянули о том, что в 2012 году для создания одного из крупнейших в мире мобильных приложений для социальных слотов компания решила написать собственный движок — Monosyne. Сегодня мы разберём, почему этот шаг был обоснован, и произошли ли какие-нибудь изменения в «стакане» мобильных движков на C#, который 4 года назад «скорее наполовину отсутствовал, чем был пуст».

Чуть больше, чем ничего

Выбирая язык для игры, менеджеры Playtika остановились, напомним, на C#. Кроме C#, ключевыми требованиями к движку были также кроссплатформенность, возможность работы с 2D и приемлемая производительность на мобильных гаджетах. С учётом этого выбор свёлся лишь к четырём вариантам: Unity, MonoGame, DeltaEngine и Axiom (Paradox, позже переименованный в Xenko, тогда находился в зачаточном состоянии).

По признанию инженера-программиста Playtika Антона Лобанова, одного из разработчиков Monosyne, серьёзно в итоге рассматривались только два движка: Unity и MonoGame. DeltaEngine и Axiom же остались за бортом из-за своей «заточенности» под 3D. О том, что весы склонились в пользу собственного решения, вы уже знаете. Ну, а чем специалистов Playtika не устроили Unityи MonoGame, мы сейчас и расскажем.

Unity: годный редактор, медлительность и закрытый код

Главными плюсами Unity для Playtika стали кроссплатформенность и приличный редактор. Жирных минусов, впрочем, оказалось значительно больше, и если бы не хорошее исполнение редактора, то даже у Unity не было бы шансов лечь в основу новой игры.

С 2012 года Unity успел сделать несколько шагов навстречу 2D, обзавевшись кое-каким набором соответствующих инструментов. В этом году разработчики движка даже обещали представить свежий 2D-модуль с редактором. Но несколько лет назад Unity всё-таки был ориентирован строго на 3D, из чего, естественно, для Playtika вытекал целый ряд различных нюансов.

Кроме этого, новая игра предполагала одновременную отрисовку большого количества «тяжёлых» объектов, которые лежали бы в сцен-графе и обладали кучей компонентов, таких как модели трансформаций, информация об иерархии и т.д. На практике Unity справлялся с подобными задачами со скрипом: при трансформации множества объектов производительность становилась удручающей. А ведь тогдашние смартфоны были куда «слабее» современных — они задуманную игру попросту не потянули бы. Также в то время Unity очень медленно рисовал текст (в версии 5.2 ситуация улучшилась значительно).

Разработчики Playtika отмечают, что одна из основных проблем производительности движков на C++, в частности Unity, использующих C# как скриптовый язык, — Interop (механизм для вызова из С# нативного кода и обратно). В итоге приходится «гонять» данные между управляемым кодом и нативным. В то же время, протестировав производительность математических операций в C# для чисел с плавающей точкой, в компании пришли к выводу, что она схожа с производительностью C++.

В итоге было решено писать все основные части движка на C# кроме совсем уж критических в плане производительности библиотек — для декодирования аудио и видео, разархивирования сжатых файлов и т.п. Также были использованы сторонние библиотеки на C++ для растеризации TTF-шрифтов. То есть third-party-инструменты не на C# задействовали только для того, что вызывается в игре редко — скажем, раз в кадр или вообще один раз, при загрузке уровня

В Monosyne все расчёты происходят в C#, нативный код C++ вызывается редко, и выигрыш в производительности при одновременной трансформации, скажем, 5000 объектов по сравнению с Unity получился в 5-6 раз. Создание объектов в собственном решении Playtika также происходит значительно быстрей. Всё это причина довольного медленного Interop’а.

«В первой рабочей версии движка iPod Touch 4 обрабатывал на 60 FPS около 300 игровых объектов — полностью трансформируемых и лежащих в сцен-графе. Это было ещё до всех наших оптимизаций, до оптимизаций Xamarin и до того, как они включили новый компилятор LLVM. Сейчас тот же iPod Touch 4 обрабатывает и визуализирует 3600 игровых объектов — это на уровне движков на C++. Кстати, во многих движках есть свой язык шейдеров, который абстрагирует от конкретного языка графического бэкенда. Мы же пишем шейдеры на GLSL и HLSL раздельно, что позволяет добиться максимальной оптимизации. Плюс мы сразу заложили хорошую систему Auto-Batching», — делится достижениями Антон Лобанов.

Ещё пара претензий к Unity были связаны непосредственно с кодом. Во-первых, его разработчики поддерживали только второй .NET, в котором отсутствуют значительно упрощающие разработку async, await и т.п. Playtika же работает с .NET 4.5.2, где всё это имеется, и более свежей версией C#. А во-вторых, из-за закрытости кода Unity оперативно решать проблемы с багами и прочими неприятностями невозможно.

Кстати, Антону закрытость кода Unity пришлась не по душе не только из-за трудностей с баг-фиксингом: «Мне не нравится, что в Unity, по сути, всё делается в редакторе, а потом ты просто всё это скриптуешь, подключая несложную логику. Этого оказалось мало для создания игры с уймой кастомных вещей. Конечно, позже разработчики Unity вынесли low-level graphics API — и его уже можно было вызывать из скриптов. Но мне кажется, что гораздо удобнее иметь свободный доступ к движку и использовать любой его уровень. То есть там, где не нужна высокая производительность, ты обращаешься к высокоуровневому API, высокоуровневым объектам и т.п., а там, где нужна, можешь использовать низкоуровневый API, написать кастомный рендер и т.д.».

И ещё один важный, во многом определяющий момент. В проекте Playtika было очень много видео с альфа-каналом (если точнее, разработчики называют это VideoSprite), которое нужно было проигрывать в текстуру в любом месте, в любое время и с любой трансформацией. В то время как многие делают спрайтовую анимацию, то есть рисуют покадрово спрайты, в Playtika рисовали покадрово видео с преобразованием YUVA в RGBA в пиксельном шейдере. В 2012 году разработчики понимали, что вряд ли смогут быстро написать движок, который позволил бы создавать такие продвинутые анимации, как сейчас, поэтому, собственно, и прибегли именно к VideoSprite. Ну, а Unity работать с видео с альфа-каналом не умеет до сих пор.

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

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

MonoGame: мало и плохо

Вторым главным кандидатом на подходящий для новой игры движок был MonoGame — порт Microsoft XNA на ещё довольно сырой Xamarin. Кроме общих для решений того времени проблем — отсутствия масок, которые формируются из 2D-изображения (любая форма, любая трансформация), и внятной работы с видео, специалисты указывают ещё на целый ворох негативных нюансов.

В общем-то, внутри архитектуры MonoGame находился API XNA — подход, послуживший основой для Monosyne. Но реализация разработчикам Playtika совершенно не понравилась. Да и MonoGame практически полностью повторял API XNA, и разработчики поняли: этого недостаточно — однозначно придётся очень многое менять и «допиливать». Ведь нужно было портировать игру с Flash, поэтому требовалось, чтобы все возможности Flash были и в задействованном решении.

Более того, в MonoGame не было почти ничего для новой игры: ни высокоуровневых спрайт-объектов и высокоуровневого API в целом, ни чего-либо касательно сцен (включая сцен-граф). Менеджер для загрузки asset’ов, спрайтов, эффектов, mesh’ей, модели, sprite batch’и — и, по большому счёту, всё. По своей сути MonoGame — низкоуровневое решение, и над ним пришлось бы самостоятельно надстраивать огромное количество инструментов.

Чтобы написать «свой MonoGame», Playtika понадобилось всего около 4 месяцев. А через 2 месяца после старта разработки в компании уже начали разрабатывать первую игру на Monosyne.

По словам Антона Лобанова, несмотря на открытость кода MonoGame, устранять баги в нём очень неудобно. Мало того что код сам по себе трудноподдерживаемый и напичкан #ifdef, так ещё и отличается рядом платформенных нюансов. Вместе с тем, разработчик Playtika отмечает, что изучение работы с C# в MonoGame помогло сделать их собственный движок лучше.

А воз и ныне там

Словом, решение написать собственный движок было более чем обоснованным. Тем более что Monosyne был использован далеко не в одной игре — на нём базируются Caesars Slots, Slotomania, Vegas Downtown Slots, Wild Luck Casino и Slotomania Sunrise с суммарной аудиторией в десятки миллионов человек.

При этом Playtika не остановилась на достигнутом. Совершенствование Monosyne не прекращается. Теперь движок умеет работать и с mesh’ами, и с particle’ами, и со скелетной анимацией, и со светом, и много с чем ещё. Monosyne уже поддерживает iOS, Android, Windows Phone 8 и 10, а также десктопную Windows, а в скором времени его планируется адаптировать для веба, Mac OS, Xbox One и PlayStation 4. Среди других амбициозных планов — создание собственного редактора и реализация 3D без ущерба производительности 2D.

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

Подытоживая, после 2012 года ситуация с движками на C# в целом улучшилась. Среди доступных на сегодня решений можно выделить Xenko — бывший Paradox. Другое дело, что почти все из «шарповых» движков, в том числе упомянутый Xenko, предназначены для 3D-проектов. А вот если вам понадобится 2D-движок на C#, то выбор у вас всё ещё будет совсем невелик.

Мастер Йода рекомендует:  Огромный видеокурс по основам JavaScript от freeCodeCamp
Добавить комментарий