Что такое портировать игру
Почему так сложно портировать игры на PC — кратко и просто о долгом и трудном
Портирование игр — это действительно нелегкая задача для разработчиков, даже если речь идет о выпуске игры на ПК, где она, собственно, и разрабатывалась. И в этой статье один из основателей студии Disparity Games Джейсон Старк (Jason Stark) расскажет, с какими трудностями сталкиваются его коллеги по цеху.
Вопросы сооснователю Disparity Games задавали журналисты сайта PC Gamer. Материал подготовлен на основе англоязычной статьи.
Как портируют игры на ПК
Геймеры спрашивают, почему разработчики просто не могут выпустить ту версию игры, которую они делали на PC во время тестирования. А когда они делают это и выпускают забагованный билд, те же геймеры сетуют на ошибки и винят девелоперов в лени.
Чтобы понять всю сложность процесса, достаточно просто представить, как много компонентов имеет любой современный компьютер. Различное «железо», тысячи версий драйверов, и иногда очень трудно предугадать, как их связка поведет себя в тех или иных условиях.
Даже хорошо оптимизированные и отлаженные игры часто работают не так, как нужно, если компьютер имеет специфический набор ПО и комплектующих. В этом смысле вопрос «хорошего» или «плохого» порта — это скорее вопрос вложения денег и времени: сколько ресурсов готов потратить разработчик, чтобы обеспечить наибольшую совместимость? Впрочем, абсолютный идеал все равно недостижим.
Перенести игру на консоли тяжело, но в случае возникновения бага на одном Xbox One, ты будешь знать, что то же самое будет на всех остальных Xbox One.
Больше платформ — больше проблем
При портировании игры разработчик фактически создает ее уникальную версию. Это означает, что выбор каждой дополнительной платформы для выпуска игры увеличивает сложность релиза на порядок. Это умножение, а не сложение. В случае нескольких платформ нужно не только выпускать, но еще и быстро реагировать на всевозможные проблемы, оперативно решать их.
Каждый патч или обновление нужно тестировать на каждой платформе отдельно. И только если ни на одной не возникло проблем, выпускать это в «паблик». Ведь безобидный «фикс» на одной платформе может вызывать критический сбой на другой. Нужно учитывать кучу факторов и особенности архитектуры каждой среды.
Создание ПК-порта игры с прошлого поколения консолей тоже довольно проблемное дело. Проект, который ранее запускался в 30 fps, далеко не всегда можно быстро «завести» в 60. А игры из прошлого десятилетия нельзя по мановению руки адаптировать к 4K-разрешению, как бы просто это не казалось.
Когда проще сделать игру заново
Короче говоря, портирование — это довольно непредсказуемый процесс. Но вместе с этим разработчик должен стремиться к тому, чтобы все версии одной и той же игры были похожи по своему функционалу и внешнему виду. При этом зачастую это невозможно на практике из-за кардинальных различий между платформами. А также из-за необходимости соблюдать лицензионные соглашения.
Вы редко слышите негативные рассказы о портировании игр, потому что в интересы разработчика не входит посвящать третьи лица в требования платформодержателей. Им не хочется читать критику в свой адрес.
Особенности продвижения
Если на минутку забыть о технических вопросах, то выпуск игр на разных платформах все равно является очень трудным делом. Ведь если игра выходит на системе, ее нужно продавать тем, кто этой системой пользуется. Нужно искать популярных «ютуберов», налаживать связь с сообществом игроков, делать промо-материалы для каждой платформы в отдельности.
Например, в коллективе из 20 человек вопросами продвижения могут заниматься трое. Они не участвуют в разработке как таковой, только занимаются изданием, маркетингом и продажами. Для маленьких студий вопрос выхода на нескольких платформах — это серьезная головная боль: рук не хватает.
К тому же никто не отменял непреднамеренных вещей вроде выпуска портов разного уровня качества. Это иногда выходит само собой, но игроки почти всегда начинают обвинять разработчиков в том, что они «продались» и перетянуть игроков на другую платформу. Хотя на самом деле большинство разработчиков хотят выпустить хороший порт для любой системы, просто не всегда это получается.
Впрочем, бывает и обратное, когда выходит переиздание какой-то древней игры и она пробивает чарты продаж. В таких случаях игроки готовы платить хорошие деньги, чтобы получить улучшенную версию любимой игры, так как это отличный способ отблагодарить девелопера за хорошую работу.
Портирование любимой игры под Android
Создание игры процесс захватывающий и познавательный. Особенно это заметно, когда ремейк «классики» делаешь сам, руководствуясь идеями оригинала и десятками часов, потраченных на прохождение кампании. У меня не было сколь-нибудь значимого опыта разработки для Android’a, поэтому создание работающего «как надо» приложения для планшета поначалу выглядело довольно туманно, но от этого не менее притягательно. При наличии времени и возможностей, можно стряхнуть пыль со старых игр, подмазать и подклеить, добавив поддержку «больших» разрешений и окажется, что они выглядят не хуже современных продуктов, выложенных на маркете, даже с палитрой RGB565 без альфа-канала. Я предполагал, что будут подводные камни и заботливо спрятанные грабли, которые лежат тихонько во время разработки, но больно лупят по голове, стоит запустить игру на реальном железе. Чего сильно не хватало, так это отладчика, а возникающие проблемы лишь укрепили желание достичь поставленной цели. Под катом будет рассказ о том, как это все заработало.
Стоит сразу предупредить, что это возможно будет рассказ о велосипедах, я не придумал ничего такого, что не гуглится на просторах «интернетов». Также Читатель вряд ли увидит новые решения или мега технологии, но найдет опробованные инструкции по сборке приложения, использующего SDL1/2, для Android.
Здравствуйте!
Ремейк игры Caesar III© начинался совсем не как отдельный проект, а скорее набор фиксов для количества жителей, поддержки «больших» разрешений и исследования декомпилированного кода оригинальной игры в поисках пасхалок и недокументированных режимов работы. А когда количество восстановленного кода перевалило за половину от общего, стало понятно, что можно попытаться восстановить игру. В качестве библиотеки отрисовки была выбрана SDL1.2, которая хорошо зарекомендовала себя в других проектах, а ещё проста в освоении и использовании. Ремейк поначалу был Linux-only, в начале этого года перебрался на другие платформы (Mac, Windows и Haiku), а потом у меня завелся вот такой планшет, а голове периодически возникали мысли «работает на одном линуксе, должно работать и на другом».
Попытка номер раз, удачная
У SDL версии 1.2 «из коробки» нет возможности работы под андроидом, зато есть замечательный проект libsdl-android, который позволяет, используя свое окружение и скрипты собирать код, использующий эту библиотеку в приложении для андроида. Собранное приложение может загрузить ресурсы как из интернета, так и распаковать из установщика. Сам libsdl-android содержит большое количество библиотек, которые могут вам понадобиться, начиная от bzip2 и разных кодеков, до самой SDL и его окружения SDL_image, SDL_mixer, ttf и другие. Если у игры нет платформозависимого кода, то портирование занимает несколько шагов:
/.bashrc;
echo «export ANDROID_NDK=
/.bashrc;
echo «export NDK_ROOT=\$$ANDROID_NDK» >>
/.bashrc;
echo «export PATH=\$$PATH:\$$ANDROID_NDK:\$$ANDROID_SDK/tools:\$$ANDROID_SDK/platform-tools» >>
Если все удачно скомпилилось, то в папке commandergenius/project/bin появится файла MainActivity-[release|debug]-unsigned.apk, который нужно подписать и установить на устройство.
/projects/commandergenius/project/bin/MainActivity-release-unsigned.apk caesaria
$ mv
/projects/caesaria.apk
$ adb uninstall net.dalerank.caesaria
$ adb install
Подводные камни
0. Определение окружения: для начала надо определиться в каком окружении будет работать Windows, Linux или Linux Android.
Решение: Проверяем наличие дефайнов ANDROID/__ANDROID__.
3. Обработка событий: пропадает событие SDL_MOUSEBUTTONUP при движении пальцем по экрану, это могла быть недоработка в самой библиотеке libsdl-android или я где-то его терял. Проявлялось иногда в отсутствии реакции элементов интерфейса на действия пользоватся, например после движения остановились на кнопкой, которая по идее должна перейти в состояние если над ней находится курсор мыши.
Решение: Специфично для моего приложения — при сборке под андроид было добавлено принудительное обновление состояния элементов под курсором при движении последнего.
4. Мелкий интерфейс: разрешение экрана современных мобильных устройств сопоставимо или превышает разрешение монитора, используемого 10-15 лет назад, но физические размеры заметно меньше, оттого и сам элементы пользовательского интерфейса выглядят мелко и пользоваться ими будет не всегда удобно.
Решение: Переделка интерфейса, что достаточно хлопотное занятие и не всегда удается сохранить первоначальный вид. 
Один переезд равен двум пожарам(народная мудрость)
Все началось с того, что один из коммитеров прислал ссылку на ветку разработки, где успешно запустил игру с использованием относительно свежей библиотеки SDL2, а до этого использовалась версия SDL1.2 — 2008 года выпуска. Надо сказать, что я и сам рассматривал возможность перехода на новую версию, особенно после просмотра списка изменений, который сулил нормальную поддержку Mac и Android, что называется «из коробки». А тут еще и миниотпуск на работе получился, взяв кувалду побольше гайд потолще и большую чашку кофе, я начал переводить ремейк на новый «движок».
Не хочу утомлять читателя техническими подбробностями переезда, просто у самой библиотеки с приходом аппаратной поддержки изменилась идеология работы, что поначалу доставляло определенные трудности, пока я к ней не привык. Переезд растянулся на неделю вечеров и под конец представлял собой исправление оставшихся недочетов и графических артефактов. Переделки были закончены и подготовлены сборки для «больших» ОС, и опять появилась необходимость повторного чтения мануалов по сборке приложения под Андроид, потому как libsdl-android нормально адаптирован для работы с SDL1.2, а поддержка SDL2 похоже заброшена (о чем сами авторы и пишут в ридми)
Осознал я правдивость этого текста, когда было потрачено несколько часов в попытке запустить порт в старой конфигурации через libsdl-android. Ну что ж, отрицательный опыт — тоже опыт: буду использовать доступные инструмены.
Попытка номер два, не совсем удачная
SDL2 уже содержит все необходимые конфиги для сборки приложения под андроид, почитав статью, рекомендованную на официальном сайте, можно пробовать собрать чтонибудь. Опять же будут несколько шагов, за исключением установки и настройки adt.
$git clone bitbucket.org/dalerank/caesaria
$hg clone hg.libsdl.org/SDL
$mkdir caesaria/android
$cp SDL/android-project caesaria/android
$mkdir caesaria/android/libs
$mkdir caesaria/android/data
$cp SDL caesaria/android/libs
Для чего все эти копирования сделаны. чтобы проще было считать относительные пути для библиотек. В папке android/libs будет лежать SDL и компания, в папке android/data — будет иконка приложения.
В папке android/android-project/jni создаем символьные ссылки на компоненты приложения
Немного о том, что же я тут написал:
zlib нужен для сборки freetype, который в свою очередь нужен для SDL_ttf и будет отвечать за рендеринг шрифтов.
Библиотека smk нужна для воспроизведения видео в формате smack, в этом формате выполнены ролики оригинальной игры.
Bzip, lzma и aes нужны для работы с zip-архивами.
libpng требуется для загрузки текстур для игры.
SDL, SDL_mixer, SDL_net отвечают соответсвенно за рисования, работы со звуком и сетью.
application содержит исходники самой игры, которые будут собраны в библиотеку libapplication.so
в папке src располагаются исходники библиотеки libmain.so, а вот для неё уже написано кружево java-вызовов над с-кодом, которое позволит нам успешно стартовать и порадовать пользователя яркой картинкой.
Настройки проекта и конфиги для ndk уже любезно предоставлены авторами SDL2
Чтобы система сборки увидела, какие нам необходимы библиотеки для работы и собрала их, нужно написать для них конфиги, наподобие Makеfile. С большой вероятностью Android.mk уже будет присутствовать в репозитории библиотеки, или их можно найти на просторах интернета. Мне пришлось дописать конфиги сборки для для игры и библиотеки libsmk.
Конфиг содержит указание скомпилировать все файлы с расширением .с, найденные в текущей папке (для libsmk это будет jni/smk)
Аналогично пишется и конфиг для сборки библиотеки, которая будет представлять саму игру.
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/$(SDL_PATH)/include \
$(LOCAL_PATH)/$(SDL_MIXER_PATH) \
$(LOCAL_PATH)/$(SDL_NET_PATH)/include \
$(LOCAL_PATH)/$(FREETYPE_PATH)/include \
$(LOCAL_PATH)/$(GAME_PATH) \
$(LOCAL_PATH)/$(DEP_PATH) \
$(LOCAL_PATH)/$(DEP_PATH)/libpng
Тоже должно быть понятно, в LOCAL_C_INCLUDES добавляет пути где нужно искать заголовочные файлы, в LOCAL_SRC_FILES добавляем файлы с исходным кодом,
в LOCAL_SHARED_LIBRARIES прописываем зависимости приложения.
флаги rtti, exceptions отвечают за использование RTTI и исключений.
Теоретически, после выполнения описанных шагов на подключенном девайсе или эмуляторе вы увидите установленное приложение. 
Грабли
1. Где искать ресурсы.
Место размещения ресурсов зависит от конкретной реализации ОС, но в большинстве случаев приложению будет доступна папка /sdcard/Android/data/имя_пакета/files, при использовании непосредственно пути может быть ошибка доступа или ошибка поиска файла.
Получить полный путь к директории приложения можно через функцию SDL_AndroidGetExternalStoragePath(), определенную в файле SDL_system.h
2. Использование флагов создания окна.
Комбинация SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN | SDL_WINDOW_BORDERLESS работает не на всех девайсах, убираем SDL_WINDOW_OPENGL или SDL_WINDOW_BORDERLESS и смотрим какой из флагов крашит программу. Не могу объяснить с чем связано такое поведение. С флагом SDL_WINDOW_SHOWN запукается по логам один в один, как и со всеми флагами, но при этом вероятность вылета намного меньше.
3. Слишком много звуковых каналов.
Наблюдаются вылеты при вызове функции SDL_mixer::Mix_AllocateChannels(N>16) c ошибкой, что невозможно иниализировать звук. Обходится снижением запрошенного числа каналов, насколько корректно решать эту проблему таким способом я не знаю.
4. stlport vs gnustl
Вылет при использовании stlport, нарвался на этот баг при обходе вектора с использованием итераторов на эмуляторе Nexus 7 (Android 4.0.3). Опять же не могу объяснить факт сей ошибки, решилось использованием gnustl при сборке приложения.
5. Мое кунгфу сильнее твоего.
Использование библиотеки с именем, похожим на имя той, что уже есть в системе приводит к загрузке чужой библиотеки, в которой возможно нет необходимых функций. Ошибка появилась из-за того, что я собираю свою версию libpng.so, решение было найдено на stackoverflow, исправилось заменой имени библиотеки libpng.so на libpnggo.so
В заключении.
Работает! Почти не отличается от ББ! Доволен ли я? Не очень!
Дело в том, что толи я криворукий, толи лыжи не едут, но на планшете приложение получилось крайне медленным (10-12 fps для крайне простой картинки результат унылый), думаю, вина тут в руках и незнании матчасти. SDL — отличная библиотека в обеих реинкарнациях, и много действительно хороших игр использует её, а также портировано на андроид.
Потраченного времени на создание порта не жаль точно, получен определенный опыт и много положительных эмоций, когда игра взлетела. Тем, кто ещё раздумывает пробовать или нет, однозначно пробовать, не откладывайте на потом!
З.Ы. За развитием проекта всегда можно посмотреть тут.
Что нужно знать о портировании игр на консоли Статьи редакции
Рассказывает основатель студии Mandragora.
Для многих инди-разработчиков консоли остаются неизведанной территорией. В то время, как выпуск игры на Steam — относительно простое и понятное дело, релиз на PS4, Xbox One и Nintendo Switch сопряжён с трудностями как бюрократическими, так и техническими.
Мы пообщались с Евгением Кистеревым, основателем студии Mandragora, которая 26 февраля выпустила на Switch свой «рогалик» SKYHILL. Он рассказал, к чему готовиться тем, кто хочет выпустить свои тайтлы на консоли.
Предположим, я сделал игру для ПК, а через пару лет решил, что неплохо было бы портировать его на консоли. Возникнут ли у меня какие-то проблемы при переносе игры на другую платформу? Нужно ли думать о потенциальном порте во время разработки?
Подумать о порте, не имея предыдущего опыта, не получится. Но некоторые вещи всё же можно предусмотреть. Первым делом я бы проследил за тем, что ресурсы игры грузятся ассинхронно и игра никогда не подвисает на одном кадре больше чем на секунду, даже во время загрузки локаций.
В случае, если ваша игра сделана на Unity, то, конечно же, придётся перейти на одну из последних версий движка. Очень часто с этим не возникает никаких проблем. Естественно, игра должна идеально поддерживать управление с геймпада во всех GUI и механиках.
Для SKYHILL нам потребовалось полностью переработать управление, перерисовать интерфейсы под управление с геймпада. Также во время создания этажей наша игра «зависала» на несколько секунд, перед тем как начать загрузку. Пришлось переписывать механизм генерирования контента так, чтобы за один кадр генерировался только один этаж. Загрузка игры из-за этого увеличилась в два раза по времени, но стала более безопасной.
Я хочу выпустить свою игру на PS4, Xbox One и Nintendo Switch сразу. Мне надо связываться с платформодержателями? Какие данные они от меня потребуют?
Ну, во-первых, для разработки под любую консоль нужен девкит, который не купишь в обычном магазине. Первый шаг — стать официальным разработчиком под определённую платформу. У каждого платформодержателя свои правила. Но обычно сильно помогает наличие выпущенных проектов или прямые контакты с представителями платформ.
Я думаю, очевидно, что это возможно, только если у вас есть юридическое лицо. Заранее я бы посоветовал подготовить дизайн-документацию для игры на английском языке. Нам сильно помогли личные знакомства с платформами и поддержка от нашего издателя.
Могут ли платформодержатели попросить внести какие-то изменения в игру?
Обычно нет, если только в вашей игре нет чего-то, что не соответствует правилам определённой платформы. Я бы посоветовал не добавлять в игру изображения, геймпады и консоли, которые можно опознать однозначно как девайсы определённой платформы. Также контент должен соответствовать возрастным ограничениям, под которые сертифицирована игра.
У нас была забавная история, когда одна из платформ нашла в окружении игры геймпад, похожий на геймпад от другой консоли, и попросила исправить это. Для того, чтобы вы понимали, в SKYHILL есть сцена с повешенным мужиком, и к ней не было никаких претензий.
Через какие вообще бюрократические процедуры нужно пройти, чтобы выпустить игру на консолях?
Нужно пройти барьер и убедить платформодержателей в том, что вы — перспективный и реальный разработчик, с которым стоит сотрудничать. Получить возрастные рейтинги на игру. Ну и главный страх, который вы слышите от тех, кто занимался портированием — процесс сертификации.
У каждой платформы есть много критериев качественного продукта и необходимо им соответствовать. В вашу игру будут реально играть, будут тестировать на техническое соответствие стандартам. Любое несоответствие критериям платформы — отказ в сертификации и потеря времени. Есть довольно много историй, когда разработчики пытались пройти сертификацию 7-10 раз. И каждый раз это занимает недели.
Вообще, половина из критериев сертификации могла бы относиться и к просто качественному продукту для ПК. Что произойдёт, если у пользователя отключится геймпад во время игры? Если он нажмёт на кнопку выключения устройства в любом месте игры?
Вторая же половина относится к SDK платформ. Ваша игра должна идеально работать в экосистеме ачивок, сохранений, профилей пользователей, облачных сохранений и так далее. Если бы часть этих требований предъявлялось к играм, которые выходят на Steam, то все бы от этого только выиграли.
В среднем, если всё складывается удачно, сколько времени уходит на бюрократические процедуры? С какой консолью проще, с какой сложнее?
На данный момент портирование на Switch выглядит проще всего. Например, работающий полностью билд SKYHILL у опытных портировщиков от издателя получилось сделать за неделю. А через месяц игра уже была загружена на сертификацию, но это больше из-за внутренних причин. В целом, можно было управиться за пару недель.
Что касается PS4 и Xbox One, то это — уже развитые платформы с кучей механизмов и они требуют гораздо больше серьёзного подхода и технического уровня. У тех, кто давно занимается портированием, есть самописные «обёртки», к которым привязывается любая игра, что сокращает время портирования в разы. Проблемы возникают когда пишешь это в первый раз. Это что касается технической части.
С точки зрения бюрократии я бы не выделил какую-то платформу. Тут именно есть большая разница. Если подступаешься к этому вопросу в первый раз (как, наверное, большинство из тех, кому эта статья интересна), то очень часто просто не знаешь с чего начать.
Путаешься в порталах, настройке девкитов, ищешь, как получить устройство, если зарегистрирован в СНГ. Получаешь возрастные рейтинги для разных регионов опять же. Во всём этом предстоит разбираться.
Nintendo и Microsoft сейчас более открыты для общения, если посмотреть в целом. У Xbox есть программа ID@XBOX, которая направлена как раз на небольших разработчиков. Nintendo тоже благосклонно относится к инди-разработчикам, поддерживают интересные проекты. У них же даже есть направление Nindies.
Для портирования мне ведь обязательно потребуется девкит? Где его достать?
Тяжело ответить прямо. Скажу лишь, что для разработчика из СНГ это не самая тривиальная задача.
Могут ли быть какие-то сложности из-за выбранного мной движка? Или без разницы?
Самые распространенные движки, конечно же, поддерживают сборку под консоли. Если вы делаете игру на Unreal или Unity, то проблем точно не будет. По крайней мере, сам движок не доставит проблем. Насколько я знаю, у Game Maker тоже эти проблемы решены (стоит лишь уточнить насчёт полноценной поддержки Nintendo Switch). А другие движки я бы и не советовал использовать в наше время кросс-платформенной разработки.
Мы разрабатываем все наши игры на Unity. Движок всегда позиционировался как кросс-платформенный и в этом его главный плюс.
Если я сам ничего не понимаю в портировании, куда можно обратиться? К издателям?
Существуют издатели, которые специализируются на портировании и выпуске игр на определённые платформы. Так мы поступили с нашей игрой Freaky Awesome. Мы обратились к нашим партнёрам из BadLand в Испании.
Игру на Steam мы выпускали сами, а вот портировать на консоли после болезненного опыта SKYHILL мы не решились и отдали Xbox One, PS4 и Nintendo Switch издателю. Они полностью взяли процесс портирования и сертификации на себя. Также существуют аутсорс студии, которые за фиксированные деньги предоставляют портирование и тестирование на соответствие требованиям сертификации.
В дальнейшем мы не собираемся портировать новые проекты самостоятельно. Несмотря на то, что у нас есть девкиты от всех трёх консолей, нам больше хочется концентрироваться на качестве игрового опыта. Так как мы продолжаем работать с издателями, эту функцию будут выполнять они.
А со SKYHILL было что-то ещё болезненное, кроме технических проблем, описанных выше, и случая с геймпадом?
В целом, когда приступаешь к портированию, то чувствуешь себя очень глупым. Знаете, как когда ты учишься в университете, и тебе задают какую-нибудь фигню, а ты даже не понимаешь, что от тебя требуется.
Это уникальные требования к игре, которые нужны только для определённой консоли. Даже такие тривиальные задачи, как выдача ачивок, например, могут обернуться проблемой, которую необходимо решать несколько дней.
На консолях нет такого многообразия магазинов цифровой дистрибуции, как на ПК. По сути, платформодержатели — монополисты. Сказывается ли это на проценте от выручки?
Он не сильно отличается от Steam. Но детально тут вам никто не ответит, конечно же. Вообще процент от прибыли — это не главное о чем стоит думать. Доступ к новой аудитории, которая привыкла покупать игры не за копейки, и меньшее количество игр в магазинах на консолях гораздо важнее.
Есть ли вообще смысл для инди выходить на консолях? Можно ли на них заработать больше, чем на ПК?
А причём тут «инди или нет»? Я не вижу разницы между крупной студией и инди из пары человек в плане бизнеса. Если есть возможность выйти на консоли, если ваша игра приносит деньги с ПК, то с консолями можно начать зарабатывать больше.
Разработчик игр создаёт интеллектуальную собственность. Вполне разумно постараться обеспечить как можно больше источников долгосрочных доходов для созданного продукта. Например, для SKYHILL Nintendo Switch — уже шестая платформа (игра уже вышла на Steam, IOS, Android, PS4 и Xbox One) и на каждой из них мы зарабатываем. Хотя игра вышла на Steam в 2015 году, она всё ещё живёт.
Freaky Awesome вышла на Steam, PS4 и Nintendo Switch. Готовится к выпуску на Xbox One. Со следующей игрой мы надеемся на одновременный релиз на ПК и всех консолях.
Как устроен фичеринг в консольных магазинах? Как можно сделать свою игру более заметной?
У каждой платформы свои правила относительно фичеринга. Обычно на старте игра попадёт в списки новинок. А дальше всё зависит от конкретной игры и общения с менеджерами платформы.
Какого-то фиксированного для всех количества показов на главной, как в было Steam, на консолях нет?
Его на Steam ведь уже давно нет. Есть общие правила для показа новинок, игр со скидками. А насчёт фичеринга нужно договариваться.
Кто назначает цены на консольные игры? Могу ли я сам управлять ими и устраивать распродажи?
Как и на других платформах, таких как Steam и AppStore, управление скидками лежит на плечах издателя игры, но также есть возможность обсудить планы по скидкам с менеджером от платформы и запланировать что-то специальное под определённые события.
А как обстоят дела с региональными ценами на разных консолях? Обязательно назначать их?
Нет, не обязательно. На некоторых платформах эта возможность ограничена и нельзя назначить специальную цену для определённой страны. Платформа также может «посоветовать» сильно не снижать цену для региона.
Но окончательное решение всё равно за издателем или разработчиком? И это справедливо для всех консолей, или у каждой есть свои особенности?
Окончательное решение всегда за издателем игры, а не платформой, конечно.
На PlayStation 4, например, для мультиплеера в одних играх требуется PS Plus, а в других — он не нужен. Кто принимает решение о том, будет ли подписка обязательной для сетевых режимов: разработчики или платформодержатели?
У нас нет игр с онлайн мультиплеером на консолях, но всё, что касается уникальных условий по попаданию в подписочные сервисы, обсуждается индивидуально.
В целом, какие инструменты предлагают платформодержатели для отслеживания статистики и управления страницей игры?
Тяжело ответить прямо, но они гораздо скуднее, чем статистика, которую нам даёт Steam и сами системы со стороны разработчика выглядят более устаревшими.
А если вам потребуется какая-то определённая информация, которую платформодержатель не предоставляет по умолчанию, вы можете её запросить?
Если вы можете объяснить, зачем вам это нужно и у платформы есть возможность предоставить вам информацию, то стоит попробовать. Причём это касается не только консолей, но и Steam, например.
Почему многие инди-студии выпускают свои игры именно на Nintendo Switch? Это связано с политикой самой компании в отношении независимых разработчиков, архитектурой консоли или условиями, которые предлагает Nintendo?
Здесь именно весь комплекс факторов. Многие издатели ААА не имеют возможность оптимизировать свои игры под слабые устройства. Вполне логично, что Nintendo нужно было идти к разработчикам инди-игр и просто менее требовательным к железу проектам, чтобы предложить своим игрокам больше выбора, после того как они пройдут Zelda и Mario. Также портирование на Nintendo Switch технически проще, если не считать оптимизацию.
А какие именно проблемы с оптимизацией возникают при разработке на Switch?
У небольших игр, как правило, не должно быть проблем, если они хорошо оптимизированы. В случае со SKYHILL и Freaky Awesome проблем с оптимизацией не было вообще.
Для более требовательных игр с 3D или большим количеством визуальных эффектов это может стать также серьёзной проблемой. Это же касается игр, которые используют много физики или просто плохо оптимизированы. ПК прощает гораздо больше.