Значит движок игры. Игровые Движки. Что они из себя представляют? Используйте итеративный подход

Это пятая статья из цикла материалов для начинающих разработчиков игр: Игровой движок - написать самому или взять готовый?

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

Почему не стоит писать свой игровой движок

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

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

Помимо бесплатных систем разработки игр, многие коммерческие игровые движки, полностью готовые к немедленному началу использования в игровых проектах, предлагают сразу несколько очень привлекательных схем лицензирования : полностью бесплатную (Unity 3D в бывшей Indie-редакции), смешанную схему с выплатой Royalties (Unreal Development Kit ) - 99 $ взнос за лицензию и выплаты 25 % прибыли после первых заработанных 5000 $, либо же доступную стоимость полновесной коммерческой лицензии (Unity Pro за 1500 $).

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

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

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

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

Unity3D

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

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

Unreal Engine

Unreal Engine - один из наиболее популярных движков для разработки ААА-игр. Gears of War, Batman: Arkham Asylum, Mass Effect — все эти хиты были сделаны именно на нем.

  • поскольку множество разработчиков его использует, то у Unreal Engine, пожалуй, лучшее комьюнити среди конкурентов. Несколько часов видео-туториалов тому подтверждение;
  • отличная техподдержка и механизм апдейта;
  • новые инструменты выходят с каждым обновлением
  • широкий ассортимент инструментов для различных целей (некоторые настолько просты в использовании, что ими может управлять даже школьник)
  • совместим с различными платформами (iOS, Android, Linux, Mac, Windows и большинство других)
  • новая лицензионная политика включает подписку стоимостью $19 в месяц и 5% роялти, если игра заработает более $5,000, что делает движок куда более привлекательным для разработчиков, чем раньше.
  • субъективны. Некоторые разработчики жалуются, что к определенным инструментам сложно привыкнуть

CryEngine 3

Если внешняя составляющая игры - ваш пунктик, то вам нужен именно CryEngine 3.

  • функция Flowgraph поможет украсить игру отличной графикой;
  • набор функций Fmod для создания мощного звукового сопровождения;
  • самый простой процесс создания AI в сегменте;
  • начинающему разработчику будет легко сделать UI.
  • относительно небрежная техподдержка бесплатной версии;
  • поскольку движок в индустрии сравнительно недавно, ему еще только предстоит создать крепкое комьюнити;
  • относительно высокий порог вхождения.

HeroEngine

Этот движок хорошо зарекомендовал себя в создании мультиплеерных игр - взять хотя бы Star Wars: The Old Republic. Лицензия довольно дорогая и вряд ли подойдет начинающим разработчикам, но если ваш проект амбициозен, то я бы советовал рассмотреть этот вариант.

  • в наличии несколько карт для создания открытого мира. Есть возможность их «бесшовного» соединения;
  • сказочно могучий AI!
  • удобный набор инструментов для моделирования карт;
  • подходит для создания комплексных миссий, крафтинга и собирания ресурсов;
  • техподдержка осуществляется при помощи сервиса HeroCloud, что весьма удобно.
  • скриптовый движок мощный, но неудобный в управлении;
  • HeroEngine вместе с сервисом поддержки клиентов HeroCloud слишком дорого стоит и вряд ли будет доступен начинающим разработчикам;
  • высокий порог вхождения.

Rage Engine

Немногие могут конкурировать с широким спектром возможностей, которые предоставляет Rage Engine. Grand Theft Auto V, Red Dead Redemption и многие другие прославленные проекты сделаны при помощи этого движка.

  • широкие возможности для создания больших миров и погодных эффектов;
  • мощный AI;
  • множество стилей геймплея на выбор;
  • быстрый сетевой код.
  • интерфейс движка сравнительно неудобный;
  • управление плохо оптимизировано под клавиатуру и мышку.

Project Anarchy

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

  • если вы планируете разрабатывать игры на платформах iOS, Android и Tizen, то лицензия — бесплатная;
  • мощные инструменты для поиска и устранения багов;
  • сильное комьюнити;
  • издатель предоставляет четкую, понятную документацию и образцы;
  • Fmod для аудио-сопровождения;
  • мощный Havok AI .
  • отсутствует возможность разрабатывать игру на Mac и Linux;
  • нет вводного руководства для начинающих разработчиков;
  • если игра для ПК, то лицензия влетит вам в копеечку.

