Плагин Structure для Jira очень полезен в ежедневной работе с задачами и их анализом. Он выводит на новый уровень визуализацию и структуризацию Jira-тикетов. И все это доступно сразу «из коробки».

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

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

Привет, меня зовут Антон Фурсов, и я занимаюсь автоматизацией тестирования в Pixonic. Сегодня поговорим про уже набившую уже всем оскомину автоматизацию тестирования. В последнее время стало модно внедрять ее везде и всюду, но в геймдеве она до сих пор встречается не так часто — из-за специфики самой сферы.

Всем привет! Меня зовут Иван Звонарёв, Principal Game Designer в компании Pixonic. Сегодня я расскажу о том, что это за роль такая, какие на ней обязанности и какую пользу компании она приносит. Или, если говорить конкретнее, какие принципалу нужны навыки, за что непосредственно он отвечает на проекте, а главное — зачем нужен принципал, когда у нас есть лид.

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

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

Пожалуй, наиболее узнаваемый пример допуска такой свободы выражения — это правило 20%, выработанное в Google. В соответствии с ним, каждый сотрудник компании имеет право 20% рабочего времени — считай, один день в неделю — посвящать сторонним проектам, не связанным с основной деятельностью. Благодаря правилу 20% в свое время появились на свет такие проекты, как Gmail и AdSense, а также сотни мелких фичей, многие из которых ушли в open source. Вокруг этой методики раньше ходило много споров, но в самой Google она действует до сих пор, да и перенимали ее даже такие гиганты, как Atlassian и Apple — в последнем программа называется Blue Sky и позволяет сотрудникам на две недели отойти от своих обычных обязанностей в пользу чего-то нового. В LinkedIn это выродилось в программу InCubator, в рамках которой сотрудники могут пропитчить свой проект и в случае, если он получит «зеленый свет», заниматься им последующие три месяца.

У нас в Pixonic тоже есть похожая инициатива. Мы называем это техдни.

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

Эта статья написана по мотивам одноименного доклада, с которым я и моя сестра Алина выступали на конференции Talents in Games в декабре 2021 года. Я — дизайнер, сестра — разработчик, и уже четвертый год мы работаем в одной продуктовой команде. Сейчас наши команды хорошо ладят и научились решать конфликты, но путь к взаимопониманию и здоровым отношениям между дизайнерами и разработчиками для нас был непростым и довольно долгим.

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

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

Всем привет, нас зовут Василий Мешкой и Владимир Махныткин, мы продюсеры в студии Whalekit. В этом совместном материале мы расскажем, как наша команда настроила рабочий процесс, чтобы обновлять Left to Survive на лету и не прерываться на бинарные апдейты. 

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

В своей работе я часто опираюсь на ресурсный подход к дизайну систем, описанный Эрнестом Адамсом (Ernest Adams) и Джорис Дорманс (Joris Dormans) в книге Game Mechanics: Advanced Game Design. Это дизайн в абстракциях, который представляет игру как экономическую систему. Подробнее с ним вы можете ознакомиться в книге или на Machinations.io. 

А под катом я расскажу про основы такого подхода и приведу практические примеры, как его применять в дизайне классов для игр любого жанра — на основе Dungeons & Dragons 3.5 и гонок, которые мне когда-то доводилось разрабатывать. 

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

Чтобы упростить весь этот процесс, существует Enterprise Service Bus — архитектура, которая помогает навести порядок и облегчает межсервисное взаимодействие. 

Всем привет, меня зовут Даниил Солодухин, я программист в игровой студии ITT. В этом тексте я расскажу про особенности ESB, а также объясню, чем она полезна в работе.

Всем привет! Пришло время третьей, кульминационной статьи цикла про левел-дизайн. Ранее мы уже говорили об общих терминах и принципах производства локаций, но многим хотелось более существенного deep-dive. Сказано — сделано. Приготовьте блокноты, потому что местами придется записывать!

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

Всем привет, меня зовут Михаил Алексеев, я работаю программистом в студии ITT, пишу бэкенд на Java. Перформанс — это моя страсть, как и распределенные системы. Но еще больше я люблю, когда математика встраивается в перформансные цели и задумки.

В этом тексте я расскажу про разницу между Consistent и Rendezvous хэшированием, а также на примерах покажу, с какими проблемами мы сталкиваемся в работе.

Всем привет, меня зовут Александр Мастюгин, я работаю тестировщиком в студии Nord. В сфере IT бытует предубеждение, что работа тестировщиком — нудное и однообразное занятие. Но я с этим не согласен: на мой взгляд, это творческая, техническая и исследовательская деятельность. Чтобы выполнять эту работу хорошо, нужно погрузиться в задачу, понять все ее тонкости, сложности, разобраться, какие у нее есть подводные камни. 

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

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

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

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

Всем привет, меня зовут Лев, я геймдизайнер из WhaleKit. И в этой статье мы разберем две математические концепции: цепи Маркова и случайные блуждания. Сразу замечу, что статья скорее «поп», чем «науч», поэтому часть доказательств выведенных формул будет опущена. После теории мы перейдем к реальным кейсам, где эти инструменты могут пригодиться, например:

 1. Сколько сундуков откроет игрок, если из сундуков могут выпасть еще сундуки;
