Кто пишет клиенты для игр?

Привет! Меня зовут Альберт, я работаю инженером в геймдеве 6 лет.

Недавно заметил, что по какой-то причине, если спросить человека, интересующегося или работающего в гейдмеве, какие есть «виды» геймдизайнеров, большинство людей смогут назвать минимум штуки три (Level Designer, Technical GD, Combat GD, Narrative GD и так далее). Но вот если задать тот же вопрос про игровых программистов, в лучшем случае Вы услышите разделение на Backend и Client-девелоперов, и DevOps-инженеров. Это отчасти верный ответ, но есть одно «но».

Современная тенденция к усложнению игр ведет к специализации. Вместе с ростом индустрии, растет и сложность технологий. Если в «золотую» эпоху видеоигр, для создания крутых проектов хватало 10-20 талантливых девелоперов, современные ААА-тайтлы требуется сотни специалистов, которыми как-то еще нужно эффективно управлять. Поэтому девелоперы (и не только) разбиваются на команды по направлениям с конкретной ограниченной зоной ответственности, но с большим углублением в свою сферу.

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

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

В статье будет много англицизмов, потому что мне кажется не естественным склонение через апострофы (Programmer’а, Programmer’у), а русскими аналогами в реальной жизни никто не говорит. Да и не у всех терминов они есть, так что будет, например «геймплей программер», а не «программист игровой логики». Также слово «Programmer» можно смело заменять на «Engineer» или «Developer» — от этого смысл меняться не будет. Просто в разных компаниях используется разная терминология для одних и тех же ролей.

Я мог что-то пропустить, плюс индустрия не стоит на месте, так что этот список не будет актуальным всегда. Если вы заметили неточность — пишите в комментариях!

Я разделил клиентских разработчиков на 4 очень условные группы:

Из специальностей я выкинул слова Programmer и Developer, чтобы сократить табличку. Отдельно сбоку я разместил Backend, о котором не будет в этой статье. Снизу поставил DevOps и Билд Инженеров, как ребят, поддерживающих всю эту инфраструктуру.

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

Итак, поехали с самого интересного.

Это самый популярный и очевидный класс разработчиков игрового клиента — он занимается созданием и поддержкой игровых механик. Плотнее всего взаимодействует с геймдизайнерами, а точнее с геймдизайн-документацией. Задача геймлей программеров внедрять новые механики в соответствии с игровым дизайном, делая их гибкими, высокопроизводительными, расширяемыми и поддерживаемыми в будущем. Геймплей программерам важна «наигранность» в конкретном жанре и в целом, для упрощения понимания документации и коммуникации со специалистами других отделов. Иногда в геймдеве их называют обобщенным термином — Front-End Developer.

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

Программист Искусственного Интеллекта отвечает за оживление NPC в соответствии с тем, как дизайнеры хотят, чтобы они себя вели.

Часто написание AI ложится на плечи Разработчиков Геймплея, особенно если в игре очень примитивный AI, который работает прямолинейно и мало влияет на геймлпей. Однако, если игра напрямую завязана на взаимодействие с ИИ, как например, в шутерах, гонках или RTS, современная планка качества игр просто не даст шанса стать популярной игре с предсказуемыми, нереалистичными, скучными или глупыми ботами.

Помимо написания логики в лоб, существует два самых популярных подхода к гибкому заданию поведения ИИ — это Behaviour Tree или GOAP.

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

Зона ответственность Сетевых Программистов — клиент-серверное взаимодействие игры. Больше всего контактируют с командой бекенда и геймдизайнерами. Их задача писать мультиплеерную составляющую игры такой, чтобы для всех игроков UX не отличался от локальной игры.

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

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

К этому еще и добавляется необходимость держать запросы легковесными. Cпайки от сериализации/десериализации тела клиент-серверных запросов вполне могут создавать просадки FPS. Особенно это касается лоу-енд девайзов и жирных запросов, например получения/отправки профиля игрока.

В мультиплеерных соревновательных играх проблемы схожие, только основаны они не на игре оффлайн, а на пинге. Это интерполяция/экстраполяция позиций между полученными кадрами, предикт поведения систем (нанесения урона, активации способностей) с последующим откатом, если сервер посчитал иначе, детерминированная симуляция физики, чтобы и у всех игроков, и на сервере, объекты разлетались одинаково и пр. На это накладывается то, что события, которые транслируются с сервера на самом деле происходят не сейчас, а некоторое количество времени назад, так как запросу нужно дойти от сервера к машине игрока. Неудивительно, что для решения проблемы неравномерного и высокого пинга Riot Games прокладывают свои оптоволоконные магистрали по всему США.

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

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

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

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

Специальность Tools Programmer часто используется как точка входа в индустрию, так как обычно при разработке тулзов не нужно задумываться об общей архитектуре игры. Проблемы с зацеплением кода описанной выше здесь почти никогда не возникает: тулзы обычно компактные по функционалу и независимые друг от друга. Также часто они зависят от существующего кода игры, но от их кода не зависит никто, так что баг в логике тулзы не приводит к каскадным ошибкам в самой игре. Но взглянув на популярные ассеты из Unity AssetStore или Unreal Marketplace, становится понятно, что и будучи разработчикам тузлов тоже есть куда развиваться.

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

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

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

Автоматизаторы Тестирования (QA Automation), они же Инженеры-тестировщики создают сценарии — авто-тесты и системы для поиска проблем и ошибок. Чаще всего они пишутся на том же языке, что и основной код игры. При этом особое внимание уделяется автоматизации объемных рутинных задач, на которые уходит большая часть времени и сил, такие как полное прохождение игры.

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

