Несколько месяцев назад к нам в офис приехал 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 тоже есть похожая инициатива. Мы называем это техдни.

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

Как и в первой части нашего рассказа, мы поговорили с несколькими сотрудниками из наших студий о том, как они попали в геймдев: кто-то работал в банке, кто-то в МВД, а кто-то уже в детстве создавал 4Х-стратегии, но к разработке игр пришел через службу поддержки. Подробнее об этом — читайте ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы обсудим:

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

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

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

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

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

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

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

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

В управлении проектами часто возникает вопрос: как лучше спланировать последовательность работ разных отделов, убедиться в отсутствии оверкапа по капасити, да и вообще понять критический путь будущего релиза? Желательно ещё и визуализировать все эти планы. Ко всему этому, часто бывает, что нужно внезапно и быстро переработать утвержденное ранее.

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

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

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

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

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

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

Обо всем этом — читайте ниже.

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

О дефиците железа, IDFA и 5G, влиянии пандемии и статистике в цифрах — обо всем этом подробнее под катом.

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

В какой-то момент мы в War Robots столкнулись с необходимостью оптимизировать экран акций: обнаружилось, что для отрисовки этого экрана Unity совершала более 300 батчей. Для сравнения: куда более сложный экран ангара, содержащий 3D-сцену, 3D- и 2D-интерфейсы, эффекты и анимации, рисовался примерно за 100 батчей.

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

В геймдеве только и разговоров, что о ремастерах. Уже на протяжении долгого времени мы рассказываем о том, как они создаются, на примере своего опыта с War Robots: о разных аспектах от препродакшна до внешних тестов и нового пайплайна разработки карт. Логично предположить, что изменение в стеке технологий требует совершенствования и внутренних процессов. 

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

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

Раньше на проекте  War Robots у нас был устоявшийся и вполне рабочий пайплайн по импорту текстурных массивов, на выходе которого мы получали массивы в конечном формате (ASTC, ETC2), отлично удовлетворяющие нашим требованиям для мобильных платформ. С этим все у нас было хорошо — до поры. Проблемы начались тогда, когда возникла необходимость релиза на ПК. 

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