Где находится игровой движок

Игровой движок — Википедия

Игрово́й двигатель (англ. game engine) — базовое программное обеспечение компьютерной игры^[1]. Разделение игры и игрового двигателя часто расплывчато, и не всегда студии проводят чёткую границу между ними. Но в общем случае термин «игровой двигатель » применяется для того программного обеспечения, которое пригодно для повторного использования и расширения, и тем самым может быть рассмотрено как основание для разработки множества различных игр без существенных изменений^[2].

Термин «игровой двигатель » появился в середине 1990-х в контексте компьютерных игр жанра шутер от первого лица, похожих на популярную в то время Doom. Архитектура программного обеспечения Doom была построена таким образом, что представляла собой разумное и хорошо выполненное разделение центральных компонентов игры (например, подсистемы трёхмерной графики, расчёта столкновений объектов, звуковой и других) и графических ресурсов, игровых миров, формирующие опыт игрока игровые правила и другое. Как следствие, это получило определённую ценность за счёт того, что начали создаваться игры с минимальными изменениями, когда при наличии игрового двигателя компании создавали новую графику, оружие, персонажей, правила игры и тому подобное ^[2].

Разделение между игрой и игровым двигателем часто неопределённо. Некоторые двигатели имеют разумное и ясное разделение, в то же время другие практически невозможно отделить от игры. Например, в игре двигатель может «знать» о том, как рисовать дугу, в то же время другой двигатель может работать с другим уровнем абстракции, и в нём дуга будет частным случаем параметров вызываемых функций. Одним из признаков игрового двигателя является применение архитектуры управления данными. Это определяется тем, что если игра содержит жёстко фиксированные данные (англ.)русск., влияющие на логику, правила игры, рисование объектов и тому подобное, то становится сложно применять данное программное обеспечение в разных играх^[2].

Большинство игровых двигателей разработаны и настроены для того, чтобы запустить определённую игру на определённой платформе. И даже наиболее обобщённые многоплатформенные двигатели подходят для построения игр определённого жанра, например шутеров первого лица или гонок. В данном контексте можно более аккуратно сказать, что игровой двигатель становится не оптимальным при его применении не для той игры или той платформы, для которой разработан. Данный эффект проявляется от того, что программное обеспечение представляет собой набор компромиссов, основанных на тех предположениях, какой должна быть игра. Например, проектирование рендеринга внутри зданий приведёт к тому, что двигатель , скорее всего, не будет таким же хорошим для открытых пространств. В первом случае двигатель может использовать BSP-дерево для отрисовки объектов, близких к камере. В то же время для открытых пространств могут использоваться менее точные способы, а также более активно применяются технологии отрисовки с разной степенью детализации, когда более далёкие объекты прорисовываются менее чётко, так как занимают меньшее количество пикселей ^[3].

Как правило, игровые двигатели специализированы в рамках жанра компьютерных игр. Так, двигатель , спроектированный для двумерного файтинга на боксёрском ринге, будет существенно отличаться от двигателя для массовой многопользовательской игры, шутера от первого лица или стратегии в реальном времени. Но в то же время двигатели имеют существенные общие части — все трёхмерные игры, невзирая на жанр, требуют взаимодействия игрока посредством клавиатуры, геймпада и/или мыши, некоторую форму трёхмерного рендеринга, средства индикации, как на лобовом стекле (например, печать текста поверх графического изображения), звуковую систему и многое другое. Так, двигатель Unreal Engine, несмотря на то, что был спроектирован для шутера от первого лица, успешно использовался для создания игр во множестве других жанров, таких как шутер от третьего лица Gears of War, приключенческая ролевая игра Grimm (англ.)русск., или футуристичная гонка Speed Star^[4].

Исторически шутеры от первого лица относятся к играм, которые наиболее технологически сложны, так как им необходимо представлять игроку иллюзию трёхмерного мира, и делать это для активных действий в реальном времени. Двигатели шутеров от первого лица больше обращают внимание на такие технологии, как эффективный рендеринг трёхмерных миров, отзывчивая игровая механика контроля и прицеливания, высокая точность анимации оружия и рук управляемого игроком персонажа, широкий спектр ручного вооружения, «прощающая» модель движения игрока и его столкновения с препятствиями, высокое качество анимации и искусственного интеллекта неигровых персонажей. При этом характерны малая масштабируемость в многопользовательских играх (типична поддержка до 64 игроков) и повсеместная ориентация на игровой процесс deathmatch ^[5]. Графические двигатели игр данного жанра используют ряд оптимизаций в зависимости от текущего окружения игрока, но вместе с тем предъявляются требования по анимации персонажа, аудио и музыке, динамики твёрдого тела (англ.)русск., кинематике и другим технологиям^[6].

Двигатели платформеров обращают больше внимания на анимацию персонажа и его аватара, и при этом им не требуется той реалистичности, которая присуща трёхмерным шутерам. Для платформеров характерно применение ряда технологий: множество способов перемещения (движущиеся платформы, лестницы, верёвки, подпорки и другие), элементы из головоломок, использование следящей за персонажем камеры от третьего лица, рендеринг нескольких слоев геометрии в сочетании с системой столкновений объектов, и другие^[7].

Файтинги ориентированы на богатую анимацию, точность ударов, возможность задания сложных комбинаций последством кнопок и/или джойстика и тому подобное. Анимационные персонажи предъявляют требования двигателям по высокой детализации, дополнительно двигатели обеспечивают возможность изменения и добавления спецэффектов (шрамов после ударов, выступление пота и тому подобное), а также предоставляются возможности симуляции причёски, одежды и других элементов ^[8].

Автосимуляторы могут быть разными и здесь имеется ряд поджанров. Графика таких игр ориентирована на «коридорность» и кольцевые треки, и поэтому двигатели больше обращают внимание на детализацию машин, трека и непосредственное окружение. Как следствие, используются технологии для рендеринга далёких фоновых объектов (отображаемых двумерно), трек часто разделяется на несколько секторов, внутри которых проводится оптимизация по рендерингу. В случае движения по туннелям или другим «тесным» местам используются техники для того, чтобы камера с видом от третьего лица не пересекалась с фоновой геометрией. Используемые структуры данных и искусственный интеллект ориентируются на решение задач машин неигровых персонажей, таких как поиск пути и других технических проблем^[9].

У стратегий реального времени нет высоких требований к графике и поэтому двигатель ориентируется на то, что отображает юнитов в низком разрешении, но при этом он должен быть способен работать с большим числом юнитов одновременно. Отдельные особенности имеются у интерфейса взаимодействия игрока и элементов управления, в которые входят инструменты работы с группами юнитов (выделение по площади, управление) и ряд меню и панелей инструментов, содержащих команды управления, элементы снаряжения, выбор типов юнитов и зданий и тому подобное^[10].

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

На домашних компьютерах 1980-х из-за отсутствия стандартизации и ограничений памяти портирование было ручным и трудоёмким: переносилась только логика работы, а остальные части — вывод графики на экран, вызов прерываний и т. п. — писалось заново. Тем не менее, в те времена появились игровые двигатели Z-Machine и SCI от компаний Infocom и Sierra соответственно. В 1980-е компания Incentive Software начала разработку Freescape — переносимого 3D-ядра.

Сам же термин «игровой двигатель » появился в середине 1990-х годов — в это время окончательно установилось доминирование IBM-совместимых компьютеров, а быстрые процессоры и «хитрое» программирование дали 30 и более кадров в секунду в трёхмерных играх. Игры Doom и Quake от id Software оказались настолько популярными, что другие разработчики вместо того, чтобы работать с чистого листа, лицензировали основные части программного обеспечения и создавали свою собственную графику, персонажей, оружие и уровни — «игровой контент» или «игровые ресурсы». двигатель Quake был использован в более чем десяти проектах и дал серьёзный толчок развитию middleware-индустрии.

Более поздние игры, такие как Unreal 1998 года (двигатель Unreal Engine) и Quake III Arena (на двигателе id Tech 3) 1999 года, были спроектированы с применением данного подхода, с отдельно разработанными двигателем и наполнением. Практика лицензирования такой технологии оказалась полезным вспомогательным доходом для некоторых разработчиков игр. Так, стоимость одной лицензии на коммерческий игровой двигатель класса high-end может варьироваться от 10 тыс. до 3,75 млн $ (в случае Warcraft III)^{[источник не указан 3343 дня]}, а число лицензиатов может достигать несколько десятков компаний (как для Unreal Engine). По крайней мере, многократно используемые двигатели ускоряют и упрощают разработку игры, что является ценным преимуществом в конкурирующей индустрии компьютерных игр.

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

Шутеры от первого лица остаются преобладающими пользователями сторонних игровых двигателей, но сейчас такие двигатели также используются в других жанрах. Например, RPG Morrowind и MMORPG Dark Age of Camelot основаны на двигателеNetImmerse, в то время, как Oblivion и Fallout 3 используют новую версию данной технологии — Gamebryo. Известная MMORPG Lineage II построена на двигателе Unreal Engine 2 (несмотря на то, что данный двигатель изначально предназначался для использования в шутерах).

Игровые двигатели также используются в играх, первоначально разработанных для игровых консолей; например, двигатель RenderWare используется во франчайзах Grand Theft Auto и Burnout.

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