GameSalad

Создатели этого популярного игрового движка обещают, что разработчику не придется написать ни строчки кода. В целом, это действительно так. Однако за все хорошее приходится платить: у движка есть ряд существенных недостатков. Если вы собрались разработать игру на iPhone в одиночку, то это ваш выбор.

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

GameMaker: Studio

Если вы начинающий разработчик и вам нужен простой и понятный движок, то GameMaker: Studio полностью отвечает вашим целям.

  • простое и интуитивно понятное управление;
  • собственный язык программирования Game Maker Language (GML);
  • интеграция со Steam;
  • кроссплатформенность.
  • относительно сложно устранять неполадки в игре;
  • чтобы экспортировать свою игру на популярные платформы, придется доплатить круглую сумму.

App Game Kit

App Game Kit - кроссплатформенный софт для разработчиков. Ценится за универсальность и легкость в управлении.

  • позволяет писать коды для основных платформ: Android iOS, Windows, Mac и Linux;
  • поставляется в комплекте с IDE , что позволяет тестить игры на любом устройстве;
  • без дополнительной установки уже включает в себя IAP, AdMob и Push;
  • есть мощные скрипты для 2D графики, физики и сетевого взаимодействия.
  • поскольку мало кто работает с этим движком, то недостатки программы долго не устраняются (относительно слабая техподдержка);
  • множество багов (что органично следует из предыдущего пункта).

Cocos2D

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

  • отлично интегрирован в платформу iOS;
  • бесплатный и с открытым исходным кодом;
  • широкий выбор инструментов разработки;
  • сильная поддержка комьюнити.
  • более сложный в применении, чем большинство аналогов;
  • высокий порог вхождения;
  • «заточен» конкретно под Mac или iOS. Отсутствует кроссплатформенность.

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

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

Общая для игр функциональность - графические решения, игровые механики, расчет физики и другое - стала выделяться в отдельные библиотеки, но, для того чтобы быть «игровым движком» было еще далеко. Во многом это было связано с серьезным различием программно-аппаратных платформ и неопределенности в самих играх. Ведь жанры и типы игр еще предстояло изобрести, при том, что многие первые игры были текстовыми. Собственно, именно для ранних адвенчур и платформеров и стали возникать игровые движки, особенно с развитием графики - хорошим примером можно назвать Adventure Game Interpreter (AGI). При разработке King’s Quest в далеком 1984 году, программисты Sierra On-Line столкнулись с неудобством низкоуровневой разработки столь сложной и перспективной по графике в те времена игры - и разработали набор решений, которым и стал AGI. Всего на нем было выпущено 14 различных игр за 5 лет на 7 различных платформах, поэтому понятие “кроссплатформенность” было важным уже тогда.

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

Начало

Ситуация начала меняться в 1993-м году после выхода игры Doom от компании id Software. Хотя при ее разработке использовались наработки движка Wolfenstein 3D, с точки зрения возможностей и модульности в ней был совершен настоящий технологический прорыв. В то время видеопроцессоры были не способны эффективно работать с трехмерной графикой, поэтому Джон Кармак (ведущий программист движка) выполнял все необходимые математические вычисления, служащие для манипуляции с трехмерными объектами, светом, затенением, наложением текстур и прочего самостоятельно. В результате, изображение выглядело трехмерным, на самом деле таковым не являясь. Поэтому Doom engine (первая версия id Tech) был не истинно трехмерным, а псевдотрехмерным. Но важно то, что техническая составляющая этой игры задала стандарт для того, что могло называться игровым движком. А именно, движок Doom был модульным, представлял из себя набор подсистем, в нем каждый четко отделенный программный слой отвечал за обработку своей порции данных. В результате, использовать его для различных игр (Hexen, Heretic, Strife) и силами сторонних разработчиков (Raven Software и Rogue Entertainment) стало намного проще. Поэтому появление игровых движков относят к середине 90-х годов 20-го века, то есть тогда окончательно сформировалось определение игрового движка в современном смысле.

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

Цели

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

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

