Лучшие игровые движки


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

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

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


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

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


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

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

Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: 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 можно было бы использовать только немногие из возможностей стандартных движков.

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


При использовании любой технологии стоит задуматься о замыкании. У Джоэла Сполски есть серия статей о бизнес-стратегии разработки ПО, в которой он размышляет о замыкании на продукте. Если вкратце, то его мысль заключается в том, что компании заинтересованы удерживать вас, чтобы вы использовали их продукт, потому что если вы не используете продукт, то они не зарабатывают денег. Мастерами в захвате целых отраслей стали Apple, Microsoft, Adobe и Autodesk, они создают ощущение, что кроме их ПО нет никаких других альтернатив.

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

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


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

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

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

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


Каждый раз, когда одна из студий переходит с собственного движка на Unreal или Unity, компании Epic и Unity набирают в игровой индустрии ещё бОльшую мощь. Поначалу такая централизация может казаться выгодной (у них ведь над движком работают 500 инженеров, отлично!), но через пару десятилетий это станет реальной проблемой. На ум приходит Google: эта компания захватила обширную часть функций, которые люди используют в Интернете, и это стоило им потери большой доли приватности.

Даже на уровне хобби отказ от исследований в пользу 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 без необходимости переписывать весь базовый код геймплея, потому что он находится в библиотеке. Чтобы код оказался достаточно гибким для таких огромных изменений, требуется серьёзная продуманность, но я думаю, что для среднего или долговременного проекта оно того стоит.

В заключение


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

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

habr.com

Выбираем мультиплатформенный движок для разработки мобильных игр (часть 1) / Habr

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

Мультиплатформенные движки спешат на помощь

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

Сайт: www.madewithmarmalade.com
Документация: www.madewithmarmalade.com/devnet/docs
Поддерживаемые платформы: ios(3.0+), Android(1.5+), Symbian, bada, webOS. Также должна появиться поддержка BlackBerry Tablet OS. Кроме того Marmalade поддерживает еще ряд платформ в bеta стадии.
Язык программирования: C/C++
Минимальная цена: $149/год.
Демо-версия: доступна 90 дневная тестовая копия для некоммерческого использования.

По виду очень серьезная штука, для серьезных игр. Я приметил Pro Evolution Soccer (PES) 2011 и Need for Speed Shift. Согласитесь, весьма серьезные продукты от именитых компаний, которые унылую подделку для своих творений не выбрали бы. Однако Marmalade скорее является не движком, а Фреймворком для создания своих движков (пример ниже). Кроме того он вам позволяет использовать различные имеющиеся у вас (или в открытом доступе) C/C++ библиотеки.

В общем, серьезный продукт для серьезных дядек. Один C/C++ не каждый осилит. Хотя для многих это будет огромным плюсом.

P.S. В заголовке сказано, что Marmalade был недавно переименован, а так же подорожал в цене, и теперь его приемлемая версия стоит $499.

Corona

Сайт: www.anscamobile.com
Документация: www.anscamobile.com/resources (в API достаточно много возможностей).
Поддерживаемые платформы: iOS, Android.
Язык программирования: Lua
Минимальная цена: $199/год за одну платформу. Или $349 за обе.
Демо-версия: доступна неограниченная по времени тестовая копия для некоммерческого использования.

Corona — это 2d движок для создания игр в духе Angry Birds. В качестве примера можно привести Bubble Ball, которую написал 14 летний парень из Америки.

У Corona достаточно обширное API на все случаи жизни, что позволит вам с легкостью реализовать все ваши хотелки. Однако, все в api предусмотреть не возможно и вполне вероятно, что рано или поздно вам захочется воспользоваться, какой-то нативной возможностью Android или IOS. Тут вас будет поджидать разочарование — Corona не имеет таких возможностей. Зато для Flash разработчиков есть приятная новость. Создатели движка утверждают, что тем, кто пишет игры на Flash, не составит труда перейти на Corona, т.к. они очень похожи.

Unity3d

Сайт: unity3d.com
Документация: unity3d.com/support/documentation
Поддерживаемые платформы: iOS, Аndroid, десктоп, Web, игровые приставки.
Язык программирования: C#, JavaScript, Boo
Минимальная цена: $400/год за одну платформу в стандартном издание.
Демо-версия: в течение 30 дней вы можете использовать полную PRO версию.

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

У движка есть много встроенных возможностей, а также ряд интересных сторонних плагинов которые добавляют недостающий функционал. Кроме того, вы можете пользоваться библиотеками? написанными на нативном для платформы языке (скажем Java для android), что весьма немаловажно для серьезных проектов. Также в арсенале Unity3d имеется визуальный редактор с огромным количеством всяческих настроек.

