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

Когда команда увеличилась вдвое, а работы кратно прибавилось, старые процессы перестали работать. Мы могли запросто утонуть в операционке, если бы вовремя не начали меняться.

Материал для тех, кто задумался о долгосрочном планировании или только начал выстраивать процессы у себя. Внутри я подробно рассказал про наш опыт: как мы целиком обновили воркфлоу разработки, внедрили Jira, систему оценки фичей ICE, методологию планирования GIST, а также целую пачку новых инструментов и гуглдоков. Теперь мы на несколько месяцев вперед точно знаем, что будет в проекте. 

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

В этой статье расскажу о том, как мы обновили сетевой код для собственной королевской битвы на Unity, ввели систему сетевых чанков, контролируемый рандом и в результате сократили траты на сервера на 20%.

Мы уже рассказывали, почему первая версия архитектуры игры не была идеальной. Pixel Gun 3D изначально был прототипом в новом для команды жанре PvP-шутер. Хотели протестировать идею, чтобы собрать фидбек от игроков, но популярность игры начала расти достаточно быстро — писать ее заново было уже поздно. Сейчас подход к разработке новых проектов у нас сильно изменился, но зато тогда, без опыта, мы не потратили уйму времени на создание прототипа, который мог оказаться неинтересным для игроков.

С ростом функционала приходилось «на лету» менять архитектуру, делать ее масштабируемой, а также реализовать нашу идею — сделать шутер без даунтаймов даже во время технических работ или форс-мажора.

Далее сравним серверную архитектуру проекта несколько лет назад и сейчас, а также расскажу, как мы добивались дополнительной стабильности с помощью аварийных режимов с рубильниками для серверов.

Однажды в своем PvP-шутере мы за один день потеряли 30% от 60 тысяч одновременного онлайна. Это был 2018-й, в тот день на iOS вышел Fortnite. И хотя хайп был уже около года, а PUBG регулярно бил рекорды, без королевской битвы нам жилось вполне спокойно. Но тут стало очевидно, что батлрояль нельзя игнорировать, игрокам он нравится и нужно разрабатывать свой.

За два месяца мы проделали много интересной и сложной работы. Например, сделали свой редактор террейна, чтобы отрисовывать ландшафт не в 500 тысяч треугольников, как это делал Unity Terrain, а всего в 30 тысяч. Или написали мешбейкер, сократив количество запросов на отрисовку с 800 до 100, а освещение научились запекать за 5 минут вместо 30 часов. 

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

Несколько лет назад в нашем онлайн-шутере столкнулись с немного абсурдной проблемой: контента стало так много, что мы уже не могли с ним работать вручную. Сотни единиц оружия, карт, механик, гаджетов и много чего еще — все нужно балансировать между собой, иначе геймплей развалится на части. Можно нанять больше людей, но лучше прибегнуть к алгоритмам, формулам и автоматизации.

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

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

Онлайн-проекты рано или поздно сталкиваются со взломом внутреннего стора, когда читеры накручивают себе игровые предметы, оружие или валюту. Классика. Наш PvP-шутер не стал исключением — брешь мы в итоге закрыли, хотя и пришлось повозиться.

В этой статье расскажу про интеграцию и серверную валидацию инаппов с точки зрения клиента: какой плагин использовать для Google Play и на что обращать внимание независимо от платформы, а моя коллега поделится кодом серверной части.

В прошлом году мы добавили в мобильный PvP-шутер режим Imposter по мотивам игры Among Us — переработанную и переосмысленную в 3D мини-игру с новыми механиками и фичами. Она стала популярным местом входа в игру даже среди тех, кто раньше не слышал про Pixel Gun. Другой пример: когда зарелизился Fortnite, мы за один день потеряли треть онлайна, и чтобы вернуть игроков, сделали свою реализацию батлрояля. Решение сработало — оказалось, им просто не хватало королевской битвы. То есть тренды, это не просто желание хайпануть — это возможность разговаривать с аудиторией на их языке.

А вот можно ли запрыгнуть в уходящий поезд и нужно ли следить за трендами инди-разработчикам — это вопрос. Попробую рассказать на примерах.

Когда-то нам пришлось полностью переработать защиту популярного PvP-шутера. Результатом стал ряд инструментов, которые мы готовили и зарелизили одновременно, чтобы не дать читерам возможность постепенно отслеживать апдейты. 

Про «первые» пять решений — обфускацию, хранение данных, миграцию прогресса и систему бана — шла речь в этой статье. Сегодня расскажу про остальные, а именно: 

• Защита от измененных версий.
• Photon Plugin.
• Серверная валидация инаппов.
• Защита от взлома оперативной памяти.
• Собственная аналитика.

И немного про то, почему так важен был одновременный релиз всех решений.

Огромное количество игр построено на сервисной поддержке, будь то тактический шутер Rainbow Six Siege или большая ролевая World of Warcraft. Игроков постоянно вовлекают ивентами, игровыми режимами, картами, персонажами или перками. Но когда в проекте уже сотни и тысячи единиц контента, а релизы ежемесячно — это может стать проблемой для разработчиков.

В какой-то момент мы тоже с этим столкнулись в мобильном PvP-шутере и пришлось искать решение. В итоге полностью пересмотрели пайплайн создания контента и оптимизировали процессы так, чтобы одна гугл-таблица заменила нам таск-трекеры. О нашем опыте на проекте со 170 млн инсталлов и 1 млн DAU подробно расскажу под катом.

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

Итак, эти шаги:

• Обфускация.
• Хранение данных.
• Миграция прогресса.
• Система бана.
• Подсчет хеша всех библиотек.
• Защита от переподписывания версий.
• Photon Plugin.
• Серверная валидация инаппов.
• Защита от взлома оперативной памяти.
• Собственная аналитика.
• И одновременный релиз всех решений.

Сегодня поговорим про первые пять пунктов.

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

Несколько лет назад мы написали тестовый прототип шутера, который быстро стал популярным — защиты никакой не было, и некоторые побежали этим пользоваться. Мы затыкали пробоины скотчем, читеры находили новые дыры, а мы учились у них — с помощью социальной инженерии и повышения технических навыков. И в итоге пересмотрели отношение к защите будущих мобильных проектов (об этом — в конце статьи).