Развитие игровых движков происходит вместе или под влиянием развития аппаратных и программных платформ, вместе с появлением новых игровых жанров и изменениями вкусов пользователей. Коротко говоря, развитием игровой индустрии в целом.

Генезис графических систем

В середине 90-х после появления видеопроцессоров, способных обрабатывать трехмерную графику стали появляться программные интерфейсы, упрощающие ее разработку. Вслед за кроссплатформенным OpenGL на сцену в составе DirectX вышел Direct3D для Windows. Эти 2 визуализатора на много лет вперед определили способы графического вывода в играх.

В 1996-м году вышла игра Quake на Quake Engine. Этот движок оказал колоссальное влияние на игровую индустрию.


Дерево движков, основанных на Quake Engine

Почти до конца десятилетия на рынке промежуточного программного обеспечения для игр (другими словами, игровых движков) практически единолично ритм задавала id Software. Однако в 1998-м году компания Epic Games выпустила успешную игру Unreal на одноименном движке - с настоящим технологическим прорывом по уровню графики. Ведущим программистом движка стал основатель Epic Тим Суини. Тим наравне с Кармаком является наиболее значимой фигурой в истории движков игровой индустрии - и Unreal Engine в его 3 и 4 версиях очень популярен и сейчас. Год спустя от Epic вышла ставшая еще более популярной игра Unreal Tournament.

В это же самое время конкурирующая компания-разработчик – id Software выпустила мультиплеерную игру Quake 3 Arena (на движке id Tech 3), ровно как Unreal Tournament включающую сетевые баталии.

Эти две игры стали флагманами индустрии, определив ее развитие на годы вперед.

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

Ситуация начала коренным образом меняться примерно в середине первого десятилетия 21-го века. Тогда на рынке и в свободном доступе стало появляться большое количество средств для разработки игр. Бизнес промежуточного ПО (middleware) стал набирать обороты. Сначала рынок заполнился графическими фреймворками: Ogre, DarkGDK и др., предоставляющие программисту высокоуровневую прослойку над графическим API. В то же время отличающиеся от игровых движков полным отсутствием внутриигровых редакторов.

Затем на рынок пришли полноценные игровые движки по ценам, уместным для небольшой инди-команды разработчиков, среди них: Torque 3D, Unity 3D, и многие другие. Даже стартовавшие как флагманские движки - например, CryEngine от Crytek и ранее упомянутый Unreal Engine - стали использовать намного более доступную ценовую политику и стали доступны даже начинающим разработчикам.


Torque 3D

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


Torque Game Builder

В это же время, благодаря World of Warcraft, в игровой индустрии стали очень популярны MMORPG - а параллельно многие жанры делали все большую ставку на мултиплеер. Целый ряд движков не смог предоставить пользователям новую функциональность для клиент-серверных приложений, поэтому они ушли в небытие. Другие движки были адаптированы для мультиплеерного мира путем разработки для них серверных решений, так для Unity 3D были разработаны Photon и SmartFox. Третий тип универсальных движков, изначально являясь клиент-серверным, не почувствовал изменений. К нему относится Torque 3D. Также на рынке появились новые движки, предназначенные для глобальных многопользовательских игр, например HeroEngine, BigWorld, объединяющие масштабируемое под тысячи игроков серверное решение и доступный конкретному игроку клиент.


HeroEngine

На рынке еще с 90х существовали браузерные игры, а затем второе рождение им дали социальные сети. необходимость эффективно создавать игры для браузера не осталась незамеченной. Разработчики универсальных движков, например Torque 2D/3D, Unity 3D отреагировали на это довольно оперативно, выпустив плагины для браузеров, которые позволили отображать графику прямо в окне последних. Сначала популярность завоевал визуализатор на основе технологии Flash, но по целому ряду причин эта технология все больше теряет свою долю на рынке. Поэтому сейчас для визуализации в вебе часто используется библиотека для языка JavaScript - WebGL, которая позволяет создавать интерактивную 3D-графику. Однако, из-за недостатков языка, таких как отсутствие многопоточности, библиотека не может полноценно удовлетворить потребности игроделов. Ей на смену консорциумом W3C (куда входят: Microsoft, Google, Mozilla и др.) разрабатывается новый низкоуровневый бинарный компилируемый формат WebAssembly.