P.S. Для обеспечения мультиплатформенности используется MonoTouch.

ShiVa3D

Сайт: www.stonetrip.com
Документация: www.stonetrip.com/developer/doc
Поддерживаемые платформы: iOS, Android, Windows, Mac OS, Linux, Palm, Wii, Web.
Язык программирования: Lua
Минимальная цена: €169.00/год в стандартном издание.
Демо-версия: можно использовать сколько влезет, но когда захотите выложить свое творение в store? то придется купить.

ShiVa3D — это движок со встроенным визуальным редактором (как в Unity3d). Для реализации мультиплатформенности движок использует Marmalade (смотрим выше). У движка много встроенных возможностей, есть сторонние плагины и возможность использования библиотек написанных на нативном для платформы языке (скажем Java для android).

И еще немного

Flash

Недавно появилась свежая версия AIR, в которой есть возможность разработки под IOS, Android и BlackBerry PlayBook. Новая версия принесла больше стабильности и производительности. Хотя в качестве демонстраций я видел только обычные приложения (НЕ игры). Также пока отсутствует возможность использования нативных библиотек. А сам API тоже весьма не богат.

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

Kobold2D (должен появиться летом 2011)

Сайт: www.kobold2d.org
Стоимость: бесплатный (MIT License).
Поддерживаемые платформы: iOS.
Язык программирования: Lua

Обертка над Cocos2D, которая должна облегчить разработку игр для тех, кто не знает Objective-C.

Заключение

Возможно, я где-то ошибся и что-то не доглядел. Если это так, то правки принимаются. Удачного вам игростроения!

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

habr.com

Лучшие движки для создания собственных 2D инди-игр

Хотите попробовать создать свою 2D игру? Перед вами лучшие инструменты для работы, даже если вы новичок в этом деле.

Создавать игры сложно. Чем больше вы знаете об этом процессе, тем сильнее вы будете удивляться тому, что кто-то действительно доводит его до конца. Как говорил один из бывших авторов PC GamerТом Фрэнсис, описывая процесс программирования игры Gunpoint: «За время работы над игрой я пришёл к одному выводу: Моя игра – это настоящее безумие. Это пациент психлечебницы. Она полностью сошла с ума, и нужно быть готовым к тому, что все разумные доводы будут встречены невменяемым кричащим бредом».

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

GameMaker Studio 2

Стоимость лицензии: 100 долларов для ПК-версии; доступен бесплатный пробный период

Подойдёт для: коротких 2D-платформеров и RPG; кроссплатформенных игр

Примеры игр: Nidhogg, Hyper Light Drifter, Undertale, Risk of Rain

GameMaker Studio 2 – это ваша первая остановка на пути в мир геймдизайна. Данная платформа включает в себя удобные в использовании инструменты, интерфейс формата drag-and-drop и возможность писать на отдельном языке программирования под названием GML. Мы поговорили с разработчиками, создавшими на движке GameMaker ряд популярных игр, и попросили поделиться опытом работы.

Плюсы

Марк Эссен, автор игр Nidhogg и Nidhogg 2, говорит, что GameMaker отлично подходит для новичков, так как система создания скриптов в нём максимально проста и понятна, к тому же на портале Yoyo Games можно найти собрание руководств и гайдов по данной теме. В интернете также немало дополнений для движка, позволяющих кастомизировать его для создания платформера или RPG с видом сверху.

Алекс Престон, создавший Hyper Light Drifter, говорит, что коммьюнити движка GameMaker оказывает неоценимую помощь новичкам. Он отмечает, что начинающим разработчикам следует «…наладить связь с сообществом разработчиков и изучить все инструменты движка, чтобы добиться того, чего нужно – а для этого стоит обращаться за советами к бывалым разработчикам».

Минусы

Разумеется, у вас вряд ли получится сразу же создать игру, которую можно опубликовать в Steam. «Из-за того, что GameMaker проста в использовании, проекты очень часто получаются несбалансированными», говорит Эссен. «Мне нравится, что на начальных стадиях разработки можно быстро обрисовать скелет своей игры и сосредоточиться на её дизайне, однако в дальнейшем это может выйти боком, особенно если вы не придерживаетесь организационных стандартов!»

Дункан Драммонд, автор всеми любимой Risk of Rain, тоже подчёркивает, что простота использования GameMaker может стать ночным кошмаром разработчика. «На движке можно быстро создать игру, но если проглядеть на ранних этапах своих ошибки, то позднее это выльется в увеличении затрат на игру», говорит он. Драммонд отмечает, что специфика работы с GameMaker сильно отличается от работы с другими движками, поэтому если в дальнейшем вы планируете перейти на Unity или любой другой движок, то вам, скорее всего, лучше поискать иной вариант.

