К книге
Комьюнити-менеджмент и оперирование игрой. Две стороны одной медалиГлава 1 Основы создания и оперирования игры и где там появляется КМ. § 1. Что и кто делает при создании игры
13%
Глава 1 Основы создания и оперирования игры и где там появляется КМ. § 1. Что и кто делает при создании игры
6

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

Итак, как выглядит разработка игры в современной студии, условно, от 10 до 1000 человек? Потому что меньше 10 человек – это, скорее всего, совсем инди, и там могут быть любые чудеса по структуре, загрузке и условиям оплаты или ее отсутствия.

Итак, над всем проектом стоит гейм-директор или продюсер, который сводит воедино все планы и задачи, отвечает за общее ви́дение продукта – от внешнего вида до монетизации (причем как при первичной разработке, так и при оперировании игры после нее), а заодно и за планирование и соблюдение бюджета.

На следующей ступеньке стоит гейм-дизайнер или группа гейм-дизайнеров, отвечающих за то, как игра устроена с теоретической точки зрения, какие игровые механики в нее заложены, где и почему. У них много задач: от написания первичных гейм-дизайн-документов (ГДД), в которых они вместе с продюсером нащупывают тот самый путь, по которому игра будет строиться, развиваться и может стать успешной, и до непосредственной детализации и тюнинга всех функций в процессе разработки, а также улучшений и дополнений после. Гейм-дизайнеры также обязательно участвуют в понимании, а то и в настройке монетизации, потому что модель игры и модель зарабатывания неразрывно связаны.

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

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

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

Единого рецепта тут нет – и состав, и структура команды разработки зависят сугубо от сути продукта.

В любом случае рядом с программистами еще всегда есть QA – специалисты по тестированию игры. Их задача – поиск ошибок и составление отчетов (WTR), как ошибку воспроизвести. После чего оформленные ошибки уходят в исправление тем, кто их сделал. Без хорошего QA-отдела или хотя бы аутсорсера вам крышка. Разработка – процесс, при котором многочисленные ошибки будут в любом случае. И лучше пусть их найдут QA, чем игроки.

Дальше идет творческий блок. Неизбежно у любой игры есть свой отдел художников. Туда могут входить те, кто делает 3D-объекты (персонажей, вещи для них и элементы окружающего мира). Среди них: скульпторы и моделлеры; те, кто «раскрашивает» модели текстурами; риггеры, которые создают в них «скелеты» и структуры для движения; аниматоры, которые заставят их двигаться…

А могут быть и 2D-художники, которые рисуют внутриигровые картинки или плоские игровые объекты, а то и все то, что должны делать 3D-художники, если игра, собственно, сделана в формате 2D.

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

Наконец, художественный отдел активно участвует в создании графики для продвижения игры в разных видах.

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

В компании покрупнее еще будут «видосеры» – те, кто создает видео как для внутриигровых потребностей (кат-сцены[2], гайды), так и для маркетинга. Ведь без хороших трейлеров игру не продать.

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

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

Если в игре много диалогов, лучше иметь отдельного сценариста по диалогам, умеющего их писать хорошо. Киношники не дадут соврать: это отдельное и весьма ценное умение.

Кстати, помучившись с разными вариантами, для нового (на момент сдачи рукописи в печать в середине 2025 года) проекта «Студии СПН» под названием «Родина ждет: Угроза нации» я в итоге на базовый сценарий и ключевые диалоги взял как раз опытных сценаристов с телевидения. И не прогадал, хотя это очень недешевое удовольствие.

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

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

Естественно, есть еще масса специалистов непроизводственных функций: маркетологи, организаторы продаж, юристы, финансисты…

И комьюнити-менеджеры. Куда же их отнести: к маркетингу, производству, оперированию? Это немало зависит и от них самих. Во всех проектах складывается по-разному. Тем более что в маленьких студиях КМ может быть «универсальным солдатом» – вести соцсети, отвечать на отзывы, даже помогать с нарративом. А в крупных проектах это отдельная роль, которая собирает фидбэк и передает продюсеру или гейм-дизайнерам; защищает интересы игроков, но без вреда для бизнеса; координируется с маркетингом, но не становится «очередным каналом продаж».

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

Предыдущая главаГлава 6 из 48Следующая глава
Комьюнити-менеджмент и оперирование игрой. Две стороны одной медали — глава 6 — читать онлайн — GetRead