WebAssembly

Под конец первого десятилетия 21-го века очень быстро развивались мобильные технологии. Как гром среди ясного неба появились мобильные устройства по мощности сопоставимые с ПК средней ценовой категории и способные запускать мощные игровые приложения со всеми спецэффектами, которыми обладали низкоуровневые графические интерфейсы. На что разработчики игровых движков ответили в некоторых случаях созданием специализированных конверторов, создающих нативный для конкретного оборудования код (как, например, Unity 3D), а в других - модернизировали свои продукты для кроссплатформенности (к примеру, Torque 2D , Cocos 2DX). Также, на рынке появились новые игроки, предлагающие кроссплатформенные движки для всего парка мобильных устройств, выполняющиеся со скоростью нативного кода. Примеры подобных средств: Corona SDK, Marmalade SDK, AGK (App Game Kit).


Corona SDK

Также, возник целый ряд кроссплатформенных движков, позволяющих разработать игру при минимальном знании программирования. Примерами можно назвать Construct 2 и GameMaker Pro. Используя готовые решения и визуальные редакторы, можно быстро - иногда в течение нескольких часов - создавать простые игры. Это оказалось особенно распространенным на мобильном рынке, где распространение free2play модели и короткая игровая сессия сделали “простые” игры вполне успешным жанром.

Новинки игровой индустрии

Низкоуровневые программные интерфейсы: OpenGL, DirectX развиваются в соответствии с видеоадаптерами. Раз в 1 - 2 года появляются новые версии, которые поддерживают и дают прикладным программистам (разработчикам движков) реализовать всю функциональность железа. DirectX уже достиг 12-й версии. С другой стороны на смену OpenGL пришел Vulkan - новый кроссплатформенный графический api, разрабатываемый консорциумом Khronos Group, куда входят производители железа и софта.

VR


Последний на текущий момент тренд игровой индустрии - виртуальная/дополненная реальность. Подавляющее большинство современных игровых движков уже обзавелись поддержкой данной технологии, среди них: Torque 3D, Unity 3D, Unreal Engine 4. Разработано и множество сторонних расширений, таких как Vuforia Unity Extension. Чтобы реализовать поддержку очков VR разработчикам движков надо не только добавить визуализацию на второй экран (для второго глаза) с отличным от первого содержимым (так как, первый и второй глаза могут видеть отличающиеся сцены), но и так же добавить поддержку управления с новых устройств ввода, которые различны для разных гарнитур VR и пока не стандартизированы.

Итоги

За годы существования игровой индустрии в ней образовались 5 больших типов игр с точки зрения игровых движков:

1) Однопользовательские игры (со своей спецификой для ПК и консолей)
2) Многопользовательские онлайн игры
3) Игры для социальных сетей и браузерные игры в целом
4) Мобильные игры (со спецификой для телефонов и планшетов, и Android/iOS)
5) Игры для VR/AR

Кроме того, существуют и другие платформы - от SmartTV до игровых автоматов.

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

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out . Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)


Your browser does not support HTML5 video.


Hop Out - та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры - перекрасить каждую из платформ, как в Q*Bert.



С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

  • Вы - ремесленник. Вам нравится строить системы с нуля и видеть, как они оживают.
  • Вы хотите узнать больше о разработке игр. Я в игровой индустрии 14 лет и всё ещё пытаюсь в ней разобраться. Я даже не был уверен, что смогу написать движок с чистого листа, ведь это так сильно отличается от повседневных рабочих обязанностей программиста в большой студии. Я хотел проверить.
  • Вам нравится ощущение контроля. Организовать код именно так, как вам хочется, и всегда знать, где что находится - это приносит удовольствие.
  • Вас вдохновляют классические игровые движки, такие как AGI (1984), id Tech 1 (1993), Build (1995), и гиганты индустрии вроде Unity и Unreal.
  • Вы верите, что мы, индустрия игр, должны сбросить покров таинственности с процесса разработки движков. Мы пока не очень-то освоили искусство разработки игр - куда там! Чем тщательнее мы рассмотрим этот процесс, тем выше наши шансы усовершенствовать его.