В дополнение к многократно используемым программным компонентам, игровые двигатели предоставляют набор визуальных инструментов для разработки. Эти инструменты обычно составляют интегрированную среду разработки для упрощённой, быстрой разработки игр на манер поточного производства. Эти игровые двигатели иногда называют «игровым подпрограммным обеспечением» (сокр. ППО; англ. middleware), так как, с точки зрения бизнеса, они предоставляют гибкую и многократно используемую программную платформу со всей необходимой функциональностью для разработки игрового приложения, сокращая затраты, сложность и время разработки — все критические факторы в сильноконкурирующей индустрии видеоигр.

Как и другие ППО решения, игровые двигатели обычно платформо-независимы и позволяют некоторой игре запускаться на различных платформах, включая игровые консоли и персональные компьютеры, с некоторыми внесёнными в исходный код изменениями (или вообще без них). Часто игровое ППО имеет компонентную архитектуру, позволяющую заменять или расширять некоторые системы двигателя более специализированными (и часто более дорогими) ППО компонентами, например, Havok — для физики, FMOD — для звука или SpeedTree — для рендеринга. Некоторые игровые двигатели, такие как RenderWare, проектируются как набор слабосвязанных ППО компонентов, которые могут выборочно комбинироваться для создания собственного двигателя , вместо более традиционного подхода расширения или настройки гибкого интегрируемого решения. Тем не менее расширяемость достигнута и остаётся высокоприоритетной в игровых двигателях из-за широких возможностей их применения. Несмотря на специфичность названия, игровые двигатели часто используются в других типах интерактивных приложений, требующих графику в реальном времени, таких как рекламные демо-ролики, архитектурные визуализации, обучающие симуляторы и среды моделирования.

Некоторые игровые двигатели предоставляют только возможности 3D-рендеринга в реальном времени вместо всей функциональности, необходимой играм. Эти двигатели доверяют разработчику игры реализацию остальной функциональности или её сбор на основе других игровых ППО компонентов. Такие типы двигателей обычно относят к «графическим двигателям», «двигателям рендеринга» или «3D-двигателям» вместо более содержательного термина «игровой двигатель ». Однако эта терминология используется противоречиво: так, многие полнофункциональные игровые 3D-двигатели упомянуты просто как «3D-двигатели». Некоторые примеры графических двигателей: RealmForge, Ogre 3D, Power Render, Crystal Space и Genesis3D. Современные игровые или графические двигатели обычно предоставляют граф сцены — объектно-ориентированное представление 3D-мира игры, которое часто упрощает игровой дизайн и может использоваться для более эффективного рендеринга огромных виртуальных миров.

Аппаратная абстракция[править | править код]

Чаще всего 3D-двигатели или системы рендеринга в игровых двигателях построены на графическом API, таком как Direct3D или OpenGL, который обеспечивает программную абстракцию GPU или видеокарты. Низкоуровневые библиотеки, например, DirectX, SDL и OpenAL, также используются в играх, так как обеспечивают аппаратно-независимый доступ к другому аппаратному обеспечению компьютера, такому как устройства ввода (мышь, клавиатура и джойстик), сетевые и звуковые карты. До появления аппаратно-ускоряемой 3D-графики использовались программные визуализаторы. Программный рендеринг всё ещё используется в некоторых инструментах моделирования для рендеринга изображений, для которых визуальная достоверность важнее производительности (количество кадров в секунду) или когда аппаратное обеспечение компьютера не удовлетворяет требованиям, например, не поддерживает шейдеры.

1. ↑ game engine | Definition of game engine in English by Oxford Dictionaries (неопр.). Oxford Dictionaries | English. — «The basic software of a computer game or video game». Дата обращения 11 декабря 2017.
2. ↑ ^{1 2 3} Jason, 2009, p. 11.
3. ↑ Jason, 2009, p. 12.
4. ↑ Jason, 2009, p. 13.
5. ↑ Jason, 2009, p. 13, 14.
6. ↑ Jason, 2009, p. 14.
7. ↑ Jason, 2009, p. 16, 17.
8. ↑ Jason, 2009, p. 17, 18.
9. ↑ Jason, 2009, p. 19-21.
10. ↑ Jason, 2009, p. 22, 23.
11. ↑ Jason, 2009, p. 23, 24.

• Jason, Gregory. Game Engine Architecture : [англ.]. — CRC Press, 2009. — 864 с.

Список игровых движков — Википедия

Краткая история развития игровых движков

О разработке игр и становлении игровой индустрии

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

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

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

Начало

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

Цели

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

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

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

В 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 модели и короткая игровая сессия сделали “простые” игры вполне успешным жанром.

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

VR

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

Итоги

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

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

Для разработки каждого типа есть определенный набор движков, потому что с технической стороны между всеми типами игр имеются большие различия. На рынке сейчас представлены десятки движков на любой вкус: кроссплатформенные и специализированные, требующие активной работы с исходным кодом движка и доступные без знаний программирования вообще, с разными производительностью, качеством документации и ценой. Подробнее о современных движках и о том, как выбрать правильный для своих целей, я рассказываю на дисциплине “Технические основы разработки игр” нашей программы “Менеджмент игровых интернет проектов” ВШБИ. Кстати, 11 февраля у нас будет однодневная конференция с бесплатным входом (надо только зарегистрироваться), где я в 12:00 буду читать одну из своих лекций про игровые движки, заходите.

Как написать собственный игровой движок на C++ / Habr

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

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

Your browser does not support HTML5 video.

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

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

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

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

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

1. Используйте итеративный подход
2. Дважды подумайте, прежде чем слишком обобщать
3. Осознайте, что сериализация — обширная тема.

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

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

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

По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал 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++ движке некоторые функции принадлежат классами, а некоторые — нет. Например, каждый противник в игре — это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, sphere casts в моём движке выполняются вызовом sphereCast(), функции в пространстве имён physics. sphereCast() не принадлежит какому-либо классу — это просто часть модуля physics. У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.

А ещё есть динамическая диспетчеризация, которая является формой полиморфизма. Часто нам нужно вызвать функцию объекта, не зная точного типа этого объекта. Первый порыв программиста на C++ — определить абстрактный базовый класс с виртуальными функциями, затем перегрузить эти функции в производном классе. Работает, но это лишь одна из техник. Существуют и другие методы динамической диспетчеризации, которые не привносят так много дополнительного кода, или имеют другие преимущества:

• С++11 ввел std::function, и это удобный способ хранить функции обратного вызова. Также можно написать собственную версию std::function, не вызывающую столько боли, когда заходишь в неё в отладчике.
• Многие функции обратного вызова могут быть реализованы с помощью пары указателей: указателя на функцию и непрозрачного аргумента. Требуется только явное приведение внутри функции обратного вызова. Это часто встречается в библиотеках на чистом C.
• Иногда базовый тип известен во время компиляции, и можно привязать вызов функции вообще без накладных расходов времени выполнения. Turf — библиотека, которой я пользуюсь в своём игровом движке, сильно полагается на этот способ. Взгляните на turf::Mutex для примера. Это просто typedef над платформо-специфичными классами.
• Иногда самый прямой путь — создать и поддерживать таблицу сырых указателей на функцию своими силами. Я использовал этот подход в своих аудио микшере и системе сериализации. Интерпретатор Python также на полную использует эту технику, как будет показано ниже.
• Вы можете даже хранить указатели на функцию в хэш-таблице, используя имена функций как ключи. Я пользуюсь этой техникой для диспетчеризации событий ввода, таких как события мультитача. Это часть стратегии по записи ввода игры и воспроизведения его в системе реплеев.

Динамическая диспетчеризация — обширная тема. Я лишь поверхностно рассказал о ней, чтобы показать как много способов реализации существует. Чем больше растяжимого низкоуровневого кода вы пишите — что не редкость для игрового движка — тем чаще обнаруживаете себя за изучением альтернатив. Если вы не привыкли к программированию в таком виде, интерпретатор Python, написанный на C — отличный пример для изучения. Он реализует мощную объектную модель: каждый PyObject указывает на PyTypeObject, а каждый PyTypeObjeсt содержит таблицу указателей на функцию для динамической диспетчеризации. Документ Defining New Types — хорошая начальная точка, если вы хотите сразу погрузиться в детали.

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

Сериализация — это преобразование объектов времени выполнения в последовательность байтов и обратно. Другими словами, сохранение и загрузка данных.

Для многих, если не большинства, движков игровой контент создаётся в разных редактируемых, таких как .png, .json, .blend или проприетарных форматах, затем в конце концов конвертируется в платформо-специфичные форматы игры, которые движок может быстро загрузить. Последнее приложение в этом процессе часто называют "cooker". Cooker может быть интегрирован в другой инструмент или даже распределяться между несколькими машинами. Обычно, cooker и некоторое количество инструментов разрабатываются и поддерживаются в тандеме с самим игровым движком.

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

