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

Прежде чем перейти к подробностям и блок-схемам, рассмотрим основной управленческий состав и разберемся в классификации специалистов.

Сейчас пойдут разные аббревиатуры из С – Level, и для начала стоит разобраться, как они формируются. Название должности состоит из Chief, дальше пропуск, Officer. На месте пропуска – слово, которое как раз и обозначает сферу деятельности, например Technical, Marketing, Executive, Financial и так далее.

CEO (Chief Executive Officer) – главный исполнительный директор. В российских организациях это, как правило, генеральный директор или руководитель. Он занимается управлением, а у него в подчинении находятся все руководители, сам же он является высшим должностным лицом. CEO относится ко второму уровню управления. Он определяет стратегию развития, принимает ключевые решения и, как правило, является публичным лицом для внешней среды. Он несет ответственность за работу компании в полной мере, как фактическую, так и законодательную, и подчиняется только совету директоров.

CMO (Chief Marketing Officer) – директор по маркетингу. Определяет и утверждает маркетинговую стратегию компании. Это высшее должностное лицо, которое руководит всеми маркетинговыми службами организации. Он запускает новые продукты на рынок, управляет маркетинговыми исследованиями и коммуникациями, ценообразованием и выстраиванием клиентского сервиса.

CFO (Chief Financial Officer) – финансовый директор или вице-президент по финансам. Финансовый директор может быть выбран из состава совета директоров предприятия. Аналогом этой должности может быть и главный бухгалтер. Он отвечает за управление финансовыми потоками, бюджетное планирование и за составление финансовой отчетности. Финансовый директор принимает решения с учетом задач и политики компании. Подчиняется CFO генеральному директору либо президенту компании.

CAO (Chief Accounting Officer) – главный бухгалтер. Главное отличие от прошлой должности в том, что главный бухгалтер является аналогом CFO в небольших компаниях, где на него ложится расширенный функционал. Задача CAO – ответственность за все аспекты бухгалтерского учета. Он осуществляет детальный контроль за рациональным использованием средств предприятия. Он также ответственен за сохранение собственности компании, отчасти контролируя финансовое планирование.

CIO (Chief Information Officer) – директор по информатизации. Это IT-директор, который непосредственно с самой сферой IT не связан. Он занимается внедрением информационных технологий и осуществляет их техническое обеспечение, отвечая за информационную сферу. То есть, другими словами, это специалист из руководящего состава, который управляет информационными ресурсами и технологиями организации. Подчиняется финансовому директору или CEO.

CVO (Chief Visionary Officer) – исполнительный директор. Это директор по развитию или вице-президент, который, как правило, еще и состоит в совете директоров. Отвечает за создание планов экономического развития и руководит деятельностью организации, которая закреплена в рамках договоров с другими компаниями. Подчиняется CEO.

COO (Chief Operating Officer) – операционный директор, он же исполнительный директор. В отличие от CVO, отвечает непосредственно за повседневные операции и текущую деятельность компании, а не занимается стратегическим планированием. Его задача – это контроль эффективного использования инструментов оперативного менеджмента. Обязанности при этом могут разниться в зависимости от структуры компании, тем не менее основной вектор COO – оперирование. Подчиняется CEO.

CSO (Chief Security Officer) – директор по безопасности. Отвечает за общее соблюдение безопасности компании и охватывает практически все сферы ее деятельности. Занимается как обеспечением физической безопасности, так и информационной. Подчиняется CEO.

CTO (Chief Technology Officer или Chief Technical Officer) – технический директор. Это главный инженер или руководитель, который отвечает за разработку и развитие новых продуктов. Отвечает за техническую часть производства и за создание и продвижение продукта с точки зрения технологических процессов. Подчиняется CEO.

CDO (Chief Data Officer) или CRO (Chief Risk Officer) – принцип расшифровки аналогичен: директор по… А дальше смотрим, какая сфера деятельности указана в должности.

Немаловажным является и то, что аббревиатура может по-разному расшифровываться. Стоит иметь в виду, что, например, CMO может означать еще и главврача (Chief Medical Officer), а не директора по маркетингу. Тем не менее, с учетом того, что у нас речь идет все же о геймдев-компании, а не о медицинском центре, все-таки CMO – это про маркетинг, а не про лечебное дело.

Если с управленческим составом все более-менее понятно, то настало время разобраться с уровнями разработчиков. Всего их три: Junior, Middle и Senior.

