Зачем в 2017 году писать свой движок для мобильных игр?

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

Игровой движок для разработчика — это инструмент. Как молоток для плотника или гоночный автомобиль для пилота, инструмент влияет на успех. Конечно, не всегда. Бывает что на слабых технологиях делают шедевры, а на hight-end движках делают откровенно провальные проекты. Но «в среднем по больнице» выбор инструмента довольно значительно влияет на успех. Чтобы понять насколько, нужно понять зачем и как делаются игры.

Большая цель

Итак, зачем мы делаем игры? У всех цели разные, кто-то делает просто для удовольствия, кто-то чтобы заработать много денег. Но все же в большинстве случаев хотят заработать на игре. Рассмотрим именно то, как влияет движок на достижение этой цели. Для этого необходимо вспомнить элементарную формулу, как получаются те самые деньги, или более правильно выражаясь — прибыль.

Прибыль = Доход — Расход

Теперь рассмотрим подробно каждую составляющую и то, как движок влияет на них. А затем определим некоторые метрики, по которым кратко оценим существующие движки.

Расходы

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

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

Оплата труда = (Стоимость специалиста 1 + Стоимость специалиста 2 + ...)*Время разработки

Выглядит просто. Исходя из формулы видно что есть фактически две величины, на которые можно повлиять: стоимость специалистов и время разработки. Уменьшаем стоимость специалиста, уменьшаем время разработки — и наш проект подешевел! Но как сделать специалиста дешевле? Как заставить его работать быстрее? Ответ — правильный выбор технологии и правильная постановка работы.

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

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

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

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

Естественно, даже если снять максимум лишних задач с программиста, ему еще нужно писать код. По опыту разработки игр могу сказать, что 80% всего времени — это скучная рутина, которую нужно делать быстро и особо не заботясь о производительности. Диалоги, клиент-серверные взаимодействия, сценарии и все в таком духе. Здесь можно выделить еще одну метрику — сложность разработки игровой логики. Она описывает насколько сложна будет разработка большей части кода, те самые 80% рутины. Обычно для этого лучше всего подходят скрипты. А остальные 20% — это как раз те узкие места, в которых необходима гибкая оптимизация и настройка. Что, собственно, тоже относится к метрике гибкости.

На цену специалиста так же влияет входной порог сложности движка. Чем проще им пользоваться, тем больше специалистов, тем они дешевле и проще их найти. Однако слишком низкий порог очень часто означает ограниченность движка.

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

Доходы

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

Доход = Средний доход с пользователя*Количество пользователей

Снова две величины, на которые можно повлиять. Итак, как влияет движок на средний доход с пользователя? Здесь довольно косвенная связь, и зачастую ее вообще нет. Но мы ведь рассматриваем «среднее по больнице», поэтому отбрасывать не станем.

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

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

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

Так же производительность влияет на удержание игрока. В среднем новый игрок устанавливает игру и принимает решение об ее удалении в течение 20-30 секунд. Заставлять его ждать загрузку игры в это время не самое хорошее решение. Так же размер игры влияет на порог вхождения. Мало кто захочет скачать игру размером 200МБ на мобильном интернете. Энергозатраты в игре так же влияют. Многие игроки запускают игру на телефоне в дороге по пути домой, и если уровень заряда батареи низок, а ваша игра сильно ее тратит, игрок скорее предпочтет остаться на связи, чем играть в вашу игру. Собственно и время, которое он предпочтет провести в игре уменьшится, если он знает, что батарея устройства неминуемо сядет. Вывод из этого один — нужно стараться экономить ресурсы.

Перейдем к следующей части формулы — охват аудитории. Здесь метрики вполне понятны. Это производительность и портируемость. Чем больше платформ, тем больше устройств охвачено, а соответственно пользователей. Чем лучше производительность, тем более слабые устройства поддерживают игру и больше игроков могут запустить вашу игру. Можно понадеяться на то, что у ваших игроков в кармане новенький продукт Apple, но статистика показывает что новых устройств мало, все ходят с устаревающими «середнячками». Примерно такая же ситуация и на Android.

Предварительный итог

Теперь у нас есть примерное представление какие метрики у движков есть и как они влияют на успех игры:

• Входной порог
• Инструментарий
• Usability
• Сложность разработки игровой логики
• Гибкость
• Портируемость
• Производительность

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

Мнение ниже не следует рассматривать как 100% истину, оно составлено мной и может не отражать действительность в полной мере

