Нашему мобильному шутеру Pixel Gun 3D уже 9 лет. За это время у проекта появилось немало блогеров, в основном, ютуберов. Некоторые становились популярными и могли влиять на мнение игроков, с ними мы время от времени выходили на связь, но регулярной работы не было.

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

В 2013 году, когда игры-сервисы были где-то в зачатках, мы продавали Pixel Gun 3D за доллар просто как прототип FPS-шутера. В игре была одна карта, одно оружие и два вида зомби, при этом она сильно цепляла эмоционально — игрокам приходилось выживать в ограниченном пространстве с постоянно появляющимися монстрами. Словом, адреналин зашкаливал (по этой же причине до сих пор популярны батлрояли). 

Проект выложили в стор и тут началось: огромное количество установок, оценок, отзывов. Вскоре он занял топ-1 в App Store среди платных игр. Мы совсем были не готовы к огромному потоку игроков, которые что-то советовали, писали развернутые фидбеки и всячески пытались выйти на контакт. 

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

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

Своими наблюдениями об игровых сюжетах поделился сценарист инди-игр, а мы перевели.

Дисклеймер: под катом идет мнение автора оригинальной статьи. Местами очень спорное, местами любопытное. Делитесь своим в комментариях.

До прихода в индустрию я искал материалы про QA в геймдеве, чтобы понять отличия от других областей. Результатов нашлось не много — обычно пишут про общие или абстрактные вещи, или о том, что это простой путь в геймдев, или рекламируют курсы. В итоге захотелось закрыть некоторые вопросы самому, так как на собеседованиях я вижу, что далеко не все представляют себе эту профессию на практике.

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

Довольно частая ситуация, когда с ростом проекта растёт и сложность его сборки. Широкий зоопарк технологий, сторонние компоненты, библиотеки, линтеры, серверный рендеринг и нюансы, связанные с конкретным проектом, — всё это в итоге приводит к тому, что конфигурация сборки достигает более тысячи строк.

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

Но если говорить о конфигурации сборки, то такая декомпозиция скорее редкость, и в больших проектах часто можно встретить огромные webpack.config.js, модификация которых может доставить немало проблем и привести к ошибкам.

Если вам хочется сделать работу со сборкой проще и надёжнее при модификациях, то добро пожаловать под кат.

Примечание: хотя статья адресована прежде всего одинэсникам, труЪ-программисты также могут узнать многие используемые методики или взять что-то на вооружение.

Одной из самых популярных и зарекомендовавших себя методологий программирования в 1С является так называемое ректальное программирование. Редкий проект внедрения и сопровождения учётных систем на платформе 1С обходится без его использования. Зачастую без знания данной методологии программистам даже бывает сложно найти работу в сфере 1С, потому что работодатели, особенно фирмы-франчайзи, в основном отдают предпочтение классическим, зарекомендовавшим себя методикам, а не новомодным заграничным веяниям.

Прим. Wunder Fund: в этой длииинной статье вы найдете ряд полезных советов по работе с Docker, как общего характера, так и Python-специфичных. Хоть мы и давно используем Docker в работе, про некоторые советы мы подумали "а что, так можно было?". Советуем вначале пролистать статью, и отметить штуки, которые покажутся актуальными для вашей текущей ситуации.

В мобильной разработке периодически возникают ситуации, когда нужно оценить время выполнения кода. Помимо теоретических подходов (например, Big O), которые позволяют отсеять очевидно неудачные решения, существуют бенчмарки для тестирования кода и поиска более мелких отличий. 

В этой статье расскажу, как устроена и работает библиотека Microbenchmark от Google, а также покажу примеры использования. С ней можно не только оценить производительность, но и решить спорные ситуации на код-ревью.

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

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