Если совсем просто объяснять разницу между уровнями, то Junior – это новичок, ограниченный в навыках, который не может обойтись без помощи. Специалисту, чья квалификация соответствует уровню Middle, помощь практически не нужна. Специалист уровня Middle – это уже опытный разработчик, знающий специфику своих задач. Senior способен помочь всем с их задачами и обладает высочайшем уровнем экспертизы. Как правило, Senior является руководителем остальных разработчиков, собеседует новоприбывших сотрудников, знает, как решаются поставленные задачи, и может объяснить их решение. Конкретное наполнение уровней зависит от стека технологий, который используется в компании.

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

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

Senior-разработчик – это ментор и тимлид с широким кругозором. Ему можно поручить руководство разработкой нового продукта или направления. Такой специалист знает несколько языков программирования, может с нуля реализовать архитектуру проекта, выбрать стек технологий, подходящий под техническое задание с учетом будущего развития проекта. Он постоянно изучает новые технологии и решения, появляющиеся в индустрии, сравнивает инструменты и находит плюсы и минусы каждого решения. Он уже руководит подразделением, при этом являясь экспертом с высокой квалификацией. Senior обладает вижном, каким должен получится продукт, каким обладать функционалом и как работать. Разработчик с широким кругозором.

Среди уровней есть и свои подуровни. Помимо Junior, есть Junior+ и Junior++. Аналогично и с Middle. А вот Senior только один, так как этот уровень считается высочайшим. Остальные специалисты растут внутри команды: есть определенный набор зафиксированных требований, при выполнении которых происходит рост уровня. Что-то вроде OKR (Objectives and Key Results).

Переход между уровнями происходит каждые полгода, а изначальный определяется на собеседовании. Уровень разработчика определяется тимлидом, который и определяет цели, которых разработчик должен достичь, а также проверяет достижение тех, которые уже были определены. Переход уровня Middle на Senior определяет уже СТО. В этом могут участвовать и другие разработчики – например, выдвинуть кандидатуру коллеги и принимать решение расширенным составом.

Теперь разберем, как выглядит схема управления геймдев-компанией. Во главе стоят CEO и инвесторы. Последние имеют прямое отношение к финансированию проекта, и это те, перед кем отчитывается CEO. Далее идет продюсер, который готовит отчеты для CEO и напрямую взаимодействует с проектным менеджером, главой отдела гейм-дизайна и руководителем арт-отдела. Каждый из них отвечает за свои блоки. ПМ отвечает за блок разработки, куда входит ведущий разработчик, левел-дизайнер, разработчик инструментария и разработчик игровой логики. Глава отдела гейм-дизайна (он же ведущий гейм-дизайнер) отвечает, как несложно догадаться, за блок дизайна. В этот блок входят гейм-дизайнер, сценарист, художник-концептер и раскадровщик. Руководитель арт-отдела, или арт-лид, отвечает за блок разработки 2D- и 3D-графики. Двухмерной графикой занимаются художник по персонажам, художник по окружению, художник по эффектам и художник графического интерфейса. Трехмерной – художник по текстурам, 3D-моделлер, специалист по скелетной анимации и 3D-аниматор. При этом множество специалистов постоянно взаимодействуют между собой как внутри отделов, так и между отделами в зависимости от пересечения задач и функционала. Например, художник-концептер взаимодействует с художником по персонажам, композитор постоянно взаимодействует как со сценаристом, так и с художником по окружению, а саунд-дизайнер – с художником по эффектам. Такая схема позволяет выстроить оптимальное взаимодействие внутри компании-разработчика: блоки задач делятся между отделами, а разные специалисты могут подключаться к ним в зависимости от хода разработки и необходимости вносить свою лепту. Эта схема была составлена гейм-дизайнером Бадом Лейсером, который использовал для ее референса реальную действующую студию.

Если прошлая схема была сделана на основе одной из действующих студий, то теперь стоит рассмотреть общую схему, которая релевантна для любой инди-студии и вписывается в базовую модель взаимодействия любой геймдев-компании. Как и в первом случае, во главе управления проектом находится руководящий состав, к которым относят не только директора проекта (в прошлом случае это был CEO), но еще и ПМ, и продюсера, не разделяя блок «Руководство» по иерархии. Далее идут блоки «Технический», «Дизайн» и «Арт», каждый из которых возглавляет свой лид, который и обеспечивает управление своим подразделением. К техническому блоку относятся программисты, которые по иерархии делятся на вышеупомянутые уровни Junior, Middle и Senior. В блок дизайна входят дизайнеры с такой же системой уровней. Блок «Арт» подразделяется на художников и аниматоров, принцип с уровнями остается тем же. Это основные блоки основной команды проекта, однако за ее пределами находятся QA, программисты промежуточного программного обеспечения, вся команда саунд-дизайна, а также аутсорс – на него приходятся 2D- и 3D-художники, аниматоры, сценаристы, актеры озвучки, локализация и все остальные, кто может быть задействован с использованием удаленного формата.