В C++ есть бесчисленное множество способов организовать сериализацию. Один из довольно очевидных заключается в добавлении функций save и load классам, которые вы хотите сериализовать. Вы можете добиться обратной совместимости, храня номер версии в заголовке файла, затем передавая это число в каждую функцию load. Это работает, хотя код может стать громоздким.

 void load(InStream& in, u32 fileVersion) { // Загрузить ожидаемые переменные-члены in >> m_position; in >> m_direction; // Загрузить более новую переменную только если версия загружаемого файла больше 2. if (fileVersion >= 2) { in >> m_velocity; } }

Можно писать более гибкий, менее подверженный ошибкам код сериализации, пользуясь преимуществом рефлексии — а именно, созданием данных времени выполнения, описывающих расположение ваших C++ типов. Чтобы получить краткое представление о том, как рефлексия может помочь с сериализацией, взглянем на то, как это делает Blender, проект с открытым исходным кодом.

Когда вы собираете Blender из исходников, выполняется много шагов. Во-первых, компилируется и запускается собственная утилита makesdna. Эта утилита парсит набор заголовочных файлов C в дереве исходников Blender, а затем выводит краткую сводку со всеми определёнными типами в собственном формате, известном как SDNA. Эти SDNA-данные служат данными рефлексии. SDNA затем компонуется с самим Blender, и сохраняется с каждым .blend-файлом, который Blender записывает. С этого момента, каждый раз когда Blender загружает .blend-файл, он сравнивает SDNA .blend-файла cо SDNA, скомпонованной с текущей версией во время исполнения и использует общий код сериализации для обработки всех различий. Эта стратегия даёт Blender впечатляющий диапазон обратной и прямой совместимости. Вы всё ещё можете загрузить файлы версии 1.0 в последней версии Blender, а новые .blend-файлы могут быть загружены в старых версиях.

Как и Blender, многие игровые движки — и связанные с ними инструменты — создают и используют собственные данные рефлексии. Есть много способов делать это: вы можете разбирать собственный исходный код на C/C++, чтобы извлечь информацию о типах, как это делает Blender. Можете создать отдельный язык описания данных и написать инструмент для генерации описаний типов и данных рефлексии C++ из этого языка. Можете использовать макросы препроцессора и шаблоны C++ для генерации данных рефлексии во время выполнения. И как только у вас под рукой появятся данные рефлексии, открываются бесчисленные способы написать общий сериализатор поверх всего этого.

Несомненно, я упускаю множество деталей. В этой статье я хотел только показать, что есть много способов сериализовать данные, некоторые из которых очень сложны. Программисты просто не обсуждают сериализацию столько же, сколько другие системы движка, даже несмотря на то, что большинство других систем зависят от неё. Например, из 96 программистских докладов GDC 2017, я насчитал 31 доклад о графике, 11 об онлайне, 10 об инструментах, 3 о физике, 2 об аудио — и только один, касающийся непосредственно сериализации.

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

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

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

Что собой представляет «игровой движок», это как библиотека для написания игр?

DND allows you to play out even the most impossible fantasies, such as:
- Speaking multiple languages
- Traveling with friends
- Being Charismatic
- Sleeping 8 hours a day
- Waking up Early
- Having money

Ролевая игра - это такая игра, в процессе которой возникает сюжет.

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

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

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

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

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

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

Смешная картинка в тему:

Подумайте дважды, прежде чем использовать игровые движки / Habr

Давайте рассуждать разумно

Уровень навыков

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

Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.

Если вы опытный/профессиональный программист, способный уверенно освоить стороннее ПО, то можете воспользоваться этим навыком и решить, насколько минималистичным/максималистичным будет ваш подход (будет ли это исключительно минимальный SDL или же полностью оборудованный Unreal Engine).

Цели разработки

• Для вас это хобби и больше всего вы хотите вырасти как разработчик? Возможно, вам стоит держаться подальше от Unity и Unreal и смотреть в сторону разработки игр на основе более низкоуровневых библиотек.
• Для вас это бизнес? На таком уровне всё становится намного сложнее. Возможные варианты следует оценивать в зависимости от множества факторов: можете ли вы нанимать людей, знакомых с технологией? Хотят ли эти люди использовать технологию? Соответствует ли она вашим временным рамкам? Есть ли у вас навыки для её эффективного применения? Нравится ли технология вашим художникам/дизайнерам?

Интерес

Подумайте также над тем, как с технологией будут взаимодействовать художники и дизайнеры. Хотите ли вы создавать инструменты, чтобы догнать по функциональности Unreal? Они неизбежно будут сравнивать возможности движка и собственные. Я слышал, что даже у AAA-студий есть проблема с художниками, требующими наличия функций Unreal, которые пока не реализованы в текущем форке Unreal студии.

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

Что они дают вам на самом деле?

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

• Иногда использованные в нём решения слишком обобщённые: возможно, в вашей игре гравитация применяется совершенно новым образом, но тогда вам придётся сражаться с жёстко заданной системой гравитации Unreal. Возможно, вы создаёте проект со сложной сетевой моделью, и тогда вам придётся полностью избавиться от серверной архитектуры Unreal.
• Иногда решения слишком специализированы: если вы когда-нибудь копались во внутренностях Unreal Engine, то видели, что весь движок пронизан кодом шутера от первого лица. Если вы создаёте игру такого жанра, то отлично. Если же нет, то это будет только сбивать с толку.
• Иногда в движке слишком много всего: это создаёт нагрузку и на мозг, и на компьютер. Выполнение полной симуляции физики твёрдого тела, 3D-конвейера со скелетной анимацией и тремя фреймворка — это абсолютный перебор для 2D-игры. Придётся разбираться, как отключить все эти функции Unreal, удачи вам в этом. Лично я нахожу, что производительность Unreal разочаровывает даже в тестовых мирах с малым количеством объектов.

Что нужно для вашего проекта?

Существуют успешные игры, которым бы послужил плохую службу любой из доступных движков:

• Для Dreams был написан собственный рендерер, упрощающий и ускоряющий интуитивное создание 3D-ассетов.
• В No Man's Sky активно используются совершенно новые способы процедурной генерации. При реализации таких вещей в движке приходилось бы постоянно с ним бороться.
• В Minecraft можно было бы использовать только немногие из возможностей стандартных движков.

Будущее вашей (и нашей) индустрии

Замыкание влияет даже на хобби/соло-разработчиков. У меня есть друг, который постоянно борется с Unity (рушащие совместимость обновления, система прототипирования, навмеш, плохая поддержка 2D...). Он хочет уйти от Unity, но сильно замкнут на этот движок, потому что большая часть его кода (и данных) полагается на Unity API.

Почему движки покупают?

Чем ярче кажутся функции, тем больше руководство компаний (которое чаще всего не является технарями) стремится использовать движки. Такие возможности, как Blueprints движка Unreal, очень нравятся художникам и дизайнерам, но создают множество проблем программистам. (Это свойственно любым скриптовым языкам; если позволить не изучавшим программирование людям программировать, то результат будет плохим, аналогично тому, как плоха графика, рисуемая программистами).

Действительно ли новые функции упрощают завершение создания вашей игры? На самом ли деле они повышают ценность конечного продукта?

Боритесь с централизацией

Даже на уровне хобби отказ от исследований в пользу Unreal или Unity вредит будущим поколениям движков. Это может повредить даже самому Unreal: если все будут использовать Unreal, то Epic не сможет больше нанять никого для создания нового поколения движка, потому что никто не будет знать, как пишутся игровые движки!

Будущее может быть за открытыми исходниками

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

• Microsoft сделала в этом направлении огромные шаги. Если меняются даже они, то я уверен, что смогут и другие.
• В лицензионном соглашении Unreal содержится пункт, позволяющий опираться на его код при работе над собственным (проприетарным или свободным) движком. Я думаю, что это большой прогресс.
• Благодаря своей полной открытости и бесплатности большую популярность набирает Godot, и я надеюсь, что если ему дать достаточно времени и поддержки, то он станет конкурентом Unity (а со временем и Unreal).
• id Software (в эпоху Джона Кармака) выпускала полный исходный код с Doom и до Doom 3. У Кармака было множество причин продвигать такое решение. Самая убедительная из них для компаний заключается в том, что это не вредит продажам. Модель shareware, по которой распространялся Doom — разработчик отдаёт движок и продаёт данные — может быть эффективной стратегией и сегодня. Если ваш бизнес беспокоится о том, что конкуренты «украдут» вашу технологию, можете опубликовать свой код уже после того, как за ним выпущена более новая игра (так поступала id). После ухода Кармака id, похоже, потеряла интерес к публикации кода.

Качество ПО

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

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

Каковы альтернативы?

Новички часто думают, что для создания игры им нужен движок. С большой долей вероятности им стоит отбросить такую точку зрения. Начинающие будут впустую тратить время на реализацию бесполезных функций движка, вместо того, чтобы дать игре решить самой, что ей абсолютно необходимо. Только игра должна управлять тем, что нужно от движка (разумеется, в качестве контрпримера можно привести Unity, как образец подхода «движок в первую очередь»; в поддержку такой концепции у Unreal Engine 4 есть Paragon, Fortnite и Unreal Tournament, не говоря уже о десятках лет опыта выпуска бесконечного количества игр в предыдущих версиях движков).

Использование библиотек

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

• Графика: SDL, SFML, Ogre
• Физика: Bullet, PhysX (которая недавно стала open source — огромная победа!)
• Звук: SDL, SFML

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

Кроме того, и Unreal, и Unity поддерживают импорт динамически подключаемых библиотек. Это значит, что можно начать работать с библиотеками, а затем перейти на Unreal без необходимости переписывать весь базовый код геймплея, потому что он находится в библиотеке. Чтобы код оказался достаточно гибким для таких огромных изменений, требуется серьёзная продуманность, но я думаю, что для среднего или долговременного проекта оно того стоит.

В заключение

В конце концов, ваша основная задача — закончить проект. Вам следует приложить максимальные усилия к поиску кратчайшего пути к решению этой задачи. Он может оказаться для вас довольно неожиданным!

5 игровых движков для создания 2D и 3D игр

При многообразии существующих движков может возникнуть довольно непростой выбор, с чего, собственно начать делать игру и какие есть решения. Игровых движков существует довольно много и под разные задачи. Используются различные языки программирования, поддержка разных платформ и готовых решений. Как часто бывает, многое будет зависеть от личных навыков и предпочтений. Если вы собираетесь создавать простенький 2D-платформер или space-шутер, имеет смысл рассмотреть что-то легкое в освоении. При разработке масштабной мобильной стратегии одним лишь простым движком обойтись будет сложно.  Для многих решающую роль может сыграть ещё и тип лицензии – иногда их может быть несколько и опять же многое будет зависеть от поставленных задач и их актуальности. На программе “Менеджмент игровых проектов” в Высшей школе бизнес-информатики НИУ ВШЭ есть отдельная дисциплина, где в течение 6ти занятий по 4 академических часа креативный директор Maik.Ru  рассказывает технические основы разработки игровых продуктов, доносит до слушателей представление об основных современных средствах и принципах разработки, дает знания в области принятия управленческих решений по процессу разработки. Чаще всего слушатели выбирают в качестве движка для своей игры Unity, примеры игр, сделанных слушателями и выпускниками программы “Менеджмент игровых проектов”, можно посмотреть на странице “Проекты выпускников”.

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

Unity используется повсеместно и являясь мультиплатформенным подходит под широкий спектр задач, хотя графически несколько уступает Unreal. Позволяет работать над 2D и 3D играми, создавая проекты под Windows, OS X, Playstation 4, XBox, Windows Phone, Android, Apple iOS и Linux, в том числе и под Wii, PlayStation 3, PlayStation 4, Xbox 360, Xbox One, Nintendo Switch. Есть возможность создавать приложения для запуска в браузерах с помощью специального подключаемого модуля Unity (Unity Web Player), а также с помощью реализации технологии WebGL.

Приложения, созданные с помощью Unity, поддерживают DirectX и OpenGL. Движок используется как разработчиками ААА-игр, так и Indie-студиями. Есть собственный Asset store, сильное и активное коммьюнити и впечатляющее количество документации и видеоуроков.

В наличии движка простой легко настраиваемый Drag&Drop интерфейс, состоящий из различных окон и позволяющий производить отладку игры прямо в редакторе. Движок поддерживает скриптовые языки C# и JavaScript. Все расчёты физики производятся с помощью NVIDIA PhysX.

Лицензия Unity Personal является бесплатной, однако, если доход вашей компании составляет больше 100 000 $ в год или же если вам удалось привлечь на разработку более 100 000 $, вы не имеете права использовать Unity Personal. Можно будет воспользоваться версией Unity Plus для компаний, зарабатывающих до 200 000 $ в год, или Unity Pro — она не накладывает никаких ограничений по доходу.

Шоукейс проектов

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

UE Поддерживает большинство известных платформ: Microsoft Windows, Linux, Mac OS и Mac OS X; консолей Xbox, Xbox 360, Xbox One, PlayStation 2, PlayStation 3, PlayStation 4, PSP, PS Vita, Wii, Dreamcast, GameCube, Nintendo Switch и т.д., в iOS и Android.

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

Начиная с 02.03.2015 движок стал полностью бесплатным при условии, что прибыль от проектов, созданных на основе движка не превышает $3000 за квартал. После превышения нужно будет отчислять Epic Games 5% прибыли от продаж игры

Шоукейс проектов

С помощью Construct 2 можно эффективно и быстро создавать прототипы 2D игры без помощи кода. Поддержка таких платформ, как PC, Mac, Linux, Android, iOS, Windows Phone, Blackberry 10, Amazon Appstore, Chrome Web Store, Facebook и браузеры с поддержкой HTML5. 

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

Construct 2 доступен бесплатно с ограниченным функционалом. Стоимость персональной лицензии со всеми функциями составляет 6399 руб на Steam. Если выручка от выпущенного проекта превысит 5000$, придётся приобрести бизнес-лицензию для коммерческого использования. Бизнес-лицензия не имеет каких-либо отличий от персональной по функционалу, а лишь является дополнительным условием при достижении конкретной суммы с продаж.

Шоукейс проектов

Corona – кросс-платформенный движок, который поддерживает iOS, Android, Windows и Mac с языком программирования Lua с недавнего времени стал полностью бесплатным.

Изначально, движок был представлен в двух версиях. Версия Corona SDK являлась бесплатной, но ограниченной в функционале и без наличия возможности создания офлайновых билдов. Платная – Corona Enterprise, Без ограничений первой версии и доп. инструментарием на борту.

С 22 июня SDK и Enterprise распространяются в лице единого продукта – Corona без каких-либо комиссий с доходов проекта и ограничений по объёму получаемой прибыли.

Монетизация движка осуществляется посредством премиум-поддержки, снятия лого движка с загрузки, процентов с продаж Corona Marketplace и бесплатных плагинов рекламной монетизации.

Шоукейс проектов

Defold - кроссплатформенный движок от компании King. Поддерживает Html5(WebGl), Android 2.3 (API level 9)+, iOS 5.1+, Windows Vista+, OSX 10.7+
Linux и является полностью бесплатным без каких-либо ограничений с момента, как был заявлен в марте этого года на GDC 2016.

Движок предназначен по большей части для работы с 2D проектами, но также поддерживает импорт 3D-мешей. Скриптинг осуществляется посредством Lua. Defold является полностью бесплатным и не имеет каких-либо ограничений по планке достижения дохода проекта. 

Есть хороший FAQ от инди-разработчика Алексея Гулева.

Шоукейс проектов

Помимо вышеупомянутых движков, их существует еще превеликое множество: CryEngine 3, App Game Kit, AndEngine, Buildbox, Cocos2D, Game Maker Studio, MOMINIS, Rage Engine, IRM, Linderdaum Engine SDK, DX Studio, Project Anarchy, gameQuery, GameSalad, Godot Game Engine, Crystal Space 3D, Monkey и многие другие.

Отличия могут быть как незначительными, так и достаточно радикальными - порог вхождения, язык программирования, саппорт, тип лицензии, 2D/3D, возможности работы с графикой и другие особенности могут склонить сделать выбор в сторону нужного решения. Если уже сложилась четкая картинка и понимание того, что ожидать от разработки проекта и какой результат должен получиться на выходе - подогнать свои запросы под нужный движок не составит труда. Достаточно ознакомиться с возможностями уже зарекомендовавших себя на рынке, посмотреть шоукейс проектов и задать интересующие вопросы в сообществе или на форуме. В этом случае, решение вряд ли заставит себя долго ждать.

В рамках программы “Менеджмент игровых проектов” мы регулярно проводим различные мероприятия по игровой индустрии, и в частности по игровым движкам. Недавно проводили встречу Unity разработчиков. Записаться на наши мероприятия можно на странице анонсов.

Автор: Михаил Пименов

Игровой движок - это... Что такое Игровой движок?

Игрово́й движо́к — это центральный программный компонент компьютерных и видеоигр или других интерактивных приложений с графикой, обрабатываемой в реальном времени. Он обеспечивает основные технологии, упрощает разработку и часто даёт игре возможность запускаться на нескольких платформах, таких как игровые консоли и настольные операционные системы, например, GNU/Linux, Mac OS X и Microsoft Windows.

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

История

В первое время из-за невысокой скорости и отсутствия какой-либо стандартизации аппаратной части даже порты одной игры серьёзно переписывались — а из одной игры в другую вообще переносили минимум кода. Впрочем, в играх жанра квест существовали Infocom'овская Z-Machine и SCI компании Sierra — именно их можно считать первыми законченными игровыми движками.

Сам же термин «игровой движок» появился в середине 1990-х годов — в это время окончательно установилось доминирование IBM-совместимых компьютеров и появились первые трёхмерные игры. Игры Doom и Quake от id Software оказались настолько популярными, что другие разработчики вместо того, чтобы работать с чистого листа, лицензировали основные части программного обеспечения и создавали свою собственную графику, персонажей, оружие и уровни — «игровой контент» или «игровые ресурсы». Движок Quake был использован в более чем десяти проектах и дал серьёзный толчок развитию middleware-индустрии.

Более поздние игры, такие как Unreal 1998 года (движок Unreal Engine) и Quake III Arena (на движке id Tech 3) 1999 года, были спроектированы с применением данного подхода, с отдельно разработанными движком и наполнением. Практика лицензирования такой технологии оказалась полезным вспомогательным доходом для некоторых разработчиков игр. Так, стоимость одной лицензии на коммерческий игровой движок класса high-end может варьироваться от 10 тыс. до 3,75 млн $ (в случае Warcraft III)^{[источник не указан 646 дней]}, а число лицензиатов может достигать несколько десятков компаний (как для Unreal Engine). По крайней мере, многократно используемые движки ускоряют и упрощают разработку игры, что является ценным преимуществом в конкурирующей индустрии компьютерных игр.

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

Шутеры от первого лица остаются преобладающими пользователями сторонних игровых движков, но сейчас такие движки также используются в других жанрах. Например, RPG Morrowind и MMORPG Dark Age of Camelot основаны на движке NetImmerse, в то время, как Oblivion и Fallout 3 используют новую версию данной технологии — Gamebryo. Известная MMORPG Lineage II построена на движке Unreal Engine 2 (несмотря на то, что данный движок изначально предназначался для использования в шутерах).

Игровые движки также используются в играх, первоначально разработанных для игровых консолей; например, движок RenderWare используется во франчайзах Grand Theft Auto и Burnout.

Современные игровые движки — одни из самых сложных в написании приложений, зачастую состоящие из десятков различных компонентов, каждый из которых можно настраивать по отдельности под нужды игры. На сайте Future Game Coders есть различные темы о подсистемах современных игр.

Обзор

В дополнение к многократно используемым программным компонентам, игровые движки предоставляют набор визуальных инструментов для разработки. Эти инструменты обычно составляют интегрированную среду разработки для упрощённой, быстрой разработки игр на манер поточного производства. Эти игровые движки иногда называют «игровым подпрограммным обеспечением» (сокр. ППО; англ. middleware), так как, с точки зрения бизнеса, они предоставляют гибкую и многократно используемую программную платформу со всей необходимой функциональностью для разработки игрового приложения, сокращая затраты, сложность и время разработки — все критические факторы в сильноконкурирующей индустрии видеоигр.

Как и другие ППО решения, игровые движки обычно платформо-независимы и позволяют некоторой игре запускаться на различных платформах, включая игровые консоли и персональные компьютеры, с некоторыми внесёнными в исходный код изменениями (или вообще без них). Часто игровое ППО имеет компонентную архитектуру, позволяющую заменять или расширять некоторые системы движка более специализированными (и часто более дорогими) ППО компонентами, например, Havok — для физики, FMOD — для звука или SpeedTree — для рендеринга. Некоторые игровые движки, такие как RenderWare, проектируются как набор слабосвязанных ППО компонентов, которые могут выборочно комбинироваться для создания собственного движка, вместо более традиционного подхода расширения или настройки гибкого интегрируемого решения. Тем не менее расширяемость достигнута и остаётся высокоприоритетной в игровых движках из-за широких возможностей их применения. Несмотря на специфичность названия, игровые движки часто используются в других типах интерактивных приложений, требующих графику в реальном времени, таких как рекламные демо-ролики, архитектурные визуализации, обучающие симуляторы и среды моделирования.

Некоторые игровые движки предоставляют только возможности 3D рендеринга в реальном времени вместо всей функциональности, необходимой играм. Эти движки доверяют разработчику игры реализацию остальной функциональности или её сбор на основе других игровых ППО компонентов. Такие типы движков обычно относят к «графическим движкам», «движкам рендеринга» или «3D движкам» вместо более содержательного термина «игровой движок». Однако эта терминология используется противоречиво: так, многие полнофункциональные игровые 3D движки упомянуты просто как «3D движки». Некоторые примеры графических движков: RealmForge, Ogre 3D, Power Render, Crystal Space и Genesis3D. Современные игровые или графические движки обычно предоставляют граф сцены — объектно-ориентированное представление 3D мира игры, которое часто упрощает игровой дизайн и может использоваться для более эффективного рендеринга огромных виртуальных миров.

Аппаратная абстракция

Чаще всего 3D движки или системы рендеринга в игровых движках построены на графическом API, таком как Direct3D или OpenGL, который обеспечивает программную абстракцию GPU или видеокарты. Низкоуровневые библиотеки, например, DirectX, SDL и OpenAL, также используются в играх, так как обеспечивают аппаратно-независимый доступ к другому аппаратному обеспечению компьютера, такому как устройства ввода (мышь, клавиатура и джойстик), сетевые и звуковые карты. До появления аппаратно-ускоряемой 3D графики использовались программные визуализаторы. Программный рендеринг всё ещё используется в некоторых инструментах моделирования для рендеринга изображений, для которых визуальная достоверность важнее производительности (количество кадров в секунду) или когда аппаратное обеспечение компьютера не удовлетворяет требованиям, например, не поддерживает шейдеры.

См. также

Ссылки

Графический движок — Википедия

Материал из Википедии — свободной энциклопедии

Графический движок (англ. graphics engine; иногда «рендерер» или «визуализатор») — промежуточное программное обеспечение (англ. middleware), программный движок, основной задачей которого является визуализация (рендеринг) двухмерной или трёхмерной компьютерной графики. Может существовать как отдельный продукт или в составе игрового движка. Может использоваться для визуализации отдельных изображений или компьютерного видео. Графические движки, использующееся в программах по работе с компьютерной графикой (таких, как 3ds Max, Maya, Cinema 4D, Zbrush, Blender), обычно называются «рендерерами», «отрисовщиками» или «визуализаторами». Само название «графический движок» используется, как правило, в компьютерных играх.

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

Графические движки в компьютерных играх[править | править код]

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

К самым известным свободным графическим движкам относятся^{[источник не указан 874 дня]}:

• OGRE — объектно-ориентированный графический движок, написанный на C++. Движок является многофункциональным, так как с его помощью можно создавать игры разных жанров и другие приложения, не связанные с играми. Поддерживается рендеринг как через Direct3D9, так и через OpenGL. Движок имеет довольно массивное сообщество поддержки, обширную документацию и обучающие примеры на многих языках, включая русский.
• Irrlicht — графический движок, использующий возможности OpenGL и DirectX, написанный на C++.
• GLScene — OpenGL-ориентированный графический движок для Delphi.

Графические движки в специализированных программах[править | править код]

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

Графические движки с GPU-ускорением и трассировкой лучей[править | править код]

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

• OptiX — графический движок реального времени, разработанный nVidia, использующий CUDA, работающий исключительно на графических процессорах производства nVidia и предназначенный для разнообразных вычислений, исследований и моделирований. «OptiX» является гибридным движком — основным является использование трассировки лучей, но присутствует и растеризация.^[1]
• Octane Render — графический движок реального времени, разработанный компанией Refractive Software LTD, использующий CUDA и работающий на всех графических процессорах nVidia, начиная с 8Х00. Использует трассировку лучей.^[2]
• id Tech 6 — графический движок, входящий в состав игрового движка id Tech 6, будет использовать трассировку лучей и воксели.

Зачем писать свой игровой движок? / Social Quantum corporate blog / Habr

Unity в условиях многообразия игровых движков

Перед вами слайд с данными компании Unity Technologies по использованию различных игровых движков в 2017 году. В следующем году ситуация, как вы понимаете, поменяется. Нас интересует то, чему тут отведён 41%, то есть — движки собственной разработки. Если взглянуть на 5 самых больших компаний, представленных на конференции, то у каждой из них будет свой движок. Получается, что в большей части компаний, представляющих игровую индустрию, используются какие-то внутренние разработки. Далеко не всегда это — самое разумное в мире решение, но это так.

Из каких базовых технологий могут выбирать компании, задумывающиеся о разработке игрового проекта?

Армия семи наций

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

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

Назад, к основам

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

Мифический человеко-месяц

Долгая разработка движка? Но если разработка с собственным движком пойдёт быстрее, то это — не аргумент. О том, что такое «рационально», пожалуй, вообще никто не знает. Поэтому все эти возражения очень субъективны.

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

13 причин почему

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

• Lord of the Platform — властелин платформы. Существуют платформы, для которых нет готовых инструментов. Например, STB, set-top box (ресивер цифрового телевидения) — коробочка для кабельного телевидения, которая стоит на столе у каждого третьего американца.
  

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

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

• Weak but proud devices — малые, но гордые устройства. Если вы делаете игры для мобильных телефонов, собираете хоть какую-то статистику, то вы знаете, что с аппаратным обеспечением у устройств от Apple всё более-менее нормально, а вот с платформой Android — просто беда.
  

При этом в случае с iPhone можно делать хоть какие-то ставки на прогресс. Например, ожидается, что Unreal будет работать под iPhone 10, хотя пока всё это доведут до ума, будет уже какой-нибудь iPhone 12, 15 или 17. А вот в случае с миром вообще в краткосрочной перспективе на прогресс ставить тяжелее. Потому что апгрейд устройств происходит очень медленно.

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

• Own language for own ideas — собственные языки для собственных идей. Когда вы сами делаете движок — вы можете задействовать эту концепцию. Дело в том, что основная проблема нашей индустрии в том, что домен геймдизайнера — это филология. Он мыслит на обычном языке. Он ничего другого не умеет. А программист мыслит в домене программирования и между ними пропасть. Как результат, некая итерация, которую приходится непрерывно повторять, стоит, например, два доллара. И вы постоянно тратите эти деньги.
  

• Unique Mechanics = Unique engines — уникальные механики = уникальные движки. Мои знакомые писали Minecraft в пятнадцатом году с использованием Unity. Был ли смысл всё это делать — вопрос открытый. Но движок они выбрали и принялись за работу. Однако движок им, очевидно, очень мешал. Им было тяжело. У них были очень долгие итерации. После того, как мы их проконсультировали, они написали, буквально за три дня, собственный рендер. Причём весь остальной код, ответственный, скажем, за построение мира, естественно, никуда не делся. Просто всё это перестало быть в C#, перестало быть в Unity. И работа закипела. Не знаю, удалось ли им на этом заработать, но главный вывод из этой истории заключается в том, что им изначально не надо было использовать Unity.
  

• The game is not a render — the game is everything else — игра это не рендер, игра — это всё остальное. Мы об этом уже говорили. Если у вас проблема только в том, чтобы нарисовать что-то, или, скажем, использовать звук, делая многоплатформенную игру, то в рассмотренной ранее пирамиде можно было видеть подобные истории. Если вы говорите: «Я хочу проигрывать звук на трёх платформах», то вам для этого не нужна большая «U» — маленькой «c» будет вполне достаточно.
  

Преимущества разработки своего движка

• Buying is often better than mortgage — покупка часто предпочтительнее ипотеки. Игровая разработка — это, так или иначе, деньги. Есть способы монетизации, при использовании которых покупка не просто лучше, чем ипотека, а это просто единственно возможный вариант.
  

• Specificity is better than universality in the long term — на длинной дистанции специализированные инструменты всегда лучше универсальных. Очевидно, что универсальность всегда медленнее, она менее производительна и менее специфична, чем специализированные вещи. Движок, написанный под конкретную задачу, справится с ней лучше и быстрее, чем универсальное средство. На длинной дистанции специальные инструменты гораздо выгоднее, чем универсальные.
  
• Tools and pipelines are developed within — пайплайны и средства разработки, созданные внутри компании. Любой движок, придуманный людьми вне вашей компании, ориентируется на несколько вещей. Первая — это best practices. То есть ориентируется движок другой компании не на то, как ваш художник рисует, а на то, как рисуют художники, идеальные с их точки зрения. Вполне возможно, что ваши художники рисуют по-другому. У них свой пайплайн и у них это получается.
  

Когда вы работаете внутри своей компании, то вы можете реализовать тот самый пайплайн, который у вас уже существует и надеть на него сверху то, чем вы занимаетесь. На самом деле, это очень важно. Дело в том, что всё это имеет отношение ко времени разработки и, как следствие, к стоимости. Поэтому, когда вы разрабатываете у себя, вы можете утилизировать тот пайплайн, который уже есть. Иначе у вас документ, который называется «Правило выгрузки 3D-моделей и создания материалов для художников» будет больше, чем дизайн документ, а это неправильно.

• Reaction time — время реакции. Речь идёт о времени реакции производителя движка на ваши обращения, о возможности оснащения движка новым функционалом, и об оперативном исследовании новых технологий.
  

То же касается и предложения нового функционала, если у вас есть на это право. Исследование новых технологий так же упрощается при использовании собственных движков.
Предположим, ваш программист съездил на конференцию, послушал там лекцию о чём-то новом. Он тут же это попробовал, вы получили представление об этом новом и знаете, нужно оно вам или нет. Вы можете прямо-таки реактивно пробовать что-то интересное из мира науки. А это, кстати, значит, что в компании может быть человек, который будет называться «исследователь». При этом исследованиями можно заниматься и на том же Unreal, поскольку он поставляется в исходниках.

• Performance — производительность. Игровая индустрия — это всегда производительность. Первый подход достижения высокой производительности заключается в использовании специальных решений. Чем более специфичные решения — тем они производительнее. Второй подход — тоже, кстати, уважаемый, это оптимизация готовых движков. Как именно это будет выглядеть — сильно зависит от этих движков.
  

Риски, связанные с разработкой своего движка

• Development time — время разработки. Это понятие пересекается с тем, что мы говорили о времени выхода на рынок. Разработка движка может быть и очень долгой, и достаточно быстрой. Но время разработки движка, в любом случае, вносит вклад в общее время разработки проекта. Поэтому это тоже риск. Например, мне известны коллективы, у которых время разработки движка стремится к бесконечности.
  
• Terminal cases of vendor-lock — терминальные случаи привязки к поставщику. Это относится не только к большим компаниям, но и к маленьким. Скажем, вы наняли Васю, он написал движок, потом влюбился, от вас уволился, и в том, что он написал, не понимает никто. В результате у вас vendor-lock похлеще Google. Потому что в Google еще можно письмо написать, хотя они и не ответят, а здесь с уходом программиста всё закончилось. В результате — потерянное время на разработку и другие неприятные последствия. Надо уметь избегать этих рисков.
  
• Reinvent the wheel — изобретение колеса. Тут дело в том, что мы живём в мире, в котором вы всё равно изобретаете велосипеды. При разработке движка получается перенос велосипедного завода из кода игры в код движка, хотя там им и не место.
  
• Closed ecosystem — закрытая экосистема. Всё, что делается внутри компании, принадлежит этой компании. Я знаю кучу компаний, у которых есть что-то вроде своего скриптового языка. Это может быть какой-нибудь XScript, который работает только в рамках их решения.
  

Главный вопрос жизни, вселенной и всего такого

Программисты

С одной стороны, сейчас очень открытый мир. Я, например, знаю код Unreal 4 и CryEngine, он открыт. Все, кто хотят знать, могут узнать код Unity, есть огромное количество соответствующих материалов. Это значит, что этим способен заниматься тот, кто является программистом и читает по-английски. Там нет какого-то rocket science. Но с другой стороны, как выяснилось, программистов, которые читают по-английски, найти очень непросто. Поэтому вы должны знать, где они водятся, должны уметь их набирать, использовать, поощрять. Если вы это умеете, то можно уже и о своём движке задуматься. Если у вас таких людей нет, то у вас всё равно ничего не получится. Примеров тому — тьма. Дело не в том, что есть плохие и хорошие решения. Просто есть такие вещи, которые не могут работать изначально.

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

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

Техническая эпидемия

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

Во-вторых, есть подход, который мы, в принципе, и исповедуем. Как работает кефир? Он всё вокруг превращает в себя. Берёте молоко, кидаете туда кефир — и нет молока, всё превратилось в кефир. У нас это выглядит так: «Ребята, давайте возьмём 5 сильных программистов, это будет внутренний технологический центр». И я всем говорю, что если вы можете себе позволить сделать RnD-отдел, если вы — большая компания — то сделайте. Пускай они даже ничего, с точки зрения денег, полезного не делают. Если компания укрепилась на рынке и перед ней возникает вопрос о том, куда расширяться, то ответом на этот вопрос может стать создание RnD-отдела. Когда компания уже богата, для неё это не потеря денег, потому что она столько денег теряет уже на том КПД, на котором сейчас работает наша игровая индустрия, что расходов на исследования просто не заметит.

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

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

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

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

Два мира

В игровой индустрии соседствуют два мира. Люди либо ориентированы на решение технологических задач, либо на нарратив. А посередине — кустарщина какая-то. То есть, инструментария практически нет. Слова, слова, слова — бах — код. Опять слова — и опять код. Мы считаем, что требуются инструменты, которые позволяют подключать к тому, что получится в результате работы над игрой, геймдизайнера, менеджера, других сотрудников, не являющихся программистами.

На слайде можно видеть behavior tree, дерево поведения. В принципе, это штука, просто взятая из википедии, но перед нами её оттуда взял Unreal. Ничего страшного в этом нет. Итак, документация к этому лежит на сайте Unreal, нам было несложно сделать подходящий интерфейс, совместимый с тем, что делается в Unreal. То есть, можно взять любой пример с анриловского сайта экшнов, пример самого поведения, так как формат вполне совпадает, вот так вот переписать, и оно заработает. Это значит, что я облегчил себе жизнь, я не пишу документацию. И таких штук здесь много.

В примере со слайда что-то происходит, бегает краб, кого-то ловит, в общем-то, это неважно. Внутри программист решает задачи, которые выглядят как «пойди в…», «стрельни в…», «посчитай расстояние» — и всё. Всё остальное поведение написано в этом редакторе человеком, который не имеет абсолютно никакого отношения к программированию. И это работает, в отличие от перевода текста в код. При этом если говорить, скажем, о балансе. Что такое баланс? Это — 15 коэффициентов, которые можно менять. А здесь описано поведение, а не коэффициенты.

То есть, например, поведение «патрулирование» описано геймдизайнером, а не программистом. Это значит, что мы сделали тот шаг, которого большая часть людей не делает. Они просто пишут в дизайн-документе: «патрулирует». А программист это может перевести 50 разными способами. Что такое вообще патрулирование? А здесь геймдизайнер пишет именно то, что он имеет в виду. И это победа, друзья мои. Именно для этого вам нужны собственные инструменты. Для того чтобы сглаживать переход от вербального определения вашего визионера, который видит игру, так сказать, внутри головы, до программистов. А иначе они перестанут быть программистами, станут девелоперами и всю жизнь будут рассаживать травку.

Итоги

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

В результате, если вы имеете поводы писать свой движок, и у вас есть ресурсы — берите и пишите.

Вопрос

→ Ответ

Вопрос

Ответ

Вопрос

Ответ

Вопрос

Ответ

Вопрос

Ответ

Вопрос

Ответ

Вопрос

Ответ

Вопрос

Ответ

А почему мы используем Lua? Потому что это недооценённый язык, он отлично подходит для встраивания. Почему JavaScript? Потому что так получилось. Потому что на рынке кроме V8 и Webkit ничего нет. А это монстроиды. Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты. У нас это есть, и вот поэтому — JavaScript. В результате, например, можно брать тех, кто знает JS и писал сайты на React.

Вопрос

Ответ

Вопрос

Ответ

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

Что такое игровой движок? Не во всех словарях найдешь определение этого словосочетания. Но если мы сами попробуем на ...: jedaj | Паб

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

Насколько вы знаете, сейчас существует огромное количество игровых движков, начиная от всем известных брендов, таких как Quake и Unreal, которые разработчики и издатели могут приобрести по достаточно внушительной цене, заканчивая движками, которые разработчики создают специально для их внутренних проектов.
Чуть ниже мы познакомим вас со списком лучших игровых движков этого поколения. Это действительно самые лучшие представители, гордо сияющие в руках их создателей, они приносят вам тот самый запоминающейся игровой процесс. Вот пример того как хорошие творческие идеи приносят вам захватывающий геймплей.
Замечание: Стоит отметить, что не все разработчики говорят о своих игровых движках, многие держат их строжайшем секрете. Поэтому много хороших движков, о которых нам не известно не попали в данный список, хотя они этого и достойны. Примеры таких инкогнито использовались и используются для создания: Metal Gear Solid 4, FIFA и God of War III.

RAGE

***
Замечен в таких проектах как: Rockstar Table Tennis,
GTA IV + его дополнительный контент
Midnight Club: Los Angeles,
Red Dead Redemption,
L.A. Noire (предположительно)
***

GTA III, Vice City, San Andreas и Bully несмотря на свой блеск не были созданы на внутреннем движке Rockstar, вместо этого они использовали движок компании Criterion «Renderware». А вот, несмотря на то, что Red Dead Revolver вроде как и был менее коммерческой игрой, именно он натолкнул популярного издателя на идею создания своего движка для нового поколения приставок. С мечтами о великом сиквеле, который не могли бы осуществить никакие другие игровые движки, отделение Rockstar в Сан Диего начала работу над игровым движком RAGE (Rockstar Advanced Game Engine) в далеком 2004, для того чтобы впервые опробовать его в их будущей игре Red Dead Redemption. А согласно словам разработчиков, к трем играм, которые уже успели выйти на этом движке, в 2010 добавится ещё как минимум одна игра. И это именно тот самый желанный сиквел Red Dead Redemption.

RAGE обладает большим количеством плюсов. Среди них стоит отметить возможность создания обширных миров, комплексного ИИ, погодных эффектов, быстрого сетевого кода и большую разновидность геймлпей стилей, всё это нам как раз и доказал GTA IV. Так же данный движок довольно таки доброжелателен к симбиозу с другими игровыми движками. К примеру, с ныне популярным движком Euphoria от NaturalMotion, который подошёл RAGE так, будто бы он был с ним с рождения (такого симбиоза не достигли даже LucasArts в своей недавней игре Star Wars: The Force Unleashed). Так же отлично к RAGE вписался и физический движок Ервина Коуманса, отвечающий за игровую симуляцию пуль. И что более удивительно, этот движок ещё совсем юн и готов к дальнейшему своему развитию. Улучшенная физика, экосистема, улучшенный ИИ и дальность прорисовки это лишь некоторые из улучшении, которые, по словам разработчикам, принесет нам RAGE в своей следующей игре.

CryEngine

***
Замечен в таких проектах как: Far Cry,
Crysis, Crysis: Warhead, Crysis 2,
Aion: Tower of Eternity
***

Немецким разработчикам из CryTek не понадобилось много времени, чтобы создать себе громкое имя. Их первая же игра, вышедший в 2004 «Far Cry», стала для всех открытием. В то время как мир, как и следовало ожидать, ждал появления Half-life 2, Doom 3 и S.T.A.L.K.E.R., которые, по мнению многих должны были ознаменовать появления нового поколения ПК игр, CryTek опередил всех на шаг, выпустив свой топический шутер, созданный на внутренним движке студии «CryEngine». Три года спустя их новая игра Crysis разработанная на второй версии движка «CryEngine 2» снова добилась того же успеха, установив новую визуальную планку в игростроении. Следующим взятым пиком должен стать Crysis 2, разработанный уже на третьей версии движка «CryEngine 3». С помощью него Crytek попытается обхватить уже и консольный рынок.

Согласно словам CryTek CryEngine 3 будет первым движком на Xbox 360 и PlayStation 3, который позволит разработчикам работать с возможностями DirectX 10 на некст-ген консолях (пф! - прим. ред.). В отличие от большинства конкурентов, этому движку не нужны союзники среди других дополнительных игровых движков. Он может работать и с физикой игры, и с её звуком и анимацией. С помощью такого движка, игры смогут добиться высоких визуальных высот. Собственно, именно благодаря им, Crytek и стали столь популярны. И если собственных игр Crytek не достаточно для того, чтобы добавить CryEngine в данный список лучших движков, тогда стоит отметить тот факт, что его разработчики делают всё возможное чтобы раскрутить его в качестве Программного Обеспечения доступного для других разработчиков. Это хорошие новости для нас геймеров, и не совсем хорошие для Epic Games и их движка «Unreal Engine 3», у которого похоже появится весьма достойный конкурент.
P.S. И ещё давайте надеяться на то, что слухи о TimeSplitters 4 на CryEngine 3 окажутся правдой.

Naughty Dog Game Engine

***
Замечен в таких проектах как: Uncharted: Drake's Fortune,
Uncharted 2: Among Thieves
***

Несомненно Uncharted 2: Among Thieves был одним из графических чудес последнего E3, а главное он доказал что PlayStation 3 обладает огромным потенциалом если правильно относится к созданию игрового движка. Движок Naughty Dog - названый в честь студии создателей не только Uncharted, но и такой популярной серии как Jak & Daxter - был создан специально под архитектуру PS3. С его помощью разработчики добились огромных высот ещё в 2007 году, с выходом Uncharted: Drake's Fortune. Великолепная анимация и модели персонажей, объемное освещение, шикарный звук, богатая палитра цветов и Голливудо-подобные кат-сцены стали его визитной карточкой. Более двух лет упорной работы было потрачено для создания движка Naughty Dog 2.0, который уже используется в разработке Uncharted 2: Among Thieves. Результат данной работы ошеломляющий. Все локации игры заполнились большим количеством динамических объектов, которые обладают своей собственной физикой. Анимация окружения стала более сглаженной и разнообразной. Поразительные улучшения коснулись света и ИИ игры. Без шовные переходы от игры к кат-сценам и наоборот. И не забудем, что в новой части Uncharted нас ждёт кооперативная игра и мультиплеер. Просто замечательные результаты.

Так же по нашим данным Naughty Dog делятся своим знанием и опытом с секретной студией Sony The Ice Team которая занимается разработкой основного комплекта инструментов, которые помогут в будущем улучшить все проекты для PS3. И ещё не стоит забывать, что на прошедшей E3 разработчики намекнули на то, что в следующем году может появиться и новая часть их популярной серии Jak & Daxter.

The Dead Engine

***
Замечен в таких проектах как: Dead Space,
Dante's Inferno
***

Dead Space была проста замечательна: настолько замечательна, что сразу же после её выхода никому не известная студия EA Redwood Shores сделала себе имя. В мае, Electronic Arts переименовало студию в Visceral Games (дословно - "Интуитивные Игры") дабы сильнее выразить культуру и личность данной студии, которая фокусируется на создании интеллектуальных экшенов (а такие бывают! - прим. ред.). Хотя Dead Engine это и не официальное название движка Visceral Games (так его прозвала пресса и фанаты Dead Space), о его существовании и технических возможностях сообщил Глен Шофилд, во время одной из промо акций Dead Space на территории Австралии.

После релиза The Godfather в 2006 году, команда разработчиков распалась, часть из них, забрав собой движок, и стала той самой студией EA Redwood Shores, выпустившей Dead Space. Движок был почти полностью переделан для того чтобы удовлетворить хоррор-футуристические запросы Dead Space. В конечном счете, успех движка больше обязан Dead Space, нежели The Godfather. Dead Space удивляла нас почти каждой новой локацией, однако главными преимуществами движка являются его легкость в работе, а так же работа со звуком и освещением игры. Dead Space с лёгкостью можно назвать одной из самых страшных игр в истории видеоигр. А следующей точкой в развитии движка уже должна стать новая игра Visceral Games Dante's Inferno.

Unreal Engine

***
Замечен в таких проектах как: Gears of War,
Mass Effect,
BioShock,
Unreal Tournament 3,
Borderlands,
Brothers in Arms: Hell's Highway,
Homefront,
Mirror's Edge,
Singularity,
Rainbow Six: Vegas
***

Как много раз мы слышали эти слова «сильно модифицированный Unreal Engine» в разных обзорах видео игр или же в игровых пресс релизах? С момента своего первого появления в 1998 году, разработанный Epic Games Unreal Engine (сейчас уже в своей третьей ипостаси) стал ничем иным, как главным оружием большинства известных и не очень разработчиков видеоигр. Он появлялся и в таких детских проектах как Surf's Up и даже в играх студий, которые имеют помимо него и свои собственные движки. Главный вопрос - почему?

Несмотря на некоторые отрицательные отзывы (Silicon Knights, создатели Too Human) и проблемы связанные с работоспособностью в ранних проектах для PS3 (в основном проблема проседания кадров в секунду), движок от Epic Games предоставлял своим потребителем высокое качество и возможность разработки игры в абсолютно любом жанре. А его скромная цена отговорила многих от дорогостоящего создания своих собственных движков. Самый популярный игровой движок Unreal Engine, именно он сформировал у нас ту самую картинку, как должна выглядеть некст-ген игра.
Согласно последним сообщения «Epic Games» уже вовсю трудится над Unreal Engine 4 и по плану этот движок должен появиться как раз к выходу следующего поколения приставок, среди возможных дат релиза был объявлен 2012 год.

Avalanche Engine

***
Замечен в таких проектах как: Just Cause, Just Cause 2,
The Hunter
***

Just Cause 2 был одной из тех игр, которая нас сильно удивила на прошлой Е3. Хотя первая часть и была достаточно интересной, прошло уже почти 4 года с момента её выхода и об игре мы начали понемногу забывать. Такой промежуток затишья немного убил наш интерес ко второй части, и мы её уже и не ждали. Однако создатели игры - Avalanche Studios, оказывается, потратили всё это время недаром. Они полностью изменили движок Avalanche Engine и пересоздали множество его элементов с чистого листа. Так что, используя новый движок Avalanche Engine 2.0 разработчики создали Just Cause 2, который может с легкостью переплюнуть успех первой части игры.

Глядя на Just Cause 2, сложно не удивится тому, что получилось достичь разработчиков с их новым движком. Движок выдает весьма разнообразную игровую механику (прыжки на парашюте, вождение, стрельба и рукопашный бой от третьего лица, дайвинг и многое другое). На экране постоянно мелькает большое количество взрывов и врагов. У главного героя появились новые возможности, главная возможность это крюк. ИИ враги тоже претерпел ряд изменении и теперь кажется в разы лучше того, что мы видели в первой части. Да и к тому же картинка игры весьма впечатляющая. Всё это действие разворачивается на обширном пространстве, здесь нас ждут и снежные вершины гор, тропические джунгли и песчаные берега. Все эти преимущества и выделяют Avalanche Engine, как один из лучших игровых движков этого поколения.
P.S. К тому же, следующим уже объявленным проектом построенном на Avalanche 2.0 будет игра под названием AionGuard, которая построена в фэнтази-сеттинге; интересно как справится с такой задачей данный движок.

IW Engine

***
Замечен в таких проектах как: Call of Duty 2,
Call of Duty: Modern Warfare,
Call of Duty: World at War,
Quantum of Solace,
Modern Warfare 2
***

Поясняем: IW расшифровывается как Infinity Ward, легендарная студия, создавшая одну из самых популярных игровых серии данного поколения - Call of Duty. И хотя в первой части своей игровой серии Infinity Ward использовали движок id Tech 3, уже к выходу второй части они подготовили свой собственный, внутренний движок, который к сожалению до сих пор так и не получил официального наименования. После одного из вопросов по поводу движка, заданного нами на прошлой Е3, Infinity Ward сообщили нам, что грядущий хит Modern Warfare 2 был создан на четвертой версий движка, то есть IW 4.0. Та же самая версия движка использовалась для создания шедеврального Call of Duty 4, вышедшего в 2007.
Если вы играли в игру, тогда вам, наверное, известны возможности этого движка и то, какой игровой опыт он может предоставить его игрокам. Феноменальная анимация и освещение, сложный ИИ, замечательный звук, симуляция реального поведения пули - всё это движок способен обрабатывать очень быстро - и это никто не отрицает. К тому же, всю эту красоту можно увидеть и играя по сети с друзьями, не зря Call of Duty считается одной из самых удачных онлайн игр за всю историю существования видеоигр. Конечно, для второй части Modern Warfare 2 движок не претерпел больших изменений, однако, они достаточно весомые, чтобы снова нас удивить. Новая система текстурирования позволит увеличить детализацию мира и поднять текстурам разрешение. А главные изменения коснутся освещения, физики и ИИ игры.

P.S. Ещё одной хорошей новостью похоже является то, что Infinity Ward разрешают использовать свой движок и остальным студиям, которые находятся под управлением Activision, к примеру Treyarch.

Anvil Engine

***
Замечен в таких проектах как: Assassin's Creed,
Prince of Persia (2008),
Shaun White Snowboarding,
Assassin's Creed II
***

Наверное, Ubisoft надоело использовать для создания игр чужие технологии, поэтому последнее время их студии начали изрядно клепать одни за другими свои собственные игровые движки. Сейчас этих движков набралось с десятка, среди них стоит отметить следующие: Dunia (Far Cry 2), LEAD (Splinter Cell: Conviction), Fox (Naruto: Broken Bond), LyN (Beyond Good & Evil 2), IRISZOOM (R.U.S.E) и собственно наш герой Anvil, aka Scimitar 2.0 Engine. На самом деле сложно пройти мимо игры построенной на этом движке и не удивится картинке, которую она выдает. К тому же, не забудем, что именно этому движку и обязан своей популярностью нашумевший хит Assassin's Creed.
И в Assassin's Creed, и в Prince of Persia, Anvil позволил анимации взаимодействовать с окружающей средой в реальном времени. Он же позволяет заселить виртуальные миры сотнями моделями, при этом наделяя их своим собственным достаточно умным ИИ. Для сиквела Assassin's Creed разработчики из Ubisoft Montreal приготовят улучшенную систему освещения, отражений, динамическую одежду, продвинутый ИИ, увеличат возможность взаимодействия с окружающим миром, дальность прорисовки, а так же прикрутят игре полный цикл смены дня и ночи. Стоит так же отметить, что ко всему перечисленному, Anvil добавил себе одну из технологий движка Dunia, на котором был построен Far Cry 2. Это технология отвечает за симуляцию растительности игры.

Так же отметим тот факт, что в Shaun White Snowboarding Anvil впервые предложил игрокам сетевую игру, что подогрело слухи о том, что сетевой режим появится и во второй части Assassin's Creed.

EGO Engine

***
Замечен в таких проектах как: Colin McRae: DiRT,
Race Driver: GRiD,
Operation Flashpoint: Dragon Rising,
Colin McRae DiRT 2,
F1 2009,
F1 2010
***

Codemasters уже издало пару весьма посредственных игр на этом поколении приставок, но когда речь заходит о внутренних проектах студии, она пытается принести нам только лучшее. Больше количество этого лучшего построено именно на движке EGO Engine (некогда известного под названием NEON). Кстати, стоит отметить, что в создании этого движка отчасти поучаствовали и люди из Sony. Для многих геймеров Codemasters известны своими игровыми сериями Colin McRae & Race Driver, весьма популярными и качественными гоночными симуляторами.
Среди плюсов движка не только возможность создания хорошего гоночного геймплея игры, с помощью него можно создать и модели и физику для этих самых машин. Так же он может создавать высоко детализированные миры разного покрова (и пустыне и снежные покровы), которые выглядит просто потрясно, особенно через лобовое окно вашего автомобиля на скорости 200 км/час. К тому же разработчики создали вразумительную систему повреждении, блестящий ИИ и освещение. Все эти преимущества превращают игру, созданную на EGO, в конфетку. Ну, а главной причиной, по которой EGO попал в наш список лучших движков, так это его удивительная возможность меняться из гоночного движка, в отличный движок, к примеру, для FPS. Это он доказал нам, став базой для суперреалистичного Operation Flashpoint: Dragon Rising, который появится на прилавках магазина уже в этом сентябре.

Ну, а в DiRT 2 разработчики решили сфокусироваться на физике игры, дабы привнести в игру ещё больший реализм. И если так и дальше пойдет, то у разработчиков F1 2010, у которых в кармане ещё целый год разработки, должно получиться что-то очень серьезное и привлекательное.

Geo-Mod Engine

***
Замечен в таких проектах как: Red Faction: Guerrilla
***

Когда Digital Illusions выпустили свои игровой движок «Frostbite Engine», который показал нам невиданную до сих пор систему динамического разрушения в игре Battlefield: Bad Company, мы были действительно впечатлены тем, как изменяется поле сражения во время битвы. Следующий шаг, в этом направлении, предприняли разработчики из LucasArts, выпустив Star Wars: The Force Unleashed, которая обладала собственным физическим движком Digital Molecular Matter. Он позволял окружающему миру изменяться под давлением внешних сил. Показанное удивило не одного геймера нашей планеты. Но Volition Inc пошли ещё дальше в Red Faction: Guerrilla. Использовав новую версию своего движка Geo-Mod, который появился ещё в 2001 во время создания первой части Red Faction.
Третья часть уже целой игровой серии позволила нам не просто бессмысленно разрушать всё в округе. Geo-Mod позволяет объектам принимать свойства их реальных прототипов, они разрушаются согласно реальным законом нашего мира, это прививает реализм не только действиям игрока, но и объектам, которые его окружают. Симулировать взрывной геймплей игры, её сложный ИИ и имитировать законы реального мира, при этом без потерь в фреймрейте, сможет не любой движок. Плюс ко всему это всё работой отличное и в сетевой игре. И пусть данный движок не обладает многими преимуществами выше перечисленных конкурентов, его способность имитировать реальные законы, создавать удивительные взрывы в реальном времени выделяют его среди остальных.

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

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

Смотрите также

• 
  Где находится город паттайя
• 
  Где находится домик лермонтова
• 
  Где находится датчик холостого хода на газели двигатель 405 евро 3
• 
  Где находится ростелеком в сергиев посаде
• 
  Где находится аксаково в башкирии
• 
  Ватикан где находится в какой стране
• 
  Где сейчас находится владислав челах
• 
  Где находится духовная семинария в москве
• 
  Кургазак где находится фото
• 
  Станция метро верхние котлы где находится
• 
  Где на карте африки находится кения