Автоматизация тестирования как направление развивается еще с 80х и давно является стандартом в интерпрайзе. Однако в геймдеве это скорее исключение из правил, и повод для гордости «взрослым» подходам к разработке ПО. К счастью, в последнее время тема становится всё популярнее и востребованнее.

Редкость использования автоматизации в геймдеве обусловлена тем, что она не всегда является выгодной для работодателя. Причины этого в отсутствии универсальных инструментов, времязатратности написания тестов, их отладки и борьбы с миганием (flaky tests), а так же необходимости задействовать программистов для написания дополнительной игровой логики. Помимо этого, результирующие автотесты получаются очень хрупкими. Они часто ломаются при малейших апдейтах игры, так что нужно учить и заставлять всю команду разработки чинить за собой. А это особенно затруднительно, учитывая, что ломают тесты не только программисты. Написанные тесты очень редко остаются статичными - по мере разработки игры в любом случае приходится возвращаться к старым тестам, чтобы обновить их, и чем больше тестов уже было написано, тем больше времени занимает этот процесс.

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

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

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

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

Рендер-программеры, они же Графикс-программеры (Graphics-Programmer) — крутые дядьки, которые позволяют играм выглядеть так, чтобы за них не было стыдно. Игра должна и передавать видение, заданное арт-директором, и работать на широком диапазоне видеокарт, и еще, не дай Бог, соответствовать современным стандартам фотореалистичности, если того требует стилистика игры, при этом выдавая стабильно высокий FPS. Если кратко — Рендер-программеры занимаются разработкой пайплайна рендеринга игры, а также его оптимизацией.

Рендер-программистам обязательно иметь идеальные знания линейной алгебры, разнообразных техник рендера, а также архитектуры и особенностей графических процессоров (GPU), поддерживаемых игрой.

Работа с GPU осуществляется через специальные API, которые инкапсулируют под собой особенности архитектуры конкретных видеокарт, позволяя «общаться» с ними через унифицированный интерфейс. Обычно это DirectX (для Windows и Xbox), OpenGL (для PS, Windows, Linux и Android) и NVN (для Nintendo Switch). Относительно недавно к ним присоединились Metal (iOS, macOS) и кроссплатформенный Vulkan (наследие OpenGL). Поддержка этих API осуществляется производителями самих видеокарт — то есть nvidia и AMD сами заботятся, чтобы их чипы поддерживали все команды последних версий графических API. Новые фичи, такие, как RayTracing или Geometry Shader (шейдеры, способные обрабатывать одновременно массивы вершин) появляются в новых версиях графических API вместе с новыми поколениями видеокарт. Соответственно, графикс-программеру нужно быть в курсе всех этих изменений во всех графических API, чтобы игра выглядела одинаково, как на DirectX 12, так и на OpenGL 4.6 (с разными наборами API), да и в случае необходимости можно было переключиться на DirectX 11, не сильно просев в качестве картинки и производительности.

Графикс-программер — это также достаточно редкий покемон. Чаще всего он является частью команды разработчиков движка, но также встречается и в играх на Unity/Unreal с самобытным визуальным стилем. Если графика в игре достаточно стандартная и не слишком сложная, нужды в Рендер-программере нет, а шейдера в основном пишет VFX Programmer или Technical Artist.

Задача VFX Программера — создание визуальных эффектов. Во многом его обязанности пересекаются с Текникал Артистом, но с бóльшим упором в программирование и меньшим в построение workflow интеграции ассетов. Он, как и Render Programmer, пишет и оптимизирует шейдера, но не разрабатывает сам рендер-пайплайн. Также в отличие от рендер-программера, который занимается low-level вещами, VFX Programmer работает на высоком уровне: задает логику партиклов, пишет шейдера под конкретные игровые ситуации и пр.

Помимо непосредственного создания эффектов, VFX программеры делают тулзы для их контроля и настройки художниками. Помимо технических навыков и идеального знания линейной алгебры, VFX программерам нужно обладать также и художественным вкусом, знать Photoshop (как минимум быть способным нарисовать спрайт для эффекта или затайлить существующую текстуру) и уметь пользоваться любым 3D-пакетом хотя бы на базовом уровне (Blender, 3DS Max, Maya). В зависимости от проекта может требоваться, например, знание Houdini — пакета для процедурной генерации и симуляции почти чего угодно — от разрушений твердых тел, до реалистичного поведения тканей, жидкостей и газов.

Задача Билд Инженеров — обеспечить сборку игры под все целевые платформы.

В проектах на кастомных движках, они — неотъемлемая часть команды Engine-программистов. Но и в разработке на готовых движках билд инженерам часто есть чем заняться. В начале разработки достаточно нажать на кнопку Build, чтобы получить сборку игры. Но тут же появляется желание вынести этот процесс на CI (сборка автоматических билдов на удаленном агенте), чтобы не блокировать машину разработчиков. Потом — слать нотификации об успешном или неуспешном билде в Slack/Teams. Потом — разделить на две хоть и схожие, но разные конфигурации для Dev и Prod билдов, заливать в TestFlight/AppCenter для тестирования, собирать ассет-бандлы, прогонять тесты, выгружать логи, автоматически поднимать версию, прокидывать в игру хеш коммита, ветку и дату сборки билда, автоматически заливать его в сторы, и так далее, и так далее. При этом хочется иметь хорошую архитектуру, позволяющую не дублировать код и удобно расширять функционал, а также иметь возможность использовать всё написанное для всех проектов игры одновременно, с возможностью быстрого деплоя новой версии вашего Build Tool для одной или нескольких игр независимо.

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

Вот и все. Спасибо, что дочитали, я знаю, это было сложно, статья получилась действительно объемной!

Если я что-то забыл или в чем-то ошибся — пишите свои замечания и дополнения в комментариях! Так же если у вас остались вопросы — с удовольствием на них отвечу в меру своей компетенции.

До новых встреч!