Следующая схема отображает, кто из специалистов с кем взаимодействует и кто к какому направлению относится: дизайн, программирование, производство контента, маркетинг и постпродакшн. Видно, как взаимодействуют между собой разные подразделения и как строится разработка игр изнутри. С ней имеет смысл подробно ознакомиться и, в частности, обратить внимание на то, какие специалисты взаимодействуют между собой. Например, художник-концептер взаимодействует с дизайнером по персонажам, а также с художником по окружению, так как его работа является для них отправной точкой, а уже на основе их работы задачи ставятся 3D-моделлеру, художнику по текстурам и аниматору. Без гейм-дизайнера не сможет работать UI/UX-дизайнер, а без сценариста – саунд-дизайнер и актеры озвучки. Обратим внимание и на то, что, прежде чем выйти в релиз, игра проходит сначала альфа/бета-тест, QA и фокус-группы, и только затем к основной работе подключается маркетинг, а уже после этого начинается дистрибуция.

Ранее мы уже обращали внимание на то, что сейчас к разработке игр привлекается много «удаленщиков», используется большое количество аутсорса: у популярных движков есть собственные магазины, как и большие комьюнити, которые предлагают и генерируют большое количество контента. Готовые звуки, паки моделей и арта есть в свободном доступе и распространяются бесплатно или требуют крайне умеренных и незначительных вложений. Более того, даже саундтреки можно собирать из готовых треков, просто приобретая лицензию на распространение неограниченного числа копий конечного цифрового продукта. Озвучкой игры и переводом тоже могут заняться соответствующие студии в лице подрядчиков, а маркетинг – и вовсе полностью взять на себя издатель. Все будет зависеть от того, по какому пути пойдет сама компания или студия-разработчик и какую модель работы для своих задач сочтет наиболее эффективной. Обычно все упирается в бюджет. В зависимости от сроков и возможностей команда проекта может включать в себя всех вышеперечисленных специалистов и даже еще более узкоспециализированных, если речь идет о больших ААА-проектах. ФОТ (то есть фонд оплаты труда) и маркетинг – это основная нагрузка на закладываемые расходы. Очевидно, что ФОТ будет расти параллельно увеличению сроков разработки. Отметим, что расходы на маркетинг нередко могут составить до половины общего бюджета. Поэтому важно при составлении сметы учитывать упомянутые «острые углы», на которые стоит обратить внимание в первую очередь. Необходимо также учесть и заложить все риски и непредвиденные расходы с поправкой на эти две статьи. Чем больше будет проект, тем больше вероятность того, что в силу тех или иных обстоятельств придется использовать средства сверх бюджета. В такой ситуации, еще раз повторю, особо важно заложить эти риски в смету сразу, это точно не будет ошибкой. Самое плохое, что может случиться, – это ситуация, когда компания не потратит лишние деньги и в итоге сможет пережить это спокойно и безболезненно.

Из своего опыта работы над проектами в игровой индустрии я могу привести несколько примеров и показать, как система взаимодействия выстраивалась там. Это уже знакомые «БУКИ», о разработке которой рассказал Станислав Лаук-Дубицкий, а также моя собственная серия игр Guard of Wonderland, которая пережила за все время своего существования три разных итерации со сменой жанра и платформ. Остальные два проекта будут не из сферы разработки, однако имеют прямое отношение к игровой индустрии – это Fan Fest, о котором уже упоминалось, и массовое мероприятие популярной культуры «Битва за науку’21» – финал киберспортивного турнира, который проводился нашей командой по заказу Министерства науки и высшего образования РФ.

Guard of Wonderland

Я уже упоминал, что игру Guard of Wonderland разрабатывал дуэт из двух студий, между которыми были распределены обязанности. На схеме выше подробно показано, кто за какие направления отвечал по трем основным блокам – контент, оперирование и технический блок. Чаще такая система характерна для схемы «издатель —> разработчик», в которой каждая из сторон берет на себя выполнение конкретных блоков работ, либо это может быть небольшой состав кор-команды, которая закрывает остальные блоки через аутсорс. В нашем же случае две студии работали в тандеме по общим документам, распределяли доходную часть между собой и сами закрывали бюджет проекта по своим блокам.

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

Guard of Wonderland VN, VR

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

