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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет! Эта статья — первая в блоге MY.GAMES, международного разработчика и издателя видеоигр. Здесь мы объединим наработки и экспертизу всех 14 наших игровых студий. Впрочем, будем рассказывать не только о внутренней кухне экосистемы MY.GAMES, но и о том, чем живет геймдев в России и мире в целом, о современных трендах и новостях индустрии. 

Меня зовут Андрей Боронников, и я работаю в команде экспериментальных проектов студии IT Territory, где занимаюсь разработкой игровых прототипов. Как-то раз в процессе поиска новых подходов к быстрой разработке прототипов мы вспомнили о таком замечательном подходе, как Entity Component System. О нем уже многое было раньше сказано, но мало что показано. 

О чем сегодня пойдет речь?

Для начала мы поговорим, куда в общем и целом движется Unity и зачем им Data Orientation System. Рассмотрим принцип работы ECS, зачем он нужен, кто вообще его использует и наиболее популярные реализации — и, конечно же, примеры практического применения ECS в играх.

Рынок облачного гейминга в России развивается ударными темпами. Здесь у нас и Loudplay, и MY.GAMES Cloud (ех. Playkey), GFN.ru. Мобильные операторы связи тоже находят свою выгоду и заключают партнерские соглашения с перечисленными сервисами, запуская собственные проекты. Так поступила «Вымпелком», запустив Beeline Gaming, а вслед за ней — МТС, Мегафон и Tele2. Особых проблем запуск таких сервисов не доставляет — ведь они реализованы на основе платформ партнеров, которые давно отлажены и работают как нужно.

Год назад мы в Playkey стали частью MY.GAMES, вложив технологию своего облачного сервиса в основу MY.GAMES Cloud. Все это время сервис находится в состоянии soft launch. А недавно объявили о своем партнерстве с AMD, в рамках которого адаптировали протокол передачи видеопотока сервиса и будем тестировать видеокарты AMD Radeon™ RX 6700 XT на своих серверах. В чем профит этого партнерства для конечного пользователя, почему мы остановились именно на AMD, а не NVIDIA с их мощной трассировкой лучей, а также о том, насколько эта технология критична для игр, запускаемых через стриминговые сервисы, разбираемся в статье.

Пару часов назад прямо во время The Game Awards Epic Games выпустила бесплатное демо Unreal Engine 5 для Xbox Series X|S и PS5, предзагрузкой которого компания дразнилась еще в начале недели.

Отчасти снятое с реальными актерами, отчасти воссозданное в игровом движке, демо создано при участии членов оригинальной команды кинотрилогии «Матрица», в том числе Ланой Вачовски, Джеймсом МакТейгу и Джоном Гаэтой, в сотрудничестве с командой Epic Games.

Демо, конечно, впечатляет, показывая нам во всей красе, что нового предлагает нам UE5, а также как он выглядит и работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы не допустить всего этого, в игровых студиях есть Art Design Document (ADD) — свод правил и рекомендаций по работе художников. Там перечислены арт-решения, которые формируют визуальный облик игры, позволяют добиться единообразия стиля, упрощают онбординг новых сотрудников и гарантируют сохранения оригинальной задумки даже через годы развития проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы обсудим:

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

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

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

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

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

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