Лого vc.ru

Советы по выбору игрового движка от генерального продюсера AminiLab Ильи Пшеничного

Советы по выбору игрового движка от генерального продюсера AminiLab Ильи Пшеничного

Генеральный продюсер компании 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 можно отнести:

  1. Сравнительную плавность кривой вхождения, хороший игровой редактор и инструментарий. В принципе, за пару дней базовые вещи может освоить любой желающий. Есть множество видеоуроков и прочей документации.
  2. Большое коммьюнити, множество выпущенных проектов во всех жанрах.
  3. Asset Store — внутренний магазин, в котором разработчики могут покупать для своих проектов готовые куски кода, реализующие ту или иную функциональность (к примеру, работу с системными лидербордами или ачивками) или художественные и звуковые ассеты (а также всё вместе).

Важность Asset Store сложно переоценить. Использовать его ассортимент можно по-разному, не только покупая готовую подсистему и встраивая ее as is, тем более, что далеко не всё, представленное там, обладает высоким качеством. Но вот купить за $5-$20 кусок кода, в который можно подсмотреть, как в пример, или набор визуальных спецэффектов, а потом переделать их под себя — это очень облегчает жизнь. Особенно, если надо быстро что-то запрототипировать.

К минусам Unity отнесем:

  1. Закрытость. В обычных условиях у разработчиков нет доступа к исходному коду движка, нет возможности что-то исправить или улучшить на системном уровне, приходится ждать, когда это сделают (если сделают) инженеры Unity.
  2. Отсутствие хорошего track-record выпущенных ААА-тайтлов. Те разработчики, которые делали или пытались делать ААА на Unity, сталкивались с большим количеством одинаковых проблем (об этом, кстати, недавно упоминали на одной из лекций на DevGamm Moscow).
  3. Отсутствие хорошего track-record выпущенных консольных тайтлов.

Повернемся к Unreal Engine. Его сильные стороны:

  1. Вот на нем AAA и консоли делать можно, что доказано большим пулом выпущенных ААА-проектов (хоть и схожих жанров)
  2. Возможности редактора. У Unreal Engine очень качественный редактор, обладающий очень богатой функциональностью, а также система визуального «программирования» с помощью Blueprints. В качестве примера приведу такой случай: на одном из проектов, который мы делали на Unreal Engine, мы расстались с программистом, отвечавшим за графику и рендер за банальной ненадобностью. Художники отлично справлялись самостоятельно со сборкой «из кирпичиков» любых нужных им шейдеров.
  3. Движок поставляется с полным доступом к исходному коду. Берите, правьте, отлаживайте, если необходимо. Можно даже исправления засылать обратно в Epic, и, если они сделаны хорошо и действительно важные, то их включат в следующий релиз.

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

Но есть у Unreal Engine и слабые стороны

  1. Порог входа. Ребята из Epic прикладывают большие усилия, чтобы его снизить, но он всё равно достаточно высок, особенно если вы собираетесь делать что-то серьёзное.
  2. Слабый Asset Store. По сравнению с тем, что есть у Unity, в магазине Unreal Engine нет почти ничего. Ситуация постепенно исправляется, но сейчас она пока ещё такая.
  3. Меньшая распространённость, особенно на постсоветском пространстве.

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

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

Ну и, наконец, небольшое резюме.

Основываясь на вышеизложенном, выглядит разумным среднеразмерные проекты делать на Unity, а если вы замахнулись на что-то больше, то внимательно посмотрите на Unreal Engine.

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

Игры — и так очень непредсказуемая область. Сосредоточтесь на пользовательском опыте своих игроков, а о пользовательском опыте ваших сотрудников пусть позаботятся профессионалы.

Давайте делать хорошие игры.


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

Статьи по теме
Чем отличается разработка игр от разработки «обычных» ИТ-проектов03 сентября 2014, 11:24
Роман Менякин, Unity: Чего ждать от интеграции с WebGL и что такое Extended Unity Cache30 июля 2014, 14:11
​Обновления Unity и бесплатный доступ к Unreal Engine — мнения разработчиков05 марта 2015, 13:55
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Мне очень нравится cocos2d-x в том его виде, в котором он представлен на сегодняшний день. Для следующей 2d-игры любой сложности выберу его. При этом опыт с Unity и Cocos2d-x примерно равный, две игры уровня match3.
Ну а по поводу 3d согласен со статьей.