Возможно пока что мало людей распробовали этот движок, но он развивается и становится лучше. В нем есть неплохой редактор all-in-one, в котором вы найдете все что нужно. Игровой код пишется на внутреннем скриптовом языке, похожим на Python. Разработчики утверждают что есть возможность оптимизировать части игры на С++, или делать дополнения для редактора.

• Входной порог
  несмотря на простоту движка он довольно высок. Во-первых, в нем собственный скриптовый движок. Во-вторых мало документации и примеров
• Инструментарий
  есть все что необходимо, а так же можно делать свои
• Usability
  здесь так же сказывается плохая документация и небольшое количество примеров. Но и в целом инструментарий оставляет впечатление непродуманности и неудобства
• Сложность разработки игровой логики
  скрипты похожи на Python, а значит писать их просто, но тем не менее язык свой, поэтому вряд ли будет просто найти какое-то решение в сети
• Гибкость
  игровая логика пишется на скриптах, исходный нативный код открыт. В теории можно сделать все что угодно, но на практике, насколько я слышал, их сложно совместить
• Портируемость
  портируется на все нужные платформы
• Производительность
  учитывая скрипты, рассчитывать на высокую производительность не стоит

Внутренний корпоративный движок от King, который они решили вывести в свет. Появился в общем доступе относительно недавно, быстро развивается сообщество. Под капотом у него, по заверению разработчиков, все максимально оптимизировано. Игровая логика пишется на LUA скриптах. Есть all-in-one редактор, но довольно ограниченный по функционалу.

• Входной порог
  довольно низкий за счет LUA скриптов и быстроразвивающегося сообщества
• Инструментарий
  есть единый редактор, но много не хватает, например анимаций, полноценной компонентной системы
• Usability
  этот движок вырос как корпоративный движок студии King, соответственно он не был изначально нацелен на широкую аудиторию. Поэтому инструменты несколько специфичны и ограничены
• Сложность разработки игровой логики
  LUA один из самых лучших скриптовых языков, весьма распространен и легко изучаем. Однако, по моему опыту, большие проекты на чистых LUA-скриптах писать затруднительно
• Гибкость
  движок довольно ограничен парадигмами, заданными создателями. Одна из них — игровая логика пишется на LUA. Хотя и есть возможность включить нативный код, упор именно на то, что игра пишется на LUA, а этот язык не позволяет делать по истине быстрые решения. Другая парадигма — вечная полная обратная совместимость. Безусловно это хорошо, что проект на первой версии движка без проблем заработает на последней. Однако таким образом необходимо поддерживать старые решения, что замедляет введение новых, а соответственно замедляет развитие
• Портируемость
  отлично портируется на все платформы. Причем даже на Web
• Производительность
  LUA очень быстрый скриптовый язык, но, тем не менее, остается скриптовым, что напрямую сказывается на производительности игрового кода. Однако остальные компоненты движка, по заверению создателей, сделаны максимально эффективно

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

• Входной порог
  очень высок. Вам потребуются настоящие специалисты в своем деле, как со стороны игрового контента, так и со стороны программистов
• Инструментарий
  набор инструментов поистине впечатляет, от редактора частиц до анимирования персонажей
• Usability
  уверен для профессионалов он супероптимален. Однако в руках непрофессионалов результат получается не очень качественным и долгим
• Сложность разработки игровой логики
  в Unreal игровая логика пишется либо на С++, либо на Blueprints. На самом деле всю игру на Blueprint'ах не напишешь, уж очень он объемный получится и запутанный, а про С++, думаю, не стоит рассказывать. По словам разработчиков все работает так: С++ программисты пишут ядро и «блоки» для Blueprint'ов, а дизайнеры из этих блоков составляют игровые механики. Уверен это отличный подход для 3D шутера, но вряд ли будет просто поместить кучу логики, например, на интерфейсы. А порой большая часть игры — это интерфейсы
• Гибкость
  архитектура и С++ дают безграничные возможности в разработке, однако опять же уклон в трехмерные проекты. Двумерные игры для создателей никогда не были в приоритете
• Портируемость
  сейчас Unreal запускается на всех мобильных платформах, однако ходят слухи о многочисленных проблемах, таких как размер приложения
• Производительность
  одни из лучших инженеров игровой индустрии разработали движок, нативный, все это говорит о том что из железа можно выжать все до последней капли

Полностью бесплатный и с открытым исходным кодом движок. Есть all-in-one редактор, документация и куча примеров. Игровая логика пишется на С++, либо на JavaScript. Очень много проектов на нем выпущено, отличительная особенность этих проектов — хорошая оптимизация. Однако при более детальном рассмотрении редактор оказывается не таким удобным как кажется на первый взгляд, находится куча недочетов в исходниках и приходится много чего доделывать.