Игровые платформы в 2017-ом - мобильные, консоли и ПК - очень мощные и во многом похожи друг на друга. Разработка игрового движка перестала быть борьбой со слабым и редким железом, как это было в прошлом. По-моему, теперь это скорее борьба со сложностью вашего собственного произведения . Запросто можно сотворить монстра! Вот почему все советы в этой статье вращаются вокруг того, как сохранить код управляемым. Я объединил их в три группы:

  1. Осознайте, что сериализация - обширная тема.

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

Используйте итеративный подход

Мой первый совет - не задерживаясь заставьте что-нибудь (что угодно!) работать, затем повторите.


По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал SDL , открыл Xcode-iOS/Test/TestiPhoneOS.xcodeproj , затем запустил на своём iPhone пример testgles2 .



Вуаля! У меня появился замечательный вращающийся кубик, использующий OpenGL ES 2.0.


Моим следующим шагом было скачивание сделанной кем-то 3D-модели Марио. Я быстро написал черновой загрузчик OBJ-файлов - этот формат не так уж сложен - и подправил пример, чтобы он отрисовывал Марио вместо кубика. Ещё я интегрировал SDL_Image , чтобы загружать текстуры.



Затем я реализовал управление двумя стиками, чтобы перемещать Марио. (Поначалу я рассматривал идею создания dual-stick шутера. Впрочем, не с Марио).



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



К тому моменту я отказался от формата OBJ и написал скрипт на Python для экспорта собственных JSON-файлов из Blender. Эти JSON-файлы описывали заскиненный меш, скелет и данные анимации. Я загружал эти файлы в игру с помощью библиотеки C++ JSON .



Как только всё заработало, я вернулся в Blender и создал более проработанного персонажа (Это был первый сделанный и зариганный мной трёхмерный человек. Я им весьма гордился.)



В течение следующих нескольких месяцев я сделал такие шаги:

  • Начал выделять функции работы с векторами и матрицами в собственную библиотеку трёхмерной математики.
  • Заменил.xcodeproj на проект CMake
  • Заставил движок запускаться и на Windows, и на iOS, потому что мне нравится работать в Visual Studio.
  • Начал перемещать код в отдельные библиотеки "engine" и "game". Со временем, я разделил их на ещё более мелкие библиотеки.
  • Написал отдельное приложение, чтобы конвертировать мои JSON-файлы в бинарные данные, которые игра может загружать напрямую.
  • В какой-то момент убрал все библиотеки SDL из iOS-сборки. (Cборка для Windows всё ещё использует SDL.)

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




Может показаться, что при таком подходе много времени теряется впустую, ведь вы всегда пишете плохой код, который потом требуется переписывать начисто. Но большая часть изменений представляет собой перемещение кода из одного.cpp -файла в другой, извлечение определений функций в.h -файлы или другие не менее простые действия. Определить, где что должно лежать - сложная задача, и решить её проще, когда код уже существует.


Готов поспорить, что больше времени тратится при противоположном подходе: пытаться заранее продумать архитектуру, которая будет делать всё, что вам понадобится. Две моих любимых статьи про опасности чрезмерной инженерии - The Vicious Circle of Generalization Томаша Дабровски и Don’t Let Architecture Astronauts Scare You Джоэла Спольски.


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


Итеративный подход дал мне куда более элегантную архитектуру, чем я мог бы вообразить, глядя на чистый лист бумаги. iOS-сборка моего движка сегодня на 100% состоит из оригинального кода, включая собственную математическую библиотеку, шаблоны контейнеров, систему рефлексии/сериализации, фреймворк рендеринга, физику и аудио микшер. У меня были причины писать каждый из этих модулей самостоятельно, но для вас это может быть необязательным. Вместо этого есть множество отличных библиотек с открытым исходным кодом и разрешительной лицензией, которые могут оказаться подходящими вашему движку. GLM , Bullet Physics и STB headers - лишь некоторые из интересных примеров.

Дважды подумайте, прежде чем слишком обобщать

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

