В прошлой статье в рамках совместного проекта dev.by и компании Playtika мы упомянули о том, что в 2012 году для создания одного из крупнейших в мире мобильных приложений для социальных слотов компания решила написать собственный движок — Monosyne. Сегодня мы разберём, почему этот шаг был обоснован, и произошли ли какие-нибудь изменения в «стакане» мобильных движков на C#, который 4 года назад «скорее наполовину отсутствовал, чем был пуст».

Читать далее

Чуть больше, чем ничего

Выбирая язык для игры, менеджеры Playtika остановились, напомним, на C#. Кроме C#, ключевыми требованиями к движку были также кроссплатформенность, возможность работы с 2D и приемлемая производительность на мобильных гаджетах. С учётом этого выбор свёлся лишь к четырём вариантам: Unity, MonoGame, DeltaEngine и Axiom (Paradox, позже переименованный в Xenko, тогда находился в зачаточном состоянии).

По признанию инженера-программиста Playtika Антона Лобанова, одного из разработчиков Monosyne, серьёзно в итоге рассматривались только два движка: Unity и MonoGame. DeltaEngine и Axiom же остались за бортом из-за своей «заточенности» под 3D. О том, что весы склонились в пользу собственного решения, вы уже знаете. Ну, а чем специалистов Playtika не устроили Unityи MonoGame, мы сейчас и расскажем.

Unity: годный редактор, медлительность и закрытый код

Главными плюсами Unity для Playtika стали кроссплатформенность и приличный редактор. Жирных минусов, впрочем, оказалось значительно больше, и если бы не хорошее исполнение редактора, то даже у Unity не было бы шансов лечь в основу новой игры.

С 2012 года Unity успел сделать несколько шагов навстречу 2D, обзавевшись кое-каким набором соответствующих инструментов. В этом году разработчики движка даже обещали представить свежий 2D-модуль с редактором. Но несколько лет назад Unity всё-таки был ориентирован строго на 3D, из чего, естественно, для Playtika вытекал целый ряд различных нюансов.

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

Разработчики Playtika отмечают, что одна из основных проблем производительности движков на C++, в частности Unity, использующих C# как скриптовый язык, — Interop (механизм для вызова из С# нативного кода и обратно). В итоге приходится «гонять» данные между управляемым кодом и нативным. В то же время, протестировав производительность математических операций в C# для чисел с плавающей точкой, в компании пришли к выводу, что она схожа с производительностью C++.

В итоге было решено писать все основные части движка на C# кроме совсем уж критических в плане производительности библиотек — для декодирования аудио и видео, разархивирования сжатых файлов и т.п. Также были использованы сторонние библиотеки на C++ для растеризации TTF-шрифтов. То есть third-party-инструменты не на C# задействовали только для того, что вызывается в игре редко — скажем, раз в кадр или вообще один раз, при загрузке уровня

В Monosyne все расчёты происходят в C#, нативный код C++ вызывается редко, и выигрыш в производительности при одновременной трансформации, скажем, 5000 объектов по сравнению с Unity получился в 5-6 раз. Создание объектов в собственном решении Playtika также происходит значительно быстрей. Всё это причина довольного медленного Interop’а.

«В первой рабочей версии движка iPod Touch 4 обрабатывал на 60 FPS около 300 игровых объектов — полностью трансформируемых и лежащих в сцен-графе. Это было ещё до всех наших оптимизаций, до оптимизаций Xamarin и до того, как они включили новый компилятор LLVM. Сейчас тот же iPod Touch 4 обрабатывает и визуализирует 3600 игровых объектов — это на уровне движков на C++. Кстати, во многих движках есть свой язык шейдеров, который абстрагирует от конкретного языка графического бэкенда. Мы же пишем шейдеры на GLSL и HLSL раздельно, что позволяет добиться максимальной оптимизации. Плюс мы сразу заложили хорошую систему Auto-Batching», — делится достижениями Антон Лобанов.

Ещё пара претензий к Unity были связаны непосредственно с кодом. Во-первых, его разработчики поддерживали только второй .NET, в котором отсутствуют значительно упрощающие разработку async, await и т.п. Playtika же работает с .NET 4.5.2, где всё это имеется, и более свежей версией C#. А во-вторых, из-за закрытости кода Unity оперативно решать проблемы с багами и прочими неприятностями невозможно.