• Входной порог
  довольно высок, ведь для качественной разработки нужно знание С++ и довольно хорошее понимание как делаются игры
• Инструментарий
  есть почти все необходимое
• Usability
  весьма сомнительное, на мой взгляд. Очень много скопировано из других технологий, но без особых раздумий почему и зачем. В конечном итоге весьма специфично и немного оторвано от реальных задач. Куча консольных утилит так же не ассоциируется с удобством
• Сложность разработки игровой логики
  в основном используются С++, но так же есть возможность использовать JavaScript. Однако использовать их вместе несколько затруднительно
• Гибкость
  открытый исходный код и С++ позволяют сделать все что угодно
• Портируемость
  все мобильные платформы
• Производительность
  из-за своей простоты и гибкости позволяет достичь очень хороших результатов

Game maker/Construct и похожие

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

• Входной порог
  минимален
• Инструментарий
  есть все необходимое для создания небольших или простых игр. Удобнее всего на них делать игры в стиле pixel-art
• Usability
  стоит посмотреть редактор Game Maker 2! Пожалуй лучшее решение для движка данной категории. Очень продумано и рассчитано на целевую аудиторию
• Сложность разработки игровой логики
  либо элементарный скрипт, либо вообще отсутствие скриптов. Вместо скриптов применяется система реакция-действие, в которой описывается все игровое взаимодействие
• Гибкость
  очень ограниченный функционал, но для простых игр хватает
• Портируемость
  все мобильные платформы
• Производительность
  естественно парадигма разработки таких простых проектов требует много дополнительных ресурсов. Как правило разработчики уходят с таких движков в более низкоуровневые именно столкнувшись с плохой производительностью

Самый распространенный в наши дни движок. И этому есть причина — он очень удобный. Великолепный редактор, практически неограниченные возможности, 2D, 3D графика, все что захочется. И конечно же C#, с которым разработка идет довольно легко. Однако у него тоже есть скелеты в шкафу. Зачастую производительность оставляет желать лучшего. Согласен, если приложить усилия, то можно сделать многое, но цена за это высока. Кроме этого порой непонятны планы разработчиков на развитие движка. Самые нужные вещи остаются на дне roadmap, но в новых и новых версиях появляется то, что отлично звучит на продающей странице, но в разработке далеко не всем нужно.

• Входной порог
  очень низкий. Вашу первую игру вы сделаете через пару-тройку туториалов. Огромное сообщество, куча доступных решений
• Инструментарий
  есть абсолютно все, некоторое даже излишне на большинстве проектов. А если нет нужного в движке, наверняка найдется в магазине
• Usability
  это самый большой плюс движка. Отличные инструменты ускоряют разработку в разы. Однако, при более глубоком использовании всплывают недостатки, например: местами не очевидная логика работы UI, не очень хорошо продуманные анимации. Некоторые вещи очень долго просят пользователи, но разработчики все никак не сделают. В целом, для разработки мобильных игр — лучшее что можно найти
• Сложность разработки игровой логики
  C#, хоть и несколько специфичный в Unity, очень удобный язык. Очень часто слышу от С++ программистов мнение, что это «глоток свежего воздуха». По личному опыту хочу отметить, что разработка на C# в разы быстрее чем на C++
• Гибкость
  очень гибкие инструменты и архитектура движка в целом. Однако, во многих вещах остается недоступен для изменения. Закрытый код дает некий эффект черного ящика, на который зачастую невозможно повлиять. Есть свобода для оптимизаций, но тонкие оптимизации не получится сделать в следствие своей закрытости.
• Портируемость
  портируется на все что возможно, ходят слухи скоро на пылесосах можно будет запустить
• Производительность
  в целом движок очень хорошо оптимизирован, и на нем при должном усердии можно сделать производительную игру. Однако, C# довольно сильно ограничивает. Порой над C# кодом думаешь гораздо больше о его производительности, чем над С++. И как правило в игре находится место, где производительность проседает. В таких случаях очень много ресурсов уходит на оптимизацию. Так же почти всегда возникают проблемы с производительностью, связанные с UI. Сложные диалоги, длинные списки без оптимизаций довольно сильно нагружают систему.

Собственные движки, С++

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

• Входной порог
  очень высок, документации нет, единственный способ узнать как все работает через коллег