Время от времени нарушайте принцип DRY

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

  • Owned<> для динамически выделяемых объектов, имеющих единственного владельца.
  • Reference<> использует подсчёт ссылок чтобы позволить объекту иметь несколько владельцев.
  • audio::AppOwned<> используется кодом за пределами аудио микшера. Это позволяет игровым системам владеть объектами, которые аудио микшер использует, такими как голос, который в данный момент воспроизводится.
  • audio::AudioHandle<> использует систему подсчёта ссылок, внутреннюю для аудио микшера.

Может показаться, что некоторые из этих классов дублируют функциональность других, нарушая принцип DRY . В самом деле, в начале разработки я пытался повторно использовать существующий класс Reference<> как можно больше. Однако, я выяснил, что время жизни аудио-объекта подчиняется особым правилам: если объект закончил воспроизведение фрагмента, и игра не владеет указателем на этот объект, его можно сразу же поместить в очередь на удаление. Если игра захватила указатель, тогда аудио-объект не должен быть удалён. А если игра захватила указатель, но владелец указателя уничтожен до того, как воспроизведение закончилось, оно должно быть отменено. Вместо того чтобы усложнять Reference<> , я решил, что будет практичнее ввести отдельные классы шаблонов.


95% времени повторное использование существующего кода - верный путь. Но если оно начинает вас сковывать или вы обнаруживаете, что усложняете что-то, однажды бывшее простым, спросите себя: не должна ли эта часть кодовой базы в действительности быть разделена надвое.

Использовать разные соглашения о вызове - это нормально

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


В моём C++ движке некоторые функции принадлежат классами, а некоторые - нет. Например, каждый противник в игре - это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, в моём движке выполняются вызовом sphereCast() , функции в пространстве имён physics . sphereCast() не принадлежит какому-либо классу - это просто часть модуля physics . У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.



Как минимум, постарайтесь представить, насколько сложными будут ваши требования. Если вы делаете маленькую игру вроде Flappy Bird, с несколькими ассетами, вам скорее всего не придётся много думать о сериализации. Вероятно, вы можете загружать текстуры напрямую из PNG и этого будет достаточно. Если вам нужен компактный бинарный формат с обратной совместимостью, но вы не хотите разрабатывать свой - взгляните на сторонние библиотеки, такие как Cereal или Boost.Serialization . Не думаю, что Google Protocol Buffers идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.


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


Я люблю сравнивать наблюдения по этой теме, так что мне очень интересно услышать мнение других разработчиков. Если вы писали движок, привел ли ваш опыт к тем же выводам? А если не писали или ещё только собираетесь, ваши мысли мне тоже интересны. Что вы считаете хорошим ресурсом для обучения? Какие аспекты ещё кажутся вам загадочными? Не стесняйтесь оставлять комментарии ниже или свяжитесь со мной

Многие, наверное, знают, сколько времени и сил уходит на создание только одной игры. Нужно придумать оригинальную сюжетную линию с интересными персонажами и написать огромный сценарий. А когда все продумано, дело идет за реализацией проекта. Создание различных моделей (объектов уровней, людей и т.д.), создание локаций, написание программных кодов, снятие внутри игровых роликов. И это далеко не все. Если вдаваться в подробности, то на описание всех деталей разработки игры уйдет не одна страница. Как правило, делаются они на специальных игровых движках. Давайте сначала разберем, что значит понятие «игровой движок» и его предназначение.

Игровой движок (англ. game engine ) - это центральный программный компонент компьютерных видеоигр и других интерактивных приложений с графикой, обрабатываемой в реальном времени. Он обеспечивает основные технологии, упрощает разработку и часто дает игре возможность запускаться на нескольких платформах. Игровой движок подразумевает целый комплекс прикладных программ, включающий движок рендеринга (визуализатор) для 2D или 3D графики, физический движок, звук, скриптинг, анимацию, искусственный интеллект, сетевой код, streaming, управление памятью, threading и графические сцены. То есть, все части кода, написанные программистами при разработке игры, являются компонентами движка. Геймплей определяется функциями, реализованными в этих программах, поэтому, чем больше этих самых функций, тем разнообразнее будет игровой процесс.

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

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

CryEngine.

CryEngine является первым игровым движком, разработанным немецкой компанией Crytek. На нем же студия сделала свою первую игру, которая носит название Far Cry . Движок был выпущен 2 мая 2002 года, а в 2006 году все права на него перешли компании Ubisoft.

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

