Comments 24
Игровой движок, как и любой другой инструмент, нужно выбирать исходя из задач продукта и навыков-знаний команды. Потребовалось что-то необычное или команда не смогла использовать, доработать купленный движок (странно почему, но такое тоже бывает) — прямой путь к разработке своего (или скорее гибели проекта).
Поэтому опрос несколько некорректен. Например, для простых 2D игр и мизерной команды (или одиночки) я с удовольствием возьму Corona SDK. Но 3D на ней я не сделаю, и тут уже будем выбирать серьёзней по планируемым задачам.
Статья большая, странная…
Есть пример реально неправильного выбора движка. Компьютерная игра Xenonauts (описание на хабре). Разработка бодренько стартовала, использовался движок, который хорошо знал один из программистов...
Выбор движка был самых худшим решением, которое мы когда-либо принимали. Playground SDK 5 — это двухмерный движок, сконструированный для казуальных браузерных игр вроде Diner Dash. Он не поддерживается разработчиками, его исходные коды не доступны и его даже нельзя больше скачать.
Я с трудом подбираю выражения для его описания. В нем есть несколько серьезных ошибок и отсутствуют несколько ключевых возможностей, которые считаются стандартным во всех остальных движках и мы не можем исправить их или добавить, не имея исходных кодов. Почти все плохо выглядящее или плохо сделанное в Xenonauts скорее всего стало таким именно из-за недостатков движка.
Движок был выбран программистом, который первым (и очень недолго) работал над проектом. Это было ужасное решение. Если бы мы правильно занимались планирование и прототипированием, то быстро бы перешли на другой движок, так как Playground SDK просто не подходил для игры вроде Xenonauts. Вместо этого мы выбрали плохую основу и следующие пять лет мучились, строя игру поверх нее.
Также автор говорит, что скопировано много технологий, хотя по факту — это до третьей версии это довольно большое легаси как следствие переноса кода Obj-C на C++ для того чтобы можно было писать кроссплатформенные приложения, а не только для iOS как в случае исходного cococs2d. Теперь там есть поддержка четырех основных мобильных платформ — iOS, Android, Windows Phone (вроде поддежку прекратили), Tizen — и основных десктопных платформ — Windows, Linux. Сейчас впиливают поддержку еще и VR и аналоговых способов ввода, параллельно выпиливая куски наследия.
Судя по комментариям нашего разработчика китайцы, ответственные за разработку не очень хорошо разбираются в OpenGL и имеется немало способов оптимизировать внутренности как рендера, так и управления памятью приложений.
Инструментарий для кокоса — таки довольно большая проблема. Тот редактор что сейчас пытаются делать пока еще довольно сырой и что-то большое писать на нем не слишком удобно. Есть всякие Marmelade которые оборачиваются вокруг кокоса и добавляют фишки вроде LiveReload при использовании Lua. Но что-то действительно комплексное в таких SDK написать довольно проблемно. Старые инструменты вроде CocosBuilder медленные, плохо написанные и уже давно не развиваются. Так что «почти все необходимое» в большинстве случае превращается в «отсутвует».
Короче это такой jack-of-all-trades в игровой МОБИЛЬНОЙ разработке.
Unity3D плохо подходит большим командам с длительной разработкой проектов, потому как нужно оплачивать подписку на каждое рабочее место. И для мобильных 2D-проектов он избыточен.
1. CryEngine — мощный, бесплатный, опенсорс движек (скриптинг С++, С#).
2. Urho3D — тоже крутой с редактором и опенсорс (скриптинг AngelScript, Lua, C++).
3. Xenko — с хорошим фичасетом (на вид очень продвинутый и много обещающий) проприетарный, платный (есть бесплатная версия), возможность получить исходники (скриптинг C#).
Зачем в 2017 году писать свой движок для мобильных игр?