• Инструментарий
  как правило в таких движках инструментов либо нет, либо есть элементарные редакторы, удовлетворяющие каким-то специфичным нуждам. Именно на таких движках как правило все делают программисты. Ведь обычному дизайнеру крайне сложно понять все эти технические дебри
• Usability
  даже если и есть инструменты, то они работают откровенно плохо. Оно и понятно, ведь такие движки пишут чтобы сделать игру, а игру нужно сделать побыстрее, отсюда низкое качество инструментов, куча багов, консольных утилит и вот всего этого. Но даже если есть какие-то инструменты, они написаны программистами без учета того, что ими будут пользоваться не программисты, в итоге редактор эффектов превращается в панель запуска космического шаттла, а не в красивый интерфейс с тремя кнопочками.
• Сложность разработки игровой логики
  начинать с такими движками очень тяжело, ведь сначала нужно понять его устройство, все его хаки и грабли. Но затем это играет лишь на руку. Как правило такие движки делаются с уклоном под игру, на которых они делаются, поэтому со временем писать код все легче и легче. Особенно если прикручен какой-нибудь скриптовый язык.
• Гибкость
  собственно самое главное преимущество таких движков. Разработчик ограничен лишь самим собой, он может делать все что угодно.
• Портируемость
  как правило такие движки портированы лишь на те платформы, на которых выходит игра. Оно и понятно, зачем тратить время на поддержку платформы, если не планируется на ней выпускать игру. Однако с опытом мною замечено, что в таких движках операции с платформами очень неповоротливы, сборки очень сложны и длительны
• Производительность
  очевидно те, кто в состоянии написать свой движок, довольно хорошо разбираются в своей теме. При этом никаких ограничений нет. Соответственно можно сделать все что угодно в угоду производительности и достичь идеального результата.

Так все же, зачем нужен еще один?

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

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

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

Верхний уровень то же должен быть достаточно продуманным, чтобы хорошо выполнять свою функцию. Многие разработчики In-house движков здесь делают одну и ту же ошибку, они собирают разные технологии вместе и строят связи между ними. Однако, как показывает практика, это ведет к тому что они плохо взаимодействуют. Более конкретный пример: импорт анимаций из стороннего редактора и эффекты частиц из другого. Как только становится необходимым использовать эффект в анимации, начинаются проблемы. В редакторе анимаций частицы не проигрываются и наоборот. Соответственно конечный результат достигается дизайнером довольно тяжело. Поэтому все должно быть в одной системе, чтобы дизайнер мог анимировать, накладывать звук, эффекты и все сразу, в одном месте.

Однако, идеал можно описывать в красках долго, поэтому вернемся к конкретике и разберем по порядку по нашим метрикам:

• Входной порог
  как можно более низкий. Система, где «верхний» уровень держится на «нижнем», полностью дает возможность снизить входной порог, при этом не ограничивая в гибкости
• Инструментарий
  должно быть все самое необходимое: работа с ресурсами, графикой, анимациями, интерфейсами, эффектами, физикой, грамотная компоновка сцены. В идеале это все должно быть в одной системе, чтобы каждый из компонентов идеально подходил друг к другу
• Usability
  каждый инструмент должен быть продуман со стороны реального использования. Недостаточно просто сделать редактор частиц, интерфейсов или анимаций. Все это должно быть понятно и удобно именно тем, кто специализируется на этом
• Сложность разработки игровой логики
  как и описано выше, высокоуровневые компоненты должны базироваться на низкоуровневых. Например, все затратные и низкоуровневые вещи делаются нативным кодом, те самые 20% сложных процентов. Остальные 80% можно переложить на скрипты, которые гораздо быстрее писать, но при этом их производительность не критична. Благо в наши дни встраиваемых скриптов много
• Гибкость
  движок должен быть полностью изменяемым и дополняемым. Единственный правильный путь к этому — это хорошее API и открытый исходный код
• Портируемость
  так как речь идет в основном о мобильной разработке, приложения на движке должны без труда портироваться на все мобильные платформы. Кроме мобильных платформ сейчас становится все более привлекательна web-платформа. С развитием WebAssembly и графики в браузерах становится все реальнее и реальнее запускать нативные игры в браузере и на мобильных платформах
• Производительность
  сама технология должна предоставлять максимально оптимизированные компоненты — интерфейс, анимации, эффекты и так далее. Чтобы при невдумчивом наполнении игры контентом все было более-менее приемлимо в плане оптимальности. Но так же стоит оставить возможность для тонкой оптимизации, которая понадобится для доведения продукта до идеала

Итог

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

Автор: Зенкович Андрей

Источник