Разработка CryEngine началась сразу же после основания компании. Изначально предполагалось, что движок будет использоваться для технологической демонстрации компании nVidia. Но на выставке ECTS 2000 (англ. European Computer Trade Show - Европейская Компьютерная Выставка) творение Crytek произвела на всех посетителей большое впечатление. После этого разработчики взялись за разработку своего первого шутера, в котором будут задействованы все возможности движка, а также несколько новых обновлений. Суть этих обновлений заключалось в том, чтобы новые шейдеры дали возможность вести все сложные просчеты в другом длинном шейдере, и при формировании рельефных изображений на сложно-освещенных объектах больше не приходилось тратить значительные ресурсы ускорителей. А новая технология движка PolyBump позволяет создавать текстуры, используя при этом, реальные полигоны. В этом и есть его отличие от Bumpmapping, где при создании текстуры используются карты нормалей. Позже разработчики выпустили другую версию движка, в которой были улучшены уже присутствующие технологии, а также были добавлены новые. Одной из таких новинок является Geometry Instancing.

Спустя 2 года, после выхода игры Far Cry, права на нее приобрела компания Ubisoft. Согласно условиям договора, к ней перешла вся интеллектуальная собственность не только игры, но и самого движка, персонажи, сюжет, франшиза, сеттинг, торговая марка, логотип, права на разработку продолжений и издание. После этого, Crytek продолжили развитие движка в дополнениях Far Cry для консолей Xbox, Xbox 360 и Nintendo Wii.

Несколько особенностей первого CryEngine:

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

CryEngine 2.

CryEngine 2 был создан немецкой компанией Crytek и в первый раз был применен в шутере Crysis от этой же студии. Официальный анонс движка состоялся 23 января 2006 года, но выпустили его только в следующем году того же числа. Разработчики делали заявление, что сама игра останется ПК-эксклюзивом, так как техническая начинка консолей не сможет воспроизвести ее в хорошем качестве. Да и на многих компьютерах того времени Crysis, из-за своей графической начинки, частенько подтормаживал. После выхода игры, Crytek решили продемонстрировать видео в HD-формате, в котором были показаны все возможности нового движка. В первый раз его показали на выставке Game Developers Conference 2007 (GDC) , но из-за своей большой популярности ролик стал публичным.

Позже этот движок продемонстрировали на выставке (GDC) 2008, проходившей в Сан-Франциско. Там ему вручили награду «Best Technology Award», что переводится как «Лучшая технология». Также в этой категории соревновался Crysis с такими известными играми как Halo 3 , Call of Duty 4: Modern Warfare , Portal и Assassin"s Creed . Что немаловажно, он обошел их всех. На этой же выставке разработчики сделали заявление, что CryEngine 2 будет показан на консолях Xbox 360 и PlayStation 3, а также, что он будет оптимизирован, а это значит, что он будет работать даже на средних по мощности компьютерных системах. К тому же, одна компания разработала игру Vigilance, которая получила награду на игровых соревнованиях I/ITSEC Serious Games Competition. Сама игра не предназначена для общественного пользования. Она нужна для подготовки военных специалистов по обнаружению и идентификаций взрывных устройств.

Особенности и ключевые характеристики.

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

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

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

Физический движок CryPhysics применен почти ко всем объектам на уровне. С его помощью, деревья в игре Crysis гнуться в ту сторону, в которую дует ветер, и могут ломаться от действий игрока. Здания разрушаются по физике, и снести их не так просто. После разрушения объекта с обломками можно взаимодействовать.

Помимо Crysis-а и его сюжетных аддонов, движок использовался в таких играх, как Merchants of Brooklyn, Blue Mars, Entropia Universe, Kailas и в ряде других проектов.

CryEngine 3.

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

Первое отличие нового движка от предыдущих версий является его кроссплатформенность. Разработчики решили перестать ПК-эксклюзивы из-за разгула пиратства. Поэтому шутер Crysis 2 вышел не только на персоналках, но и на консоли. Новый CryEngine оптимизировали для хорошей работы на средних по мощности компьютерах и приставках. В сети есть ролик, где сравнивались кадры CryEngine 3 с запущенной игрой Crysis на CryEngine 2.