2. Сколько золота уйдет на прокачку меча, если меч может ломаться;
3. Какая вероятность победить в денежном поединке.

Если долго играть в онлайновые мультиплеерные игры с одним и тем же набором контента, это кому угодно быстро наскучит. Хочется, чтобы что-то новенькое постоянно будоражило интерес. Для этого существует много способов, один из которых — игровые ивенты. Кто-то проводит их с определенной периодичностью, привязывая только к конкретным событиям, а кто-то постоянно: закончился один — тут же начался другой. Как это делаем мы.

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

Меня зовут Даша Карманова, и я UI-дизайнер в Pixonic. В этой статье мы с моим коллегой Андрееем Лузановым расскажем о том, как мы  на проекте War Robots провели редизайн ивентового арта — одной из самых емких категорий UI-контента в игре.

Мы обсудим:

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

Однажды, если мне не изменяет память, в Нью-Йоркском университете кто-то сформулировал определение геймдизайна как «мотивирование игрока на определенные действия». Хорошая формулировка. По аналогии с ней, про левел-дизайн я бы сказал так:

Левел-дизайн — это мотивирование игрока на определенные действия через окружение, в котором существует управляемый персонаж. 

Почему мы отталкиваемся от определения геймдизайна — хотя, казалось бы, я должен отстаивать левел-дизайн как самостоятельную нишу? Всё очень просто: наша первая и основная задача — подкреплять в пространстве механики, заложенные геймдизайном. Давать игроку возможность поиграть. А «душную» поправку про управляемого персонажа я добавил тогда, когда в очередной раз услышал в обсуждении левел-дизайна споры про интерфейс. Давайте забудем про него на время прочтения этой статьи: все-таки UI почти всегда существует вне игрового пространства и не является инструментом левел-дизайнера.

А теперь, когда у нас есть определение, разберемся в сущности левел-дизайна. 

Откуда возникла эта ниша? Что левел-дизайнер отдаёт в результате работы над локациями? В этом мы и будем разбираться дальше в этой статье. А вообще их будет целый цикл, в котором я постараюсь охватить всю базу этой области геймдизайна от самых основ до приемов AAA-сегмента.

Эта история началась весной 2021 года.

Страдал от того, как медленно запускается Docker Desktop.

Страдал от того, сколько он ест оперативной памяти.

Страдал от того, что постоянно что-то ломалось при обновлениях.

Страдал от того, что на Windows Server надо устанавливать Docker через какой-то особенный механизм, не работающий через proxy и не работающий на Windows Server 2016. Причём в связи с тем, что Docker Inc. передала enterprise-сервис компании Mirantis, этот способ через какое-то время вообще перестанет работать. В результате вы получаете Docker, собранный из непонятно каких исходников. Всё, что про них известно — они точно не такие, как в Docker Desktop. Вообще, для инструмента, задача которого — просто скачать один единственный пакет и установить его, в трекере задач этого проекта на удивление много багов.

Страдал от того, что Docker Desktop прекратил поддержку Windows 10 LTSC 2019, которая продолжает поддерживаться Microsoft вплоть до 2024 года (а расширенная поддержка — аж до 2029).

И я спросил себя: а почему, за что, как так? Есть ли какая-то такая фундаментальная причина, по которой софт, решающий эту задачу, обязан доставлять столько неудобств? И не нашёл её. 

А потому подошел к проблеме по принципу: если тебя что-то не устраивает, сделай это лучше.

После чего быстренько придумал название проекту и создал репозиторий.

Я много работал с Docker-контейнерами под Windows и страдал.

Каким должно быть портфолио художника, который хочет работать в игровой студии? Что больше всего ценят рекрутеры и арт-лиды, сколько работ нужно показать и почему компания может отказать? Об этом на конференции TBD Pro: Art рассказали старший менеджер по подбору персонала в MY.GAMES Ольга Дёмина и креативный директор BIT.GAMES Антон Лунков.

Преимущества использования системы оркестрации контейнеров — удобство их развертывания, обновления и масштабирования. И одним из наиболее популярных таких инструментов является Kubernetes. 

Многие знают, что Kubernetes имеет встроенный механизм для автоскалирования подов — Horizontal Pod Autoscaling (HPA). Но что, если надо принимать решение с учетом множества факторов: суммы метрик, зависимости от количества готовых контейнеров, процента или доли доступных/недоступных подов или даже времени суток? А если эти показатели важны для нас все вместе? 

Мы в студии Whalekit смогли решить эту задачу. И отличным решением для этого стал Custom Pod Autoscaler (CPA).

Всем привет, меня зовут Сергей, я руковожу группой серверных программистов студии Whalekit и активно занимаюсь наймом в эту группу. Сервер пишем на Java — соответственно, нанимаем мы тоже джавистов.

В 2016 году мы выдавали кандидатам тестовое задание, успешным кандидатам назначалось техническое собеседование.

В 2018 мы добавили 45-минутный «мотивирующий на выполнение тестового задания» этап, чтобы кандидаты лучше понимали, соответствует ли вакансия их ожиданиям.

В 2021 мы полностью отказались от тестовых заданий.

Но обо всем по порядку.