Если у вас есть собственные наработки по кокосу, которые упрощают создание match3 под выбранную вами платформу - то, наверное, это оправдано.
Но для "2l-игры любой сложности" - не рекомендовал бы.
Все-таки кокос - это не движок, а набор библиотек, местами упрощающих некоторые инженерные задачи.
Тут тонкая грань, когда тот пайплайн, о котором идет речь в статье, превращается в движок. Но кокос, при всем уважении, к ней еще не подошел.
Как только размер проекта станет больше или появится любая задача, которую на кокосе делать сложно - трудозатраты на то, чтобы "дописывать" кокос привысят от него пользу.

0

А какие особенные наработки могут существенно упростить создание match3?
Можете уточнить насчет пайплайна? Какие именно аспекты по вашему в него должны входить, чтобы библиотеки стали движком.
Я сравнивал cocos2d-x и unity программируя на них параллельно.

Да, в Unity есть NGUI плагин, который позволяет довольно быстро делать UI.
Но в cocos2d-x из коробки есть своя UI-система, которая достаточно удобная даже при создании из кода. Плюс, они все же делают CocosStudio, где уже можно частично верстать UI.

В cocos2d-x есть C++11. Он гораздо приятнее и удобнее для программирования чем C#. Тут наверное мало кто со мной согласится, но после опыта Java, obj-c, ocaml и с# с++ для меня стал идеалом.

В cocos2d-x из коробки идут твины, удобная событийная модель.
В unity твины все сторонние, событийная модель своеобразная.

По анимациям они наверное на одном уровне находятся. Для Unity мне приходилось использовать самописный примитивный скрипт, чтобы можно было юзать анимации, которые были сделаны для других технологий.
В cocos2d-x как минимум спрайтовые анимации простые и прямые.

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

Еще у Unity c git не очень, даже когда все в тексте. Если не иметь опыта, можно наворотить в команде.

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

Ну и конечно open source иногда неплохо помогает. Но это скорее преимущества при том, что кокос пока не идеален.

Безусловно, мое мнение основано не на самых крупных проектах. Мне было бы интересно услышать какие именно качественные преимущества есть у Unity при разработке достаточно крупных проектов.

0

Вот кстати, С++ - действительно весомый аргумент, кроме шуток. Правда, не для всех :)
Как я и говорил, все зависит от размера проекта.
Небольшие проекты - делать можно на чем угодно.
Но представьте, что вам надо, чтобы в вашей "2Д" игре был, скажем, navmesh.
Или чтобы корректно работали данные с sd карты.
Или что тормозит и надо профильнуть. Вот по серьезному, и память, и процессор(ы)
Т.е. у вас много сравнительно сложных систем, которые должны работать вместе.
Но и это не самое главное. Чтобы сделать хорошую игру, скорость итерации - одна из ключевых составляющих успеха. Вам должно быть удобно что-то поменять и сразу же увидеть результаты своего изменения. И если при небольшом проекте это можно сделать каким-то "наколенным" способом, написать какой-то скрипт и тп, то при средне-большом - уже очень неудобно, надо чтобы была кнопка "Пыщь" которая все запускает и желательно на целевой платформе.

0

CryEngine рулит.

0

я бы их так расставил по классу и сложности
-Unreal
-Cry
-Unyty
Other

0

Только КриатЕнжин, только Инсектициды и Смешкарс!

0

"Основываясь на вышеизложенном, выглядит разумным среднеразмерные проекты делать на Unity, а если вы замахнулись на что-то больше, то внимательно посмотрите на Unreal Engine"

Как на счет сырости UE для мобильных платформ? Или это лишь миф?

0

Хотелось бы услышать сравнение UE и Unity для сетевых игр - скажем условная moba или сетвой шутер. Какие плюсы и минусы в случае создания сервера под эти UE, Unity технологии.

0

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

0

Ломаю голову что выбрать Unity или UE для разработки небольшой игры под VR, вернее для начала это будет типичный RollerCoaster. Основная цель - минимальными усилиями добиться качественной картинки. Посмотрев на список игр Unity (просто гуглим картинки) я не вижу того качества, которое присуще UE. Однако, вопрос практического отсутствия у UE в Asse Store бесплатных или недорогих материалов несколько удручает..
Есть небольшой опыт в C#, но в UE обещают довольно простой С++ или blueprint. В принципе, с программированием проблемы не должны возникнуть ни там, ни там.
На мой взгляд, для игр и приложений VR особенно важно будет хорошая, по возможности фотореалистичная картинка. Это и склоняет в сторону UE. Будет интересно мнение других разработчиков.

0

Фотореалистичная картинка для VR - да, для некоторых приложений очень разумно. Но эта фотореалистичность требует достаточно большого продакшена (арт продакшена). Вы уверены, что это согласуется с "небольшой игры"?

0

В моём случае я просто хочу хорошую картинку минимальными усилиями. Демо-игр и приложений с низким качеством графики для Oculus уже предостаточно, мало кого удивишь очередным RollerCoaster. Но ощущения реальности в них лично у меня не возникает. Пробовал тут один VR аттракцион на основе Oculus, ролики и демки могут удивить разве что ребёнка дошкольного возраста, то есть всё довольно печально... Поэтому размер игры или ролика тут особо не имеет значение, значение имеет конечный визуальный результат, пусть даже игра на 2-3 минуты. По вашему мнению, UE лучше подходит для этих целей?

0

Какие вообще подвохи могут ожидать при работе с ним?

0

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

0

Для начала платформа Oculus DK1. Но и UE и Unity , насколько мне известно, прикладывают усилия для поддержки и других девайсов. Буквально вчера закончил обучающий Survival Shooter на Unity. Проблема в том, что в ряде видео, которое я смотрел (в том числе игра The Forest) лес и большие пространства выглядят, мягко говоря, не очень. Я не знаю с чем это связано, с кривостью ли рук конкретного разработчика, но это факт. Возможно, дело в дешёвых ассетах, но от этого не легче. Берём UE, смотрим обучающие ролики, демки и удивляемся. На мой взгляд, Unity хорошо подходит для небольших игр, но с жанром Action или FPS дело у него гораздо хуже, чем у UE. Возможно, дело в нацеленности Unity именно на мобильные и веб платформу, я не понимаю в чем дело. Из коробки если использовать готовые ассеты получается, извините, какая-то хрень на уровне 2000-х годов. В UE я на вытаскивал объектов из примеров, огонь, деревья и они выглядят довольно достойно. Поскольку я только осваиваю то и другое, то в UE сразу из коробки выглядит всё шикарно. Про Unity я такого пока сказать не могу. Разубедите меня, пожалуйста. Unity нравится как редактор, но у меня к нему большие претензии с графической стороны.

0

Дмитрий, я выше писал, что если вы хотите сделать фотореалистичную демку, вам придется здорово вложиться в продакшен. Задумайтесь об этом. Речь не идет об ассетах, что "из коробки". Анрил - отличный движок, который заточен под First Person Shooter игры. Но порог входа у него достаточно высокий.
Юнити - тоже можно делать отличную картику (посмотрите последний деморил Юнити 5), и порог входа куда ниже, и, м.б. найдутся подходящие ассеты в сторе.
И в том, и в другом случае вам стоит приготовиться к тому, что "быстренько сделать маленькую демку" не получится. В случае с Анрилом будет больше свободы и результат потенциально лучше, в случае с Юнити - результат будет быстрее.

0

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

Сейчас обсуждают
Антон Адамов

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

Компания «Альянс» показала на бутылках своего сидра героев знаменитых картин в состоянии опьянения
0
Yus Teryukalov

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

«В кризис банк никто не купил, пришлось развивать самому»
0
Philip Salnikov

Суммы инвестиций и заработков тоже удивляют. Кому нужны любительские фото в таких количествах?

«Я потратил $10 млн и два года на то, что мог выяснить за 4 недели»: основатель Twenty20 об ошибках проекта
0
Sakari Sauso

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

«Азбука вкуса» и бывшая «Афиша-Еда» запустили сервис для доставки ингредиентов по рецептам журнала
0
Sakari Sauso

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

«Азбука вкуса» и бывшая «Афиша-Еда» запустили сервис для доставки ингредиентов по рецептам журнала
0
Показать еще