Советы для новичков

«Не забывайте удалять свои старые работы! Чем чаще вы начинаете игру с нуля, тем опытнее по части геймдизайна вы становитесь», — Марк Эссен, Nidhogg

«Просто начните! Запустите движок, почитайте руководства и приступайте к работе, даже если у вас толком не получается. Чем больше ошибок совершите, тем больше уроков вы вынесете», — Алекс Престон, Hyper Light Drifter

«Не бойтесь начать! Это интересный и относительно простой способ разработки, и тратит он разве что ваше время», — Дункан Драммонд, Risk of Rain

Unity

Стоимость лицензии: Бесплатный стартовый пакет, 35 долларов в месяц за пакет Unity Plus, 125 долларов в месяц за пакет Unity Pro

Подойдёт для: практически любой инди-игры

Примеры игр: Ori and the Blind Forest, Galak-Z, West of Loathing, Cuphead

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

На официальном сайте Unity можно найти и специальные дополнения, позволяющие кастомизировать движок для разработки 2D-игр. К примеру, бесплатное расширение 2D Platformer или инструменты вроде Corgi Engine и Rex Engine, предлагающие игровую физику, управление и особенности, заточенные специально под платформеры.

Мы поговорили с Джозефом Хамфри из inkle и Виктором Томпсоном из Asymmetric Publications, которые рассказали о своём опыте работы с Unity.

Плюсы

Томпсон, ранее создававший игры классическим способом, быстро стал поклонником Unity – движка, на котором была создана недавно вышедшая игра его компании под названием West of Loathing. «После 2-3 лет работы с движком больше всего меня радует то, насколько быстро можно совмещать концепты и прототипы», говорит он. «Я использовал множество различных движков – как небольшие для своих собственных проектов, так и крупные для разработки AAA-игр, однако Unity – это пока что лучший из всех движков, что я видел, так как он позволяет мне быть наиболее продуктивным».

Минусы

Впрочем, если вы собираетесь использовать одну платформу для всех своих разработок, вы столкнётесь с определёнными ограничениями. Если вы найдёте баг в Unity, вам придётся ждать, пока авторы движка его исправят, и это не всегда быстро. «Несмотря на то, что представители движка заявляют, что исправление багов является их важнейшим приоритетом, разработчики компании inkle по-прежнему считают стабильность дебаггинга одной из главных проблем движка», говорит Хамфри.

Советы для новичков

«Прежде всего, постарайтесь создать в голове конечный образ игры и сфокусируйтесь на нём – вашей конечной целью должен быть не опыт, полученный в процессе, а готовый продукт. Конечно, полезно вынести пару уроков из неудач, но, как мне кажется, намного важнее задаться целью, изучить всё, что необходимо для достижения этой цели, и в итоге реализовать задуманное», — Виктор Томпсон, West of Loathing

Ren’Py

Стоимость лицензии: Бесплатно

Подойдёт для: 2D визуальных новелл, симуляторов

Совместим с: Python

Примеры игр: Long Live the Queen, Analogue: A Hate Story

Ren’Py – это простой в освоении движок с открытым исходным кодом. И хотя он требует начальных навыков программирования, на самых ранних этапах вам понадобится лишь умение работать с текстовым редактором и приложениями по редактированию фотографий. Это удобная стартовая площадка для тех, кто в будущем планирует изучить язык программирования Python.

Джорджина Бенсли, автор Long Live the Queen, говорит по поводу Ren’py следующее.

Плюсы

«Открытый исходный код Ren’Py и его кроссплатформенность дают множество возможностей для всех пользователей движка», говорит Бенсли. «Я также считаю плюсом тот факт, что движок рассчитан на новичков, но при этом требует вносить правки в программный код игры. Это лучше, чем графический drag-and-drop интерфейс, так как это показывает, что в программировании нет ничего страшного».
Ren’Py подойдёт вам в том случае, если вас пугает сама перспектива создания игры с нуля:

«Одно из важнейших препятствий, с которым сталкивается большинство людей, ранее не работавших над созданием игр, заключается в их уверенности в том, что программирование – это нечто “слишком сложное”, а потому это попросту им не по силам. А данный движок позволяет быстро и успешно создать простую игру, что придаёт уверенности начинающим разработчикам, даже если они и не планируют в будущем выпускать одни лишь визуальные новеллы. Как только ты создаёшь нечто, во что могут играть другие, пусть даже простенький проект, ты уже не ставишь под сомнение свои способности».

Минусы