Общей чертой в обоих случаях было то, что все версии игры всегда разрабатывались инди-студиями – небольшими командами, которые используют нестандартные подходы. Например, один специалист может закрывать сразу несколько задач, которые находятся в разных блоках. В случае с Guard of Wonderland мной осуществлялся базовый гейм-дизайн, работа со всей проектной документацией, сценарий, локализация и в том числе некоторый дизайн по визуалу. В инди-среде считается нормальным, когда программист отвечает за гейм-дизайн, художник закрывает все задачи по арту, включая элементы интерфейса, концепт-арт, а возможно, еще и сам все это анимирует. Например, Slavania – платформер в славянском сеттинге с элементами метроидвании и RPG, который вышел в 2024 году, разрабатывался силами всего трех человек. При этом Game Art Pioneers, в лице их издателя, взяла на себя полностью функционал по оперированию, который входит в блок на схеме выше.

Релиз игры «БУКИ» состоялся в 2023 году, и, в отличие от всех версий «Стража», студия АНО «ГРАММА» задействовала гораздо больше людей в процессе разработки. В работе над проектом было задействовано 2 продюсера, 2 программиста, 3 проектных менеджера, 12 гейм-дизайнеров, 14 художников, 2 человека, которые занимались оперированием, и 6 человек, которые были задействованы в локализации. Может показаться, что гейм-дизайнеров и проектников сильно больше, чем обычно бывает на проекте, но тут есть важный нюанс: механики игры сильно завязаны, во‐первых, на лингвистической составляющей, во‐вторых, на левел-дизайне, так как в игре большое количество уровней, и это не говоря о геймплейных механиках, которые тоже нельзя назвать простыми. Кроме того, к игре разрабатывается ряд DLC[85], над которыми работает по большей части отдельная команда.

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

«Битва за науку» стала мероприятием, финал которого нашей команде нужно было сделать буквально за две недели. Так как мероприятие делалось под тендер, что априори подразумевает плотную работу с документацией, нам понадобилось подключить 5 человек из GR-департамента, 3 специалистов из бухгалтерии и 2 – из юридического отдела. Всего в рамках работы над БЗН’21 было задействовано 83 человека, из которых 40 – волонтеры на площадке. Маркетингом и пиаром занималось 8 человек и 10 – проектным менеджментом, не считая руководителя проекта и программного продюсера.

«Битва за науку – 2021»

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

* * *

Самый верный способ узнать, как разрабатывают игры, – это читать много информации о том, что такое игровая разработка, и представлять, чем вообще является сама по себе индустрия интерактивных развлечений, что за исторический путь она уже успела пройти и что повидать на своем веку. На рынке есть немало книг об индустрии видеоигр – как в целом, так и об отдельных играх. «Кровь, пот и пиксели» Джейсона Шрайера – уже, можно сказать, классика. Еще есть солидная книга «Играй!» Тристана Донована. Для того чтобы понять, как создаются и работают игровые механики, имеет смысл прочитать «Гейм-дизайн. Как создать игру, в которую будут играть все» Джесси Шелла. Не будет лишним ознакомиться с «Game Over. Как Nintendo завоевала мир» Дэвида Шеффа и «Консольными войнами» Блейка Дж. Харриса – в них подробно описывается становление NES и Sega, на которых многие из поколения начала 1990‐х успели вырасти. Об истории индустрии есть также книги, которые выходили под моим авторством вместе с соавторми: «Наша игра» – об истории отечественной игровой индустрии, и «Игра и мир», которая охватывает историю зарождения видеоигр, начиная от первых видеоигр и заканчивая началом 2022 года.

Компании нередко выпускают арт-буки по играм, где описывается разработка концепции персонажей и окружения, в том числе с наглядным визуалом: «Мир игры The Last of Us», «Мир игры Alice Madness Returns», «Мир игры Uncharted 4: Путь Вора», «Мир трилогии Uncharted», «Мир “Ведьмака”», «Искусство Deus Ex Universe», «Мир игры DOOM» и так далее. В них наглядно показано, как идея может меняться в процессе вплоть до финальной реализации и на что разработчики делали упор, что хотели показать, на какие мелочи обращали пристальное внимание.

Еще можно посмотреть сериал High Score, а также фильмы Console Wars (по одной из вышеупомянутых книг) и Atari: Game Over об истории индустрии видеоигр, Indie Game: The Movie – о независимых разработчиках, и Free to Play – о киберспорте. Из художественных фильмов можно обратить внимание на Ready Player One – хорошее кино о виртуальной реальности с большим количеством отсылок на культуру видеоигр. Ну и, конечно, послушать ряд выпусков подкаста «Как делают игры» – одного из старейших подкастов о специфике игровой индустрии. Всё это станет отличным подспорьем, чтобы двигаться дальше и, что самое главное, понять для себя, в какую именно сторону.