Cравнение CryEngine 3 и CryEngine 2

Видео показало, что первый проигрывает второму в плане качества графики, но это не помешало ему стать популярным. Движок завоевал награды: «European Innovative Games Award» (Европейская премия за инновационные игры) и «Best Simulation in Real Time» (Лучшая симуляция в реальном времени).

Нововведения в CryEngine 3.

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

Технология попиксельного освещения поддерживает симуляцию пулевых отверстий, окон, поверхностей, анимированные текстуры, отражение и преломление. Новая внедренная технология «bershader» содержит в себе кучу полезных нововведений: до четырех источников света, карты нормалей, зеркальные и детализированные текстуры, туман и т.д.

Игровой движок Rockstar Advanced Game Engine (RAGE) создан подразделениями Rockstar San Diego и Rockstar North основной студии Rockstar Games. Движок используется только этими компаниями, поэтому он не лицензируется и не предназначен для использования частным лицам.

Изначально «Рокстаровцы» использовали движок Criterion Games, который носил название RenderWare. Но позже, крупное американское издательство Electronic Arts приобрело саму студию, и ее творение, что плохо сказалось на политике лицензирования движка.

В связи с этим, Rockstar решили создать свой собственный движок, и привлекли к этой работе свои подразделения. Первая игра, созданная в новом (RAGE) вышла 23 мая 2006 года и носит название «Rockstar Games presents Table Tennis». А спустя некоторое время, разработчики выпустили новую часть знаменитой игровой серии - GTA 4 , которая была уже второй игрой на новом движке и впервые использовала новую технологию процедурной анимации «euphoria».

Особенности и характеристики.

Как и все другие движки, RAGE содержит в себе графический, звуковой, анимационный и физический движки, игровой искусственный интеллект, скриптовый язык и все необходимые инструменты. Главным преимуществом творения Rockstar является способность эффективно обрабатывать большие игровые пространства, так как игры этой студии не делились на небольшие уровни, а составляли огромную территорию. Разработчикам пришлось создать специальный менеджер памяти движка. Он постоянно распределяет и удаляет объекты из оперативной памяти без ее фрагментирования.

Кроме обработки игрового пространства разработчики уделили внимание и физике транспорта в играх. Им постоянно приходилось учитывать такие параметры машин, как вес, силу сцепления, езду по определенной поверхности и другие характеристики. За анимацию людей в играх отвечает «euphoria». Его особенностью является то, что он самостоятельно создает анимацию персонажей на лету. Такая технология стала применяться после выхода GTA 4.

id Tech 4.

id Tech 4 в начале своей разработки планировался как расширение для уже готового движка Quake III. Но после внедрения нового рендеринга, было принято решение создать новый движок, путем полного переписывания и изменения остальной части от старого. Но вся проделанная работа стоила того. В свое время он был один из самых технологичных игровых движков. На его основе были созданы игры: Doom 3 , Quake 4 , Prey , Enemy Territory: Quake Wars , Wolfenstein .

Особенности.

Одной из главных новшеств id Tech 4 является использование попиксельного освещения. Такая техника применялась в Doom 3. Также эта игра использовала технологию унифицированного освещения и затемнения, которая генерирует все эти параметры «на лету». Если раньше вся информация об источнике света сохранялось, и на все освещение в уровне в целом никак не влияла, то теперь все изменилось. Любой объект или персонаж может отбрасывать тень не только на определенную часть локации, но и на самого себя.

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

Системные требования.

Существенным недостатком id Tech 4 является необходимость в высокопроизводительной видеокарте, совместимость с Direct3D 8. Из-за этой проблемы приходилось выбирать определенные типы графических плат, так как не все из них поддерживали нужный Direct. В качестве примера можно привести видеоадаптер GeForce 4 Ti. С этой картой игра спокойно работала, в то время как на других она, либо вообще не запускалась, либо шла с недостаточным количеством кадров в секунду. Пользователи не были довольны этим и поэтому, id Software пришлось внести значительные изменения в движок. После добавления этих изменений ситуация заметно улучшилась.

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

Статьи по теме: