- PVSM.RU - https://www.pvsm.ru -
В наши дни существует много игровых движков. Двумерные, трехмерные, нативные и на скриптах. На первый взгляд уже сделано все что нужно и можно просто делать игру. Однако по статистике около половины из топ 100 мобильных игр сделаны на своих движках. Почему многие крупные студии делают проекты исключительно на своих технологиях? Что их не устраивает в тех движках, что сейчас есть? Чтобы ответить на этот вопрос нужно понять зачем нужен движок, какие они вообще бывают и чем отличаются.
Игровой движок для разработчика — это инструмент. Как молоток для плотника или гоночный автомобиль для пилота, инструмент влияет на успех. Конечно, не всегда. Бывает что на слабых технологиях делают шедевры, а на hight-end движках делают откровенно провальные проекты. Но «в среднем по больнице» выбор инструмента довольно значительно влияет на успех. Чтобы понять насколько, нужно понять зачем и как делаются игры.
Итак, зачем мы делаем игры? У всех цели разные, кто-то делает просто для удовольствия, кто-то чтобы заработать много денег. Но все же в большинстве случаев хотят заработать на игре. Рассмотрим именно то, как влияет движок на достижение этой цели. Для этого необходимо вспомнить элементарную формулу, как получаются те самые деньги, или более правильно выражаясь — прибыль.
Прибыль = Доход — Расход
Теперь рассмотрим подробно каждую составляющую и то, как движок влияет на них. А затем определим некоторые метрики, по которым кратко оценим существующие движки.
Любые разработчики стремятся уменьшить эти расходы. Для маленьких разработчиков расходы могут стать фатальными, и проект даже не увидит свет. Большие разработчики так же заинтересованы в уменьшении расходов, ведь так можно сделать быстрее проект, проверить его, выйти на рынок раньше других или просто попробовать гораздо больше идей за те же деньги.
Разберем расходы на разработку подробнее. В них входит много вещей, таких как маркетинг, оплата оборудования, оплата труда и так далее. В разных проектах по-разному, но как правило оплата труда составляет одну из самых больших статей бюджета проекта. Как влияет движок на стоимость разработки? Снова небольшая формула:
Оплата труда = (Стоимость специалиста 1 + Стоимость специалиста 2 + ...)*Время разработки
Выглядит просто. Исходя из формулы видно что есть фактически две величины, на которые можно повлиять: стоимость специалистов и время разработки. Уменьшаем стоимость специалиста, уменьшаем время разработки — и наш проект подешевел! Но как сделать специалиста дешевле? Как заставить его работать быстрее? Ответ — правильный выбор технологии и правильная постановка работы.
Правильный набор инструментов позволяет найти подходящего специалиста для определенной работы. В идеале художник рисует, программист пишет код, верстальщик верстает, аниматор анимирует, технический дизайнер настраивает контент, в общем, каждый занят своим делом. Однако, в реальности очень часто бывает что программисты заняты всем — версткой, анимацией, настройкой ресурсов. И даже не потому что это некому делать, а потому что только он может собрать интерфейс и заанимировать его через код. Для определенных работ все же необходим специфичный инструментарий.
Отсюда первая метрика движка — инструментарий. Наличие инструментов позволяет нанять соответствующего специалиста, который будет лучше и быстрее справляться со своей работой. Естественно для разных игр необходимы совершенно разные инструменты, но есть общие, которые необходимы для всех: настройщики ресурсов, анимации, эффекты, графика, физика, звук, интерфейсы. Все это можно делать кодом, но, как показывает практика, это довольно не эффективно.
Помимо общих инструментов почти в каждой игре есть какая-то специфика, требующая специальных инструментов, например редактор уровней или редактор конфигураций игровых объектов. Здесь можно выделить такую метрику как гибкость движка — это возможность подстроить его под свои специфичные нужды с минимальными затратами.
Далее, время разработки. Предлагаю разложить его на две составляющие: время произведения операции и количество повторений. Рассмотрим на примере интерфейсов. Если у вас есть специальный редактор интерфейса, то верстка в нем будет гораздо быстрее, чем в текстовом файле или в коде. Соответственно время на операцию верстки будет меньше. Если есть возможность работать с шаблонами, то количество однотипных операций будет меньше. Проще говоря, чем проще, удобнее и продуманнее инструмент, тем быстрее будет проходить разработка. И это уже следующая метрика — удобство инструментария или usiability, как это чаще называют. Здесь многие могут заметить, что во многих инди-командах нет специализированных людей и все равно все делает программист. Которому удобнее писать код. Тема довольно спорная, но я видел кучу примеров, когда те же программисты делают контент гораздо лучше и быстрее в специальных редакторах, чем с помощью кода.
Естественно, даже если снять максимум лишних задач с программиста, ему еще нужно писать код. По опыту разработки игр могу сказать, что 80% всего времени — это скучная рутина, которую нужно делать быстро и особо не заботясь о производительности. Диалоги, клиент-серверные взаимодействия, сценарии и все в таком духе. Здесь можно выделить еще одну метрику — сложность разработки игровой логики. Она описывает насколько сложна будет разработка большей части кода, те самые 80% рутины. Обычно для этого лучше всего подходят скрипты. А остальные 20% — это как раз те узкие места, в которых необходима гибкая оптимизация и настройка. Что, собственно, тоже относится к метрике гибкости.
На цену специалиста так же влияет входной порог сложности движка. Чем проще им пользоваться, тем больше специалистов, тем они дешевле и проще их найти. Однако слишком низкий порог очень часто означает ограниченность движка.
Так же ко времени разработки можно отнести такую метрику как портируемость — возможность применять одно и то же решение на разных платформах, вместо реализации на каждой отдельно. Если делать игру на несколько платформ сразу, временные затраты уменьшаются пропорционально количеству охваченных платформ.
Здесь все не так очевидно как с расходами. Для начала рассмотрим из чего складывается доход от игры. И снова формула, очень упрощенная, но в большей мере отражает результат:
Доход = Средний доход с пользователя*Количество пользователей
Снова две величины, на которые можно повлиять. Итак, как влияет движок на средний доход с пользователя? Здесь довольно косвенная связь, и зачастую ее вообще нет. Но мы ведь рассматриваем «среднее по больнице», поэтому отбрасывать не станем.
Существует много факторов, из которых складывается этот доход: вовлеченность игрока, интересность игры, необходимость платить за продвижение, возможность платить, время провождения в игре и так далее. Факторов очень много, они всегда разные, хотя бы примерно сказать о величине дохода очень сложно и мало кто умеет это хорошо делать.
Одним из факторов, влияющих на успех и доходность игры, является ее качество. Красивый арт, плавные анимации, хорошие эффекты, интересный геймплей — все это влияет на мнение игрока, на его желание остаться в игре. А на это уже непосредственно влияет движок. Мы уже рассмотрели, что инструментарий необходим для эффективной разработки, но так же необходим для разработки качественного контента. Красивые анимации, интерфейсы, эффекты, сцены: все это сложно сделать без хороших инструментов. Плохой инструмент — это как велосипед с овальными колесами, на котором уехать куда-то довольно сложно. Однако, довольно часто разработчики ездят на таких велосипедах: программист лепит несуразные анимации на своих любимых синусах и косинусах, дизайнер верстает уровень в текстовом файле и так далее. Все это не приводит к качественному результату. Поэтому инструментарий важен.
Кроме инструментов на качество влияет производительность движка. Пусть в игре отличный контент, красивый арт и классные эффекты, но все это улетучивается когда игра начинает тормозить. Игроку не комфортно играть, интерфейс становится неотзывчивым, анимации не производят должного эффекта. Так же производительность влияет на то, каким богатым будет наполнение в игре. При не оптимальном подходе мы можем показать N спрайтов и X анимаций, а с оптимизированным движком мы можем показать больше. Не всегда это производит нужный эффект и порой излишне, но это дает большую свободу действий, больше возможностей реализовать свои идеи.
Так же производительность влияет на удержание игрока. В среднем новый игрок устанавливает игру и принимает решение об ее удалении в течение 20-30 секунд. Заставлять его ждать загрузку игры в это время не самое хорошее решение. Так же размер игры влияет на порог вхождения. Мало кто захочет скачать игру размером 200МБ на мобильном интернете. Энергозатраты в игре так же влияют. Многие игроки запускают игру на телефоне в дороге по пути домой, и если уровень заряда батареи низок, а ваша игра сильно ее тратит, игрок скорее предпочтет остаться на связи, чем играть в вашу игру. Собственно и время, которое он предпочтет провести в игре уменьшится, если он знает, что батарея устройства неминуемо сядет. Вывод из этого один — нужно стараться экономить ресурсы.
Перейдем к следующей части формулы — охват аудитории. Здесь метрики вполне понятны. Это производительность и портируемость. Чем больше платформ, тем больше устройств охвачено, а соответственно пользователей. Чем лучше производительность, тем более слабые устройства поддерживают игру и больше игроков могут запустить вашу игру. Можно понадеяться на то, что у ваших игроков в кармане новенький продукт Apple, но статистика показывает что новых устройств мало, все ходят с устаревающими «середнячками». Примерно такая же ситуация и на Android.
Теперь у нас есть примерное представление какие метрики у движков есть и как они влияют на успех игры:
Исходя из этого списка оценим существующие движки. Предлагаю рассмотреть лишь самые значимые, опираясь на статистику, собранную Unity3D, с несколькими моими дополнениями.
Мнение ниже не следует рассматривать как 100% истину, оно составлено мной и может не отражать действительность в полной мере
Возможно пока что мало людей распробовали этот движок, но он развивается и становится лучше. В нем есть неплохой редактор all-in-one, в котором вы найдете все что нужно. Игровой код пишется на внутреннем скриптовом языке, похожим на Python. Разработчики утверждают что есть возможность оптимизировать части игры на С++, или делать дополнения для редактора.
Внутренний корпоративный движок от King, который они решили вывести в свет. Появился в общем доступе относительно недавно, быстро развивается сообщество. Под капотом у него, по заверению разработчиков, все максимально оптимизировано. Игровая логика пишется на LUA скриптах. Есть all-in-one редактор, но довольно ограниченный по функционалу.
Профессиональный игровой движок на пике технологий. Отличная картинка, производительность, инструмент для настоящих профессионалов. Однако в мобильной разработке применять его сложно. Все же он больше рассчитан на трехмерные AAA игры. Делать мобильные 2D игры на нем — это как из пушки по воробьям.
Полностью бесплатный и с открытым исходным кодом движок. Есть all-in-one редактор, документация и куча примеров. Игровая логика пишется на С++, либо на JavaScript. Очень много проектов на нем выпущено, отличительная особенность этих проектов — хорошая оптимизация. Однако при более детальном рассмотрении редактор оказывается не таким удобным как кажется на первый взгляд, находится куча недочетов в исходниках и приходится много чего доделывать.
Движки такого рода создавались для того, чтобы любой человек мог сделать свою игру, без каких-либо знаний о разработке. Все максимально просто и понятно, с этим эти движки справляются великолепно. Однако для крупных или даже средних проектов они плохо подходят.
Самый распространенный в наши дни движок. И этому есть причина — он очень удобный. Великолепный редактор, практически неограниченные возможности, 2D, 3D графика, все что захочется. И конечно же C#, с которым разработка идет довольно легко. Однако у него тоже есть скелеты в шкафу. Зачастую производительность оставляет желать лучшего. Согласен, если приложить усилия, то можно сделать многое, но цена за это высока. Кроме этого порой непонятны планы разработчиков на развитие движка. Самые нужные вещи остаются на дне roadmap, но в новых и новых версиях появляется то, что отлично звучит на продающей странице, но в разработке далеко не всем нужно.
Выбор либо крупных студий, либо безумцев. Для этого нужны крутые специалисты, а их мало и стоят они дорого. А в итоге получается франкинштейн из технологий, который то и дело разваливается. Получается очень неправильно поставленная разработка, чаще всего именно те дорогие программисты делают все. Но зато получается самый идеальный продукт. Все что захотели дизайнеры — реализовано, работает максимально плавно и запускается на древних устройствах. Но цена за такую технологию велика.
По краткому описанию тех что выше становится ясно, что нет такого решения, которое удовлетворит всем нуждам. У каждого из них есть какие-то недостатки, будь то удобство или производительность. Давайте попробуем представить тот самый идеал, который удовлетворит все наши нужны, окажется той самой «серебряной пулей».
Очевидно он должен сочетать в себе качества, которые очень сложно совместить. Он должен быть простым, но в тоже время гибким. Это можно решить построив систему, где верхнеуровневые компоненты базируются на низкоуровневых. Например, есть какой-то очень гибкий низкоуровневый фреймворк, а поверх него какие-то верхнеуровневые вещи типа редактора и скриптов. То есть верхний уровень дает удобство и предназначен для большинства задач, а к нижнему можно прибегнуть в поисках более эффективных решений.
Причем низкий уровень должен быть действительно низким, а не просто предоставлять хорошее API. Здесь должно быть все максимально прозрачно для разработчика. Если есть хоть небольшой эффект черного ящика — разработчик не сможет абсолютно контролировать систему, а соответственно достичь максимального результата. Единственный путь к этому, на мой взгляд, это открытый исходный код.
Верхний уровень то же должен быть достаточно продуманным, чтобы хорошо выполнять свою функцию. Многие разработчики In-house движков здесь делают одну и ту же ошибку, они собирают разные технологии вместе и строят связи между ними. Однако, как показывает практика, это ведет к тому что они плохо взаимодействуют. Более конкретный пример: импорт анимаций из стороннего редактора и эффекты частиц из другого. Как только становится необходимым использовать эффект в анимации, начинаются проблемы. В редакторе анимаций частицы не проигрываются и наоборот. Соответственно конечный результат достигается дизайнером довольно тяжело. Поэтому все должно быть в одной системе, чтобы дизайнер мог анимировать, накладывать звук, эффекты и все сразу, в одном месте.
Однако, идеал можно описывать в красках долго, поэтому вернемся к конкретике и разберем по порядку по нашим метрикам:
В конечном счете в наши дни еще может появиться движок, который будет лучше. Но это мнение лишь одного, меня. Хоть и опыт разработки на разных движках дает мне представление о том инструменте, который я бы считал идеальным, хотелось бы узнать мнение других на этот счет. Думаю будет многим интересно, если кто-нибудь еще в комментариях напишет свое мнение о каком-то движке. Возможно даже будет полезно тем, кто еще выбирает движок, на котором хочет сделать игру.
Автор: Зенкович Андрей
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/dvizhok/264536
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/338214/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.