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

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

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

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

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

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

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

В играх существует огромное количество интерфейсов: инвентарь, диалоги, меню крафта и торговли, лобби, карта, деревья прокачки персонажа и его экипировки и многие другие. Все они позволяют игрокам взаимодействовать с представленными через интерфейс механиками, которые создатели игры заложили в свой продукт. И в этой статье мы подробно разберем один из самых важных элементов игрового UI: HUD (heads-up display).

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

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

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

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

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

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

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

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

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

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

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

Предыдущие статьи из цикла:

1. Левел-дизайн 101: язык разработки локаций
2. К ориентиру по хлебным крошкам, или базовые приемы левел-дизайна
3. Продвинутый левел-дизайн: киноприемы в играх, кор-луп и силуэты

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

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

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

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

Часто проблема возникает еще на этапе выбора метрик для анализа — традиционного набора из Retention, ARPU и конверсии в платящего может не хватить, чтобы сделать правильные выводы и построить планы для развития проекта. В этом тексте я хочу рассказать, как мы анализируем метрики для нашего mid-core шутера Left to Survive, а также поделиться собственными откровениями.

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

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

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

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

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

Но все-таки — что это такое? В чем заключается работа дизайнера филинга?

Меня зовут Игорь Журавлев, и я геймдизайнер филинга в Allods Team. И чтобы ответить на вопрос из предыдущего абзаца, мы рассмотрим, как понятие филинга вырастает из феномена игры и какое место занимает в структуре геймдизайна.

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

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

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

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

Потешу своё геймдизайнерское самолюбие и скажу, что у разработки игр и искусства много общего: ни та, ни другая область в достаточной мере не формализована и не изучена с научной точки зрения. Хотя попытки были: взять, к примеру, труд Иосифа Шиллингера «Математические основы искусств» из первой половины XX века.

Реальность такова, что при создании игры во многом приходится основываться на своих ощущениях, опыте, чуйке и косвенных признаках вроде обратной связи от игроков. Геймдизайн пока ещё не превратился в науку — и большой вопрос, произойдёт ли это когда-нибудь. Но думается, что каждый геймдизайнер хотя бы раз мечтал о методичке «Как сделать хорошую игру».

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

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

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

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

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

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

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

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

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

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

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

Мы обсудим:

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