Пять проблем при разработке мобильных free-to-play игр

Не секрет, что в последнее время кроссплатформенные мобильные free-to-play игры стали основным направлением деятельности большого числа игровых компаний. В этой статье мы не будем говорить ни о причинах, которые к этому привели, ни о перспективах данного направления. Компании изменили свои бизнес-модели, начертили схемы монетизации и игровых циклов, помолились на SCRUM и Agile, однако в статье речь пойдет и не про это. Игры по-прежнему нужно делать качественно, нужно правильно выбирать технологии, нужно понимать, что ждать от загадочного free-to-play и с чем придется столкнуться. В этой статье мы рассмотрим 5 наиболее важных технологических проблем, возникающих при создании кроссплатформенных мобильных free-to-play игр.

1. Кроссплатформенность

Мысль о создании приложений, способных работать на нескольких платформах сразу, далеко не нова. Для этих целей была создана платформа Java, Microsoft пытался решить проблему разработки под Windows, Xbox и Windows Mobile 7 при помощи .NET и XNA. Была создана Mono, и .NET вышел за пределы, очерченные Редмондом. В общем, копья ломались, кроссплатформенность в каком-то виде появлялась. Однако, реалии таковы, что мобильные free-to-play игры необходимо запускать одновременно на iOS, Android и, совсем идеально, на Facebook.

Проблема в том, что под iOS особо на Java не попишешь, а для приложений для Facebook нужен Adobe Flash. К счастью, обозначенные платформы объединяет язык C++ (не все, наверное, знают, но существует компилятор FlasCC под Flash). Идея проста – игра пишется на C++ и делается обвязка на языке, специфичном для платформы. Таким образом, код на C++ без особых изменений переходит с платформы на платформу. Разница между платформами может нивелироваться игровым движком, как делается в случае Alawar Engine или Marmalade SDK.

Хорошим вариантов является использование Unity. Несмотря на то, что основной язык в Unity – C#, благодаря Mono он может исполняться и на iOS и на Android. Однако в этом случае о Flash можно забыть. Можно еще вспомнить про HTML 5 и PhoneGap, однако в этой платформе до сих пор есть ряд проблем, в частности с производительностью на мобильных устройствах.

Еще одним камнем преткновения в кроссплатформенной разработке является использование сторонних библиотек и SDK. Многие библиотеки, такие как Facebook SDK, Flurry, разрабатываются под каждую платформу в отдельности. А так как эти библиотеки могут быть тесно связаны с кодом игры, и написать общий интерфейс для них и добавить в движок не всегда удается, то приходится создавать код вида

#if defined(_ANDROID_PLATFORM) // put your Android code here #elif defined(_IOS_PLATFORM) // put your iOS code here #endif 

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

2. Размер дистрибутива

Разработчики игр, особенно перешедшие на мобильных платформы с десктопных, часто не задумываются о размере получившегося на выходе дистрибутива. Редкая игра под PC последних лет занимает меньше 4Гб. Не вызывает большого приступа ненависти и то, что популярная MMORPG это 20Гб+. Тенденцию не останавливает даже то, что дистрибьюция игр практически полностью стала цифровой. Однако в мобильном free-to-play все кардинально иначе.

Проблема в том, что Google Play и App Store ограничивают размер дистрибутива игры, который может быть выкачен через мобильные сети. У вас есть примерно 50Мб. Игры, которые занимают больший размер, разрешается выкачивать только через сети Wi-Fi. Интересно, что есть такие страны, в которых основная масса населения «сидит» на 3G, и результаты распространения вашей игры в этих странах по понятным причинам будут неутешительными.

Для преодоления этого препятствия многие разработчики идут на хитрость, выкладывая основную часть контента игры на собственных серверах. Игра, которая в магазине занимала всего 10Мб, при первом запуске может спокойно докачивать еще 300Мб даже по 3G. За примерами далеко ходить не надо, практически каждая free-to-play игра сейчас так работает. Надо ли говорить, что для 3G-стран ситуация от этого в лучшую сторону не меняется. Огромная аудитория отваливается, так и не дождавшись первой игровой сессии.

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