Ren’Py немного ограничен по части графических и геймплейных функций. Если вы намерены создавать игры с 3D, Live2D, системой повреждений и другими особенностями, то вам стоит поискать другие варианты.

Советы для новичков

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

ink

Стоимость лицензии: Бесплатно

Подойдёт для: текстовых приключенческих игр

Совестим с: Unity, C#, HTML

Примеры игр: 80 Days, Sorcery!

Ink – это хорошее бесплатное дополнение для Unity, если вы хотите разбавить свою игру диалоговыми ветками и расширенным повествованием. Его легко освоить, в нём не используется продвинутый код, и он бесшовно интегрируется с Unity. Как говорит создатель ink Джозеф Хамфри, данный движок является «промежуточным» — после создания скрипта в ink его можно перенести в более крупную игру на движке Unity. Тем не менее редактор Inky Editor позволяет также создавать веб-игры.

Плюсы

Создание масштабного сценария со множеством диалоговых веток может быстро превратиться в запутанную кашу, поэтому ink поможет вам не потеряться в процессе. «Авторы игр могут использовать инструменты движка для создания диалогов и текста в формате удобного интерактивного сценария с ключевыми метками», говорит Хамфри. «Затем движок ink, запущенный внутри Unity, сможет читать эти сценарии и выводить текст на экраны уже в самой игре».

Открытый исходный код играет важную роль в разработке амбициозных проектов. Хамфри отмечает, что «создаваемый на движке ink текст необязательно должен показываться в виде текста. К примеру, в игре Heaven’s Vault движок ink создаёт динамичный сценарий, который интерпретируется самой игрой в виде интерактивной графической новеллы с приключенческими элементами».

ink также является отличным инструментом для тех, кто больше заинтересован в написании сценариев для игр, а не о чистом программировании. «…Количество сценаристов, использующих ink для написания интерактивных историй, постоянно растёт», добавляет Хамфри. «Where The Water Tastes Like Wine – это один из таких примеров. Её создали авторы игры Gone Home при помощи движка ink. Над игрой работали такие известные сценаристы, как Ли Александр, Эмили Шорт и Кара Эллисон. Поэтому если вам нравится сочинять сценарии и вы интересуетесь разработкой игр, то ink может стать отличной площадкой для начала».

Минусы

ink лучше всего использовать для игр, разрабатываемых на движке Unity. Хамфри говорит, что «ink не является альтернативой Unity — это скорее дополнение. Более того, ink – это единственный инструмент для создания интерактивных сценариев, который был намеренно создан в виде промежуточного звена».

Советы для новичков

«У меня есть один-единственный совет – просто попытайтесь создать демо-игру. Если же вы хотите заполнить своё портфолио, в котором указаны примеры того, в чём вы хороши, то самое время начать заполнять его. Создавайте эти примеры!»

RPG Maker и другие движки

В начале 2017 года мы писали о внезапном появлении RPG Maker на площадке Steam и о том, как движок стремительно набирает популярность среди начинающих инди-разработчиков. Но есть и другие инструменты, на которые стоит обратить внимание:

HaxeFlixel с открытым исходным кодом и кроссплатформенностью.

Stencyl – инструмент для создания игр без использования программирования.

genapilot.ru

Лучшие игровые движки

Наверх
  • Рейтинги
  • Обзоры
    • Смартфоны и планшеты
    • Компьютеры и ноутбуки
    • Комплектующие
    • Периферия
    • Фото и видео
    • Аксессуары
    • ТВ и аудио
    • Техника для дома
    • Программы и приложения
  • Новости
  • Советы
    • Покупка
    • Эксплуатация
    • Ремонт
  • Подборки
    • Смартфоны и планшеты
    • Компьютеры
    • Аксессуары
    • ТВ и аудио
    • Фото и видео
    • Программы и приложения
    • Техника для дома
  • Гейминг
    • Игры
    • Железо
  • Еще

ichip.ru

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

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


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

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

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

Начало


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

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

Цели


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

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

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

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


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

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


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

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

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

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

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

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

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


Torque 3D

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


Torque Game Builder

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


HeroEngine

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


WebAssembly

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


Corona SDK

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

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


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

VR


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

Итоги


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

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

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

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

habr.com

О игровых движках! «На каком движке делать игру?» #1 / Блог Toytoy

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

Начнем с того, что существует куча игровых движков и редакторов для создания собственных творений, но кол-во по-настоящему годных очень мало. Еще одна проблема заключается в том, что многие из них являются закрытыми для общего использования. Например движок Frostbite 3, да-да, тот самый движок на котором была сделана игра с крутейшей графикой на данный момент — Battlefield 4. Хотя возможно вы видите достойного конкурента батле по графике :).

