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

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

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

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

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

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

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

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

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

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

Каковы ваши цели в этом проекте? Технологии должны по максимуму упрощать их достижение:

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

Интерес

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

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

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

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

У Джонатана Блоу есть удивительно мудрое видео о том, что же на самом деле дают игровые движки ^[2]. Они решают за вас «простые» проблемы, но потом встают на пути, когда пытаетесь решить сложную проблему, из которых и состоят увлекательные игры.

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

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

Вам нужно задаться вопросом: «Что же мне требуется на самом деле?» Избавляйтесь от всего лишнего. Каждая ненужная система — это впустую потраченные ресурсы и время.

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

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

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

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

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

При использовании любой технологии стоит задуматься о замыкании. У Джоэла Сполски есть серия статей о бизнес-стратегии разработки ПО, в которой он размышляет о замыкании на продукте ^[5]. Если вкратце, то его мысль заключается в том, что компании заинтересованы удерживать вас, чтобы вы использовали их продукт, потому что если вы не используете продукт, то они не зарабатывают денег. Мастерами в захвате целых отраслей стали 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 сделала в этом направлении огромные шаги ^[6]. Если меняются даже они, то я уверен, что смогут и другие.
• В лицензионном соглашении Unreal ^[7] содержится пункт, позволяющий опираться на его код при работе над собственным (проприетарным или свободным) движком. Я думаю, что это большой прогресс.
• Благодаря своей полной открытости и бесплатности большую популярность набирает Godot ^[8], и я надеюсь, что если ему дать достаточно времени и поддержки, то он станет конкурентом Unity (а со временем и Unreal).
• id Software (в эпоху Джона Кармака) выпускала полный исходный код с Doom ^[9] и до Doom 3 ^[10]. У Кармака было множество причин ^[11] продвигать такое решение. Самая убедительная из них для компаний заключается в том, что это не вредит продажам. Модель shareware, по которой распространялся Doom — разработчик отдаёт движок и продаёт данные — может быть эффективной стратегией и сегодня. Если ваш бизнес беспокоится о том, что конкуренты «украдут» вашу технологию, можете опубликовать свой код уже после того, как за ним выпущена более новая игра (так поступала id). После ухода Кармака id, похоже, потеряла интерес к публикации кода.

Качество ПО

Джонатан Блоу ^[12] и Кейси Муратори ^[13] — ярые критики современных практик написания ПО. Их точка зрения заключается в том, что мы создаём надстройки над слоями абстракций так долго, что получаются огромные хрупкие слои ненужного хлама, и это не позволяет нам писать более качественные продукты.

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

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

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

Вместо использования движка вы просто пишете игру.

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

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

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

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

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

Это лишь очень малая доля существующих библиотек.

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

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

В заключение

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

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

Автор: PatientZero

Источник ^[14]