Кстати, Антону закрытость кода Unity пришлась не по душе не только из-за трудностей с баг-фиксингом: «Мне не нравится, что в Unity, по сути, всё делается в редакторе, а потом ты просто всё это скриптуешь, подключая несложную логику. Этого оказалось мало для создания игры с уймой кастомных вещей. Конечно, позже разработчики Unity вынесли low-level graphics API — и его уже можно было вызывать из скриптов. Но мне кажется, что гораздо удобнее иметь свободный доступ к движку и использовать любой его уровень. То есть там, где не нужна высокая производительность, ты обращаешься к высокоуровневому API, высокоуровневым объектам и т.п., а там, где нужна, можешь использовать низкоуровневый API, написать кастомный рендер и т.д.».

И ещё один важный, во многом определяющий момент. В проекте Playtika было очень много видео с альфа-каналом (если точнее, разработчики называют это VideoSprite), которое нужно было проигрывать в текстуру в любом месте, в любое время и с любой трансформацией. В то время как многие делают спрайтовую анимацию, то есть рисуют покадрово спрайты, в Playtika рисовали покадрово видео с преобразованием YUVA в RGBA в пиксельном шейдере. В 2012 году разработчики понимали, что вряд ли смогут быстро написать движок, который позволил бы создавать такие продвинутые анимации, как сейчас, поэтому, собственно, и прибегли именно к VideoSprite. Ну, а Unity работать с видео с альфа-каналом не умеет до сих пор.

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

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

MonoGame: мало и плохо

Вторым главным кандидатом на подходящий для новой игры движок был MonoGame — порт Microsoft XNA на ещё довольно сырой Xamarin. Кроме общих для решений того времени проблем — отсутствия масок, которые формируются из 2D-изображения (любая форма, любая трансформация), и внятной работы с видео, специалисты указывают ещё на целый ворох негативных нюансов.

В общем-то, внутри архитектуры MonoGame находился API XNA — подход, послуживший основой для Monosyne. Но реализация разработчикам Playtika совершенно не понравилась. Да и MonoGame практически полностью повторял API XNA, и разработчики поняли: этого недостаточно — однозначно придётся очень многое менять и «допиливать». Ведь нужно было портировать игру с Flash, поэтому требовалось, чтобы все возможности Flash были и в задействованном решении.

Более того, в MonoGame не было почти ничего для новой игры: ни высокоуровневых спрайт-объектов и высокоуровневого API в целом, ни чего-либо касательно сцен (включая сцен-граф). Менеджер для загрузки asset’ов, спрайтов, эффектов, mesh’ей, модели, sprite batch’и — и, по большому счёту, всё. По своей сути MonoGame — низкоуровневое решение, и над ним пришлось бы самостоятельно надстраивать огромное количество инструментов.

Чтобы написать «свой MonoGame», Playtika понадобилось всего около 4 месяцев. А через 2 месяца после старта разработки в компании уже начали разрабатывать первую игру на Monosyne.

По словам Антона Лобанова, несмотря на открытость кода MonoGame, устранять баги в нём очень неудобно. Мало того что код сам по себе трудноподдерживаемый и напичкан #ifdef, так ещё и отличается рядом платформенных нюансов. Вместе с тем, разработчик Playtika отмечает, что изучение работы с C# в MonoGame помогло сделать их собственный движок лучше.

А воз и ныне там

Словом, решение написать собственный движок было более чем обоснованным. Тем более что Monosyne был использован далеко не в одной игре — на нём базируются Caesars Slots, Slotomania, Vegas Downtown Slots, Wild Luck Casino и Slotomania Sunrise с суммарной аудиторией в десятки миллионов человек.

При этом Playtika не остановилась на достигнутом. Совершенствование Monosyne не прекращается. Теперь движок умеет работать и с mesh’ами, и с particle’ами, и со скелетной анимацией, и со светом, и много с чем ещё. Monosyne уже поддерживает iOS, Android, Windows Phone 8 и 10, а также десктопную Windows, а в скором времени его планируется адаптировать для веба, Mac OS, Xbox One и PlayStation 4. Среди других амбициозных планов — создание собственного редактора и реализация 3D без ущерба производительности 2D.

Подробнее об особенностях создания Monosyne, его сильных и слабых сторонах и перспективах разработчики собственного движка Playtika расскажут в следующей публикации проекта.

Подытоживая, после 2012 года ситуация с движками на C# в целом улучшилась. Среди доступных на сегодня решений можно выделить Xenko — бывший Paradox. Другое дело, что почти все из «шарповых» движков, в том числе упомянутый Xenko, предназначены для 3D-проектов. А вот если вам понадобится 2D-движок на C#, то выбор у вас всё ещё будет совсем невелик.

Также читайте в проекте: 

Как крупнейший разработчик социальных казино вырос в 15 раз за 5 лет
Логирование как главный инструмент техподдержки
Как мы писали одну из крупнейших платформ для слот-машин