Так вот, что же делать если величайший в мире движок, на котором вы собирались делать свою игру оказался закрытым для простых смертных? Ведь вашей игре нужна такая же крутая графика и механика. И тут на помощь приходит не менее крутой движок, на котором можно творит ого-го какие вещи. Барабанная дробь… Unreal Engine 3!

Это не просто очень крутой движок, это движок с собственным языком программирования — Unreal Script, который даже сложно назвать языком. Unreal Script можно считать просто инструментов для связи всех объектов в вашей игре, создания геймплея и т.д. Так же UDK имеет довольно простой функционал и набор инструментов непосредственно в самой программе. Рассказывать как пользоваться Unreal Development Kit или же UDK, я вам сейчас не буду. На рунете и так полно как обущающих видео, так и статей по этой проге. Вы наверно сейчас думаете — «Хм, никогда не слышал об этом движке. Какие же игры были на нем сделаны?». А современных игр на нем, которые стали очень популярными великое множество. Я думаю для примера можно привести Mass Effect 3. Да-да, эта игра была сделана на том самом движке). Графика в этой игре была очень даже приемлема. Возможно многие посчитают ее даже отличной. А может вы просто забыли как выглядит Mass Effect 3? Тогда вот вам скрин).

Кроме Mass Effect 3 существует еще много известных игр на Unreal Engine. Возможно такие игры как: Dishonored, Borderlands 2, Thief, Outlast и Bioshoсk:Infinite вам о чем нибудь говорят?). И еще раз повторюсь что это не далеко не все игр сделанные на этом замечательном движке. Самой главной особенностью движка является его полная бесплатность. Однако если вы захотите продавать вашу игру за деньги, вам нужно будет приобрести лицензию у Epic Games.
На этом я заканчиваю свое повествование о Unreal Engine и мы переходим к следующему движку.
((СКАЧАТЬ UDK))

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


Примерами игр Unity3d могут служить такие игры как: Slender (Не Arrival, а тот, где надо бегать средь низкокачественных деревьев и собирать записки), Survivers, 1916 Der Unbekannte Krieg(довольно годная игра кстати), Surivers: Viy, Plague Inc., Call of Duty: Strike Team, Among The Sleep и Knock-Knock. Это опять же не весь список популярных игра на данном движке. Но вынужден сказать, что большинство игр, сделанных неопытными инди-разработчиками, которые только осваивают редактор выглядят просто ужасно. Это вызвано тем, что большинство людей, наполненные желанием создать собственную игру, начинают эту делать именно с Unity3d. Возможно это хорошее начало, но увы, результат почти всегда печальный.

Но! Хотел бы напомнить, что Unity3d является величайшим инструментом для создания игра на мобильные платформы — Android, iOS. И это все благодаря тому, что разработчики движка Unity3d внедрили функции компиляции проекта под Windows, Mac, Android, iOS и Linux! Это является очень важным достоинством движка. Для примера опять же приведу довольно популярную игрулю Temple Run 2. Возможно вы даже играли в Counter-Strike Portable созданный на данном движке.

Я думаю многие из вас поняли, что Unity3d не очень подходит для вас если вы хотите достичь замечательной графики не особо напрягаясь. НО чтобы не навязывать вам стереотип о ужасном графоне в играх на Unity3d, приведу вам пример игры с графикой, которую можно сравнивать с Battlefield 4. И имя этой игры -Свет! Игра от русского разработчика, который сумел достичь в своей игре на Unity3d довольно годной графики. Думаю вам лень гуглить игру и смотреть скрины, по этому все будет тут :)



((РУССКОЯЗЫЧНОЕ СООБЩЕСТВО UNTIY3d))
((CКАЧАТЬ UNITY3d))

Перейдем к последнему на сегодня движку — CryEngine. Это один самых популярных движков, созданных для разработки игр и помещенный во всеобщий доступ. На этом движке были сделанны любимые многими людьми игры серии Crysis. Crysis 1,2 и 3 — это все творения CryEngine! На данный момент актуальной версией движка является CryEngine 3. Разработчики движка — CryTech, предоставляют нам доступ к движку совершенно бесплатно, но опять же для распространения своей готовой игры за деньги и за коммерческое её использование вам нужно будет заплатить. Думаю много говорить о графических возможностях движка нету необходимости т.к большинство людей все же играли хоть в одну часть серии игр Crysis. Но скрин все же для примера кину.