• Версионирование игры. Хорошая free-to-play игра постоянно обновляется, причем игра обновляется из официального магазина, а контент докачивается с ваших серверов. Необходимо следить за тем, чтобы версия игры и контента были согласованы. А ведь некоторые ваши игроки могут и не обновлять у себя версию игры.
• Скорость скачивания. Скачивание дополнительного контента, даже если он разбит на порции, это очень вероятное место ухода игроков. Поэтому в процессе скачивания игрока нужно как-то развлекать, по меньшей мере, не останавливать геймплей. Асинхронная работа с чем-либо всегда вносит дополнительные сложности в организацию кода и архитектуру игры.
• Свободное место на карте памяти. Понятно, что размер карт памяти ограничен, причем для многих классов устройств существенно. Необходимо еще перед скачкой контента убедиться, что места хватает, а если не хватает, то выдавать игроку осмысленные рекомендации на этот счёт.
• Место для сохранения контента. Не секрет, что iOS строго следит за тем, куда пользователю разрешается сохранять файлы. Не сохраняйте скачанный контент в папках, где по задумке Apple должны содержаться кэши и временные файлы программ. Любая утилита по оптимизации места на i-устройстве может удалить ваши файлы без какого-либо предупреждения.
• Докачивание. Отличительной особенностью iOS и Android, например, от десктопных операционных систем, является то, что программы здесь часто завершаются снятием задачи в диспетчере. Это означает, что скачивание может быть прервано в любой момент, в том числе в процессе записи на жесткий диск. Необходимо предусмотреть продолжение скачивания контента в следующую игровую сессию и проверку результирующих файлов на целостность.

3. Оперативная память

Оперативной памяти на мобильных устройствах мало. Мало не для программ и операционной системы (хотя и такое бывает, особенно на Android), мало для компьютерных игр. Качество контента в мобильных играх продолжает неуклонно расти, чему способствует большая конкуренция на рынке игр. Люди в основной массе уже не готовы играть в игры с посредственной графикой, предпочитая более качественные аналоги. А текстуры в высоком разрешении могут занимать после загрузки в оперативной памяти значительный объем.

Что же делать? Самый простой и наиболее частый путь – ограничение парка устройств, на которых можно запускать игру. Сделать это просто как в Google Play, так и в App Store, однако, чем больше бюджетных моделей устройств будет отброшено, тем больше потенциальных игроков будет потеряно. Перед решением о превращении устройства в неподдерживаемое необходимо обязательно проконсультироваться со статистикой использования этого устройства, благо сейчас такую информацию можно достаточно просто получить.

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

Динамическая загрузка и выгрузка контента – еще один из вариантов преодоления проблемы. Понятно, что нагружая игровой цикл операциями по загрузке и выгрузке контента из памяти, мы неизбежно увеличиваем время кадра. Однако варианты есть, в частности использование загрузки ресурсов в отдельном потоке и отдельном контексте OpenGL ES с применением EAGLSharegroup.

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

4. Клиент-серверное взаимодействие

Неотъемлемой частью free-to-play модели является взаимодействие клиента игры с сервером. Можно долго обсуждать, на каких технологиях создавать сервера для free-to-play игр, как их сделать гибко конфигурируемыми, легко масштабируемыми и переносимыми. Можно сделать самый лучший сервер на свете, но если сетевое соединение слабое, то от сервера проку будет мало. А соединение (особенно через мобильные сети) слабое, постоянно прерывающееся и восстанавливающееся. Ваши игроки будут пытаться играть в метро, в лифте, в поезде, именно тогда, когда им хочется скрасить ожидание.

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

Мобильные free-to-play игры по способу взаимодействия с сервером можно разделить на 2 условные категории: игры, которые не позволяют играть без интернет-соединения, и те, которые позволяют это делать. Игры, которые предоставляют какой-либо оффлайн геймплей, как правило, делать сложнее, вместе с тем такой подход может неплохо работать для удержания пользователей. Можно выделить следующие основные сложности при реализации оффлайн функционала в онлайн-игре:

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

5. Производительность

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

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

• Используйте предвыделение памяти и минимизируйте выделение памяти внутри игрового цикла;
• Используйте кэши для данных, которые трудоемко вычислять;
• Используйте двоичные форматы данных вместо текстовых, где это возможно;
• Не создавайте сложные иерархии классов и не используйте RTTI для них;
• Не копируйте объекты по значению;
• И самое главное — не надо заниматься «ранней оптимизацией».

Вместо заключения

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