Генеральный продюсер компании AminiLab Илья Пшеничный, занимающийся разработкой игр последние 13 лет, написал для подраздела Unity колонку о том, как выбрать подходящий игровой движок для проекта.
Несмотря на название статьи и на раздел, в котором она опубликована, мы постараемся избежать напрашивающихся выводов.
Чтобы развеять сомнения почтенной аудитории в том, стоит ли прислушиваться к мнению, изложенному в статье, могу сразу сказать, что можете и не прислушиваться. Но мы предупреждали.
Статья написана на основе почти 15-летнего опыта разработки видео-, компьютерных, мобильных игр под широкий спектр платформ — начиная с PlayStation 2 и Nintendo DS и заканчивая Android и iOS, с использованием различных движков и технологий — Unreal Engine, Unity, Cocos, Ignite, Gamebryo, CreatEngine, Xamarin, Fire Engine, Renderware и так далее.
Означенный опыт включает в себя как известные проекты вроде FIFA, NHL, Sims, Alone in the Dark, так и менее известные и успешные (а временами и совсем неизвестные и неуспешные).
Кстати, если вы собираетесь делать «2048» или похожую игру, можете дальше не читать. Используйте любой движок или технологию, которая вам нравится.
О чём пойдет речь
В рамках статьи мы не будем затрагивать такие интересные темы, как:
- в каком движке лучше реализован шейдер воды;
- как там дела с deferred shading;
- сколько полигонов отрендерить;
- и подобные.
Мы не считаем эти вопросы сколько-нибудь важными при выборе движка для подавляющего числа проектов и, если вы поднимаете их в своих обсуждениях, то рекомендуем вам крепко задуматься.
Не считаем мы их важными по той причине, что при выборе движка надо в первую очередь думать о конечной цели. А конечной целью является выпуск коммерчески успешного проекта(ов) — то есть такого проекта, полученная прибыль с которого превысит прямые и непрямые затраты на его производство и поддержку в обозримый срок.
Критерии выбора движка должны быть именно такими — позволит ли он выпустить тот самый проект, того самого уровня качества, в тот самый срок. Заметим, что срок играет важную роль, так как игровой рынок меняется всё быстрее.
При выборе движка мы настоятельно рекомендуем не отталкиваться от аргументов вида «Это опенсорс», «Лёгкий движок, если что, поправим сами», «Новая технология! Хэтэмэель5 вебжэль, будет работать и в браузере, и на FirefoxOS». Вместо этого предлагаем оперировать аргументами «У ведущего художника двое детей и они хотят есть» или «У продюсера банк отберет ипотечную квартиру, если проект не выйдет в срок и не заработает денег».
Так что же такое игровой движок
(Неплохой вопрос на собеседовании, кстати.)
Говоря строго, игровой движок — это набор решений и технологий, обеспечивающий пайплайн данных от их производителей — художников, геймдизайнеров, игровых программистов, до потребителей — игроков. И чем этот пайплайн полнее и требует меньше труда для настройки, тем движок лучше.
Обратите внимание, что речь идет именно о полном процессе, а не о какой-то его части. Именно поэтому нельзя считать движком многие технологии, которые имеют смелость себя так называть.
Если вы уже делали хоть сколько-нибудь сложные игры, то знаете, что большую часть трудозатрат занимает не задача «давайте отрендерим модельку», а труд художников (2D, 3D, аниматоров…), геймдизайнеров, а также программистов, борющихся с системой — файловой, сетью, покупками, асинхронностью и так далее. И если ваши сотрудники вместо того, чтобы делать крутую игру, которая заработает денег, борются с системой, неудобным инструментарием, медленным пайплайном, невозможностью быстро увидеть результат своей работы и итерироваться — то технология, которую вы выбрали — не движок, а просто набор библиотек.
Так как же выбрать
Наконец приведем те критерии, которые считаем нужно использовать при выборе игрового движка.
Самое главное, помните о конечной цели и не забывайте, что игру делает команда. И всем членам этой команды должно быть удобно (а значит, и эффективно) работать. Поговорите со своими художниками, аниматорами, художниками по спецэффектам, левел-дизайнерами и прочими — спросите их, что им надо от инструментария, как им будет удобно работать. Покажите альтернативы, дайте день на то, чтобы они попробовали освоиться. А если люди новые и никогда раньше с играми не сталкивались, то, может, и не стоит игру делать вообще, или сразу переходите к выводам.
Итак.
Во-первых,
на выбранном движке должно быть принципиально возможно сделать игру, которую вы придумали. К примеру, вы хотите делать 3D-игру, значит, движок должен поддерживать 3D-пайплайн. И, конечно, работать на выбранной целевой платформе (этого подробнее коснемся ниже).
Во-вторых,
богатство инструментария и полнота областей, «закрываемых» движком — работа с магазинами приложений, рекламными сетями, клиент-сервер, ввод-вывод и так далее. Всё это определяет стоимость производства, поддержки и развития вашей игры. Помните, что каждый раз, когда вам приходится решать проблемы с неподдерживаемым форматом текстур, неудобным редактором анимаций, протаскиванием гейм-дизайнерских таблиц с настройками в билд, работой с SD-картой — вы каждый раз крадете деньги у самих себя.
В-третьих,
порог входа. Этот порог зависит от проекта, его сроков и предыдущего опыта команды. Не обязательно команда должна иметь опыт работы с этим движком (хотя и очень желательно), но важно, чтобы команда могла изучить его на необходимом для проекта уровне в разумный срок. Срок этот может быть разным — на одном из проектов мы изучали новый движок около шести месяцев, но оно себя оправдало в итоге.
В четвертых,
доступность кадровых ресурсов на рынке труда и «троллейбусный коэффициент». Насколько технология уникальна и насколько сложно найти специалистов на рынке. Что будет с проектом или компанией, если заболеет или уволится технический директор или главный технический художник?
Наконец,
общая известность и распространённость технологии. Большое ли коммьюнити? Много ли игр сделано на этом движке? А игр выбранного вами жанра? Как работает служба поддержки?
Последние два пункта, к примеру, говорят о практической непригодности для разумного использования такого, движка (вне всяких сомнений), как CryEngine, просто в силу того, что риски, сопряжённые с разработкой на нём, слишком велики (если вас не спонсирует Crytek).
А первые пункты говорят о том, что многие технологии — ни разу не движки, а просто технологии. И использовать их для проектов размером от среднего и выше мы бы не советовали.
Кстати, о популярном критерии — «кроссплатформенности». Важность этого критерия заметно преувеличена. Если мы говорим о кроссплатформенности в рамках мобильных операционных систем — ок. Или в рамках консолей PlayStation и Xbox.
Но не надо думать, что можно сделать игру для консолей, а потом дёшево перенести её на мобилы или наоборот. Игровой опыт на этих платформах настолько отличается, что технические вопросы портирования не играют ключевой роли.
Критерий стоимости тоже уже отошел на второй план — прошли те времена, когда один известный движок стоил $1 млн, сейчас большинство движков стоят сравнимых денег и предлагают гибкие условия лицензирования.
Что же в сухом остатке
Говоря о проектах для мобильных платформ или ПК размерами средний и выше, выбор движков не такой и широкий. По большому счёту, это или Unity, или Unreal Engine.
И тот, и другой являются полноценными движками, с богатой функциональностью, отличным инструментарием, скрывающие от разработчиков многие «неинтересные» и сложные аспекты работы с платформами на низком уровне и, наконец, они мультиплатформенные.
Подробнее остановимся на каждом из них.
К плюсам Unity можно отнести:
- Сравнительную плавность кривой вхождения, хороший игровой редактор и инструментарий. В принципе, за пару дней базовые вещи может освоить любой желающий. Есть множество видеоуроков и прочей документации.
- Большое коммьюнити, множество выпущенных проектов во всех жанрах.
- Asset Store — внутренний магазин, в котором разработчики могут покупать для своих проектов готовые куски кода, реализующие ту или иную функциональность (к примеру, работу с системными лидербордами или ачивками) или художественные и звуковые ассеты (а также всё вместе).
- Закрытость. В обычных условиях у разработчиков нет доступа к исходному коду движка, нет возможности что-то исправить или улучшить на системном уровне, приходится ждать, когда это сделают (если сделают) инженеры Unity.
- Отсутствие хорошего track-record выпущенных ААА-тайтлов. Те разработчики, которые делали или пытались делать ААА на Unity, сталкивались с большим количеством одинаковых проблем (об этом, кстати, недавно упоминали на одной из лекций на DevGamm Moscow).
- Отсутствие хорошего track-record выпущенных консольных тайтлов.
- Вот на нем AAA и консоли делать можно, что доказано большим пулом выпущенных ААА-проектов (хоть и схожих жанров)
- Возможности редактора. У Unreal Engine очень качественный редактор, обладающий очень богатой функциональностью, а также система визуального «программирования» с помощью Blueprints. В качестве примера приведу такой случай: на одном из проектов, который мы делали на Unreal Engine, мы расстались с программистом, отвечавшим за графику и рендер за банальной ненадобностью. Художники отлично справлялись самостоятельно со сборкой «из кирпичиков» любых нужных им шейдеров.
- Движок поставляется с полным доступом к исходному коду. Берите, правьте, отлаживайте, если необходимо. Можно даже исправления засылать обратно в Epic, и, если они сделаны хорошо и действительно важные, то их включат в следующий релиз.
- Порог входа. Ребята из Epic прикладывают большие усилия, чтобы его снизить, но он всё равно достаточно высок, особенно если вы собираетесь делать что-то серьёзное.
- Слабый Asset Store. По сравнению с тем, что есть у Unity, в магазине Unreal Engine нет почти ничего. Ситуация постепенно исправляется, но сейчас она пока ещё такая.
- Меньшая распространённость, особенно на постсоветском пространстве.
Важность Asset Store сложно переоценить. Использовать его ассортимент можно по-разному, не только покупая готовую подсистему и встраивая ее as is, тем более, что далеко не всё, представленное там, обладает высоким качеством. Но вот купить за $5-$20 кусок кода, в который можно подсмотреть, как в пример, или набор визуальных спецэффектов, а потом переделать их под себя — это очень облегчает жизнь. Особенно, если надо быстро что-то запрототипировать.
К минусам Unity отнесем:
Повернемся к Unreal Engine. Его сильные стороны:
И важность доступа к коду движка тоже сложно переоценить, особенно, если вы делаете большой проект. В случае с движками без доступа к коду игра может вдруг просто «упасть» в каком-то неизвестном месте, или начать «тормозить», или ещё как-то странно себя вести, и вы ничего с этим не сможете ни поделать, ни даже понять, почему, кроме лечения симптомов и гадания, что же не так. В случае же открытого кода вы сравнительно легко можете найти первопричину ошибки и или поправить её в своих исходных данных, или же даже поправить код движка.
Но есть у Unreal Engine и слабые стороны
Кстати, не рассмотрели еще один крайний случай — у команды есть самописный движок. Если это узкоспециализированный движок, который позволяет делать, к примеру, HOG
(Histogram of Oriented Gradients, гистограммы направленных градиентов — прим. ред.) или ещё какой-то конкретный жанр игр под конкретные платформы, и он много раз проверен «в бою», сотрудники с ним хорошо знакомы — отлично, используйте его, не думайте о чём-то другом.
Но если вы решили написать свой «универсальный» движок, или адаптировать свой текущий движок для match-3 до «универсальности», то мы очень не рекомендуем вам этого делать. Такой подход был оправдан лет 10 назад, когда с движками дело обстояло значительно хуже, но сейчас вы, вместо того, чтобы делать крутую игру, будете тратить бюджет компании и время, которое не вернуть, на то, что давно и хорошо сделано до вас и предлагается практически бесплатно в любом хорошем движке.
Ну и, наконец, небольшое резюме.
Основываясь на вышеизложенном, выглядит разумным среднеразмерные проекты делать на Unity, а если вы замахнулись на что-то больше, то внимательно посмотрите на Unreal Engine.
Выбор движка — занятие интересное, но не забывайте, что результат имеет весьма большое влияние на будущее проекта или всей компании. Хорошо, когда есть время и деньги эксперементировать, выпускать разные проекты на разных технологиях, сравнивать результаты и писать постмортемы. Если такой возможности нет, то наша рекомендация — максимально снижайте риски своего бизнеса или проекта.
Игры — и так очень непредсказуемая область. Сосредоточтесь на пользовательском опыте своих игроков, а о пользовательском опыте ваших сотрудников пусть позаботятся профессионалы.
Давайте делать хорошие игры.
Если вы хотите написать материал для рубрики «Рынок игр», рассказать о разработке своей игры или кейсе её роста, присылайте материал на games@siliconrus.com.
About the author