Движок просто ооочень легок в использовании. Вам совершенно не надо знать каких-либо языков программирования (ну по крайней мере на начальных стадиях разработки), все связи событий основаны на аутпутах и различных ивентах. Если кто-то хоть раз открывал редактор FarCry 3 или FarCry 2, то интерфейс CryEngine 3 будет ему более менее привычен и легок в использовании. Ну можно еще добавить, что по сравнению с Unity3d тут добиваться хорошей графики не надо, она и так есть и будет всегда ;). В следующей статье я расскажу о 2d движках и о их преимуществах.
((СКАЧАТЬ CRYENGINE 3))

И так, подведем некоторые итоги). Сегодня мы обсудили 3 актуальных игровых движка которые повседневно используются как начинающими, так и уже опытными разработчиками для создания шедевров. В случаем с Unity3d — «шедевров». Думаю за период прочтения этой статьи вы выбрали для себя оптимальный движок для разработки собственной игры. А если же вы не собирались разрабатывать игру и вам просто было интересно на чем делает игры настоящие тру инди-разрабы, то вы узнали, что хотели). В любом случае я надеюсь, что эта статья оказалась для вас интересной и познавательной!
Пишите в комментариях, какой на по-вашему мнению самый лучший открытый игровой движок для разработки игр или же с каким движком работаете вы! Спасибо за прочтение статьи :)

ВТОРОЙ ВЫПУСК УЖЕ НА САЙТЕ!КЛИКНИ СЮДА, ЧТОБЫ ПЕРЕЙТИ КО ВТОРОМУ ВЫПУСКУ

stopgame.ru

Игровой движок для инди-студии и карьеры, что выбрать? — Хабр Q&A

Всем доброго времени суток. Заранее пишу, что текста будет много и жду вразумительных ответов от людей которые действительно понимают что пишут и почему дают совет.
И так начнем, я уже создавал тему раннее, но не получил нормального ответа. Мне 28 лет, я дизайнер в рекламном агентстве, рисую всякие флаера, буклеты, делаю логотипы и т.п., не хочу обидеть других дизайнеров, но я начал понимать что это не мое. Я давно мечтал уйти в индустрию геймдева, не знаю правда почему не решался и почему не ушел уже давно, но вот на данный момент решил окончательно забросить дизайн и идти только к своей мечте. Расклад такой, так как мне 28 лет, я поставил для себя цель, до 30 лет, то есть за 2 года изучить игровой движок, хотя бы процентов на 60-70, да многие скажут это невозможно и т.п., но я брошу все дела и сделаю полное упорство на изучение именно движка. В планах после изучения, создать свою инди-студию и делать игру. Игра уже есть, ну точнее диздок по игре готов на 50-60 процентов. План был таков, что я делаю диздок, изучаю выбранный движок, далее ищу 3д-моделера, худождника и совместными силами мы будем пытаться воплотить игру из диздока.
Теперь самая суть вопроса. Какой же игровой движок можно выбрать из мною предоставленных, а это: Unreal Engine 4, Unity3D, CryEngine, Blender. Отметил только эти, так как имею расположение что данные движки спокойно справляются с играми по типу ММО, да и сетевая часть у движков хорошо проработана. Но стоит и другой вопрос, но сколько я знаю, UE4 стал бесплатным и лишь после того как игра привысит 3000$ я буду должен платить им по 5% от прибыли. Вроде приятная плюшка. На счет Unity3D и CryEngine честно вообще нечего не знаю, хотелось бы услышать от Вас что то вразумительное. Про Blender не буду говорить, так как все прекрасно знают, что он полностью бесплатен, но и далеко на нем вроде не уедешь. Так что вроде остаются только три гиганта.
Так что, что же лучше выбрать инди-студии, чтобы в дальнейшем не обжечься, не прогореть из-за движка. Да и самое главное, что даже если у меня не получиться сделать игру, чтобы потраченные на изучения движка 2 года, не ушли в пустую, чтобы с этими знаниями я смог устроится на работу в гейм индустрию и дальше продолжать изучать движок и наслаждаться любимым делом.
В общем вот такой вот рассказ :) Жду ответов уважаемые коллеги...

  • Вопрос задан
  • 6102 просмотра

qna.habr.com

Как написать собственный игровой движок на 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.

habr.com

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

В декабре прошлого года, на конференции Games Gathering 2017, мы сделали доклад, в котором рассказали о том, надо ли компаниям, работающим в игровой индустрии, писать собственные движки.



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



Зачем в современном мире, в котором существуют такие гиганты, как Unity, делать что-то своё, писать собственные игровые движки?

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

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

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



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

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

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

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



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

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

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



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

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

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

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



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

