что такое бандл в рамках сервисов экосистемы
Бандлинг JavaScript-кода и производительность: передовые методики
Сейчас, на рубеже десятилетий, самое время критически переоценить то, что считалось правильным в недалёком прошлом, и выяснить, не потеряло ли оно актуальности в наши дни. Иногда вчерашние передовые методики разработки становятся сегодняшними антипаттернами.
Автор статьи, перевод которой мы сегодня публикуем, собирается исследовать три подхода к бандлингу JavaScript-проектов на примере простого Hello World-приложения, созданного с помощью React. Некоторые из приводимых им примеров подразумевают знание читателем основ сборщиков модулей, таких, как Webpack, который, похоже, является сегодня самым популярным среди подобных инструментов.
Подход №1: в бандл попадает абсолютно всё (это похоже на большой клубок ниток)
Главная мысль: не пользуйтесь этим подходом.
До выхода HTTP/2 этот паттерн можно было признать, в некотором роде, вполне приемлемым, так как его использование сокращает количество HTTP-запросов, выполняемых браузером при загрузке материалов страниц. Но учитывая то, что большинство сайтов в наши дни используют HTTP/2, этот паттерн стал антипаттерном.
Почему? Дело в том, что при использовании HTTP/2 выполнение множества запросов больше не создаёт такой же нагрузки на систему, как раньше. В результате упаковка кода в единственный большой бандл больше не даёт проекту существенных преимуществ.
При таком подходе усложняется эффективная организация браузерного кэширования. Например, изменение всего одной строчки кода в простейшем приложении приводит к изменению хэша бандла и к инвалидации кэша, хранящего весь код проекта. В результате всем возвращающимся посетителям приходится снова загружать весь код сайта, даже учитывая то, что этот код на 99% не отличается от того, который они загружали при предыдущем визите. Тут мы имеем дело с нерациональным использованием сетевых ресурсов за счёт многократной передачи от сервера клиенту одних и тех же данных.
HTTP/2 в наши дни поддерживают более 95% клиентов. В 2019 году этот протокол был реализован большинством серверов. Здесь можно найти более подробные сведения об использовании HTTP/2 в 2019 году.
Подход №2: раздельная упаковка кода проекта и кода сторонних библиотек (разделение кода)
Главная мысль: пожалуйста, используйте этот подход.
Вот каким стал код подключения скриптов:
А вот как выглядит водопадный график загрузки страницы, при работе с которой используется HTTP/2.
Водопадный график загрузки страницы
Мне подобный уровень разделения кода всё ещё кажется довольно-таки непростым делом. Это пока выглядит как экспериментальная технология (и как нечто такое, в чём вполне могут проявиться трудноуловимые ошибки). Но мне совершенно ясно то, что сильное разделение кода — это то направление, в котором двигается индустрия веб-разработки. Возможно, благодаря поддержке браузерами JavaScript-модулей, мы в итоге сможем полностью отказаться от бандлеров вроде Webpack и просто отдавать клиентам отдельные модули кода. Интересно будет понаблюдать за тем, куда всё это нас приведёт!
Подход №3: использование общедоступных CDN для кода некоторых зависимостей
Главная мысль: не пользуйтесь этим подходом.
На первый взгляд всё это выглядит вполне здраво, но у такого подхода есть некоторые минусы, которые я предлагаю рассмотреть.
▍Минус №1: использование разными сайтами одних и тех же файлов зависимостей? Уже нет…
Разработчики старой школы хранят в себе надежду на то, что если все сайты ссылаются на один и тот же CDN-ресурс и используют ту же версию React, что и наш сайт, то посетители нашего сайта, если в кэше их браузеров уже есть код React, не будут тратить время на его повторную загрузку. Это серьёзно повысило бы скорость вывода страниц нашего сайта в рабочий режим. Да и документация React, посвящённая этому вопросу, выглядит многообещающе. Поэтому, наверняка, некоторые разработчики используют этот паттерн. Правильно?
Хотя раньше подобное вполне могло работать, недавно в браузерах, ради повышения безопасности, начали реализовывать механизм разделения кэшей. Речь идёт о том, что даже в идеальных условиях, когда два сайта используют одну и ту же библиотеку, загружаемую по одной и той же CDN-ссылке, код независимо загружается для каждого домена, а кэш, из соображений приватности, попадает в «песочницу», выделенную конкретному домену. Как оказалось, этот механизм уже реализован в Safari (по-видимому, он существует с 2013 года?!). А если говорить о Chrome 77, то для включения разделения кэша пока нужно использовать особый флаг.
Тут делается обоснованное предположение, касающееся того, что использование общедоступных CDN снизится по мере того, как во всё большем количестве браузеров будет реализовано разделение кэша.
▍Минус №2: трата ресурсов системы на вспомогательные операции (для каждого домена)
Здесь озвучена мысль о том, что использование CDN приводит к повышению нагрузки на системы, так как даже ещё до отправки HTTP-запроса браузеру нужно решить множество задач: DNS-разрешение имени, TCP-соединение, SSL-рукопожатие. Браузеру, для подключению к сайту, в любом случае приходится выполнять эти действия, но если он вынужден подключаться и к CDN — это увеличивает нагрузку на него.
Вот водопадный график, иллюстрирующий процесс загрузки страницы, на которой используются скрипты с общедоступного CDN-ресурса.
Водопадный график загрузки страницы, использующей общедоступные CDN-ресурсы
Красными овалами выделены области, в которых происходят операции, предшествующие выполнению запросов. Кажется, что для простого Hello World-приложения это уже чересчур.
По мере того, как мой простой пример будет развиваться и расти, настанет момент, когда мне захочется использовать в нём собственный шрифт. Например — взятый из Google Fonts. А это означает, что число подобных задержек лишь увеличится, так как для загрузки шрифтов придётся подключаться к соответствующему домену. Тут начинает казаться весьма привлекательной идея хостинга всех ресурсов сайта на собственном основном домене (который, конечно, расположен за собственным CDN-ресурсом проекта, основанным на Cloudflare или Cloudfront).
Если в нашем примере переключиться на загрузку двух React-зависимостей с основного домена сайта — это приведёт к тому, что водопадный график загрузки страницы станет гораздо более аккуратным.
Водопадный график загрузки страницы, не использующей общедоступные CDN-ресурсы
▍Минус №3: использование разных версий зависимостей различными сайтами
Я, на скорую руку, провёл не особенно научное исследование 32 крупнейших сайтов, использующих React. К своему сожалению, я выяснил, что лишь 10% из них используют общедоступные CDN-ресурсы для загрузки React. Оказалось, правда, учитывая то, какие версии React используют все исследованные сайты, что это особого значения не имеет. В идеальном мире не было бы разделения браузерного кэша, а все сайты могли бы организоваться и использовали бы одни и те же версии скриптов с одних и тех же общедоступных CDN. В реальности же наблюдается чрезвычайно сильный разброс версий React, используемых разными сайтами. Это уничтожает идею общего браузерного кэша.
Версии React, используемые разными сайтами
Если сначала открыть один популярный сайт, использующий React, а потом — другой, то окажется, что шансы того, что оба эти сайта используют одну и ту же версию React, весьма невелики.
Я, в ходе исследования, обнаружил ещё некоторые любопытные сведения об этих React-сайтах. Возможно, они покажутся интересными и вам:
▍Минус №4: проблемы, не касающиеся производительности
К несчастью, в наши дни тот, кто использует общедоступные CDN-ресурсы, сталкивается не только с проблемами, касающимися скорости загрузки страниц, но и с некоторыми другими неприятностями:
Итоги
Совершенно очевидно то, что будущее лежит за подходом №2.
Размещайте перед своими серверами собственные CDN-ресурсы, использующие HTTP/2 (вроде Cloudflare или Cloudfront). Разбивайте код на небольшие фрагменты для того, чтобы эффективно использовать браузерный кэш. В будущем те фрагменты, на которые разделяют код сайта, могут стать ещё меньше, достигнув размеров отдельных JavaScript-модулей, благодаря тому, что в браузерах начата реализация поддержки данной технологии.
Уважаемые читатели! Пользуетесь ли вы технологиями разделения кода в своих веб-проектах?
Где мои деньги чувак: оформление и бандлы Steam, локализация и дистрибуторы
Это статья включает в себя несколько уже опубликованных на других ресурсах материалов. Я заранее уточнил у администрации хабра о возможности из разместить в таком формате, чтобы сохранить единую нумерацию тут, без ссылок на внешние ресурсы. Простите, но вам потребуется порядка 40 минут, чтобы прочитать её целиком. Последние две статьи первоначально выйдут на хабре.
Оформление, группы и кураторы в Steam
По опыту последних нескольких лет, от четверти до половины всех людей, которые есть в вашей группе в Steam на момент выхода игры, конвертируются в продажи в течение недели — в большей мере это самая лояльная вам аудитория.
В Steam можно посмотреть всех участников группы в игре. Очень простого скрипта вам хватит, чтобы пересечь аудитории групп любых игр и лучше понимать к какой аудитории и как обращаться после релиза вашей игры.
Помимо большого числа показов и фичеринга вы обязаны позаботиться о хороших конверсиях в переходы от таких показов и конверсиях в покупки или добавления в список желаемого. Мало получить много показов — их нужно эффективно конвертировать в покупки.
В Steam не так много статистики и с ней не всегда удобно работать, однако Click-thru rate (конверсии в переходы на вашу страницу) критически важны — это одна из тех метрик, к которой нужно отнестись предельно внимательно.
Обязательно экспериментируйте с ключевым артом, иконками и оформлением. До запуска игры простым и недорогим вариантом могут быть A/B-тесты в Facebook на вовлечение.
Инструменты связи с кураторами в Steam странные — у вас есть всего 100 заявок, которые вы можете послать, и если не успеть отозвать те, на которые куратор никак не прореагировал — ваша заявка сгорит. Если вы и куратор ещё не знакомы — обязательно пишите сопроводительные сообщения. Напишите, что у вас за игра, почему ему стоит её показывать своей аудитории. Попросите написать вам, если он не будет делать обзор.
Не игнорируйте кураторов — начните знакомиться и договариваться об обзорах за 2-3 месяца до выхода игры. Для крупных включайте режим «дятла» — пишите настойчиво и без остановки.
Если говорить о моём опыте — совокупно мы связались и смогли поговорить чуть более чем с 400 кураторами, из которых более 80 написали ревью или рекомендательный отзыв. За первые два месяца после запуска игры это дало 5,161 миллиона показов и 189,587 тысячи переходов на страницу игры.
Региональные ограничения
Уверен, что вы знаете о G2A, Kinguin, Gamivo и многих других площадках, где перепродаются ключи. И вы точно не хотите, чтобы вашу игру продавали на них с большой скидкой. Как минимум до той поры, когда вы начнете продавать игру в составе бандлов.
Главная ошибка, которую не стоит совершать — запросить глобальные ключи, которые можно активировать в любой точке света, а потом продавать их по региональной цене. Иными словами, я могу купить в России ключ, который стоит не 20 долларов, а 500 рублей (8 долларов), затем отправиться на Kinguin и продать его за 12 долларов. Вот и вся нехитрая бизнес-модель.
Чтобы этого не случилось — нужно разобраться с региональными ограничениями на запуск и активацию ваших ключей до выхода игры. По умолчанию, в Steam нельзя завести пакеты, которые содержат региональные ограничения.
Вам нужно заранее связаться со службой поддержки Steam — обосновать необходимость и и запросить как минимум дополнительные региональные пакеты для региона CIS, Китая и LATAM.
Важно! Во многих магазинах есть продажа по региональным ценам — помните, что в 3rd-party можно продавать не только в долларах, знайте, что вам нужно будет для каждого из этих магазинов передавать пакеты ключей с региональными ограничениями.
В Steam есть два вида ограничений — на активацию и на запуск. Делайте оба — если мы посмотрим на предприимчивых китайцев, то самый типичный хак с перепродажей ключей — купить ключ по низкой региональной цене, например, в России, у которого есть только ограничение активации. Изменить IP-адрес с помощью VPN или proxy и активировать ключ. После можно вернуться к своего оригинальному IP и играть без ограничений. Если же будет включено ограничение на запуск, то играть получится только с постоянным подключением к VPN или proxy.
Как бы вы ни крутились, ключи все равно появятся на маркетплейсах и сделать с этим почти ничего нельзя — это совершенно самостоятельная группа перепродажников ключей, имеющих связи в региональных магазинах.
3rd-party дистрибуция
Сейчас весомая часть дистрибуции строится вокруг Steam-ключей. Если смотреть на весь рынок 3rd-party дистрибуции в ПК, то стоит рассчитывать, что от 90 до 95% денег вы заработаете на Steam, а остальные 5-10% — вне его.
Если вам повезет, у вас очень хорошая игра, вы очень хорошо умеете делать маркетинг или знаете какое-нибудь волшебство — этот процент может быть выше. Есть большие сомнения, что всерьез рассчитывать на выход за границу 15-20%.
Продавая через 3rd-party магазины, вы так же делитесь с ними прибылью. Обычно 70/30, иногда 60/40. Разница в том, что Steam из этих денег не получает ни копейки. То есть вы приводите в Steam людей, они устанавливают игру на Steam, но прибыль делится между вами и магазином.
Важно, что ключи в Steam вы запрашиваете заранее, но деньги получаете лишь по факту их реализации в 3rd-party магазинах. А Steam имеет возможность (и периодически пользуется ей) отказать вам в генерации ключей без объяснения причин.
Иногда 3rd-party магазины используют свою часть прибыли, чтобы делать эксклюзивные скидки на игры — вместо 30% они возьмут себе 20%, а оставшиеся 10% “вложат” в экстра-скидку на хорошо продающуюся игру. Все в выигрыше — у вас растут продажи, у магазина аудитория и доход.
Помните про кассовый разрыв? Все 3rd-party работают по-разному: кто-то из них перечисляет вам деньги каждый месяц, кто-то перечислит деньги раз в квартал. У крупных, например Humble Bundle, вы можете управлять минимальной суммой вывода средств самостоятельно. В ряде магазинов, если вы захотите вывести сумму меньше 1000 долларов, то заплатите дополнительную банковскую комиссию за перевод.
В прошлой статье развернулась бурная дискуссия на тему использования скидок и подходу, в котором вы никогда не снижаете цены. Моя позиция достаточно простая — если мы говорим об инди играх в 2018 году и у вас нет нескольких десятков или сотен тысяч долларов на PR вы не сможете эффективно продавать игру. Скидки в Steam — единственный инструмент для привлечение новой аудитории.
Если вы видите, что вашу игру ждут или она хорошо продается — не стесняйтесь говорить о том, что вы готовы сделать какое-то эксклюзивное предложение при условии фичеринга. Это работает, к этому все привыкли, это вполне нормальная практика.
У большого количества площадок, если не у всех, есть желание сделать самую большую скидку первыми. И если вы хотите фичеринг — вы раз за разом будете увеличивать скидки.
Дистрибьюторы
Большинство знакомых мне крупных дистрибьюторов работает с разделением прибыли — 70/30. Другие пропорции, как правило, характерны для мелких компаний.
Помните про скорость выплат? Дистрибьютор может облегчить ситуацию — управляя портфелем игр, он получает выплаты чаще, чем отдельный разработчик. Зачастую крупные дистрибьюторы имеют собственные системы аналитики и управления ключами, которые интегрируют конечные магазины. Это позволяет лучше контролировать процесс продаж и их эффективности.
Открытые платформы
Ситуация с GOG аналогична Steam, главное пройти внутренний контроль со стороны платформы. Если ваша игра им подходит — получаете зеленый свет. Разница со Steam в том, что никакого гарантированного трафика у вас не будет.
Вы можете договориться про фичеринг с менеджером, который будет с вами работать в GOG. Вне фичеринга органика близка к нулю. Цикл жизни точно такой же, как у Steam — распродажи. Летняя, зимняя, связанные с жанрами или индивидуальные договоренности с менеджером. В отличие от Steam, в GOG менеджеры намного более отзывчивые. С ними намного быстрее и проще договариваться о продвижении или предлагать скидки (сами вы не можете изменить стоимость игры в GOG).
Itch— де-факто главная платформа для небольших инди-разработчиков. У платформы около 10 миллионов уникальных посетителей, практически все — американцы. Платформа работает по открытой ставке — вы можете отчислять платформе от 0 до 30%, рекомендуемая ставка — 10%.
Я общаюсь с довольно большим количеством людей, которые там что-то продают, в среднем их заработок составляет от 400 до 1200 долларов в год.
При этом платформа с высокой степенью анархии и демократии — для получения фичеринга можете связаться с автором платформы или с одним из двух его коллег. Если вы понравитесь — вас разместят на главной. чтобы вы там какое-то время открутились. Средние цены на игры крутятся вокруг 1-5 долларов. Большая часть игр — бесплатны или продаются по модели «заплати сколько захочешь». Посмотрите их статистику за 2017 год, чтобы лучше понимать успешные кейсы и игры на платформе. Я отдельно хочу упомянуть инструменты паблишинга этой платформы — от настройки страниц до загрузки игры. Они удивительно удобны, понятны и просты.
GameJolt — брат-близнец Itch и, в целом, все работает так же. Последняя доступная статистика за 2016 год. Основная аудитория — Латинская Америка и США. Аудитория на два порядка меньше Itch. Я считаю, что при прочих равных стоит просто пройти мимо и не тратить на эту платформу своё время.
Несколько особняком стоят платформы с моделью «Netflix of games» — Utomik, Hatch, Jump, PlayKey. Они работают по подписке — «плати за то время, которые ты провёл в игре» или просто по месячному абонементу к всему ассортименту игр.
Почитайте статью Брендона Синклера «Netflix of games» a threat to developers — прямо сейчас, в 2018 году, я разделяю скепсис как автора, так и тех разработчиков, что пришли на эти платформы.
Будущие звёзды — Kartridge от Kongregate, Discord, Shard от Fig, The Abyss от команды издателя Destiny Games, Robot Cache от Брайана Фарго, KorroBox от парней, которые работали в Riot Games, Blizzard, Twitch и Gung Ho. И ещё с десяток платформ, запуск которых состоится в 2018 и 2019 годах. Как минимум две из них — Kartridge и Discord — выглядят очень интересно.
Держим в уме, что существуют также условно открыто-закрытые платформы с очень большой аудиторией. Пример — Uplay от Ubisoft, на ней есть игры, которые не принадлежат и не издаются Ubisoft.
Рубрика «за что купил, за то и продаю»: Origin (EA), готовится открыть двери для сторонних продуктов. Я слышал об этом от двух проектов в разработке (Б и АА класс), которые общались с EA в начале июля этого года. Пожалуйста, напишите, если у вас есть какая-то информация на этот счёт.
Компания EPIC планирует открыть свою игровую платформу: 7% роялти для игры на Unreal Engine (только комиссия за использования движка ) и 12% для игр на других движках.
3rd-party бандлы
Я уверен, вы видели или слышали о бандлах хотя бы от одного из таких магазинов как Humble Bundle, G2A, Indiegala, Green Man Gaming, GamersGate, Fanatical или Gamivo. Фактически, в 2018 году, у всех крупных и многих средних 3d-party площадок есть свои аналоги этого формата, работающего по единым правилам.
Вы должны держать в уме, что все неиспользованное количество ключей, которое вы генерируете для бандлов, с высокой вероятностью отправится на перепродажу и после этого любые ваши органические продажи сойдут на нет. Помните, 3rd-party бандлы — это напоследок, когда вы уже выжгли органические продаж и скидки.
Ниже представлен неудачный опыт одной студии, выложившей свою игру в бандлы HB на третьем месяце после начала продаж и, по сути, своими руками похоронившей её.
Итак, магазины платят вам flat fee за каждый ключ, в составе бандла. Если говорить о порядках — то это 0,25-0,35 доллара за ключ к играм B класса, 0,7-1,2 доллара за BB или А и 2-4 доллара — для ААА. Зачастую размеры бандлов варьируются от 5 тысяч до 30 тысяч копий или 2-10 тысяч долларов для игр B класса. Безусловно, цены могут варьироваться (причём сильно) и напрямую зависят от вашего умения вести переговоры.
Есть плюсы у бандлов помимо денег? Да, конечно: большое число установок вашей игры на Steam с использованием ключей поднимает органический трафик. Появляются новые отзывы (они не учитываются в ранжировании), которые видят друзья игроков, уведомления в социальной части Steam, растёт число установленных копий, что влияет на блок similar products.
В этом формате HumbleBundle (HB), пожалуй, более других на слуху у многих разработчиков. Последние инфоповоды, связанные с этим хорошим магазином, зачастую идут неразрывно с едким замечанием «humble lose bundle» — в последние год-полтора они перестали делать фокус на 1-2 относительно свежих ААА играх в каждом бандле. И в этом нет ничего странного — с 2015 года компания активно продвигает формат подписок (12 долларов в месяц) за доступ к обновляемому каждый месяц набору хороших игр, с обязательной ААА на борту.
В период с 2010 года по декабрь 2013-го HB запустила 70 бандлов, с 2014 года стала активно продвигать книги и музыку. На текущий момент она выпустила более 650 бандлов. Если вы не знакомы с The Humble Visualisations — срочно знакомьтесь (2011-2016 годы).
9,000 копий из которых активировано не менее 40% ключей.
Как работает формат подписки в HB? Вы связываетесь с менеджером, и если ваша игра подходит по качеству или формату распродажи — вас возьмут. Humble предлагает фиксированную сумму за участие в подписке без учёта количества аудитории, которая получит игру. На начало 2018 года аудитория подписок превысила 200 тысяч человек и, судя по динамике, удвоится в течение 2019 года.
По данным на начало года участие в подписках для игр ВВ и А-класса приносит 10-90 тысяч долларов (0,05-0,45 доллара за копию) в зависимости от качества игры и внутренней политики оценки Humble Bundle (основана на числе проданных копий, количестве и качестве отзывов в Steam, гадании на кофейной гуще).
Steam-бандлы
В этом инструменте нет ничего необычного — вы можете взять свои игры и DLC и сделать на их основе набор одного из двух типов: с возможностью докупить только недостающие части набора (Complete the set) и без него (Must purchase together). Последний — основной механизм, если вы хотите сделать Special Edition для своей игры.
В первой статье мы говорили о скидках и том, что Weeklong Deals и ваши собственные скидки имеют одно неприятное ограничение — их можно запускать только раз в 60 дней. И именно с этим бандлы могут нам помочь. Поговорим про бандлы, состоящие из игр нескольких игр, включая игры разных разработчиков.
Такие бандлы отображаются в разделе Specials и имеют отдельный автоматический фичер в Steam. В этом формате есть критически важное отличие от отдельных игр — на бандлы, состоящие из набора игр, не распространяются ограничения на изменение размеры скидки. Вы можете менять их хоть каждые 5 минут. Вы можете размещать одну и ту же игру в нескольких бандлах одновременно.
Это формат, который хотя бы отчасти помогает обойти ограничения Steam на изменение цен и запуска скидок. А правильно подобранные бандлы позволяют вам увеличивать продажи и эффективно использовать время в ожидании скидочных окон. И инструмент любого нормального издателя — правильно собирать свои игры и игры партнёров в наборы.
Это, в том числе, повод дружить — если вы встали на путь self-publishing, ищите и договаривайтесь с другими ребятами из «клуба отчаяных» о том, чтобы запускать совместные бандлы.
Вы не одни
Epic предоставляет гранты (Unreal Dev Grants) на поддержку разработчиков (от 5 до 50 тысяч долларов). У Xsolla есть инвестиционный фонд для разработчиков Xsolla Capital. Mail.Ru создала специальное подразделение Mail.ru Games Ventures и инвестирует в игровые компании и проекты. Wargaming.net совместно с LVP тоже учредили инвестиционный фонд для разработчиков игр. Голландский издатель Good Shepherd привлекает инвестиции в игровые проекты. Nvidia предлагает поддержку с обучением и даже PR (Indie Spotlight Program). Такую же помощь (за исключением PR) окажет AMD.
Вы можете получить помощь инженеров Epic, nVidia или Radeon, если игра, которую вы делаете, интересная или использует передовые возможности движков или железа. Они могут помочь оптимизировать вашу игру, разобраться со сложным рендером или решить те тривиальные проблемы, в которых вы не можете разобраться.
Вендоры оборудования — nVidia и Radeon — имеют свой формат поддержки разработчиков в виде Featured Games. Это весьма активные и открытые компании и инженеры, которые могут вам помочь и с которыми стоит познакомиться.
Не стоит забывать и про более редкий, но от того более значимый формат — презентации нового железа. Ярким примером такой поддержки может служить презентация nVidia на недавней GamesCom, во время которого новая технология демонстрировалась на примере игры Atomic Heart.
В России с грантами всё сильно грустнее — государственных программ нет (и, возможно, слава богам), а частные инвест фонды не спешат заходить в игры из-за сложностей в оценке прибыльности и высоких рисков на фоне ухудшающейся экономической обстановки.
Краудфандинг
Если сможете договориться, у Fig есть формат Backstage Pass Program — запустить приватную кампанию на наиболее лояльных бекеров Fig. Эта площадка особенно интересна тем, что помогает с PR и активно продвигает те игры, что взяла к себе на сбор средств.
Последние несколько лет для проектов, собирающих до 100 тысяч долларов, они брали 25% до полного покрытия инвестиций и далее 15% в течение трёхх лет. Крупные проекты — 12-13% до покрытия и 10% в течение трёхх лет. При прочих равных я бы рассматривал Fig скорее как инвестфонд, нежели краудфандинг.
Правила следующие: каждый месяц внутренняя команда проекта отбирает четыре игры из тех, что подали питч в текущий период. Дальше пользователи площадки голосуют за вашу игру — если вы наберете высокие оценки Square Enix совершенно безвозмездно поможет вам в период вашей кампании — сделает рассылку по пользователям Collective, напишет о вас историю, пошарить ссылку на кампанию в Twitter и Facebook.
Локализация
На этот раз я чувствую необходимость в небольшом пояснении, почему я считаю себя вправе писать о локализации. С коммерческой локализацией и адаптацией я впервые столкнулся в 2006 году. С той поры мне, как разработчику, приходилось заниматься встраиванием перевода для ПК, браузерных и нескольких мобильных игр.
Будучи сотрудником издателя я, в истовой попытке сэкономить на Trados, занимался разработкой инструментов для команды локализации. Бес попутал меня два года назад, и я упал в глубокую пропасть community-driven перевода. Локализация больших проектов не вызывает во мне ужаса, только холодную склизкую дрожь и зубовный скрежет.
Процессы
До того, как мы расчехлим беспощадные калькуляторы, давайте потратим пару абзацев на то, чтобы разобраться с самим процессом и теми аспектами, которым стоит уделить внимание, будь вы разработчик или менеджер проекта.
Пока мы говорим об игре на 10 тысяч слов — почти ничего не важно, но если у вас большая игра на 100-300 тысяч слов — отсутствие верного понимания процессов и инструментов выльется в огромную головную боль. Зачастую переводчик не видит, как тексты выглядят в игре.
Если он не может понять логической связи между частями loc pack (комплект локализации), например, названием предмета и его описанием, названием квеста и брифингом, это создает поле для массы ошибок и, как следствие, выливается в огромные потери времени и ресурсов (время на поиск ошибки, репортинг, фикс и верификация).
Готовность движка. Вы обязаны уметь отображать UTF-8/16 символы, уметь использовать sprite sheets для шрифтов, иметь инструменты для создания наборов символов для sprite sheets (особенно для языков, использующих иероглифы — чтобы тупо впихнуть весь китайский алфавит вам потребуется текстура не менее 8К для размера символа в 12 пунктов).
Попробовав работать с google sheets с экспортом и импортом в движок, очень сложно себя заставить перейти на другие форматы. Часть платформ локализации умеет обновлять текст в режиме реального времени — это очень удобно, особенно если вы делаете мобильный проект. Это очень важная и полезная фича.
Шрифты. Оставляя за скобками вопросы лицензирования, вы должны ответить себе на вопрос, готовы ли выбранные вами шрифты для отображения всех нужных вам символов — латиницы, кириллицы, умляутов романских и германских языков. С высокой вероятность вы станете использовать отдельные группы шрифтов для китайского, корейского и японского языков.
Определитесь с тем, как доставить перевод пользователю — включать ли все доступные языки в игру или использовать отдельные языковые DLC для каждого конкретного языка.
Убедитесь, что у вас есть инструменты или вы понимаете, как будет идти локализация не текстовых ассетов (изображений, звука, моделей). Убедитесь, что ваш инструментарий и движок или выбранная библиотека умеет это делать без дополнительной работы с вашей стороны.
Трезво оцените, готовы ли и хотите ли вы связываться с озвучкой на разных языках — цена будет заоблачной на фоне стоимости перевода и возникнет ворох новых технических проблем, но это сразу поднимает качество локализации на новый уровень.
Как мы будем это делать?
Перевод, который вы делаете, не статичен. Ваша игра будет развиваться, вы будете выпускать дополнения, что-то менять, что-то добавлять. Какие-то части будут переводиться заново. Подумайте о том, как вы будете это делать, в самом начале разработки. Есть как минимум три подхода, каждый со своими плюсами и минусами. Схемы ниже — частные случаи каждого из подходов.
Последовательно. Пока количество слов в вашем лок паке не превысило десятка тысяч слов, вы смело можете положить болт на любые сложности и последовательно заниматься локализацией на язык за языком. Минус такого подхода — время. Чем больше языков, тем больше времени у вас уйдёт. Плюс — простота.
Параллельно. Такой подход характерен для больших проектов, которым важна готовность большого числа языков к установленной дате и наличие большого числа переводов с одного базового языка на другие. После полной готовности основного языка запускается параллельный перевод на другие языки. Потом идет общая интеграция и LQA. Минус — дороговизна LQA и внесения изменений. Плюс — скорость, ценой большей сложности менеджмента процесса, особенно, если работу для вас выполняют несколько подрядчиков.
Каскадом. Гибрид первых двух методов — по мере готовности и стабилизации отдельных частей текста (например, глав игры или категорий UI) они направляются на перевод одна за другой так, что отдельные блоки текста переводятся и проходят интеграцию быстрее. Этот подход идеален, если вы используете несколько базовых языков или идёт последовательный перевод между парами, например с русского на английский, с английского на испанский и итальянский, с испанского на португальский. Плюс — скорость, с относительно дешёвое внесение изменений. Минус — высокая сложность менеджмента.
Инструменты
Translation memory (TM). Это ключевая технология для современных переводов не столько для экономии времени, сколько для снижения стоимости и повышения качества. Ни вы, ни ваши переводчики не должны тратить время на перевод одинакового текста, один и тот же исходный текст в едином контексте должен переводиться одинаково. Необходимость изменения ключей перевода (но не текста) не должна быть проблемой. Чуть ниже мы будем говорить про fuzzy — без ТМ это не работает. Мой последний опыт — 5,1% экономии за счёт использования TM, опыт моих знакомых руководителей отделов локализации показывает, что на крупных ММО проектах экономия может доходить до 25% — 30%.
Контроль повторов (Repetitions). Количество повторов легко может достигать 30-40% в большой игре и при грамотной обработке текста перед переводом можно свести эту величину до 50 — 60% от общего объёма текста. Свежий пример — прямо сейчас мы переводим одну ММО на английский и изначальный объём на перевод составил около 300 тысяч слов. Правильная настройка memoQ снизила объём до примерно 245 тысяч слов (около 20% или 6,5 тысячи долларов экономии).
Инструменты корректора (proofreading). Простая фильтрация, пометка и аналитика по объемам ключей и текста, которые уже прошли вычитку. Помогает понимать, какие ключи уже прошли проверку — это критически важно, если над переводом работает несколько человек.
Контроль изменений (fuzzy). Пометка и фильтрация ключей и текста, который изменился в исходном языке, с возможностью внести правки в язык перевода. Представьте, что у вас частично изменилась какая-то строка или в предложение добавилось одно слово. Вы точно не хотите, чтобы переводилось и оплачивалось всё предложение. Более того, зачастую мелкие стилистические изменения в одном языке совершенно не обязательно означают, что потребуется дополнительный перевод на другой язык.
Глоссарий. Контроль единообразия перевода в отношении переводов имён собственных, названий, в том числе географических, в едином формате и по единым принципам. Единый подход к переводу и правилам работы с придуманными словами (их зачастую много в любой игре с богатым сюжетом). Простота изменений таких слов и словоформ. Если на проекте работает несколько переводчиков одновременно — это критически важное требование. Если вы поленитесь его создать, то сможете увидеть в тексте разнообразные вариации перевода одних и тех терминов, на выпиливание которых нужно будет потратить Х времени и денег сверху.
Лайфхак: обычно, когда ты заказываешь перевод у агентства, ты отсылаешь им текст на оценку и получаешь от них количество слов или символов на перевод и стоимость, всё круто. Все нормальные агентства работают в каком-то САТ-туле (никто не переводит в вордах и экселях), их прибыль может составлять до 40-50% именно за счет повторов и fuzzy-совпадений (если уже есть наработанная ТМ). Когда вы идёте в агентство, говорите, что вы работаем только по статистике CAT (хорошо, когда у вас самих есть этот САТ, и вы можете перепроверить всю статистику), просите прислать расценки за fuzzy и за повторы. Обычно менеджер скрипит зубами, но идёт навстречу, а вы получаете совсем другие сметы.
Фильтрация глав, файлов, частей. Без этого сложно выполнять параллельный или каскадный перевод, сложно понимать, что отдельные части текста стабильны и готовы или прошли LQA.
Форматы loc pack. Загрузка и выгрузка в вашем формате loc pack или простая адаптация для вас процесса загрузки и выгрузки. Ну, или наличие API для автоматической загрузки и выгрузки данных.
Версионирование. Встроенное наличие версионности и/или возможности делать снапшоты. Критически важно, когда вы работаете с большим объемом изменяющегося текста.
Розовые очки
Я категорически призываю включать пессимиста, рационалиста и статиста до того, как решение о перечне языков для перевода принято. Зачастую даже перевод на несколько языков сопряжен с относительно высокими затратами и временем.
Представить создание и выпуск игр без переводчиков невозможно. При этом, простите, но навязчивее только композиторы — стоит где-то написать, что вам нужен перевод, и на почте можно поставить крест.
Агентства. Стоит помнить, что не существует ни одной компании, у которой была бы должная экспертиза во всех языках. Типичное агентство — это купленный CAT, найденные на Proz или профильных форумах переводчики, корректоры, редакторы, внятный менеджер и наценка в 20-40%. При этом собирать эффективную команду зачастую сложно. При прочих равных, не думаю, что обойтись без услуг агентства по переводу, которое обеспечивает полный цикл работы над текстом, можно в 100% случаев.
Переводчики. Есть достаточно большое количество хороших индивидуальных переводчиков, которые работают сами по себе, без редактора, и занимаются переводами игр. Выбор есть практически любых языковых пар.
Общайтесь со своими коллегами по индустрии! Попросите поделиться прямыми контактами переводчиков. Это в два раза дешевле по сравнению с агентствами, а люди заведомо будут понимать специфику работы с играми.
Краудсорсинг. Если вы чувствуете в себе силы — собирайте команду по пользовательскому переводу игры. Только снимите сначала розовые очки и сразу ответьте на вопрос, как будете решать вопрос редактуры, корректуры и LQA.
В своей последней игре с помощью комьюнити мы перевели игру на итальянский и португальский (совокупно чуть более 570 тысяч слов), не смогли — на корейский и испанский. Если вы сможете сформировать вокруг себя нормальное сообщество — всегда найдутся люди, которые помогут с таким переводом. Это работает даже когда перевод занимает многие месяцы и является сложным, главное трезво смотреть на вещи и помнить, что только вы сами отвечаете за все процессы и контроль.
Итак, услуги компаний, как правило, включают перевод и редактуру, легко можно заказать услуги корректора и LQA. Отдельные переводчики переведут вам игру, зачастую помогут пруфридингом, порой редактурой. Практически никогда качественным LQA. Комьюнити — перевод, намного реже корректура и очень редко качественная редактура, LQA — останется вашей головной болью.
Языки
Лайфхак, которым грешат многие агентства: заказываем перевод текста не нейтив-переводчику, а редактуру нейтиву — такой подход позволяет экономить до 30% по сравнению с полным переводом нейтивом. Качество — как повезёт.