Вот вам история. В одной компании на сайте было задание для программистов, выглядящее примерно так: «Ребята, если хотите у нас работать, напишите пожалуйста «Астероиды», которые должны запускаться на платформе Android без использования внешних библиотек. Мы считаем, что на это вам достаточно 8 часов. Время пошло». Потом время увеличили до 12 часов. Может быть, выглядит это смешно. Сначала я наблюдал за этим, снаружи, потом заглянул в эту компанию и попросил рассказать мне о том, что прислали в виде отклика на это задание. Как оказалось, отбор прошли больше двухсот программ, то есть — эти программы запускались и работали. Это значит, что если вы вдруг захотите издать «Астероиды» для Android, то найдется как минимум 200 человек, которые могут это сделать за 8 часов. Я не говорю, что это можно продавать. Но рассказал я эту историю к тому, что очень часто, собственно, движок — это и есть Time to Market. Скажем, просто потому, что у вас такие маленькие потребности, что вы дольше будете изучать документацию на тот же Unreal, чем просто взять и сделать своё.
  • Lord of the Platform — властелин платформы. Существуют платформы, для которых нет готовых инструментов. Например, STB, set-top box (ресивер цифрового телевидения) — коробочка для кабельного телевидения, которая стоит на столе у каждого третьего американца.

У Warner имеется 120 миллионов пользователей этой услуги. Если вы пишете туда софт, и игры в том числе, то вы имеете доллар с коробки. Это 120 миллионов долларов в год. При этом кроме вас писать для этой штуки не может больше никто. Потому что там нет DirectX, там вообще ничего нет. Если вы умеете писать программы для STB — то вы властелин платформы, вы имеете эти сто двадцать миллионов долларов в год. Чем не повод писать свой движок?

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

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

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

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

При этом в случае с 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 — покупка часто предпочтительнее ипотеки. Игровая разработка — это, так или иначе, деньги. Есть способы монетизации, при использовании которых покупка не просто лучше, чем ипотека, а это просто единственно возможный вариант.

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

У вас есть 2 варианта действий: либо их переучивать так, как положено с точки зрения best practices, либо использовать своё. Есть простые примеры. Предположим, вы говорите: «Мы импортируем 3D-модели». Вы не знаете — что там с той стороны. Поэтому вам нужен промежуточный формат. Промежуточный формат пускай будет FBX. Огрехи FBX все, кто этим занимаются, знают. А вам некуда деваться, потому что вы не знаете, что там будет делаться, вы не будете писать плагины под 450 средств 3D-моделирования.

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

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

Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.

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

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

Разработка собственного движка — это не только преимущества. Это ещё и риски. Рассмотрим их.

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



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

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

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



Рассмотрим очень важный вопрос. Какой ресурс требуется в первую очередь для разработки собственного движка? Ресурс, без которого бессмысленно задумываться о том, надо или не надо делать собственный движок. Ответ на него, конечно, не 42. Вопрос в том — что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да, у нас хоть что-то есть, мы можем начать что-то делать». Ответ на этот вопрос заключается в том, что для разработки собственного движка нужны программисты.

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



Для того чтобы создать собственный движок, нужны программисты. Если не знаете — погуглите разницу между словами «developer» (разработчик) и «programmer» (программист). Это очень важно. Девелоперы — это основная группа. Игровая индустрия так устроена, что большинство людей в ней программистами назвать нельзя. Извините, но они разработчики. Разработчики не способны грамотно сделать движок. Опять же, если взглянуть на разницу между первыми и вторыми, то разработчики делают игры, а программисты делают инструменты. Разработчики делают продукт, компания зарабатывает за счёт продукта, но инструменты должны быть сделаны программистами, иначе они просто не будут работать.

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

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

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

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



Сейчас уместно вспомнить ещё об одном аспекте поиска сотрудников, который касается, преимущественно, больших компаний. У таких компаний есть несколько подходов к подбору персонала.

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

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

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

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

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

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

Два мира



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

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

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

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

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

Итоги



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

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

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

Вопросы и ответы

Вопрос


Какова стоимость вашего движка, если оценивать её в деньгах и в трудозатратах?
→ Ответ

Сколько это стоило в деньгах, я, наверное, сейчас не могу сказать. А если говорить о трудозатратах, то это девять месяцев команды из шести человек. Но надо понимать, что это наша последняя разработка, и тут мы целимся достаточно высоко. Я не рассказываю о нашем наборе инструментов, о том, что мы делаем с Lua, или о том, что мы делаем с JavaScript такого, что не делает вообще никто. Мы планируем выпустить в опенсорс пару модулей, которые, если и не перевернут индустрию, то, как минимум, помогут людям осознать — что такое скриптовые языки. Наш предыдущий движок делали два человека четыре месяца. Он — тоже 3D, но попроще, телефонный. Можно быстрее, я уже рассказывал, как «Астероиды» пишут за 8 часов, но это, конечно, далеко от реальности.

Вопрос


Сколько времени потребовалось на реализацию дерева поведения?
Ответ

Это я могу точно сказать, делалось это совсем недавно. Два человека занимались этим месяц. Но проблема тут шире, чем создание дерева поведения. Дело в том, что экшны у нас пишутся в Lua, занимает это, наверное, дня четыре, а написать редактор на Qt — месяц.

Вопрос


Насколько я понимаю, вы используете Lua, у вас есть экшн-система, которую вы изначально написали, а дерево поведения просто дёргает эти экшны?
Ответ

Да, так и есть. На самом деле, мы работаем над тем, чтобы вывести это в опенсорс, пишем документацию, систему сборки, примеры.

Вопрос


Наша компания имеет очень схожие взгляды с вашими, и проблемы у нас тоже интересные возникают. Хотелось бы узнать — какое у вас соотношение трудозатрат на игру, на движок, на инструменты? То есть, сколько людей, например, работает над движком, над игрой, сколько игр используют один движок?
Ответ

У нас сейчас два движка, предыдущая редакция и новая. То есть это не рефакторинг. Это полностью новый движок. Если говорить о трудозатратах, то можно сказать, что компания у нас большая, работает около 500 человек, программистов около 250, 5 офисов. Проектная команда работает над играми. Проект — это некая игра, и ей занимается некоторое количество людей. Команда разработки движка — это отдельный коллектив. Это — тот самый кефир, о котором я говорил, элитные подразделения, там немножко другие деньги и подходы к формированию команд. Сейчас мы немного обгоняем разработку. Две новые игры запущены на новом движке. Это достаточно мучительно, так как разработчикам игры не очень комфортно, потому что они работают в ситуации, когда у них что-то может буквально из-под рук взять и взорваться. И у нас команда движка — это 6 человек. Команды продуктов — это, в среднем, человека по четыре программиста, они не пересекаются.

Вопрос


Под движком вы подразумеваете и инструменты тоже?
Ответ

Да, у нас есть отдельная команда по разработке инструментов. У нас был очень неудачный пример. Очень плохо разрабатываются GUI-инструменты. Потому что любой нормальный программист считает, что это очень просто. Мы попытались это аутсорсить. Потому что понятно — ты отдаёшь полный интерфейс, у тебя всё есть, ты говоришь: «Создай окно, нарисуй кнопки — и всё». Но эта затея провалилась, поэтому сами делаем, мучительно работаем с Qt, потому что нам важно, чтобы это работало на всех трёх настольных платформах. Поэтому сами делаем. И у нас 6 человек делают и то, и другое, и третье. Но мы всё равно находимся чуть впереди запросов продукта.

Вопрос


Реально ли сейчас продать свой движок?
Ответ

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

Вопрос


Я так понимаю, что ваш новый движок — это С++ и Lua?
Ответ

Да, C++, Lua и ещё JavaScript.

Вопрос


А почему C++? Были ли варианты, или вы чётко знали, что именно возьмёте?
Ответ

Смотрите, существует такая мода. Каждый второй, кого встречаешь, говорит тебе: «Golang», или говорит тебе: «Rust». И если бы это было сейчас, я бы в принципе задумался. Но когда ты приходишь в компанию руководителем процесса разработки движка, а было это год назад, тебе надо строить какие-то планы, а так придётся включать в эти планы пункт «Почитать о Go». Тут ведь важна производительность, а на C++ мы достаточно давно работаем, умеем им пользоваться.

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

Вопрос


Скажите, вы дерево поведения используете только для управления поведением, или применяете его ещё для управления игровыми механиками и для продвижения игрового прогресса?
Ответ

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

Вопрос


Насколько трудно прогнозировать развитие технологий на будущее? То есть, как сложно предвидеть появление каких-то подводных камней и тому подобных вещей?
Ответ

На данный момент я вижу одну проблему. Сейчас интересно выглядит технология WebAssembly. Flash умер. Мы хотим, естественно, издаваться ещё где-то на вебе. Портировать игру, скажем, с Unity на WebGL — это задача, которая не решается нажатием на одну кнопку. То есть сейчас мы смотрим на WebAssembly и пока неясно — будет ли это стандартом, или нет, начинать сейчас с этим работать, или подождать. В мобильных технологиях тоже ничего особенного не происходит. Нет пока каких-то сингулярных взрывов, но если будут — будем готовиться.

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

habr.com


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



© 2010- GutenBlog.ru Карта сайта, XML.